Fog Creek Software
Discussion Board




Have you evaluated each Programming Languages ?

Have you evaluated each Programming Languages ?

C++, C+, Pascal, Visual Basic, SmallTalk, Perl, Python, Ruby, Delphi, Snobol, Prolog, Java, Lisp

To know which one is best suited for a particular job ...

I'm asking this question because since a couple of years
I've been stuck with the same programming language and I've a hard time to push myself hard enough to learn what "new tools" are available to me, ie : Perl, Python, C# ...

Could you guys give me some tips & advices on how you check out the possibilites of other languages (knewing that you could only master it after a few years under your belt)

Newbie
Monday, April 12, 2004

Learn enough to write simple programs (a good choice could be a simple "text adventure" game, a small web server, a tetris game, a backup utility, or whatever else strikes your fancy).

That should take a couple of days if you've got experience (divide by 4 if it's Python, multiply by 4 if Perl, multiply by 10 if APL -- but generally, that's what it should take).

At this point, you're definitely not qualified to evaluate if a language is good for a given job - but you are prepared to start reading code in that language -- and that's what you SHOULD do. Find an interesting project (or 10, or 20) that comes with Source code. Make sure it's a real project and not a "toy" or "demonstration" project. Then read it. Lather, rinse, repeat. [ http://sourceforge.net ] is a good place to find software projects with source, as is [ http://freshmeat.net ]

Yep, this does take a _lot_ of time. but it's well worth it. Also, you'll find that there are essentially only 3-4 paradigms you'll need to grok before everything is just variations on a theme.

Make sure your list includes Python and Lisp (or Scheme).

Ori Berger
Monday, April 12, 2004

The way to check capabilities of a language is to look at what experienced people have done in it. Dabbling with something for a few weeks won't show you much, unless the language is extremely simple, in which case it won't teach you anything. 

Sometimes you need to learn to think in terms of a language to unleash its full power, but it well worths it. Perl and Lisp are good examples.

Egor
Monday, April 12, 2004

Agree with Egor.
Find out what the others think about a particular language, read articles, how they  rate it , where and when use it - then make a decision.

LI
Monday, April 12, 2004

Real programmers program in machine language.

A Real Programmer
Monday, April 12, 2004

"Real programmers program in machine language"

On most modern processors machine language is, hilariously, a "high level interpreted language" that is converted to microcode. Thus, today real programmers program in microcode, where we don't all of those high level instructions.

Dennis Forbes
Monday, April 12, 2004

"Thus, today real programmers program in microcode, where we don't all of those high level instructions. "

Er, ok, then...

Real programmers program in microcode.

Fo' shizzle!

A Real Programmer
Monday, April 12, 2004

Ori, while agreeing with most of what you said, I do have to point out that your comment about Perl vs Python smacks a bit of trolling.. *grin*
Disclaimer: I know both languages reasonably well, but I tend to prefer Perl

I'd probably suggest that you group the languages together.. I'd think it easier to learn Ruby, Perl and Python one after another. I'd also class Pascal as being before Delphi (syntax is similar, so it makes sense to learn those two together). Prolog is completely different from ALL the other languages in this list, so I'd probably have that somewhere either in the beginning or the end of your list of "things to learn".

It might also make some sense to not try to do ALL of them at once. I am gratified to see that I know a fair bit about most of those languages in your list; but I learnt them for differing reasons over a number of years..

For example:  I learnt C++ because at one point, it was the only decent programming language for a C programmer to go into.. (this was before Java was popular).

I learnt Prolog solely because my final year of undergraduate studies required it. It made me a better programmer, but I haven't used it since. I learnt Lisp as a natural consequence to learning Prolog, because I wanted to explore functional programming after I figured out how Prolog worked.

I learnt Perl because I wanted to do simple text processing tasks, I learnt Python because ... Perl's object oriented concepts were rather clunky, IMHO. I learnt Ruby because I was curious to see why people kept saying it was better than Perl :)

