Hacker News Reader

Comment by silentbicycle | Hacker News Reader

I think it's impossible to have any kind of meaningful conversation about language design when one side is just writing off everything they don't like as "blub". It's incredibly condescending, no better than people reflexively writing off Lisp users as "lisp weenies".

View on HN

The "blub" argument fairly applies just as much to Lisp as it does to, e.g., Java. For example, (any dialect of) Lisp is my blub language, as I understand Lisp quite well. I do not understand Haskell to anywhere near the same extent. I've tried to learn it several times, but monad transformers consistently make my eyes glaze over. I am perfectly comfortable admitting this, and I intend to try harder to understand programming language concepts with which I am unfamiliar, rather than write off Haskell advocates as condescending.

I get what you're saying, but I think dropping the "blub" term would make everybody better off. Using "blub" intrinsically frames the conversation in terms of one language being "the stupid one used by the stupid people", and that's likely to be counterproductive. The word always has that baggage.

It's not a linear continuum, with some "most powerful language" at the top. Different styles of languages have different strong points and weak points.

I think monad transformers are starting to do Haskellers up in knots, especially when there are many types of computations you want to do which are by necessity monadic in Haskell.

I, for one, find uniqueness types to be an easier to understand and use solution to the problem of maintaining referential transparency in the face of a stateful universe.

Would it be as offensive to call the extra repetition that is inherent in some languages as "blub code", and languages like Arc trying to get rid of the blub(ber) in code?

I'd lean toward avoiding "blub" entirely; it sounds like you're implying their code (and brain) is full of mush. You're probably making a face like a fish blowing bubbles while you say it. Be civil!

As novel as this may seem, most people who regularly program in languages other than Lisp also consider excessively verbose code to be a bad thing. (Hence the interest in refactoring.) If you're dealing with someone who just started programming a few months ago, they don't have enough experience to know why it's problematic, but then, they probably need someone to be patient and helpful, rather than smug.

You can say, "There are some things that are inherently hard to express in some languages that come naturally in others, and until you have experience with a couple different styles of languages, you'll only really know techniques used in your main language. Learning new languages adds new techniques to your problem solving toolkit. It takes a while, but it'll make you a much better programmer in the long run.", and it doesn't make you sound like you're sneering inside.

If you want to make the point that the way their language's object framework is designed makes any nontrivial program in it have a bunch of repetitive boilerplate, say that. Name-calling makes people defensive, not likely to consider new ideas.

I can't tell if you're trying to be funny or not. If we want to make a point about how a language is better at letting us build useful abstractions, we have to spell out exactly what we mean by that every time, even though somebody has invented a word that macroexpands to exactly that?

It macro-expands to that, but there's an occasional variable capture bug that has the side effect of making one sound incredibly smug.

"Blub" is offensive, I agree. I've been bemused at the name-calling. It undermines the factual content and alienates adopters. Why do it? I wonder if an explanation is that name-calling simply isn't regarded as offensive within the community. For example, there's a development environment called "Slime"; and of course the name "Lisp".

Those aren't personal, though. The way "blub" is used is:

"You're writing in 'blub', therefore you're a 'blub' programmer, and all you're capable of understanding is 'blub'. Maybe some day you'll wise up and use my 'language for smart people' (LFSP)."

