Let's learn to program

[Quinton]

I like C as a base since so many other languages use similar syntax, and if written properly can translate almost directly to many of those.  I don't know if it is the best to learn on, but no other language has been so important to my understanding of programming in general.  And if you can code in C, then when using something like Perl, PHP, or whatever, you can do some really slick things without much thought.

Total agreement here.  Also, C is close enough to the machine that if you learn it even moderately well, you're going to have a better understanding of what really happens under the hood when you use one of those fancy managed languagues.

All the programmers I know, and this is only limited to my experience not a scientific study, learned on their own.  College was because businesses like seeing a degree.  Most of the people who learned it in college that I knew couldn't code their way out of a paper bag.  (Likely because they only did what they could for assignments, not messing around on their own, and that's just not good enough to really learn programming.)  Actually I still see it in many of the CompSci grad students my boss gets.  Even the competant ones only care that the code compiles, not that it outputs the correct answer.

What I've seen a lot of (at least from when I was busy writing software for a living, while failing out of CompE in the mid 90s) was that the CS dept was pretty focused on teaching "Computer Science", not "Software Engineering."  The result being people graduating with no useful coding skills (ability to work effectively in small teams, understand revision control, have any idea how to debug, etc).  Knowing the theory, algorithm analysis, etc is great, but it's sad that often very little in the way of practical, applied software engineering skills are taught.  Many of the people with CS degrees I know who are good software engineers learned to code despite their CS program, not because of it.

I have worked with people who had never written a line of code until college and still managed to be really good at it by the time the graduated, so it's certainly not impossible.

[Miasma]

Yeah you have to be careful buying computer books because there are so many and most of them are awful, check reviews and sell rating on amazon etc. first.  If you open up a book and the font is 24pt and the pages are filled with 75% images just put it back down... If it has a cd that is often a black mark too but not too many do that anymore.

[Lantyssa]

I have worked with people who had never written a line of code until college and still managed to be really good at it by the time the graduated, so it's certainly not impossible.

Oh it's certainly possible to learn it in that timespan.  I just don't think it's (most of) the colleges teaching it.  As you say, they're about theory and not practical applications.  My only decent coding courses were taught by outside lecturers, and they were looked down upon by the faculty.

[Tarami]

As you say, they're about theory and not practical applications.  My only decent coding courses were taught by outside lecturers, and they were looked down upon by the faculty.

Tell me about it.

[Quinton]

Oh it's certainly possible to learn it in that timespan.  I just don't think it's (most of) the colleges teaching it.  As you say, they're about theory and not practical applications.  My only decent coding courses were taught by outside lecturers, and they were looked down upon by the faculty.

At UIUC, the student ACM chapter was a pretty awesome resource for working with people on fun projects and learning practical hands-on coding skills.  I wasted a ton of time on fun projects with ACM folks.  The EE dept also focused a bit more on small group projects and hands-on stuff.

These days it sounds like a lot of schools are moving to a java-only program for CS, which seems to produce people who often have trouble understanding lower level concepts or working outside of a fancy IDE. 

[raydeen]

The one thing I really miss these days are periodicals with a half-dozen or so programs in them that you can type in and run. Growing up, we had Compute! and a number of other more specificaly geared mags that offered tutorials, games, apps, etc. that you could learn from. Yes, we do have the internet today, but there's too much temptation for beginners to just copy and paste and get instant gratification. The best thing anyone can do when learning to code is type the thing in themselves. Mistakes will be made, but you become very intimate with the code and learn a lot as you're entering it. It gives you the chance to analyze and examine the code one line or block at a time and gain an understanding  from it that would be lost by just downloading and running it from a file. I remember being blown away by a game I typed in from Antic magazine. I ran it, thought it was pretty good, then realized I didn't remember typing in any of the standard Atari joystick routines. I went back through the listing and found that the author had collapsed what would have normally been 4 to 8 IF/THEN statements into two long logic statemens incrementing or decrementing the player x and y coords simply by checking what the value of the joystick return was. My head assploded and I still use his routine to this day as it's easy to implement in almost any language.

[Salamok]

When I was in school, the software/application types went the MIS/CIS route and the hardware/device driver types went CS.

Many of the people with CS degrees I know who are good software engineers learned to code despite their CS program, not because of it.

Not sure I would agree with this, I would go so far as to say that all good programmers acquire a ton of knowledge in addition to (including prior to and instead of) what a CS program has to offer.  One of the best sources of added knowledge I was exposed to during my time college was not the educators (internal and external) but the fellow students. 

