Fog Creek Software
Discussion Board

Learning Ways

I've started this thread because of Chris Tavares' post to the 'Squeak' discussion on this forum.

Quick version: what makes specific programming languages uniquely powerful, and what resources (books, websites) exist for learning each language's strengths (without wasting time on the X for Dummies stuff)?

Long version: Different languages have different Ways of doing things, which are often particular to that language: C++'s STL is a powerful implementation of generic programming; LISP's macros are extremely powerful; in Ruby has iterators (a language support for the Visitor pattern) that replace 99% of loops; FORTRAN enforces assumptions (e.g. no variable aliasing) that allow the compiler to generate extremely efficient code; ML's structural induction allows terse code to be written and efficient code to be generated; C's calling convention is standard on UNIX systems so everything talks to C and C talks to everything; and so on.

What languages have what amazing advantages (i.e. what hard problems suddenly become easy)? What resources exist for learning this language's advantages (and doesn't waste time teaching you about OO/declaritive/generic programming, i.e. assumes your basically competent)?

Tom Payne
Tuesday, November 12, 2002

IMHO, I think an amazing advantage of any language is the libraries that are available for use with that language.  Unless your aim is build a database library, having to do so while attempting to create an order entry system (or any other database oriented application) is, for lack of a better term, a headache.  The same goes for a UI library, XML parser, IO classes and so on. 

Take for example, .NET (although you could probably make the same comparisons of Java).  The C# language by itself has limited functionality, but add in ADO.NET, ASP.NET (or Windows Forms) and the rest of base class libraries (BCL) and you have a set of tools on which to build real world applications.  If you were to have to craft your own data access, application server and xml parser libraries it would clearly take you much longer than if you started with the included libraries.

So, that's my vote on what makes one language more advantageous over another... what pre-existing libraries the language has access to. 

With .NET, you have the BCL, the Win32 API and all of the COM components already out there.  Not a bad start.

If .NET is your game, I’ve found a good book that is a well thought out (intermediate/advanced) introduction to what’s offered in the BCL (ADO.NET, ASP.NET, Windows Forms, Remoting, Web Services, etc…)

Microsoft .NET for Programmers

Guy Incognito, MVP DOA
Tuesday, November 12, 2002

One set of languages that I think gets overlooked far too often is the OPS5 family of languages.  These languages are immensely powerful and efficient (in terms of time) when processing complicated conditional logic.  They are also an attractive alternative to imperative languages for responding to a non-deterministic environment.

I'm rather surprised these kinds of languages haven't made more of a dent into certain areas.  Certainly using one of these to manage complex GUI state information would be much simpler than the equivalent code in Java or VB.  They also seem very useful in coordinating, scheduling, and routing messages in object-oriented systems.  A final example might be in personalizing content or configuring a system based on a large number of interacting parameters.

I think these languages have failed in the marketplace (to date) for a variety of reasons, but I'm hoping that as systems get larger and more complex, they will start to penetrate into the mainstream.  They already seem to be making some headway into the "business rules space,"  so I'm hoping that more general adoption won't be too far behind.

Dr. Rete
Tuesday, November 12, 2002

