OSNews

"10 Ph.D.'s You Should Have Today," or "10 Companies You Should be the CEO of."

ROFL!
My god .. you got me on laughing myself to tears !

"10 Ph.D.'s You Should Have Today," or "10 Companies You Should be the CEO of."

ROFL!

My god .. you got me on laughing myself to tears !

I'm glad I could make you laugh. Did this person must have having a writers block the day the wrote it.

You know...I was thinking the same thing. LOL!

I was like..."Yeah, I'll jump right on that. Thanks for the tip!"

If only it was that easy...

LOL

A Ph.D isn't something you can earn in a week. A programming language is something you can learn in a week. I remember learning TCL while preparing to give a tutorial on it

That said, this article is more like "5 languages you should learn right now". You've got {C# Java}, {Python Ruby}, {Javascript PHP}, Perl, and C. Once you know Java or C#, the other is trivial. The languages inside each set of brackets behave pretty much the same way, differing only slightly in syntax and APIs.

"A programming language is something you can learn in a week"

I actually learned C# in two days (having a good Java base), but doing good things and do them well in certain language, takes a lot of time; months, maybe years. I just have read my first applications written in C# and they are soo crappy....

A programming language is something you can learn in a week.

The correct statement is that you can learn the syntax in a week, but it takes years to master how to use the language. Then add years for every API you interface with (ie. just because you are a guru in Win32 API, it means jack shit if you move to Carbon). Add a decade before you become a master a handfull of API's. A decade per handful, and there are thousands of API's for a single language out there.

It is not uncommon to find C level kernel/driver guru's who do not know something simple like HTML. People who have spent years mastering HTML, yet do not know Java etc etc, you get my drift.

This article is a waste of time. It's like saying "10 languages you should speak". Yeah, right.

Most of the languages listed do not really differ in semantics enough to require learning that much more than the syntax. Skills transfer quite readily between similar languages. The same is true of APIs. Win32 and Carbon, for example, share a great number of similarities, to the extent that if you're a Win32 guru, you can probably program Carbon quite efficiently within a week or two.

In any case, it doesn't make sense from my point of view to spend all that much time mastering APIs. APIs are tremendously fluid, and if you spend years learning an API, the next big thing will come out by the time you're done. Given the limited time a programmer has available for learning, that time is almost always better spent mastering programming itself, instead of learning specific tools. Someone who has mastered network theory can learn what (usually small amount) of BSD sockets he needs to program a particular network app as he needs it. Meanwhile, a person who has spent an inordinate amount of time mastering the sockets API will probably never have to put all that knowledge to use at once, and will be hopeless when it comes time to actually design and implement complex networking algorithms.

