The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Day job languages vs. night time languages

I think there has been a lot of debate on this board about the strength of particular languages.  Usually, it boils down to the night-time personal language vs. the language used during our day jobs.  Normally, this is something like Lisp/Ruby/Python vs. C++/Java/C# (some languages might show up on different sides of this equation depending on the person). 

In general,  I am observing that the languages which are used at work are languages that have strong support from a particular company (Sun for Java, Microsoft for C#, etc).  They also come, by default, with a platform, a way of doing things, and very often an extensive set of libraries.  I also observe that the languages that we use at home sometimes are not directly supported by one company, but by a more distributed network of people (open source like).  Further, I don't (in my experience) think they have as good of library support. 

For the purposes of this argument I am assuming the programmer uses the language he likes best at night, and maybe not his favorite during the day.  If you wish to debate this, start another thread and I will.  Why does the programmer like the language that he likes at home so much?  I would argue that it is largely about efficiency in the language.  If you can do something quickly in a language you get that feeling of control that I think most programmers enjoy.  Also, at night, you presumably have less time to do something than you would if you were doing it at work (since work takes up 40-60 hours of your week).  Therefore, the speed (or power) of the language you use at home is even more important because you are limited on the amount of time you have to get something done. 

I, therefore, put forth the theory that what we use at home is more powerful, but has less library support because there isn't an entire company of people writing libraries for that language.  At best, there are people writing it in a distributed manner in their spare time. 

Suppose language X (your favorite language) had a $2000 IDE, compilers, editors, auto-completion (intellisense), 10 minute installation routines, support for all databases, architecture support from the operating system, 100s of companies writing libraries and controls and selling them cheaply and everything else that comes with a company supporting full time their language.  I cannot imagine what it would be like for me to use Scheme from within Visual Studio.NET. 

More and more, as I write code generators for C#, I am starting to believe the quote "those who don't know Lisp are doomed to reimplement it."  Problem is, I want to add "and write their own libraries."
Joshua Volz Send private email
Friday, December 30, 2005
Spot on. I would only like to add one thing: the "support" that big companies give to their mainstream languages is often a double-edged sword. Microsoft in particular has a nasty habit of yanking the rug out from underneath developers. These days I lean toward open source tools because living without the support is an acceptable tradeoff for having tools that won't be yanked away from me. And I like dynamically typed languages more, too--especially if they come with a command-line read-eval-print loop.
John Foxx
Friday, December 30, 2005
I agree with the hypothesis. I think the difference between "daytime" and "nighttime" languages is all to do with capital.

Daytime languages are ones where you have a steady and stable supply of programmers, largely because they are backed by big companies and hence backed by universities. There is corporate support and a whole bunch of third party companies that will sell you widgets, libraries and whatever else you need for your business.

Nighttime languages tend to be more elegant and open source. They're backed by a stable of fickle, but talented programmers. The support may be free and better, but there's nothing written into a contract. Libraries, widgets and a supply of programmers are also often free, but also lacking. The libraries are incomplete and undocumented. The programmers lose interest and quit.
Colm O'Connor Send private email
Friday, December 30, 2005
Is it possible that we use our day time languages for production code purely because they are safer? I am defining safer as supported by the same company as the operating system, supported with lots of previously tested libraries, and supported by all the other companies making and testing code in those languages.  Further, they are safer for the company that is doing the development because if someone leaves the company they can more easily find someone to replace them.  Could it simply be that for production code companies (and therefore programmer employees) prefer to make the safer bet, rather than taking the larger gamble of using a language that might (likely, is) be more powerful but that doesn’t have all these safety nets?  Does this mean that as Paul Graham says, companies that use superior technology, along with the increased risk that it brings, can get things done faster?  Could this be part of the reason that large companies can’t develop new products as easily or as well as start up companies? 

I know I am asking a bunch of questions and not giving any answers, so here is my guess.  I would bet that the more risk you take in your programming development model, the larger the potential reward can be if you succeed in producing something that people want.  No established business is willing to make such a large bet on a single programmer, or group of programmers, for an obscure language because they are too hard to replace.  Meaning, they are closer and closer to being the people who are indispensable, instead of the management that controls those sorts of decisions. 

So, I am saying, take your favorite language, find a problem that is hard and make something people want.

(P.S.  Okay, so this might be paranoid, but is the use of less powerful, safer languages a control mechanism against programmers?  Is management forcing us to use safer languages so that they can guarantee that we can be replaced, and in doing so hold down software production costs?)
Joshua Volz Send private email
Friday, December 30, 2005
>Is management forcing us to use safer languages so that
>they can guarantee that we can be replaced, and in doing
>so hold down software production costs?

Essentially, yes. The chances of you staying in the same job for life are virtually nil.
Colm O'Connor Send private email
Friday, December 30, 2005
I largely agree with this analysis, but I find that certain nighttime languages have very powerful commercial support -- and relatively weak free software.

Take Common Lisp. Some here probably followed the entertaining Reddit story, complete with the angered Frenchman who passionately defended Lisp's honor... anyhoo, one thing pointed out is that in some ways, Lisp's commercial implementations are currently slicker, more featureful, have friendlier IDEs, etc than the free alternatives.

Some other languages like this are (I guess) Rebol, K, etc.

Now, one thing to note is that oftentimes, daytime languages pull people towards the nighttime ones. So one of Java spec's coauthors explained, "And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers.  We managed to drag a lot of them about halfway to Lisp.  Aren't you happy?"

(I think that Java was a regression in some areas; for example Common Lisp has multiple inheritance; but the sentiment's nice.)

There's also another axis that probably needs to be considered: David vs. megacorp.

Finally, there's an odd tension deskilling tool/technological choices, between managers and skilled workers:

"Having been a manager myself, and given a choice between a small department of highly effective but unpredictable geniuses and a large department of homogenous, average, _replaceable_ programmers, I'd really have a hard choice to make.  Other managers would not find the choice hard at all.  More than 50% would choose the homogenous interchangeable department."
-- Duane Rettig, of Franz (Lisp implementor)
Tayssir John Gabbour Send private email
Friday, December 30, 2005
This must sound very strange to a lot of people, but I tend to choose languages according to what's best suited to the task at hand: For example, you tend to write text-processing code in Perl if you can, unless you've got serious performance concerns, or unless yacc's doing the hard parts, or unless the intended audience can't be presumed to have Perl installed. That last kills Perl for Windows in most cases, unfortunately.

Sometimes, you use more than one: From time to time I'll whack up a scriptable COM object in C++ and call it from Perl (via Win32::OLE), if I need something from the API that I can't get normally.

If you're in a situation where a manager imposes a language on you against your judgement, either the manager's a fool, or you are (more often the latter, in my experience). So leave. The job market's not bad right now. When I switched jobs last summer I turned down offers.

By the way, this "control mechanism against programmers" thing lacks only the Elders of Zion to score 100% on the Knucklehead Scale. Obscure languages confer no particular benefit just by virtue of obscurity. On the other hand, they tend to have lousy tool, debugging, and library support, support of *any* kind may evaporate without warning, and when the neurotic prima donna who insisted on using the Magic Mystery Language flounces off to join an ashram, you're liable to find yourself dead in the water until you can find somebody else equally neurotic to maintain his code. Of course some programmers naturally gravitate to job-security languages, but if they feel that strongly about it they can go start their own companies.

How much, exactly, would you bet on the future of a company if the founder's primary professional goal is to keep his job by writing code that other people can't maintain? I don't see anybody rushing to sign a check. But people like that never, ever start companies, because that involves risk. They think you should take the risk, and then give them all the rewards if it works out. If it doesn't work out, they'll generously give you all the blame.

But you don't have to put up with it. The magic words are "employment at will", if your local laws allow it. If some clown starts throwing language-bigot tantrums and insisting that you basically give him a sinecure for life, fire him on the spot and escort him out of the building before he catches his breath. He won't learn his lesson -- people like that are untrainable -- but at least he'll be out of your hair.
Walter "Darth" Gropius Send private email
Saturday, December 31, 2005
Most people's intuition is to choose languages "suited to the task at hand." For example, I frequently relegate Common Lisp to a support function, as I code the main parts of a project in something like Java and PHP. So parts of my scaffolding are in a language which doesn't appear in the final product -- and may not even be stored in source control.

Some commentators start self-destructing when confronted with less popular languages, entertainingly calling your observations "conspiracy theories" when you point out obvious observations, like some employers decide to choose languages which are easier to offshore.

"Primary characteristics of the Java programming language include a simple language that can be programmed without extensive programmer training while being attuned to current software practices. The fundamental concepts of Java technology are grasped quickly; programmers can be productive from the very beginning."
-- Gosling, McGilton 1996

We see in fact that people like Paul Graham (most notably, but there are lesser-known people) have famously taken on significant risk in using "obscure tools." Because under capitalism, you often try outmaneuvering lesser competitors using techological advantages. While your competitors are on newsgroups pontificating about "Knucklehead Scales" (is this Fox News?), because they don't understand the economic roles of technologies, you're busy reading up on the pros and cons of different tools. Intelligently evaluating which are appropriate for what situations, and how much poisons are in the various koolaids.
Tayssir John Gabbour Send private email
Saturday, December 31, 2005
And that's not to provide evidence that Java's a bad tool in some objective sense. But to be a competent engineer, you need to know the role of tools in business. Without koolaid, without ideology. Tools are not only judged on technical terms, nor should any rational person do so.

Maybe Luv2Surf666 and Darth Gropius on the forums might wish to flame your conclusions.. and some of them will certainly be mistaken, everyone makes errors.. but you'll likely be ahead in any real metric that you consider important.
Tayssir John Gabbour Send private email
Saturday, December 31, 2005
Darth, you are right in that obscurity doesn't, by itself, create a better or more powerful language.  However, several strong arguments can (and have) been made for the increased productivity of languages which are not widely used in the Microsoft dominated business application world (Python, Lisp, Scheme, Ruby, probably 10 others I don't know about). 

My argument is that managers seem to choose languages which are easy to pick up (which means there are more people who know them) so that they have a greater programmer base to choose from, which in turn lowers their costs (increased supply = lower price for programming talent in that language).  From the perspective of managers, this language choice is "safer." 

Finally, your argument about someone betting on a single programmer using his favorite language is probably correct; a business person wants to know that if that person leaves they still have a business.  Here's what you overlooked though, the business person and the programmer using his favorite language sometimes ARE the same person.  Therefore, he is not afraid of himself leaving.  This gives him the technological advantage of a stronger language, without the risk of his #1 employee leaving.
Joshua Volz Send private email
Saturday, December 31, 2005
I disagree with the daytime-nighttime language approach.

I think for a developer to command the MOST money possible therein becoming the most successful in the IT field requires that person to SPECIALIZE in SOMETHING.

In other words, your DAYTIME & NIGHTTIME language should be THE SAME thing.

That "something" by way of programming languages depends on how much your brain can handle comfortably. Add this to the thought that it helps tremendously to specialize in a field that is viably marketable and will be foreseeably useful in the future.

For me, I specialize in fundamentally two areas - VBA for MS Office apps and MS Access small-scale database apps with a working specialization soon to be added to my IT pocket: VB.Net WinForms.

I believe I will be highly marketable for the next 5-7 years...
Brice Richard Send private email
Saturday, December 31, 2005
>have famously taken on significant risk in using "obscure tools."

What Graham seems to be saying is that if you use "best practices" you are not going to get things done any faster than the competition. He used Common Lisp for Viaweb because they could work much faster.

Lisp I don't know about.

I do know that we can get projects done in Perl much faster than C++ or Java.
sometimes unprepared
Saturday, December 31, 2005
I agree with the above poster that specialization is an important asset.  I would argue that it might be better to specialize in a particular type of application than a particular technology.  For example, if you have written three (small business) enterprise systems for the health/medical industry, you could call that your specialization.  You have domain knowledge at that point, since you have had to work with people from the industry and support those programs. 

If you are going to specialize in a technology, I believe you should *everything* there is to know about that technology.  For example, Paul Graham, using Common Lisp, was successful with Viaweb.  He has written books on that technology.  He is in the middle of writing another Lisp variant called Arc (I believe that is the name).  He knows Lisp inside and out.  If you pick a technology, learn everything about it.  Know how to do every conceivable programming task in that technology. 

Things I might make sure I knew if I only knew 1 tech:
- DB connectivity
- Multithreading in that environment
- Talk to COM objects
- Talk to DLLs
- Server/Client communication (sockets)
- Regex
- Web Apps (are they possible?)
- Web Services (can we write one in this tech. easily?)

I am sure this is not an exhaustive list, feel free to add to it.
Joshua Volz Send private email
Saturday, December 31, 2005
Your premise falls apart very early on, since most of the "libraries" which make Java so useful are open source.
M1EK Send private email
Saturday, December 31, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz