Hacker News Reader

Comment by inklesspen | Hacker News Reader

Prove it. Sapir-Whorf is fun for sci-fi, but there's no evidence for anything but the most loose variations of it.

No, the reason Blub programmers have a hard time picking up more powerful languages is that they have invested time in their skillsets, so even if they were to program in Lisp syntax, they'd still write Blub-in-Lisp code, not using macros, closures, functional programming, etc. Because they never learned about them and don't see the point.

The same thing comes up all the time in Python communities; people who don't know Python very well write "un-Pythonic" code that doesn't take advantage of the language's best built-in functionality like list comprehensions and generator expressions.

Compare:

# unpythonic way of squaring each element in a list

source_list = [1, 2, 3, 4, 5]

dest_list = []

for x in range(len(source_list)):

    dest_list.append(source_list[x]*source_list[x])

# Pythonic way

[x*x for x in [1, 2, 3, 4, 5]]

View on HN

Well, I think there is more to it that having invested time in inferior languages. Programming well in higher order languages requires a different kind of thinking from writing simple procedural code and using UML and "design patterns" as crutches. I would argue that Python is easier to learn than either C++ or Java, but much harder to master because mastering Python requires one to think differently. The same is true of Lisp, Erlang or Haskell.

Sadly I think most people are not taught how to think, but rather how to perform repetitive tasks based on some formula (works great for writing Java).

Another problem I think is that most Blub programmers don't program because they love programming and therefore are not willing to put in the time and effort to learn a different way of thinking.

Personally I believe programming is an art and as such it requires talent as well as dedication. I'm disappointed that after all this years everyone still thinks programming is some form of science. Software engineering? WTF?

As one learning lisp and working through SICP...

I've got to say that this is practically like learning to program all over again.

I'd almost go so far as to say that it's like learning to program. Period. Regardless of the years of experience in those other languages....

I did love programming, though... even though I was so Blubby. As long as I wasn't pushing the limits of the languages, I wouldn't think to look anywhere else. I didn't quite imagine that real Computer Science (like SICP) could benefit me-- given how atrocious so many programmers I'd met that had even Master's Degrees were.... Now I feel like I've wasted years and years of time.

(Why didn't anyone tell me? Ah... but would I have paid attention if they tried?)

# unpythonic way of squaring each element in a list

...

# Pythonic way

...

# Correct way (...in any language, and if I see anything else in my co-workers code, you damn well better believe there will be a re-write):

List dest_list = squareEachElementInList(source_list);

The problem with languages like Lisp, Haskell, Erlang, etc, is that the syntax is completely atrocious. It's not just a matter of parenthesis or whatever. It's a matter of eye-straining horribleness. People have little trouble learning and using Javascript, for the simple reason that its syntax is reasonable.

I find LISP syntax to be quite easy on the eyes, personally. Of course, since whitespace is unimportant in LISP, it is easy to write unreadable, non-indented code, but it is also easy not to.

Javascript might be easy to learn, but generally people don't do very complex things in Javascript. Actually, if you ignore the syntax, Javascript is closer in some ways to LISP than it is to C/C++/Java.

I heard it described as the "soul of lisp in the body of java" ;)

No, actually, that's not correct. Why should I have to write a function to traverse a list, square each element, and recombine them into a list, when Python already takes care of the first and third parts for me? Code smart, man.

Why should I have to write a function

A function hides the implementation.

to traverse a list

Because there are different ways to traverse a list. An arraylist is easier to traverse with respect to CPU cycles and memory usage (typically) than a linked list. What does python use internally? I don't know, and I'd just as soon decide that myself...

square each element

While there are only so many ways to square numbers, for more complicated things, you are doing to want to change implementations while keeping it all hidden. In java, you are occasionally going to want to splice in native code.

recombine them into a list

I may not want to recombine them in a list, but square them in place. A function makes that trivial, and further makes it trivial to decide when and how to do that.

--> The real reason is one of readability. More english, less brackets and commas please.

I don't see the advantage of hiding the implementation in this case. The new name doesn't give any new insight, nor provides any useful abstraction over the list comprehension syntax. It only raises question marks in the reader's head: where is this defined? Does it have side effects? Am I OK to mutate the returned list? The passed list? Am I OK to assume the passed list unchanged? etc.

Re: different ways to traverse a list and square elements, whenever the idiomatic implementations in your language are good enough for you, you just want to go with them. Hiding those details behind names is premature abstraction IMO. If you know you'll need your own list and square implementation, you can abstract that from the start. If you find needs for change that you didn't anticipate, the overhead of refactoring (or overloading operators, if it suits the problem) there and then is probably less than having abstracted everything that you might possibly want to change.

Deciding to square the list in place is not trivial at all. If you do that, you'd better change the signature of the function so that it doesn't return anything [Edit: or using whatever convention you have to highlight mutators, like bang! names in Scheme]. Otherwise, it's too easy to use the old list assuming it has the original values, or to mutate either the old or new references assuming they belong to independent lists.

Re: readability, you have to balance the familiarity of the syntax for a newcomer, and more importantly, the ease with which you can get acquainted to it, with its expressive power and its consistency with the rest of the language. If English was precise, concise, unambiguous, and consistent enough a notation, we wouldn't have many other programming languages.

More specifically, I find list comprehensions (and generator expressions in general) very quick to get used to, I find that they read well once you have acquainted yourself with them, I find that they have a great ink to information ratio that justifies making that initial learning investment, and I find that they feel right at home in Python.

An arraylist is easier to traverse with respect to CPU cycles and memory usage (typically) than a linked list. What does python use internally? I don't know, and I'd just as soon decide that myself...

Ah, here's a major difference between us: I'd rather not decide that myself, unless it becomes a problem.

I guess you never heard the one about premature optimization? And who in their right mind 'splices in native code' to java? You sound like you learned how to program from reading slashdot.

That may be the correct way, e.g., if you do a lot of list squaring, and if you don't square other things a lot. Even in this case, I'd prefer something like

dest = mapsquare(src)

Consider the possibility that C-like syntax and mixedCaseVerboseNames may be an acquired taste.

If you do square a lot other things than lists, it's probably best to say

dest = map(square, src)

For one-shot usage where defining square seems overkill, and where it's available and idiomatic, I find the list comprehension most readable.

dest = map(square, src)

Well, this is okay. Of course, in java, you have to hack it unpleasantly,

List dest = map(UtilityMethods.class, "square", src)

...you have to manually extract the method "square" from UtilityMethods.class and process it over src. One advantage: You can use UtilityMethods as a namespace and swap in different methods thereby.

> List dest_list = squareEachElementInList(source_list);

Well, that had better be wrapped in a needless function, too:

    # Correcterest way
     assignSquaredListToVariable( dest_list, source_list);

or there'll be some serious code rewrites going on!

I agree with you that syntax matters, but don't think it's the only reason. Functional programming is a much bigger obstacle, in some ways, than a new syntax.

So, your argument is that they have a hard time because they've invested time in other things?

Sorta. PG got it spot on in his article on Blub. The Blub programmer doesn't see Lisp as being more powerful than Blub, he sees it as being equally powerful, only with too many parentheses and maybe some extra features. But he doesn't need those extra features, he's a skilled Blub programmer, and once he learns the Lisp equivalents of his favorite Blub function calls (etc.) he'll happily carry on writing Blub code in Lisp syntax. And that's only if you force him to use Lisp, because he still thinks there's too many parentheses, and anyway Lisp doesn't have an XML-driven build engine like Blub does.

Reply on news.ycombinator.com