The world is full of half-assed crap made by half-assed people that learn things half-assed and then spread their half-assed understandings to others. This "learn a programming language in a week" thing is really just an example of this. There is more conceptual effort involved in learning initial concepts than learning the particulars of various implementations (so learning Java from scratch might be considerably harder than the transition to C# which is mostly similar), but a superficial understanding of anything is just that and results in errors and lost productivity. It makes considerable sense to obtain a level of expertise in the APIs and languages that you will actually be using. It makes sense to obtain a level of expertise in whatever future APIs and languages that you will be using. This is because APIs do not change anywhere near as much as is implied by you here, and because you will be tasked with writing software that uses these APIs and your productivity is your task master's productivity. You will find the time to learn what you are doing or your software will suck hard. I also like how you've naturally associated expertise with APIs with not having any time to have gone to college and obtained theoretical appreciations for subjects. Raise your hand if you studied computer networks in class as an undergraduate.

Honestly attending a tutorial session by you when you're just reading someone else's tutorial is pretty useless. I could eliminate you and read the documentation myself--in the end I would learn more, because I am no longer limited by your understanding of the material. That is why InformIT and all of those Sams books are so utterly useless: you're obtaining the most basic, superficial information that can possibly be communicated to you by someone that probably only has half of an idea what he's even talking about to begin with and it shows in the work.

This "learn a programming language in a week" thing is really just an example of this... but a superficial understanding of anything is just that and results in errors and lost productivity.

The effort required to learn a language is the efford required to map from universal concepts of programming, to specific concepts within a language. Many commonly-used languages are so similar, that there is not more than a week worths of new content for those who know a similar language to begin with.

I assert that a Java programmer can program productively and efficiently in C# (and vice versa) after not more than a weeks worth of learning. There is simply not enough of a semantic barrier between the two languages to require a greater period of adaptation than that.

It makes considerable sense to obtain a level of expertise in the APIs and languages that you will actually be using. It makes sense to obtain a level of expertise in whatever future APIs and languages that you will be using.

Sure, if you're going to spend five years doing a project in C++, it makes sense to learn C++ to a high level of expertise. However, that's not what this article is talking about. It's talking about learning languages for the sake of putting things on your resume. It doesn't make sense mastering all these languages just in the hopes you may get a job using one of them.

This is because APIs do not change anywhere near as much as is implied by you here, and because you will be tasked with writing software that uses these APIs and your productivity is your task master's productivity.

Please. Look at the APIs listed in the article. Ruby on Rails. AJAX? Do you think these will still be in vogue four or five years from now? Microsoft ships a new API every few years. Just in the last decade and change, we've gone through MFC, ATL, WTL, iterations of .NET, and now WinFX. There is no point in intensely studying each of these APIs, just in the hopes that putting them on your resume will land you a job from a buzzword-infatuated PHB.

I also like how you've naturally associated expertise with APIs with not having any time to have gone to college and obtained theoretical appreciations for subjects.

I didn't say anything about college. What I'm talking about is good old opportunity cost. Any time you spend learning one thing is time you could've spent learning something else. My point is that you're a more productive asset if you spend months studying the theory, instead of spending that same time studying the nuances of the APIs.

Raise your hand if you studied computer networks in class as an undergraduate.

Actually, I write network code only because I know the API. I've never taken a network theory course in my life. However, I'm completely aware of the fact that finding a guy who knows BSD sockets is trivial, while finding a guy who can write a network formation algorithm that converges quickly is not. Moreover, I realize that the network theory PHD can easily learn enough BSD sockets to implement his algorithm, while it'd take me a long time to learn enough network theory to design the same algorithm.

Honestly attending a tutorial session by you when you're just reading someone else's tutorial is pretty useless.

You're assuming that both parties have an equal level of experience. A person with more experience gains more knowledge from the same tutorial, because he is able to connect it with his general knowledge of programming. The content of the tutorial consists of that augmented understanding of the material, not just the bare understanding a person with no experience would glean.

In practice, the level of expertise necessary is dependent on the nature of the tutorial. A decent programmer who'd never used Matlab could easily come in and TA a "Intro to Computing in Matlab" course with little study. In fact, that's precisely what happens in some cases, as Matlab classes are often administered by the CS department for engineering majors, but CS majors aren't required to take those classes.

Please. Look at the APIs listed in the article. Ruby on Rails. AJAX? Do you think these will still be in vogue four or five years from now?

Rails might be quite relevant to Rails developers in five years, but as far as I'm concerned Rails doesn't exist. AJAX isn't an API. Determining the fashion of web frameworks is a different matter.

Microsoft ships a new API every few years. Just in the last decade and change, we've gone through MFC, ATL, WTL, iterations of .NET, and now WinFX.

Prior to the push for .NET the largest change in the Windows API was the development of Win32 like 12 years ago. MFC is mostly wrapper classes around the Win16 and later Win32 APIs. The WTL is an unsupported template library that wraps a few of the same Win32 APIs that MFC does without providing the same document interface, serialization, and so forth. The domain of the ATL is entirely different. Microsoft adapts its APIs incrementally regularly. That is not some wild upheaval. In these cases you are essentially contending with the Win32 API. You see more upheaval in the transition from DDE -> OLE -> COM. The NET 3.0 push will be the real next big change, with so much of the current .NET framework being interfaces for currently extant Windows APIs.

There is no point in intensely studying each of these APIs, just in the hopes that putting them on your resume will land you a job from a buzzword-infatuated PHB.

You study them because having expertise is valuable. Anyone that does anything poorly so as to tantalize a HR drone is a fool.

My point is that you're a more productive asset if you spend months studying the theory, instead of spending that same time studying the nuances of the APIs.

This is hardly ever the case, since studying the theory outside of any basic requirements will have limited application to an employer in practice. Having the prerequisite theoretical understanding to obtain expertise in the framework will benefit more from experience using the framework than continued theoretical study for the purposes of producing usable code. It is not an either-or choice, but someone that is only steeped in theory will quickly earn the derision of his coworkers when they cannot do anything of use. The point is to learn both, because that is what is necessary to construct software that isn't garbage.

You're assuming that both parties have an equal level of experience

No, I'm assuming that anyone that professes to educate me on a topic who has less than or equal to seven days of casual experience with it is more useless to me than the documentation. I will invariably ask you questions that you do not know the answer to, and you will tell me things that are incorrect. I can avoid both problems by eliminating you from the equation. Anything that you can teach me with that experience is of marginal value, like an InformIT except from a Sams book.

Rails might be quite relevant to Rails developers in five years, but as far as I'm concerned Rails doesn't exist. AJAX isn't an API. Determining the fashion of web frameworks is a different matter.

Ah, so fashionable web frameworks are a different matter than fashionable APIs? So where does Java Beans, J2EE, etc, fit into all this? Beans were huge a few years ago, and you barely hear about them anymore.

MFC is mostly wrapper classes around the Win16 and later Win32 APIs.

That's an implementation detail. From a programmer's standpoint, MFC is a completely different API. And MFC experience is something PHBs used to ask for.

The WTL is an unsupported template library that wraps a few of the same Win32 APIs that MFC does without providing the same document interface, serialization, and so forth.

Again, implementation detail. WTL is a completely different API from Win32 or MFC. Each of the above APIs was created based on what was fashionable at the time. Win32 was created wen C was big, MFC was created when classic C++ was big, WTL was created to harness the new template-based C++, etc. Many of these are wrappers, but the interface provided to the programmer is very different, and just knowing Win32 isn't going to help you maintain a big MFC-based codebase.

This is hardly ever the case, since studying the theory outside of any basic requirements will have limited application to an employer in practice.

It depends on the job in question, but its a general consideration too. Most programmers I know, including myself much of the time, create ad-hoc solutions to problems. The very best programmers I know use theory to create closed-form solutions to problems, at least for the most important algorithms. The latter is far preferable, and its a skill that only comes from a good understanding of the theory.

Let me give you an example of what I mean. If you ask your average programmer to write a control loop for a thermostat, he'll likely write a little loop that turns on the AC when the temp is over the set-point, and turns on the heater when its under. If he's clever, he might realize that this algorithm is unstable, and include a dead-zone feature. A real engineer would approach it completely differently. He'd write out the differential equations involved, then use control theory to create a PID controller, choosing the proper gains based on the response characteristics he desires. He'd not only be able to tell you whether the algorithm is stable, but its frequency response, etc. This might not matter for a house thermostat, but it definitely does for something controlling a chemical reaction. Heck, it even matters for brewing coffee:

http://www.murphyslawonline.com/silvia/

No, I'm assuming that anyone that professes to educate me on a topic who has less than or equal to seven days of casual experience with it is more useless to me than the documentation.

We're not talking about you Back to my Matlab example, most engineering students, when you throw the Matlab manual at them, won't know what to do with it. Descriptions like "this is how Matlab does a loop" are lost of them, because they don't know what a loop is. That's why even someone who has a basic knowledge of programming can digest the material and present it in a much more understandable manner.

Yes...I have friends that can pick up a language very quickly... I am not that type. It took me forever to pick up PHP, and now trying to learn Ruby.

I just think it is funny that the article says "Right Now." As if you should start learning all 10 at once.

Picking up programming languages is usually pretty easy when you're dealing with similar conceptual models to languages that you already know. Learning them in a week is a gross overestimation of one's abilities or a testament to how much of that week is obviously being spent to learning the idiosyncracies and variations from that which you know. Especially with absurdly complicated languages like C++, anyone that says that they've learned the language in a week should prepare themselves for some serious quizzing by me. I know very many programming languages, and not one of them did I obtain any meaningful expertise in within one week's time. Recognizing similar constructs and picking up syntax is trivial, but actually knowing a language well is usually a bit more involved. It probably shouldn't take that long, though, unless it's one of those ridiculously complicated languages with so many corner cases you question the existence of justice in the world.

As of a few years back, it's now okay to end a sentence with a preposition, according to the Oxford English Dictionary. The preposition thing was based on Latin grammar, and modern English only borrows elements from Latin; a lot of its grammar still derives from Anglo-Saxon (like the little connector words), which has more in common with Icelandic than with Latin.

You can be the CEO of anything you want to be the CEO of.

No Object Pascal?

I don't see many job opportunities for Object Pascal. Most of the listings I see are for exactly the languages listed in the article.

No C++?

That is a good one to know but I don't think it is going to get any more popular at this point. There are a ton of better object oriented languages out there that don't have all the problems that C++ has today. I don't see many people starting projects with C++ anymore, mostly just maintenance.

Well im sure Qt/KDE developers won't aggree with you.

and btw, I make a living making programs with Delphi aka Object Pascal.

and btw, I make a living making programs with Delphi aka Object Pascal.

The problem with Delphi is that if Borland ever tanks or decides to end support for it, you're up shit creek without a paddle. What else are you going to do with your Pascal knowledge? Are there many jobs available for Freepascal programmers?

At the moment, I'm learning C#, and that (with the .NET framework underpinnings) is quite a task, so I'll be on this one for awhile. I'm sure I'll get around to the other 9 eventually

Ummm ever heard of lazarus?

Well im sure Qt/KDE developers won't aggree with you.

I can say with 100% certainty that I have never seen a job listing for "KDE developer". What I can say is that I have seen listings for C++ maintenance programmers, a lot of them. Maybe things are different where you live but here the list is perfectly sensible.

And I program an operating system kernel in Object Pascal. People may not want to admit a Pascal into Cori Celesti, but it's still a Real Language.

Delphi user here, too. Object Pascal is a brilliant learning language. No beginner should be without it. BASIC is a crappy learning language.

I agree with you on Basic, and would go so far to say it is a crappy language for anything.

I think Object Pascal is a good language to learn on, but I think other languages, like Python for instance, are better.

I don't see many people starting projects with C++ anymore

I wonder what the gaming industry would say about that ..

oh, haven't you heard? Quake 5 is going to be written in Java.

rofl, again !!!
that's exactly what I thought !!

It'd be funnier if the lead developer at Id hadn't been experimenting with Java for mobile games recently. Although since they sold the rights to Quake I doubt there will be a Quake 5...

Hell, any industry. C++ is still the language people start from, outside of the web-development or business applications community.

That C and C++ are the development languages of choice. Unless you're one of those mobile Java developers working on games for cell phones. I have absolutely no experience with that, however.

Hmm...What do you have to say for complex system software. Are they going to be written in Java,PHP, Perl or C#.

I used to work for a networking company who implemented all their network protocols in C++. I was also intern at research institute who had all their testbed code in C++.
I don't think C++ is loosing ground.


Tejas Kokje

Edited 2006-09-16 00:04

Someone mentioned C++? Quick, to the fudmobile!

No one has actually provided any proof to the contrary. From where I'm standing, and from what I've heard from friends living elsewhere, C++ jobs are easy to find but consist of mostly maintenance coding. Most new projects use Java. Posts about individual usage of C++ aren't an argument at all. Just look up programming jobs in Careerbuilder or check your local newspaper. We're talking job prospects here, not the popularity of the language itself, and personally I wouldn't want to end up like all those COBOL programmers.

yeah it wasn't too great.

fact is at least half of those are just the current buzz words in the industry. a year from now they'll be replaced with new buzz words and continue the vicious cycle.

and not that i really think their "job availabilities" number is accurate, but how could someone say you should run out and learn ruby/rails as fast as you can if there are only 210/54 jobs available compared do the 6,000+ C positions. sure ruby is getting alot of press lately because of rails, but "learn right now"? c'mon.

Stop living in the past, I guess.

No Objective-C?

No tcl, no jython, no lua ? Bad article!!!

Jython is invaluable for very rapid Java scripting.
TCL is the temple of scripting.
Lua for embedded scripting in C,C++.

ObjectiveC -> I think there is an OS called MacOSX.
FPC (Pascal) -> I think Delphi migrates to .$H1T

Not sure, but to be honest, and as far as I'm concerned, if C# is on the list, it only means that you should stop reading the article and do something better with your time ..

I did that ...

Agreed. I skimmed it over and saw C#, VB.Net, and Java. No need to keep reading in my opinion.

The article was talking about job availability, and Java is a very popular language.

Java: 14,408
C: 6,164
AJAX + Javascript: 5,512
C#: 5,111
Perl: 4,810
VB.Net: 2,090
PHP: 1,152
Python: 811
Ruby+Rails: 264

Yeah, why the hell is C# on the list?!





Oh, yeah, because knowing it makes you much more attractive to a large number of employers. That is pretty much the point of the list, not which languages are cooler, or which languages YOU like.

Mono isn't a language, it's a framework...you would still need to learn C#, VB, python, etc...but yeah Mono is a great way to learn the basics of the .NET framework.

dynamic languages are terrible for aplications that are performance dependable, games are such, and by the way, gaming industry at the moment, profits more that films industry

First of all, Java is far from a "dynamic" language. Secondly, there's no reason a "dynamic" language can't be fast, see: common lisp.

Edited 2006-09-15 23:58

Common Lisp will usually get you 80-90% the performance of C, but game developers want that last 10-20%. On the other hand, these days, the GPU does so much of the work, that it might not even make a difference.

In general game developers desire predictability and the ability to optimize critical sections. This motivated Naughty Dog's design choices with respect to GOAL, which any true Lisp zealot will drag out for all to see that Lisp can be used to develop games that people will actually play. However the one thing not even writing your own Lisp dialect will do is provide you with programmers that are experienced at writing games in Lisp. You have to see some serious productivity gains from the language to makeup training developers, limiting your dev tools, and possibly incurring all of the R&D expenses.

In non-critical areas it isn't entirely uncommon to see various DSLs or general purpose scripting languages used in games that are many times slower than any Common Lisp compiler's output.

That's by default. It's not impossible to create a compiler for a dynamically typed language that can be completely overrided by the programmer at a cost of flexibility. Basically, C/C++ force you to care about performance from the start, whereas dynamic languages default to flexibility but can be overrided. The only reason you don't see a lot of the latter is that programmers tend to be a lazy lot, and apparently compiler writers don't mind shoving complexity onto the user (programmer) rather than doing it themselves.

Why not Q5 in Java?

http://www.bytonic.de/html/jake2.html

This is far from insanely slow, it's just showing decent performance, I tried it out myself.

Microsoft even wants to replace DirectX with a managed environment.

I think that you are mischaracterizing Microsoft's intentions with respect to DirectX and .NET. MDX and XNA do not replace DirectX--they are essentially wrappers for it. Those wrappers are not at least currently intended to replace the development of applications with C++.

I wholeheartedly agree. I think a good programmer is one who seeks to broaden his views, learn new ways of solving problems, new perspectives. Learning languages that vary greatly in syntax and "way of thinking" will make a programmer improve even if she/he never uses those anymore after having learned them. Curiosity is very important there, I think.

Learning a wide range of languages that all look and work alike without needing to is probably a waste of time. I think the article is more about "Languages you should know to get a job right now" rather than "Languages you should learn". In any case, most of those can't really work as "bonus" to add to a resume.

Edited 2006-09-16 10:52

The problem with learning COBOL is you also need to learn the mainframe environment (and JCLs if you are on an IBM mainframe). To get good with them takes years, AND you have to have access to a mainframe environment.

I worked as a consultant for Merrill Lynch for four years, with a large group of mainframe programmers (COBOL and JCLs on an IBM mainframe) (I was on of the few "PC" programmers on the floor), and I can say with certainty that you won't pick up COBOL, JCLs OR the mainframe environment in a week. Or a month. Or a year. That is going to take a lot of time and effort.

Probably the best bet would be to go to a community (junior) college that still offers mainframe courses. At least then you'd have a shot.

Nice list, though mine would be slightly shorter.

Python
Perl
C
PHP
XML

In other words focus more time learning Operating system concepts then many languages

Edited 2006-09-16 03:20

Focus more at being able to make things, and make them well--preferably in topic areas where people are willing to exchange money for your work. Ignore random websites professing to tell you how to succeed with formulaic gimmicks.

Here is the way I'd do it, in chronological order:

1) Scheme or ML. Start pure, don't get the important CS concepts mixed up with hardware-stuff better left to the computer enginering guys.

