
Production Languages and Toy Languages - drm237
http://lkesteloot.blogspot.com/2008/01/production-languages-and-toy-languages.html
======
koolmoe
_A production language should favor reading the code over writing it, and a
toy language should do the opposite. Note that I don't mean that the language
is a toy, but that it's used to make toys._

Yes, Lisp is used to make toy programs like the software running on the $100
million 1998 Deep Space 1 probe.

 _Their final top-level function is:_

    
    
      (define (sqrt x)
      (fixed-point-of-transform (lambda (y) (- (square y) x))
                              newton-transform
                              1.0)
    

_Good luck figuring that out. I'm sure it was fun to decompose the problem
into those functions, but in production two years from now some programmer is
going to be in a world of pain when he has to add a feature to that program._

That's only hard to read if you don't know Lisp. And the function names are
quite descriptive if you understand numerical methods. If the hypothetical
developer doesn't understand fixed points and Newton's method, he shouldn't be
modifying that sqrt function anyway.

There might be a good point about obfuscation via abstraction somewhere in
SICP, but this example isn't it. Even if it were, it has less to do with the
language itself and more to do with the developer that designed the
abstraction.

I suspect Mr. Kestleloot is simply ill-informed.

~~~
Xichekolas
The guy has the phrases "secret startup" and "java enterprise development" in
the same sentence in the About Me section of his blog... can't imagine a real
hacker saying either of those things, let alone in the same breath and without
laughing.

Of course, I wouldn't claim to qualify either, but then again, I understood
that sqrt function just fine.

I'm pretty sure his true definition of 'Production Language' is 'Java' and
'Toy Language' is 'Anything Not Java'

------
reitzensteinm
I had a quick look through the archives. This is another fun one:
<http://lkesteloot.blogspot.com/2006/08/hackers.html>

_I want nothing to do with hackers because I don't have hard problems. I don't
have to write compilers or distributed databases. I have problems where co-
workers write "WARNING:" in capital letters in messages to the user,
effectively yelling at them. I have problems where co-workers write, "5
selected album(s)" because they can't be bothered to write an "if" statement
to conditionally remove the pluralization. I have problems where co-workers
write the entire text of a dialog box in bold and don't line up the title and
the body of the message. Those are the problems I have, and hackers aren't
going to help me. In fact, hackers are the ones most likely to commit these
errors because user interfaces bore them._

Yes, user inferaces bore me. I wrote a recursive layout generator so I'd never
have to worry about lining up anything ever again, so I literally do not have
the problems he does at work. But I guess my 'toy' implementation isn't fit
for a 'production' system, wherein you manually align everything.

~~~
pchristensen
That article shows that he actually DOES understand the concept of a hacker,
he just doesn't think it applies to computer hackers (weird, huh?).

He says "a hacker is someone who wants to understand his trade a few levels
deeper than everyone else." Um, that could be the tagline for Hacker News -
"For people who want to understand their trade a few levels deeper than
everyone else".

I doubt he's met any of the Great Hackers in the Paul Graham mold - I think pg
would be furious if any of his yc people made those UI mistakes. Isn't the
ultimate hard problem to "make something people want"?

------
raju
"Many modern languages similarly give up readability for writability, like
Ruby, where you can literally redefine the + operator on integers so that it
no longer gives you their sum." I believe Dave Thomas covered this in
"Metaprogramming Ruby" video
[<http://www.infoq.com/presentations/metaprogramming-ruby>], and the problem
here is not that the language allows you to do it, rather your programmers are
willing to do something like this.

This is not a language feature problem, its a developer education problem. I
agree with sammyo that a wrong abstraction can make it harder to decipher
whats really going on. On the other hand, isn't that true for any kind of
abstraction? Frameworks like Spring abstract away notions of AOP and unless
you really understand whats going on under the hood you will be left
scratching your head. Does that make Java a toy language? If yes, then whats
the point of this post?

------
gills
Let's take a poll. Which is easier to maintain?

1\. Lisp.

2\. "Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Common Lisp."

~~~
reitzensteinm
The funny thing is, the example given approaches 'sufficiently complicated'
territory already, even though it's so short. Unless, of course, you use the
'Human Compiler' design pattern.

------
mnemonicsloth
Didn't read a word past the author blurb:

 _Lawrence Kesteloot is a software developer working at a secret start-up in
Palo Alto, California, where he does Java enterprise programming._

Roll that over your tongue a few times, just to get a feel for it: he works at
a _startup_ where he does _Java enterprise programming._ At his _startup_.
Java programming. Java _enterprise_ programming. There we go -- that sounds
much more impressive...

------
sspencer
Anyone who trashes SICP can probably safely be ignored. See Norvig's review of
SICP here
([http://www.amazon.com/review/R403HR4VL71K8/ref=cm_cr_rdp_per...](http://www.amazon.com/review/R403HR4VL71K8/ref=cm_cr_rdp_perm))
for an explanation of why people either love it or hate it.

~~~
eru
I like SICP Wadler does, too. Nevertheless I think he has a point in his
critique.
([http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p...](http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf))

For example - he argues that Scheme has not enough free Constructors. (Look
into the pdf for an explanation..)

------
pchristensen
It's interesting to see how this guy has defined himself. There aren't many
posts (21 posts since May 2003) and of those, only 8 appear to be about
programming. Out of those, 3 of them are trashing higher levels of
abstraction, and small but powerful languages, including Lisp and pg by name.
It strikes me as weird that a significant portion of his writing effort would
go defending the status quo against a small, upstart philosophy. If you're on
Goliath's side, why are you so defensive?

------
Zak
Advocates of languages with both low and high expressiveness use the
readability argument. The writing speed argument is a bit of a red herring;
Java and .NET programmers tend to use code generators to write code quickly.
The code they emit is widely regarded as unreadable.

I think using the right abstractions makes code more readable, so having the
tools to write them available is a Good Thing. Abusing those tools makes code
unmaintainable - that's why large projects have (or should have) coding
standards that say things like "don't redefine what the + operator does to
built-in numeric types".

The big problem I see with less expressive languages and less compressible
code is that it's really hard to get a higher-level view of what's going on.
There's too much you can't abstract away to the point that you _can_ ignore it
while trying to think about how the bigger pieces fit together. You can
uncompress your Lisp as much as you need to to see the details you want to
see. You cannot compress your Java as much as you need to to see the big
picture.

------
sammyo
Bit of a slam on Viaweb and lisp here, but well meaning and has a point worth
considering. The wrong abstraction or fantastically efficient highly optimized
(and, er, undocumented) DSL, that only one person in the world can work with,
perhaps should be considered a prototype rather than an application.

------
tyn
Python : myFile = open(argFilename)

Java : import java.io.*; BufferedReader myFile = new BufferedReader( new
FileReader(argFilename));

Verbosity improves readability? Really?

~~~
eru
Python : myFile = file(argFilename)

open is deprecated. Besides: You are right.

~~~
Kaizyn
Open() is an older construct but it isn't deprecated. I hate to sound like the
language police but there it is.

~~~
eru
Oh, I misremembered. Thanks for pointing out.

------
gruseom
His argument could just as easily be used against languages that have
subroutines in favor of languages that don't. Sure, subroutine calls make your
code more concise, but at the expense of readability: you have no idea what's
going on in all those called functions! Better stick with a more verbose
language - there's more code, but at least it's clear and explicit.

------
zyroth
I personally think that C++ and Java are less readable then Lisp, Python,
Ruby, ...

I think you get used to every Syntax. The point is, Lisp et al are much more
compact, which makes the concepts easier to grasp.

I get a (mapcar #'f '(1 2 3)) much quicker than a

x = {1, 2, 3}; for (int i = 1; i < 4; i++) { x[i] *= 2; }

~~~
Xichekolas
Well in all fairness it would be:

    
    
      (mapcar #'(lambda (x) (* x 2)) '(1 2 3))
    

vs

    
    
      x = {1, 2, 3};
      for (int i = 1; i < 4; i++) { x[i] *= 2; }
    

(I think... my only real experience is with Scheme, so I'm sure I messed up
the pound-tick or some parens in Lisp)

But yeah, I generally agree the Lisp version is easier... especially once you
get past trivial stuff like this.

~~~
reitzensteinm
Easier, but more importantly safer in that any potential memory trashing code
is implemented inside the language implementation itself (the bug that's in
your C version couldn't really happen in the Lisp version).

~~~
rglullis
Nor it would happen in the C version. This code doesn't compile. The compiler
will throw you a _WTF_ at x = {1, 2, 3} ...

~~~
Xichekolas
I was just assuming the zyroth's example was in Java, since that is what the
article's author favored. Not sure where you guys got the idea that it was C.

But, just to cover all bases, it wouldn't work as Java either. This would
though.

    
    
      int[] x = {1, 2, 3};
      for (int i = 0; i < 3; i++) { x[i] *= 2; }
    

Yet another reason to use:

    
    
      (mapcar #'(lambda (x) (* x 2)) '(1 2 3))
    

... you don't have to think about whether array indexes start at zero or one.

------
bfioca
Does this seem troll-ish to anyone else?

~~~
jgrahamc
Yes.

And I find it very odd that he points to the Viaweb transition from Lisp to
C++/Perl as an example of going from an unreadable/unmaintainable language to
a readable/maintainable one?

I've programmed a lot in C++/Perl and those languages require very, very
careful programmers to prevent them from becoming unreadable.

Also when he says "There are probably two ways to write Lisp code: with all
the expressive constructs (in which case it's unmaintainable) and without (in
which case you may as well use Java)." I think you can replace Lisp with Perl
or C++ there and come to the same conclusion.

Java's verbosity is one of its great weaknesses IMHO. Just the shear reams of
code that I have to wade through to discover that we've done something very
simple.

------
theoneill
_voodoo meta-programming_

...spoken like a true Blub programmer.

------
henning
> This definitely makes it easier to write code, but it then takes 20 minutes
> for anyone reading to figure out what's going on in the tiniest of
> functions.

With Lisp, it's easy to broadcast your ignorance. To do that, just make it
clear that you don't actually understand macrology and what the right
circumstances for using and creating macros are.

------
edw519
A clever title for the Language War post of the week.

------
jimbokun
I don't think this author makes his point very well. But I think Amit makes a
similar point here:

<http://amitp.blogspot.com/2007/04/lisp-vs-python-syntax.html>

Single quote summary: "When I'm writing code I prefer Lisp; when I'm reading
code I prefer Python."

I think where Mr. Kesteloot goes wrong is comparing Lisp with Java. Java sucks
both for reading and writing, pretty much.

~~~
anamax
Amit's "point" about being able to tell what a Python form does by looking at
it isn't true thanks to __call__ and properties,