Plus if left to your own devices you probably would not say gee I want to learn 5 languages in 2 years (or 7 to 8 in 4 years), no you aren't mastering them but the exposure is good and if you have to master them later the foundation will be there.  Not sure if anyone else does this but when I start a new language it is usually with a specific task in mind, this usually results in large holes in my knowledge of that language (in the areas that did not involve my project).  Even an introductory college course would fill in much of that missing knowledge (or at least let you know where the holes are).

[Yegolev]

Back to your original post, I'd really would love to learn some C#/.Net and would be down for a learning buddy. Yegolev are you still working on it when you have time?

Yes and no, because I have not have much time lately.  Also the looming threat of being jobless in October has been wearing away on any creativity I somehow have when not busy with other things (learning how to work with DB2 is on the list, yikes).  Also if I'm going to be released into the wild, I'm inclined to sharpen my existing korn/perl skills rather than get into Windows-land.  So, I'm still interested but my brain is full.  I am hoping that working with PowerShell will help keep the spark in my head, I just need to figure out something to do with it.

My primary problem has been and continues to be the alien object-oriented programming style.  Simply put, I don't know how to design a program before I write it.

[Murgos]

The main thing to get out of OO, IMO, is simplification through encapsulation.

If you can clean things up by encapsulating it and moving the details to somewhere behind the scenes then great.  If it just makes it more confusing to encapsulate it then don't.

[Yegolev]

I've started learning C# and made a contact program with the help of a book. Unfortunately, my program doesn't run because SQL Server 2008 Express is convoluted and ridiculously hard to update/install.

I believe this is the Head First C# book, and the first program is excessively flashy if you ask me.  I'm probably going to use that first one as a model for my intended recipe-storage program (one day) but it's not awesome at teaching you anything and kinda makes you when you try to use what you learned right away.  More to get you interested, I think.

If you are looking at books, I'd probably suggest that one and the two C# books by Jesse Liberty, but then again books seem to be as personal as languages.

The main thing to get out of OO, IMO, is simplification through encapsulation.

If you can clean things up by encapsulating it and moving the details to somewhere behind the scenes then great.  If it just makes it more confusing to encapsulate it then don't.

The thing that makes me angry is how I can encapsulate all day long using functions in ksh and perl, but when I start trying to do the same in C# it just gets all .  Most of my perl and ksh have terribly small main sections which are often just a getopts/var settings and series of function calls, but somehow what to have a function do comes easy while "making a Dog object" makes my brain baby kick.

I often have to bang my head on a particular wall before I get things to sink in (like when I first successfully learned ksh) so I'm sure I will get it.  Still pisses me off.

[Lantyssa]

The thing that makes me angry is how I can encapsulate all day long using functions in ksh and perl, but when I start trying to do the same in C# it just gets all .  Most of my perl and ksh have terribly small main sections which are often just a getopts/var settings and series of function calls, but somehow what to have a function do comes easy while "making a Dog object" makes my brain baby kick.

I have that problem, too.  I never could get C++ to click.  It seemed to complicate my thought process by turning my perfectly good working code into an abstract concept.

[Evil Elvis]

Here are some good links if understanding OO design is your main goal:

http://www.brpreiss.com/books/opus4/

http://www.dofactory.com/Patterns/Patterns.aspx

http://sourcemaking.com/design_patterns

[Murgos]

Usually, I would say that the design patterns stuff is just going to confuse and intimidate people who are just learning.  However, C# implements quite a few of the patterns so it might be worth a read through with the caveat that it's something to watch for but don't worry about until you've got WAY more experience under your belt.

Also, I think half the problem people have with OO design isn't the concept it's that every single example of what is good about OO is some super trivial inheritance and encapsulation example that just makes it look like extra work for little or no pay off.

"So, OO means one dog object can have blue eyes and spots and the other dog object can have brown eyes and white fur?"

[Yegolev]

My particular OO issues are somewhat documented in the Game Dev subforum, but in a nutshell I have a terribly difficult time deciding what needs to be an object.  One great example is if I make a card game, I know I'm going to want to have a Card object from which every particular card inherits methods and properties.  Beyond that, I can't seem to decide if I need only a Deck object which knows how to shuffle, deal, etc. or if I also need a Hand object and what does it need to do?  I'd really like to use this to learn how to properly set up objects instead of dump all my code into one object, UNFORTUNATELY I have realized that I only know how to write a program as a lump and refactor it at certain, later points.