2) Lisp. Not from the functional angle, which would've been introduced adequately in the previous class, but from a "practical programming" angle. Even though Common Lisp is not commonly used, tremendous amounts of real world things (design patterns, OOP, design of APIs, etc) can be expressed very conveniently in Lisp.

3) Smalltalk or Java or C# (in that order of preference). For OO programming, etc.

4) C or C++. I put this here because learning C/C++ will ruin somebody who doesn't know Lisp, Scheme, or ML first. A computer scientist should be thinking in terms of functions, values, and types, not pointers, blocks of memory, and word sizes. I always wish I'd started with something like Scheme first, because to this day I have to fight the urge to think about pointers and blocks of memory.

I'd also throw in some special topics for a vector programming language (eg: APL), a logic programming language (eg: PROLOG), and a concurrent programming language (eg: ERLANG).

Thats not really true anymore. These days, "embedded" systems can be quite powerful. I worked on some code that targetted the JTRS spec for military radios. It had to be fully portable, using an OS-agnostic and language-agnostic CORBA-based framework. We're talking about everything down to handheld radios here, running a full CORBA ORB. No ASM in there!

Most kernels these days have minute amounts of ASM hidden behind a few macros, and that doesn't require the ability to program in ASM so much as it requires a rudimentary understanding of it, and the ability to use a manual.

As for games --- even as of Quake III, the assembly code was limited to a few functions, and only then because they needed to leverage MMX and SSE. These days, the GPU does so much work, they may not have even that.

Edited 2006-09-16 04:58

VB is still popular and so it "made the cut." If you should be surprised by something, it should probably be the presence of Ruby and maybe Python. Further the version of VB selected is the .NET incarnation, which has the same overhead as C#.

Come to think of it, I think UnrealEd was orginally written in VB. Better load up your boomstick and take out Epic for its previous crimes against humanity.

And people who are ignorant about languages should be shot too.