Yes you're right. I was trying to find a way to excuse them, and see them in a kinder light. But you're right. :-(

I hate to be "that guy", but I think you all might be misunderstanding the meaning of "blub".

Remember, "Blub" comes from the Blub Paradox (http://paulgraham.com/avg.html) in which one paradoxically believes that his or her language of choice (let's call it Blub) is the overall best language and that others are no good, usually due to missing some particular feature, or that they are too complicated.

An ironic example is that Paul Graham, who I believe is the creator of said paradox, asks rhetorically "If LISP is so great, why doesn't everybody use it?" and later, "I will say that LISP is at the top of the power spectrum." In effect, he's guilty of falling into his own paradox by assuming his language is at the top of the power spectrum, which is no different from assuming some other hypothetical language (that may have more capability than LISP) is too complicated.

I'm aware of where it comes from. The idea is that people who don't use lisp are so profoundly ignorant, that they don't even know they are ignorant. That's an offensive idea to start with. The second thing is that the word used to denote that concept, blub, is itself offensive, and it's used in an offensive school-yard way ("blub programmer"). It's surprising to see people promoting arc with this approach.

But reading your post closely, you're saying that blub strictly only refers to people who believe their language is the best and others are no good. In the avg.html article, it also says "How can you get anything done in Blub? It doesn't even have y." and talks about people looking down on less powerful languages. Therefore, a person programming in Java (or assembly or whatever) isn't a blub programmer unless he believes that language is the best, that others are no good, and he looks down on less powerful languages (maybe a more accurate word for this attitude is "snob".) My experience is that most programmers don't do that.

Well that depends on Paul Graham's knowledge of other languages. If Paul Graham knows Lisp and only Lisp, perhaps he's falling into the Blub paradox when it comes to Prolog. But if Paul Graham knows Lisp, C, Smalltalk, and Cobol, and has all the necessary language concepts from those to understand Ruby and Perl even if he hasn't used Ruby and Perl extensively, then he's on decent grounds to claim that Lisp is more powerful than those languages.

The blub paradox comes from someone who only knows Pascal doesn't understand why you'd want classes or functional programming. (We're assuming he only knows classical Pascal, not Delphi.) It accounts for the resistance of C hackers to object oriented languages (as illustrated, rather passive-aggressively, in such books as Object Oriented Programming in ANSI C), the resistance of Java coders to first class functions (we have a design pattern for that! it's called "functor"!) and so forth. It doesn't apply to someone who knows Haskell criticizing Java for OO fetishism, or a Java programmer scoffing at Pascal for not having classes.

And the only place where I've ever read pg as critical of another language's abstractions is his remarks on Prolog. Now, that might be because he's fallen into the blub paradox, or maybe he has a good enough understanding of Prolog to authoritatively say it's only useful for 2% of problems and gets in your way the rest of the time. I can't read minds.

Perhaps Prolog isn't very relevant to the sort of problems Paul Graham works on? Much of Peter Norvig's _Paradigms of Artificial Intelligence Programming_ is about Prolog (and logic programming in general); he ultimately implements a Prolog engine in Common Lisp, because it's a more appropriate tool for the sort of problems he's dissecting.

I only know the basics of Prolog from PAIP and CTM (one of many things I hope to get into deeper over the summer...), but it seems like it would be incredibly useful, albeit within a very specific niche. I wouldn't try to write an OS in make, but that doesn't mean it isn't handy sometimes.

Undoubtedly there's a category of "languages" that, despite their power, are only really useful for a specific application (make, yacc, SQL, PostScript) distinct from more general purpose languages. Perl used to be in the camp of specialized languages (need to munge some text?) but now it's squarely a general purpose language.

I've always seen Prolog billed as a general purpose language. If it's intended as a special purpose language, then it doesn't even make sense to criticize it compared to Lisp or C.

Indeed. Yet I was also trying to illustrate (albeit unsuccessfully) how the language snobbery is basically the same thing--a failing to recognize a language for what it's worth. As you point out, languages often have specialties and are better suited than more powerful languages for certain tasks.

it sounds like you're implying their code (and brain) is full of mush

That might be how some people use it... heck that might even have been the original intention, but I'd still rather just use it to describe the extra code a language makes you write.

If you think about it, there is no name for that... you could call it "cruft", but that's usually used to describe unnecessary verbosity in a framework or library, not the language itself.

"Boilerplate" has that meaning, but without the connotation that the person using it is automatically a moron.

http://en.wikipedia.org/wiki/Boilerplate_%28text%29

See also: Simon Peyton-Jones's "Scrap Your Boilerplate" papers (http://research.microsoft.com/en-us/um/people/simonpj/papers...)

Not all language cruft is created equil. I find the more more that happens within a line the easer it is to write but the harder it is to read.

x = (a = 7 * (b = 14)) + (c = 9 * ((d > 7)? e:f));

Now toss in some casts and the line becomes harder to read, but at the same time it's considered poor from to have 4 assignments on one line. Yet that's valid C, C++, Java, C# etc and it's got fewer symbols so it must be better according to the arc view of the world.

So is reqiring one assignment per line cruft or a good idea? How about those assignments? I would argue that one of the most useful mesures of a language is how easy it is to read other peoples code, but then you end up with something like Pascal...

PS: I acutaly like mantaining pascal code more than most languages then again it could have more to do with the experence of the people who use Pascal.

That's one line, yes, but what a line! That's 20 tokens or so, many of which are weird and hairy (the ? operator, multiple assignments). And in Lisp style you'd have that as multiple lines anyway.

True, but my point is it's more tokens if you write it as several lines. a = b = c 2; vs b = c 2; a = b;

So token count is still not really what we want to measure even if it's better than line count.

"it's more tokens if you write it as several lines"

As several lines or several statements?

x =

____(a = 7 *

________(b = 14))

____+

____(c = 9 *

________((d > 7)? e:f));

Same statement, same token count, multiple lines.

Statments, that's in no way easer to parse than that some code on a single line. (Assuming you have collar coding for the ()'s in your IDE.)

  c = 9 * ((d > 7)?e:f);
  x = ( a = 7 * (b = 14)) + c;

IMO is not that bad, it's the mixing of all the assignments and the conditional that makes it hard to parse, and

  c = 9 * ((d > 7)?e:f);
  x = c + (a = 7 * (b = 14));

is fairly readable even if some of the ()'s are not needed.

PS: ;'s I thought it was clear that the ;'s denoted lines not the whitespace which is meaningless.

Semicolons do denote statements, but that doesn't prevent you from clever use of line breaks. I still think my version is more readable.

Edit: NM, reply is now working.

I just wanted to say that personaly I have tryed learn to ignore indention and other clues becasue it's far more costly to misunderstand what the code is doing than try and use hint's that may have become old over time. To paraphrase: in that way lay bugs that look like dragons.

I also tend to do the same thing with comments on the first pass though. It's only when I don't understand the code or or it looks "odd" that I start to notice the extras like that.

I can't reply to: "Semicolons do denote statements, but that doesn't prevent you from clever use of line breaks. I still think my version is more readable." for some reason.

I just wanted to say...

Edit: NM, reply is now working so I moved the comment.

Just because such code parses, it doesn't mean you should write that way. Rather than requiring a ludicrously dense or terse style, most real projects will just have fairly reasonable coding standards (whether formally specified or just commonly understood) and expect you to exercise good judgment.

Besides, I don't think anybody is really expecting you to cram as much into one line as possible.

Care to suggest a short term that has the same denotational meaning without the connotations you dislike?

'cruft'

As noted elsewhere in the thread:

"Boilerplate" has that meaning, but without the connotation that the person using it is automatically a moron. (http://en.wikipedia.org/wiki/Boilerplate_%28text%29)

See also: Simon Peyton-Jones's "Scrap Your Boilerplate" papers (http://research.microsoft.com/en-us/um/people/simonpj/papers...)

Reply on news.ycombinator.com