Prediction:  In 15 years, most code will still be written using terse { } languages (C++, Java, C#, derivitives).

Why?  Because most code is general purpose, needing a linear "one foot in front of the other" execution path.  This eliminates functional or rule based languages (Haskell, etc.).

Specialized languages (PERL, T-Sql, XSL) are generally only practical for small portions of an app.  In 15 years, we may get to the point that something like Smalltalk can work for "most apps", but we're not there yet.  Heck, we're barely there with Java.

Momentum is key.  It's amazing that "C" style syntax has been around for 35 years.  Even more amazing that no one has any serious gripes about it all these years later.

Someday in our lifetimes, we'll get to the point that every machine will have a lightning wireless connection and that each keystroke or mouse movement can make a server roundtrip, go through 20 layers of abstraction, query an OO database of "UI rules" and return a complete rendering of UI changes in the blink of an eye.  Until then, curly brace languages will dominate.

Bill Carlson
Wednesday, November 13, 2002

This doesnt exactly fit your question, but I find it interesting to see the design methodologies suggested or enforced by languages.

For example, Java's forced object-oriented-ism can result in extremely nice, compartmentalized, clean code (It can also write horrid speghetti code which the OO-ness makes worse than the equiv. speghetti code in C, but you can shoot yourself in the foot anywhere.)

Then you have C: It requires paranoid checking of function returns. Its lack of support of the public/private division encourages fewer abstractions. It can be done, but the language helps you not do it, unlike java, where it's the reverse.

C++ can be written just like C, but supports everything. The STL really encourages genericness in certain aspects. The use of overloading operators can make some things really easy, rather than a buttload of function calls (like C needs)

Perl makes it really hard to do any sort of OO or abstractions, because it doesn't support structures well.

This wound up to be much more poorly written than I planned, but I think it is interesting to note the different 'feel' of languages: when writing things in one versus another I tend to use different methodologies.

Mike Swieton
Wednesday, November 13, 2002

C is certainly awkward at handling abstractions, it can be done just as C++ originally was a set of abstractions using macros that in the end resolved into C but the result is awkward and ugly.

At writing efficient code that's close to the metal or at least abstracted thinly from it, C is very useful indeed and when it comes to it C++ becomes C for those kind of functions.

Initially, .NET looks like a panacea where you can use whatever syntax and grammar makes sense (or that the programmer knows) to describe a solution efficiently  and build an application out it without having to worry about integrating different languages.  However, a single byte code object form, even with different surface syntax means that optimisations will tend to be equivalent.

This, I think, will tend to mean that the specific advantages of a particular language will be lost when it is generated by a .NET compiler.

xBase languages (for me specifically Visual Foxpro) combine within an algol/basic type syntax, so its structured but interpreted so it can be used in an immediate mode, a database manipulation language that makes complicated row and set handling very much simpler whilst within a familiar programming language style.

With Visual Foxpro you can abstract the underlying database from the language, so you don't have to use the native database and files you could use any ODBC source and have the same advantages.  Though doing row operations on a remote SQL database would probably not be the most efficient way to do something.

Additionally, Visual Foxpro has the cleanest definition of classes and OO around, its interesting to see how that has fed back into the .NET languages whilst Foxpro keeps its own compiler and runtime.

.NET development '.NET Framework Essentials' O'Reilly Thuan Thai & Hoang Q. Lam

Visual Foxpro check out

Simon Lucy
Wednesday, November 13, 2002

Java is interesting because it's not just a language.  It's a vm, huge bunch of libs, plus a language.  So you can get many of the advantages of Java without programming in a language you don't like.  You can use Python, for example, or a lisp dialect.

There are many texts for Java covering different topics.  I'd suggest the Java Class Libraries series from Sun, as a base.

About "Java the Language," it's basically all about bondage & discipline.  The real abstractions are interfaces.  Maybe the code behind a particular interface beat each other, but you see a nice facade.  Still, it's a well-engineered language.

Wednesday, November 13, 2002

"What languages have what amazing advantages (i.e. what hard problems suddenly become easy)?"

Programming language Erlang has been designed especially  for concurrent oriented programming. Erlang's virtual machine is almost like an operating system as it provides processes, scheduling, distribution and so on. Creating processes, for example, is very efficient in Erlang. You can create tens of thousands of processes where creation of an individual process takes only few microseconds.

If your problem happens to be one that can be modelled in terms of concurrency (let's say a web server for example), using a language like Erlang makes it a lot easier to implement such system. Programming in Erlang doesn't make distributed programming *easy* (there are problems that are near insolvable there), but in a lot of cases it makes it considerably easier.

"What resources exist for learning this language's advantages?"

Erlang whitepaper at makes a short overview. Probably not the most neutral introduction, but I think the claims mainly hold. 

Jarno Virtanen
Wednesday, November 13, 2002

"In 15 years, we may get to the point that something like Smalltalk can work for "most apps", but we're not there yet." 

What is it about the Smalltalk language that makes you believe it is not a general purpose application language?  It's imperative, just like C or Java, only without the curly braces.  Given the same set of libraries, the structure of a Smalltalk program and the structure of a C# program implementing similar functionality would probably look very similar.

Have you ever used it?

Former Smalltalker
Wednesday, November 13, 2002

*  Recent Topics

*  Fog Creek Home