Fog Creek Software
Discussion Board

Right tool

One of things that I've heard several times over the last couple of decades is that 'real' programmers know several programming languages because some things are just easier (faster, better, whatever) in language X than in language Y.

Why is that? What is the effect of something like a single shared library/framework (I'm thinking .NET here, but there are probably other ways to get it done)?

Yes, I know it all eventually ends up as 1's and 0's, but I also know that some things are easier in AWK than in BASIC. I've always believed that there was more to the difference than just syntax, but maybe that means I don't understand what syntax is :)

Ron Porter
Monday, March 3, 2003

With me, I tend to use different tools for different platforms. Without starting a religious war over language choices I tend to use Delphi for Windows C/S development. Most stuff I do involves some database stuff, so me using Delphi is simply more effective for me, than learning say C++ or whatever.

I know a bit of C, which I use as a last resort when doing UNIX related stuff. Shell-scripting with sed/awk and even perl and such takes you a long way most of the time. Thing is, server side programming includes alot of boring stuff, like parsing XML or text files. For this shell scripting saves you time. Debuging my fread() calls for the umpteenth time is a vaste of time.

For Linux I play around with both Kylix and gcc, which provides a good mix of both worlds. Reading C code is really no problem, while writing it takes substantially
longer :)

I have some assembly too, from back in the 8088 days, which is really useless job-market-wise today, but helps provide a better understanding of the different languages.

Combine this with a multi-platform database engine, with some portable stored procedure language, and I am pretty much set.

As for platform independent development tools, (Java/.NET) I havent used them extensively. I played around with Java for a while, but I dislike Java because of confusing re-implementation of the widgets. Buttons have rounded corners, comboboxes behave strangely and all that.

There is really a limited need for platform independence for end-user software. What I mean by this is that 99.9% of the users have Windows Desktops. Writing a client/server solution in Java, just to satisfy the 0.1% which uses Sun Ray clients are not worth it in my book. I dont mind using Java or what have you, for server side programming, because that is invisible to the user.

Hope I didnt bore you to tears...

Feel free to disagree :-)

Monday, March 3, 2003

"Real programmers" know several programming languages because there isn't any one programming language that captures all of the conceptual abstractions that are useful in problem solving (Though that may change as languages like Perl are hard at work glomming together all of the useful concepts from other languages)

Syntax plays a role because it allows for concise expression of the concept in question, but other than that doesn't matter too terribly much.  As long as the concept can be expressed within the key-stroke tolerance that programmers who use it are used to, all is well.

As far as frameworks go, if they allow you easily express all of the concepts you need to express, life is good.  If not, that's when you build higher abstractions or code closer to the metal.  If the concept/code gap is wide enough and the programmer has enough tuits, that's when new frameworks get created.

Jonathan Scott Duff
Monday, March 3, 2003

I agree. If the only tool you have is a hammer, everything looks like a nail, etc.

Also, being conversant with multiple languages makes it more likely, I think, that you'll understand general concepts rather than specific implementations. Especially if you've had exposure to widely varying languages: assembly, pure OO, functional, etc. It's not the differences in syntax that matter, it's different ways they enable (or force) you to approach a problem.

John C.
Monday, March 3, 2003

Something that may make it easier to accept the "renaissance man" concept - instead of thinking of multiple languages, think about multiple tools.

You *could* write an enterprise application in Visual Basic. Instead, you could either have the broad skills base and/or hire the appropriate experts to:
-Put the data in a relational database (normalized)
-Put the data access code in stored procedures
-Put the business logic in business components (C++, C#, Delphi. etc)
-Put the presentation logic in windows forms (ATL/C++, VB, ASP/.Net)
-Put data mining logic in an analysis package

Even within those tools you'll be doing things like using RegEx for string searches, maybe some Perl for text file parsing, javascript for client-side functionality on web apps...

Knowing multiple languages or tools means learning the limitations of each. You really can't appreciate the limitation of a tool until you use a tool that doesn't have that limitation (there's a mathematical theorem that states this, but I can't recall it right now)


Philip Janus
Monday, March 3, 2003

Real programmers don't know multiple languages.

Real programmers know multiple paradigms of programming (object oriented, functional, generic, relational, string processing, etc) and how each paradigm maps to one or more real languages.

Real real programmers knows how functional programming maps to C++, object oriented programming maps to C, and generic programming maps to Smalltalk. ;)

flamebait sr.
Monday, March 3, 2003

Some things are easier in one particular programming language than others.

Rather than fight for two hours with C++ to write an application to do complicated string manipulation, you can write it in Perl in fifteen minutes.  Or, rather than spend a day writing a simple GUI application for Windows in C++, you can put it together in Visual Basic in a couple of hours.  Or, rather than try to finagle some way to write a beautiful GUI e-mail client in Smalltalk, you can write it in C++.

Obviously, the above examples are gross oversimplifications.  But that's the basic reason.

Brent P. Newhall
Monday, March 3, 2003

Oh, and I'm realizing that I should post

flamebait sr.
Monday, March 3, 2003

Real Programmers know multiple languages because Real Programmers use whichever language they know that is:
  a) most appropriate
  b) best supported
  c) required by the customer

Under the "most appropriate" category, syntax is very important.  Compare these two approaches for calculating when to do something.  This is from a real example where the original was in Pascal, which did not allow overloaded operators for operating on structured types and a machine where the basic types were not large enough to hold a time value.  This syntax is not Pascal, but it is something that matches many different languages.

Overload operators on abstract types:
    Time preroll_time = event.start_time -
    Time wait_time = preroll_time -;

No overloaded operators:
    Time preroll_time;
    Time now;
    Time wait_time;

The semantics of both examples is the same but the syntax is quite different.  I claim the first one is far more natural.  An interesting observation is that I was able to write the first part quickly but I had to refer to the first expression while writing the second sequence in order to "dumb it down" with proper calls while preserving the proper order of those calls to accomplish the same abstraction.

I believe the next big gain in productivity will come from a better programming language - one that makes it easy to write "good code" and hard to write "bad code".  It is easier to verify that good code works than it is to debug bad code.  It is a matter of debate whether this "better language" is at a higher level, has different abstractions, provides more or less features, or whatever.  I claim it will be known to be better because it makes it easier to write good code and harder to write code with bugs.

Bill Davis
Monday, March 3, 2003

The plethora of different languages exist primarily because of differences in programmers or platforms, not because they express different paradigms.
If I write in depth for .NET, I must know C# (or VB.NET), ASP.NET, HTML (and maybe some JScript), XML (and a few relatives like XSLT and SOAP), SQL, IDL and C++ because each has a unique role for which no other can substitute. Not my choice.
If I write for the Open Source market (or I don't like paying for my development products) I might feel free to choose languages like Perl or Python, Java, PHP, but the choice tends to determine how or by whom my code can be used.
If I'm an amateur programmer I'm more likely to only be able to write VB (eg VBA for Office) or Access.
Rarely does a programmer get a free choice, but there are few decisions that seem to attract quite such agony.

David Bennett
Monday, March 3, 2003

"The story of Mel" really brought back memories. My first computer was a VIC-20. I couldn't afford to buy the assembler cartridge and I had some things to do that just didn't work out in BASIC. My solution was to write a 'loader' that read strings of decimal numbers, POKEing them into memory. I didn't learn until years later that this was more than a bit wacko by most people's standards. I eventually got to the point where I was thinking in 6502 instead of English or BASIC, but I still can't help feeling that if I had been a real programmer, I would have written an assembler/compiler instead :)

Ron Porter
Monday, March 3, 2003

*  Recent Topics

*  Fog Creek Home