[cmeyer42]

After reading this thread since its beginning, I don't think this question has been asked or answered, and I'm sorry if it has been.

So, after a lot of "mental problems" about this topic, I am here to ask the "crew": Is it better to know one language "inside and out" as much as possible before learning other languages (Mastery of One), or is it OK or better to have a "working" knowledge of one language and dabble with others (jack of all trades yet a master of none)? This is a concept, idea, phobia, etc. that has been one of my demons for a long time, and I need to "kill it" once and for all!!
Without explaning my skill level, (i have no idea what my skill level is anyway!), I hope others will be able to help answer this nagging question of mine.

"And I thank you for your support" - (from some old wine commercial)

[ghoti]

Definitely go for depth first. You need to understand the concepts behind the language, why things are done a certain way, etc. These things will not differ that much between languages, and will make it much easier to pick up another one should the need arise. Most languages really only differ in details, and of course the libraries and functions you have available (especially in python/perl/PHP, Java, etc.), but the underlying concepts are all the same. In the end, it all boils down to a handful operations the CPU can do (arithmetic, comparison, conditional branches).

[chucker]

It's a good idea to understand the basics of multiple languages, because:
1) that way, you will mostly differentiate them by their syntax
2) you will end up with the ability to make an informed choice over what you prefer.

For example, you may prefer Smalltalk-esque object messaging over the more prevalent C++ style — or perhaps not!

You will also find that some languages aren't well-suited for certain tasks, but greatly suited for others. You probably wouldn't use PHP to build an entire application, even though you could; the idea of Gtk+ for PHP strikes me as completely insane. Likewise, Objective-C is a far too complex language for something as simple as a scheduled script for cron/launchd/etc. You could, indeed, build an Objective-C console tool, but you probably ought not. Use a shell language for that.

Finally, low-level languages and high-level ones both have their places, and sometimes, you even want to mix them in one single app. Use low-level where efficiency and/or direct hardware access is key, use high-level during user interaction, and use a scripting language to give the user extensibility means

[Enki]

Jack of all trades. Once you learn one imperative language to a basically proficient level you have those same concepts for all the others. The variations in how the other languages handle situations allows you to learn the concepts deeper though. e.g. Java object technology, C++ objects & Obj-C objects are all basically similar but differently implemented ways to tackle problems from the same class of imperative languages.

Different language types such as declaratives (HTML/XML...) or functional languages (LISP/Prolog/APL...) are radically different and should be tackled a little later [for a programmer, which is a different order than a web dev would attack the issue]. But understanding the basics of these can give you a whole new outlook on problem solving without having to become an expert in any of them.

Eventually recognizing the differences can help you choose a best tool for the job later. Something no "One Trick Pony" could ever hope to do.

[billybobsky]

Does this have anything to do with Bruce Campbell?

[bassplayinMacFiend]

Another thing to spend time on is program design. Can you flowchart what you want to accomplish? If you can't flowchart it, you can't code it.

Different languages have different syntaxes but the basic functionality; if-then-else, for, do-while, etc. will operate the same in every language.

For example, in Objective-C you might code [someObject getData]. In Java you would write the same function as someObject.getData().

[chucker]

Yep, that's what I meant by

For example, you may prefer Smalltalk-esque object messaging over the more prevalent C++ style —or perhaps not!

It's

[object messageWithArgument:argument1 andAnotherArgument:argument2];vs.object.message(argument1, argument2);

The first gives you a very good overview of what means what. ("What's that fifth argument again?") The second, however, is more concise and more common. It's a matter of preference, nothing else.

[Enki]

Originally Posted by bassplayinMacFiend Another thing to spend time on is program design. Can you flowchart what you want to accomplish? If you can't flowchart it, you can't code it. Different languages have different syntaxes but the basic functionality; if-then-else, for, do-while, etc. will operate the same in every language. For example, in Objective-C you might code [someObject getData]. In Java you would write the same function as someObject.getData().

You obviously haven't programmed in LISP or Prolog, They don't even have those constructs.

[bassplayinMacFiend]

Oh noes, I haven't programmed LISP or Prolog!

[Kickaha]

From my days teaching undergrad CS programming language classes...

Learn the theory. The rest is just syntax.

Sounds trite, I know, but it's true - my objective was that my students could walk out into the real world and pick up any language they wanted to in less than three days. You should be able to as well, at least as a goal.

Every language group has its strengths and weaknesses, and every language within each group has its own set of same. Learn the ideas behind the major groups, then expose yourself to a few syntaxes.

You'll find that the mastery of the principles is much more important than the mastery of the languages. Choosing the right language for a job is perhaps the most important decision an architect can make - it influences *everything* else from that point on. At the other end of the spectrum, being able to work in most any language on short notice makes you valuable to any good employer.

The example projects I used with my students was that they were to do the same simple task in multiple languages, and see what portions of the task were easier in which languages. Specifically, 'search a file for a string'. Simple, no? Okay, now do it in C, C++, ML, Prolog, and Lisp. It becomes really interesting to compare the solutions.

