This has become even more evident with .NET; they have 10 years of experience and in .NET, most of them are still at beginning level – four years after .NET was launched. Books on this technology are so shallow that if .NET were an ocean, you could cross it without getting your knees wet. They simply don’t get OOP because they’re worried about where to drag that handy-dandy control. VB .NET code is much too often plagued by inefficiency because the guy behind the keyboard didn’t get the changes. How many of them still code the way they did in previous version? Almost all of them. Oh, yes, and using the VisualBasic namespace is another thing they shouldn’t do – but who cares? It’s fast, and the guy won’t even care whether code is good or not.

Learning Java? Why not? It’s another dead programming language that nobody will pick up in a couple of years. It’s the same thing I said about COBOL, and everybody laughed at me at that time. Now, does anybody still program in COBOL? Yes, a handful of dinosaurs still do.

As RobC said, it doesn’t really matter which language you start with. What does matter is the thinking behind all this. They’re supposed to solve problems, so it’s about time they understood this. And if PHP solves a problem, won, then by all means use it. It needs different abilities than making applications, but it fits the needs, right? And when I see truly well-written code, I actually don’t care what language it was written in. Recently, some people from VB have understood that, but this is a minority. I would wish they could slow down and think for a moment or two, but I have reason to doubt that this will ever happen.

Just about any endeavour that is worth achieving a degree of competency in requires discipline, work and structured learning. Be it golf, playing the piano or writing poetry – there are skills to acquire and perfect (through practice). Bad habits, learned early on are an impediment to the long-term goal.

GB

gbyrne D0t xit on google mail

After that I started picking up some perl for quick and dirty scrips. As with Visual Basic I just learned how to write a script, but not understanding how it’s working.

I find this troubling because I fully support Open-Source, but see problems if I continue with this mindset. One obvious problem is I would just be definitely be re-inventing the wheel as without a proper in depth understanding of the underlying components, I’m stifled not in my creativity but actually applying it.

Anyway I’m at a point where I want to start from scratch, and if I don’t understand something, instead of skipping it, I’ll ask someone(pride’s a doozy). I want to ultimately create powerful applications that could be used on multiple platforms, database-driven, maybe even support some low-level type of enterprise base.

With this, what would you suggest. I really _want_ to learn C#, but I’m worried about it’s limits. The code that I’d read is almost somewhat intuitive. It’s also very secure from what I read about exception handling and garbage collection. What does everyone think, and what would be the pros and cons on learning C# as my primary language?

Thanks
JP

I would say that from my point of view, having gone through this over the past 6+ years, that scripting languages are a good place to start.

My reasoning is slightly different. Scripting languages are fast. You see results of your effort in near immediacy. And they are fun. Including these added enjoyment incentives early in the process of learning to become a developer was a boon.

Then the neophyte can travel down the well, to interpretted languages such as Java or C# and finally (if they choose too) move on to C++ or even C.

Like you say this whole process is a marathon, not a sprint. I agree that bad habits can be learned if scripting languages are your first exposure, but I would argue that is part of the learning process (at least for a self taught programmer). They will need to be unlearned, but even that process can help in understanding the why’s and wherefors.

My last point and really one of the most important is READ. Read, read, read. And when you’ve finished the latest book on structure, pick up the next on design patterns, and when you finished that, pick up one on extreme programming, after that, how about one on hardware or compilers. And when you finish those ask your freinds what books they recomend.

Two great books that really helped me along the way:
Code Complete – McConnel
The Object-Oriented Thought Process – Matt Weisfeld, Bill McCarty

You’ll note that “useful” and “easy to learn” weren’t actually criteria that I was applying.

Learning the craft of programming is a marathon, not a sprint. In my experience, most scripting languages are indeed useful and easy to learn, and if they are the first exposure a new programmer has will teach her bad habits that may take years to unlearn.

Functional languages also encourage developers to abstract data in powerful ways that scripting language, by their very “get it done NOW” nature, don’t.

Anyone who learns a functional language first will have no trouble learning any scripting language there is. Some people who learn scripting languages first -may- have a harder time going to a functional language.

I had to spend years unlearning the damage done to me by Applesoft basic. Somewhere out there today is someone who someday will be a great programmer, after he unlearns his Tcl.

BASIC was horrible. Inelegant, messy programs, with unclear structures. I still hate it today, and loathe Visual Basic. I keep as far away of it as I can

When we got our first PC, I started learning Pascal. At the time, that was a very useful language for learning proper imperative programming. I can still recommend it, although, just as Modula-2 and Modula-3 it is no longer mainstream enough to be used in any serious work. One could also take a look at Delphi, although I’m not too fond of that.

Java is an excellent choice at this time and place, although I’m in doubt whether you want to dump the full weight of OO on a learning programmer.

Personally, I like Java best for its clean, well defined architecture. But for a living, I mostly write C and C++. Where power of expression is concerned, I like C++ best, but would never ever recommend it to a learning programmer.

Finally: if you’re interested in functional languages, take a look at Miranda (or it’s free cousin Amanda).

Does java have a console interface? Forcing students to learn such a confusing architecture like java (events, and all that inheritence, I mean) would be awful.

A scripting language seems like the place to start, because it’s forgiving and better designed for quick problem solving (as opposed to efficient maybe), which gives newbies a better environment to learn to think about how they’ll solve the problem, not why they are segfaulting. Eg. Some of my peers early in college just never got “it,” and couldn’t solve the simplest of problems – I’m not saying C++ was the whole problem for them, but a simpler language might have helped frusterate less and afford them more time to figure out the logic required of them. After a scripting language the newbie can study pointers, linked lists, and more complicated stuff with any language they want (probably something popular and useful like C++/Java).

I like perl and C++ myself. However, I’m finding the perl syntax for classes to be a little strange.

I don’t agree with Rolf on learning english. A second language is hard! One only needs to understand the alphabet and pronunciation, since I expect there are many resources for programming in most popular natural languages (but Japanese especially).

It doesn’t really matter which language you start with. In reality every new programmer should start with Analysis and Design (logic) for the problem they are trying to solve. Once a programmer (he or she) has defined the problem, only then can it be solved by programming. This is why so many programmers fail, they start from the top down instead of drawing the blueprint first. As a software engineer and home builder, every day I am reminded how planning can save effort, time and money at a later date.