[Rasix]

My particular OO issues are somewhat documented in the Game Dev subforum, but in a nutshell I have a terribly difficult time deciding what needs to be an object.  One great example is if I make a card game, I know I'm going to want to have a Card object from which every particular card inherits methods and properties.  Beyond that, I can't seem to decide if I need only a Deck object which knows how to shuffle, deal, etc. or if I also need a Hand object and what does it need to do?  I'd really like to use this to learn how to properly set up objects instead of dump all my code into one object, UNFORTUNATELY I have realized that I only know how to write a program as a lump and refactor it at certain, later points.

Nouns, dude, nouns.

Odd, I haven't programmed anything OO in years, and I can see the object breakdown and methods of that clear as day.  Then again, it's how I was taught. 

Getting thrown into C and assembly my third year was harsh.  At least relational databases still felt like home.

[Yegolev]

That's how I know it's a mental block on my part.  I'll get it one day.  I'm possibly thinking about it too hard.  To that end, I'll probably see what I can write while ignoring OO guidelines; I expect they will make themselves apparent at the proper time.

I also need to remember what my first shell scripts looked like and not get frustrated.  Man, I was doing some inelegant bullshit.

[Evil Elvis]

It might still be good to look over the GoF Patterns and descriptions.  You'll see a lot of classes named things like DatabasePool, ButtonFactory, CalendarSingleton, etc.  Learning just the purpose of those patterns will give you some good insight into how a class works.

For instance, think of how you would design a program to calculate the cost of a pizza.  You have small, med, large pizza, with cheese, with pepperoni, with meat, etc.  Then go read up on the Decorator pattern, and you'll realize how simple the program would have been if you had used it.

[Samwise]

A big part of "good" programming is breaking your code into a manageable number of comprehensible chunks.  OO is just one way to do that; one way to look at defining things as objects is as that it lets you bundle a certain chunk of code up so it can be looked at easily when you need to modify it and ignored the rest of the time.

[Tarami]

Hey folks, how's this going? Any progress?

[Yegolev]

To the contrary, I continue to learn about SAP on DB2, converting a OS image to use JFS2, the small wonders of NIM on AIX 6.1, and hacking an OS backup image to make it fit somewhere it would not normally fit.  I'm almost looking forward to losing my job.

[NiX]

To the contrary, I continue to learn about SAP on DB2, converting a OS image to use JFS2, the small wonders of NIM on AIX 6.1, and hacking an OS backup image to make it fit somewhere it would not normally fit.  I'm almost looking forward to losing my job.

No wonder you're so weird and creepy.

[naum]

To the contrary, I continue to learn about SAP on DB2, converting a OS image to use JFS2, the small wonders of NIM on AIX 6.1, and hacking an OS backup image to make it fit somewhere it would not normally fit.  I'm almost looking forward to losing my job.

SAP? AIX? DB2?

Wow, these platforms still serving live production…

I should not be surprised — the outfit that I spent 8 years at American Express still is running a system (the financial capture system that routes all charges to billing systems and accounts (service establishments) payable) that while rewritten in the 80s, dates further back than that — COBOL, IMS (an IBM mainframe hierarchical DBMS that predates DB2), etc.… Grandiose attempts have been conducted to re-engineer a "modern" solution, but to date, those have been giant money holes with little success… …of course, that department that had 200+ employees (probably 65% FTE and 35% "on-shore" consultants) now has like 1-2 employees with offshore teams in India and some non-immigrant visa workers housed in a body shop just down the road…

[Murgos]

Knowing what the errors are and how they are caused is often much more valuable than moving to something 'newer and better' and not knowing where the dangers lie.

[Yegolev]

SAP? AIX? DB2?

Wow, these platforms still serving live production…

These things are being actively developed and supported, if that's what you're commenting on.  Also the hardware it runs on.  I can't speak to the quality of that development and support in the case of SAP.   I'm hoping we can get to a point where we can put AIX 6.1 into production since it allows us to move running images from one frame to another.  Now that's fancy!

To your point, The Company has been trying to get rid of the mainframe for over ten years.  Unsuccessfully.  We do keep buying new ones, but replacing the apps is hard.  Same with Teradata.

Knowing what the errors are and how they are caused is often much more valuable than moving to something 'newer and better' and not knowing where the dangers lie.

Very true but also very boring.