and so on.. the point here is: learn each language for a reason, instead of just as a "language I must know". It doesn't matter if the reason is fairly trivial, but if you have a specific job in mind, learning the language is simpler than if you just wanted to "find all the strengths and weaknesses of a language". After the first few languages, you will find (I think) that it's all about syntax and idiom. Most concepts translate fairly well from one language to another.. at a high level. Keep those high level concepts in mind and you will be able to use a language pretty quickly (it took me just hours to figure out what I needed to do in Tcl, for instance).

deja vu
Monday, April 12, 2004

I stopped evaluating new programming languges when the time I needed to learn a new language was longer than the time saved by using this new language.

Ignore my ignorance
Monday, April 12, 2004

> Have you evaluated each Programming Languages ?

I haven't evaluated them all; I've been learning them 'as needed'.

> Could you guys give me some tips & advices on how you check out the possibilites of other languages (knewing that you could only master it after a few years under your belt)

I learned Intel's x86 assembly a long time ago: I wanted to write a real-time game for my PC, BASIC wasn't fast enough, and I couldn't afford to buy software (e.g. a compiler). So I learned to write assembly that I could pipe into "debug.com" ... then I wrote an assembler in BASIC ... then I wrote an assembler in assembler.

When unemployed, a recruiter told me he couldn't place me in a programming job unless I knew "C": so I learned C (by volunteering somewhere to write a program using C). In a previous decade I had used a HLL similar to C to write some telecom switch software, so I wasn't entirely unfamiliar with the concepts.

I later used assembly commercially to write a DOS TSR, and used C commercially for the GUI portion of a Windows 3.1 program.

Later I learned C++, because by the time we ported it to NT the C program was getting large and difficult to maintain. C++ was good enough for me for many years, given that I was writing a Win32 real-time server application and device drivers (so not much GUI ... I used MFC when I needed to write GUI software, rather than learn VB).

I've since started to use C#, and found it almost trivially easy to learn after C++ (it took about 10 days, rather than "a few years", to learn it).

I'm not writing web-based applications, and I work with a team of other programmers, which I think reduces the number of languages I must choose between.

Christopher Wells
Monday, April 12, 2004

> assembler in assembler
should be "an assembler in assembly".

Christopher Wells
Monday, April 12, 2004

Egor: I agree with your statement, but must also add that most languages _are_ extremely simple, if you have a solid basis.

Perl, Lisp[/Dylan/Pliant], APL[/K/J], and Prolog are the exceptions; And perl is mostly there because of the odd shorthand syntax perl programmers like to abuse so much[1] - whereas the others are in the list because of a unique paradigm. Perhaps SNOBOL and Harlequin should be in that list too - I'm not versed enough to make a comment.

Almost all other 200 or so languages are not fundamentally different, and mainly offer variations on a theme (automated memory management y/n? access control on records y/n? dynamic/static typing? strong/weak typing? etc.)

Which is not to say they are equally bad (or equally good). In my opinion, Python excels at almost every metric except speed and popularity - and both are continuosuly improving with a bright future (if you haven't Psyco'd your Python installation, you should!). And popularity is much less important metric than most people make it.

Ori Berger
Monday, April 12, 2004

P.S: Regarding what experienced people has done with it - this statement should be better qualified.

Arthur Whitney and Stevan Apter (both experienced with K) have done with K what many experienced software people consider outright impossible. This does not necessarily mean that mere mortals can achieve similar results.

Ori Berger
Monday, April 12, 2004

Now that you mentioned Psyco I had to look it up...

http://psyco.sourceforge.net/

Whoa! Python runs 2-100x times faster? The JIT compiler automatically creates different code for different types, from the same Python routine? Is that true and actually implemented yet?

Chris Nahr
Tuesday, April 13, 2004

It's real and it does work. Give it a try. My experience is that on the average I'm on the x4 range (which is already impressive). You get the x100 improvement mostly on number crunching and type-predictable-ints-and-floats stuff.

And if you like Python and Psyco doesn't work well enough for you, Pyrex or IronPython might.

