Production Languages and Toy Languages | Hacker News Reader

Production Languages and Toy Languages

lkesteloot.blogspot.com

15 pointsdrm23733 comments

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.

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'

He just posts a basic code snippet and then says "good luck figuring that out." Seems like he's just appealing to those who don't know and who don't want to know, but who are happy to have some blogger confirm their prejudices.

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.

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"?

"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?

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...

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."

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.

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...) for an explanation of why people either love it or hate it.

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...)

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

I don't think he trashed SICP.

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?

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.

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.

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.

Python : myFile = open(argFilename)

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

Verbosity improves readability? Really?

Python : myFile = file(argFilename)

open is deprecated. Besides: You are right.

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

Oh, I misremembered. Thanks for pointing out.

Does this seem troll-ish to anyone else?

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.

Just wanted to mention that I posted this because I thought it might generate some good discussion. I don't agree with everything the author says and wasn't trying to be a troll.

This brings up an interesting question. I assume most people post things they find interesting even if they do not agree with the content, no? Does anyone think that every story someone posts reflects that individual's beliefs?

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; }

Well in all fairness it would be:

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

  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.

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).

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} ...

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.

> 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.

voodoo meta-programming

...spoken like a true Blub programmer.

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

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.

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,

Reply on news.ycombinator.com