[scratt]

I am really just echoing what other great minds () have already said here..

Once you have learnt the basic principals of programming, looping, conditions and so on, you find that every language has them.. It's just learning the dialect of the one you are using. As Kick says.. It's all in the syntax.. And that is where most people get caught out when trying a new language.. Not in the logic. As logic is logic is logic.

I have to say I am still far more comfortable with Assembly Language.. Again, the great thing is that once you have learnt one Assembly Language, they are all pretty similar in concept.. Just learn the new registers, and the quirky stuff and away you go on a new chip.. But assembly, high level, and whatever else they dream up all still have loops, variables / registers, and conditions...

[Banana]

Originally Posted by Kickaha Learn the theory. The rest is just syntax.

Playing devil's advocate here-

Would you say this applies even if they were learning VB? E.g., a guy who understand theory but only VB will pick up C or whatever in no time?

[Kickaha]

Off the cuff, I'd say sure.

FWIW, my first program I ever wrote in Python was my dissertation project, about 25kLOC. Took me a couple days to navigate the syntax (mostly that damnedable whitespace = semantic nesting) and language primitives until I was comfy with it, and off I went. Of course, I was always learning more from the vast libraries, but I could write acceptably in it in a week (and I'm picky), and proficiently in it in less than a month (as in I was answering other people's questions about it, and sharing design and architecture tips). 95% of it was stuff I already was familiar with, just in slightly different clothing.

The important thing though is that this hypothetical programmer *know the theory*. If they know VB, and have kinda heard of the theory, then every language will be a from-scratch affair.

[Banana]

I'm sorry- I tripped over the "off the cuff" remark.

You meant it as unprepared because VB doesn't "show" the theory that well or did you mean that assuming this hypothecial programmers does understand the theory, he'll fly off (e.g. off the cuff?)

[chucker]

Originally Posted by Banana I'm sorry- I tripped over the "off the cuff" remark. You meant it as unprepared because VB doesn't "show" the theory that well or did you mean that assuming this hypothecial programmers does understand the theory, he'll fly off (e.g. off the cuff?)

Er, I think Kickaha is just saying that he has no personal experience with this particular scenario (learning any language when previously only having used VB).

[Kickaha]

What he said.

"Off the cuff..." = "Off hand..." = "Without having any particular experience with that particular scenario, my educated guess would be..."

Put it this way... I'm working on a project right now with some C-heads. Serious C-heads. I was told originally that I could, providing my module had a nice clean C interface, do my work behind the scenes in C++, so I did. They. Freaked. Requested that I (get this) rewrite about three months of work in C. Well, I chose C++ for a *reason*, and those reasons still stood - so I implemented a C++ runtime in C (really, it's not that hard once you think it through), and these crazy cats are much happier. It doubled the line count, it looks like grotty hell to me, but they think it's better than the clean, simple, C++ code I had before. *shrug* Bottom line though - by understanding the theory behind both the OO and procedural realms, I was able to emulate one in the other pretty quickly... like less than two weeks.

What's the point? Flexibility. You can shuttle around between languages or even programming eras at ease. That lets you talk in whatever language you need to at the time to communicate your intent to the compiler, and other developers, to get the job done most efficiently. And that's really all that software engineering boils down to: communication of intent.

[thuh Freak]

curious: if u had a pure c interface, what was those guys problem?

[Kickaha]

Personal preference. *shrug* Their code base, I play by their rules.

(They originally had very good reasons for choosing C, but as we talked, I ran through each reason in turn, and it became evident that they were no longer relevant. In the end, it was just their personal preference to hanging on to what they know, and being a bit worried about being asked at some future point to maintain code they didn't fully grok. Can't blame them too much on the front, but it was still annoying.)

[cmeyer42]

Wow!! This is great, thank you all for the replies! This shows me that I haven't "waisted" my time in learning a little in this language and a little in that language, and not spending that time just learning one language. I knew that design/theory was actually more important than what language is used or learned, but I was nervous that because I haven't learned one language REALLY well, that it was going to bite me in the ass one of these days! (I am currently studying C++ again and going to use that as my "one language" ).

After reading Kickaha's last post, (or should it be DR. Kickaha?) I'm glad that I at least have a desire to learn more than one language. I think that being to "stuck" on one language without the interest in learning other languages really limits ones ability. Granted, years of experience can't be learned in an instant, but that's what comments are for! So, I guess my ADHD isn't so bad after all!

Now at the risk of being a "bad toady" and not starting another thread, what about design methodologies? UML, OMT, Booch, Top-Down, Bottom-Up, (whatever else is out there)? Any thoughts, experiences, horror stories, hate stories, love stories on this? (Moderator: I will start another thread and repost this part if asked to).

[Enki]

The most important aspect of the design process is actually having one! It's ridiculous how little though design really gets. And I don't count going through the motions part-way drawing sketchy UML diagrams as design. That's usually just monkeywork drawing pictures, not putting thought into an architecture and/or algorithms.