Ori Berger
Tuesday, April 13, 2004

Pyrex and IronPython are a bit more work to use, though, especially since IronPython is still an "unreleased research prototype".

Pyrex is primarily intended for interfacing with C code, although it can also be used as a way to write C code using an almost-Python syntax.

Psyco is probably the most practical speedup option today, for x86 architecture machines (the only kind of systems it currently supports).  But the author has moved on to working on PyPy, which he believes can ultimately be made to work even faster than Psyco.

I would expect great things in the future from both IronPython and PyPy.  PyPy has more people working on it, and it already does various kinds of interesting type inference and compilation of regular Python programs to C (via Pyrex).  But PyPy is also very much under development, just like IronPython.

There are other research prototype Python compilers out there, like Starkiller, but I think Starkiller's fundamental approach has some issues that will keep it from properly generalizing to the full Python language.

There's also the whole Parrot thing (the Perl 6 interpreter).  Specifically, one of the guys working on the Parrot engine has made a bet with GvR (Python's designer) that Parrot will run a Python benchmark faster than the then-current version of Python.  It's going to be interesting to watch, including the pie-in-the-face at ten paces (that's the bet) for the losing designer.

In short, there's a *lot* of effort being put into faster execution of Python programs.  The Python language is beginning to change less and less as time goes on, and the developers' focus is moving from new features to library expansion and performance improvements.  In the future, we're likely to see several target environments for a Python program (depending on language features used):

* CPython (aka "classic" or "C" Python)
* Jython (Python on the JVM)
* IronPython (Python on the CLR)
* CPython + Pyrex and/or Psyco
* PyPy
* Parrot (aka the Perl 6 bytecode interpreter)

CPython 2.3 also has about 10-15% speedup over 2.2, out of the box.  CPython 2.4 is expected to have almost as much of an improvement over 2.3.

In short, I wouldn't be surprised if Python ends up matching C# or Java speed in another 2-3 years.  Meanwhile, it's already plenty fast enough for most business applications, especially server-side.

Phillip J. Eby
Tuesday, April 13, 2004

You ask the wrong question.

Learn ANY language take from hours to weeks. You only need to know:

1)how declare vbles

if is a OO

2)how declare class
3)how acces/write class propierties

4)how do a for loop, a while loop
5)how do a if
6)how do a case

this take 1 day, if you have previous experience

7)plus a little mix of functions.
this take some weeks, but can be learn in the road

Learn THE APIS, THAT TAKE TIME.

So, you need is evaluate the FRAMEWORK+API+WHOLE CAPABILITIES

Have integrated regex parsing in languages like perl is cool, but not have much impact, you can put a regex class everywhere.

But still the languages have impact. Mainly, because produce a kind of "culture". For example, a lot of C/C++ code like do the things the hard way... exist good coder, but need un-learn some C++ 2ways" for that. But, is normal.you need un-learn in any language. The "culture" afect how the api, vbles, function, components 6 aproachs are implemented, named & used. The "way" in Delphi is very diferent to vb or c++, but you can do the same, however, you learn the "culture" and follow it (for bad or good)


So, i suggest:

- Learn a language for get a job:(Ups! bad, bad word chosen) Learn A PLATAFORM for get a job: .NET/Java/LAMP
- If want build you own company, and not want be a slave forever, chose Delphi,C++, or any other tool. Is you chosee, is your problem.
-Learn a script language: JScript is the best election because almost any other scripting language is based. Plus, is simply get a script language:take weeks master it.

For comercial development, chosee api, frameworks, tool, components is the hard thing.

Last suggestion: Research a lot. Not follow blindy MS or Sun or IBM or Borland or any Open Source marketing. The VAST mayority of the time, the tools &frameworks provided by others are marketed for the wrong reason and become very good for other reasons. So again, if you want be, for example, in the .NET road, learn about it.

Mamcx
Thursday, April 15, 2004

*  Recent Topics

*  Fog Creek Home