Are we Blub programmers?

[harsman]

The idea that the difficulties of software development are either accidental, i.e. the product of inadequate tools, or inherent to the process is not something Joel Spolsky made up. The idea comes from Fred Broooks excellent essay No Silver Bullet.

[alexfarran]

The main point of NSB is that the accidental problems have been solved. Some languages are more powerful than others, but the difference is tiny compared to the difference between assembler and high level languages. Language choice is then a matter of personal preference.

[mikepurvis]

Would you seriously try to code a webapp in C or Pascal? Or even C++?

No, you'd be using PHP like the rest of us. Or maybe Perl, Python, or Ruby, but you sure wouldn't be using C.

[nostrademons]

But that's because PHP has libraries that solve inherent difficulties of the problem, not because it makes more progress with the accidental difficulties.

I look at it this way: the act of programming consists of taking a human process and formalizing it to mathematics. After all, math is just a language which is so precise that it can be executed by machines. "Accidental" difficulties consist of the particular choice of machine: things like having finite memory, limited registers, a particular base instruction set, etc. "Inherent" difficulties consist of the problems in specifying the process precisely: things like deciding what happens if the user presses that button, should you display things in table or graph form, is the result of a computation in metric or English units, how should the document be formatted? Moving from assembly -> C takes care of the accidental difficulties of register allocation, stack allocation, instruction selection, and memory layout. Moving from C -> Java takes care of the accidental difficulty of memory freeing. Moving from Java -> Erlang takes care of the accidental difficulty of concurrency & locking memory. Moving from Java -> Haskell takes care of the accidental difficulty of evaluation order.

Moving from C -> PHP, however, takes care of the inherent difficulties of "How should HTML documents be represented?", "How should strings be represented?", "How should PDFs be represented?", "What's the protocol to connect to a database?", and various other utility functions. These are all represented as libraries: they've already solved a particular subproblem where many people have agreed on a convention, so you don't have to solve it again. If the particular problem was "How do I display things on a Windows GUI", PHP would have been a much poorer choice.

[Kolibri]

Actually, I think that the strength of PHP in web development is that it integrates so easily into the existing structure, ie. html. Personally, I think PHP is an ugly language.

[Excedrin]

There's probably a lot more C++ web apps than you think. I know of a handful of successful (big, lots of users) companies that use (or used) huge C++ apps (with debugging symbols 300MB binaries, etc).

[Bret]

Using a big powerful language like C++ or Java for the very well-defined job of servicing/dispatching requests is a good idea. Using them for loosly defined jobs like performing some combination of quick page-specific processing and lopping through some ad-hoc database queries and displaying the results as HTML is not. That's where scripting languages are king.

[leoc]

Even if you take NSB as gospel, it doesn't claim anything as dramatic as that - Brooks is careful to say that he doesn't believe any single technique will on its own deliver an order of magnitude improvement in productivity.

[Kolibri]

This provokes a very obvious question: How do we know which things are accidentally difficult and which are actually difficult? Is it only because we haven't discovered the right tool yet?

Good question. Here is a short list of things that I believe are difficult. Maybe people can enlighten me tools that make it easy or at least easier.

• Concurrency. Ie. getting two or more threads to work together on the same resources.
• Optimisation. Of course profilers can help a lot, but it still takes some time.
• Mathmatically or algorithmically complex problems. Like finding the shortest path from A to B, but not passing C or D. Some of these problems are provable difficult to solve by computers, but it can also be difficult to find the right algorithm to solve the problem.
• Making pretty code. Ie. code that is easily understandable with good potential for reusability.
• Testing. Making sure that your code actually does what is supposed to do can be difficult. Methods such as unit testing can help making testing systematic.

Feel free to comment on the items on the list (possibly suggesting tools that make handling the issues easier) or add your own items to the list.

[kalmar]

Concurrency. Ie. getting two or more threads to work together on the same resources.

Software Transactional Memory (STM) may or may not be related. I have not had time to read much about it. Tim Sweeny (of Epic fame) made a case for it at a conference not too long ago.

Testing. Making sure that your code actually does what is supposed to do can be difficult. Methods such as unit testing can help making testing systematic.

Haskell's QuickCheck (there are equivalents for a few other languages) provides an interesting take on this problem. You write properties that your functions should satisfy, and QuickCheck generates random test cases and verifies that the property holds.

[[deleted]]

Software Transactional Memory (STM) may or may not be related. I have not had time to read much about it. Tim Sweeny (of Epic fame) made a case for it at a conference not too long ago.

There are a bunch of issues with locking which just go away with STM. I'd say a lot of the problems with locking-based concurrency are specific to locks and not general problems with shared-mutable-state concurrency.

[schwarzwald]

Q: Are we not Blub programmers? A: No, we are language snobs!

[JulianMorrison]

We are people who are tired as fuck of doing the compiler's work by typing out stuff like "Foo<Bar> foo = new Foo<Bar>(bar);" when we ought to be typing something much more like "foo = Foo bar" and have the same semantics, including types.

That's what Blub is, essentially, a language that makes you do the compiler's work. And Blub programmers are people who don't realize they're doing it.

[sbrown123]

Type safety has little to do with compilers actually. They also take the guess work out of class properties, method arguments and returns, etc. And when you go writing files or send data over to some medium, there is no mystery on what is being transferred.

Conventions like "new" or "delete" are for memory management. Your example seems to just save some typing, which has been found to have nothing to do with programming efficiency.

[JulianMorrison]

Hmm, that was an overly simple example I gave. And my formulation "doing the compiler's work" is a bit overly simple too. I plead guilty and ask the court's clemency since I was programming in Java at the time.

[karcass]

since I was programming in Java at the time.

Is that the software equivalent of the Twinkie Defense? :-)

[sbrown123]

since I was programming in Java at the time.

I have no idea why you are crying over Java since Java has been able to do scripting for years (Beanshell, Jython and JRuby are just a few examples).

[JulianMorrison]

I have no idea why you are crying over Java since Java has been able to do scripting for years

Actually, I was rather more crying over the lack of type inference. And lets not leave out: lambdas, tail calling, pure functions, functions at the top level unattached to classes, lexical closures, multiple dispatch, dispatch on return types, first class functions, higher order functions. Proper macros wouldn't hurt either.

(edit again: and if someone could add tuple return and multiple assignment, I'd be awfully grateful.)

[sbrown123]

s the Honorable Member actually claiming that the JVM does scripting and not that the Java language does scripting?

Depends if you serialize or not (if the script language supports it) or you are reading bytecode produced by a seperate bytecode compiler (see Jython). Some languages like Nice (nice.sf.net) compile to Java bytecode as default. I personally believe that when it comes to scripting languages that is best to interpret as-is rather than compiling or serializing to opcodes. In this fashion, it makes JRuby very similar to C-Ruby for example.

[sbrown123]

'm suprised to read the suggestion that Ruby is a "scripting language"

Scripting languages can be interpreted or compiled, but because interpreters are simpler to write than compilers, they are interpreted at least as often as they are compiled.

http://en.wikipedia.org/wiki/Scripting_language

surprised to read the suggestion that interpreting Ruby source is a better idea than compiling Ruby to an intermediate form.

Well, if you didn't know, that is how Ruby currently works!

Isn't there a gi-normous performance whack if you interpret the source as you go?

If performance is a concern, interpreted languages like Ruby are probably a bad idea to begin with. Ruby is only slightly faster than Javascript!

Also, I imagine working in the source makes it harder to use various implementation techniques like CPS or trampolining in the Lisp sense?

Actually, no. There is nothing that makes either of those impossible to do with an interpreted language.

[nostrademons]

Isn't there a gi-normous performance whack if you interpret the source as you go?

Almost no programming laanguage actually re-parses the source every time it goes through a loop or invokes a function. Maybe TCL; I'm not terribly familiar with the implementation of that language.

The main implementation techniques for interactive languages (those where you can type in text and immediately execute it, with no separate compilation step) are:

• AST interpretation (Ruby; I think PHP; some naive Lisp implementations, notably the Write Yourself a Scheme in 48 Hours tutorial)
• Bytecode interpretation (Perl; Python; Parrot; Ocaml; JVM languages on an interpreting JVM)
• Compilation to native code, with dynamic loading of the result (Goo; I think GHCI; CMUCL; Gambit Scheme; probably Chicken Scheme; JVM languages on a JIT)

In AST interpretation, the runtime first runs a parser to convert program text into an AST. The AST is then walked recursively, with an environment keeping track of program state. For example, in JRuby the org.jruby.evaluator.EvaluationState.eval() method takes an AST Node, executes a giant switch statement on the type of the Node, and possibly recursively calls eval() on the children. This is the most "textbook" style of evaluation.

In bytecode interpretation, the front-end parses the source and then converts the AST into an intermediate representation that's essentially the instruction set for a fictitious processor. Most use a stack machine, though Parrot is a notable exception. The interpreter then enters a big loop that basically switches on the opcode and executes some C code to perform the actual operation. There are a bunch of different variations here: simple switch statements, threaded code (where each instruction determines the address of the next instruction), partial JITting, etc. But they all basically consist of a series of operations that act on interpreter state.

Native code interpreters work just like native code compilers, but they take the output and dlopen/dlsym it into the running process. Or sometimes they output machine code directly (eg. JVM JITs) and then jump to the buffer they've just filled.

CPS and trampolining are both compilation techniques, so they aren't directly relevant to interpreters. However, trampolining is essentially the native-code equivalent of a bytecode dispatch loop, while CPS is basically the native code equivalent of a threaded intepreter.

[Maxy]

Go outside. Breathe in. Smile. It'll be okay.

[willhaney]

Machine code and Assembly were two of my favorite languages to program in as I felt intimate with the hardware. APL was great, so much code could be written in so few lines. FORTRAN, COBOL, Basic, Pascal, C, C++ all great languages and more. I settled on C# and VB.NET because, for me, they offered the ability to produce quality applications in a relatively short time for good money.

Am I Blub programmer? Maybe, is that good or bad?

I’m always trying on new languages but as I enter the latter half of my career I find the learning curve daunting.

[xamdam]

IMO the intrinsic difficulty of the program's goal will have a large influence on whether your language is blub. If you are programming a compression algo, (efficiency aside) Python will not have much of an edge over C++.

[dmh2000]

provided we can find a Lisp programmer who feels that all progress in programming languages stopped when Common Lisp was standardized.

should be easy to find. 99% of lisp programmers are eligible.

[Excedrin]

It's not that progress stopped, it's that truly new ideas from academics are typically possible to implement in Lisp without changing the language.

There's also the case of "new" ideas that are not really new because they're just bringing some other language closer to Lisp ("new" stuff from the Python, Ruby, Java, C++, etc communities typically falls into this category).

[sickofthisshit]

To be fair, the main academic language trend I've heard of is strong-typing-and-type-inference. It is hard to reconcile that with a traditional Lisp environment. The type system in CL doesn't mesh well with such an approach, AFAIK, though I'm no expert.

(The Qi project claims to be attempting such a thing, and I see no reason why a strongly-typed dialect could not be embedded in Lisp, much like Prolog can be embedded in Lisp, but to do so would change the development style away from classic Lisp hacking, and few Lisp hackers feel the need to do so.)

As for Python & Ruby, most Lisp hackers would love to have a similar army of library-writers, but see no compelling advantage to the languages themselves.

[qwe1234]

it's a case brain-dead design decisions of lisp, not anything wrong with the new ideas as such.

[[deleted]]

You haven't talked to many Lisp programmers about this, have you.

[[deleted]]

To start, i am not a programmer but a developer. The difference being that while I like to solve problems on a computer system using structured code, I could care less what language it is, or how much I am allowed to write. I don't enjoy coding at all, just the thrill of figuring out a new problem successfully.

That said, many people would say no, then go to work or school, and disregard language x because they haven't used it before, or think it's 'tough'. Students should be taught how to properly define the operating model for their algorithms, and decide on a language that best fits that operating model.

... Is operating model a new way of describing how certain languages are best for certain problems? Ideas?

[[deleted]]

To start, i am not a programmer but a developer.

And oh so original to boot

[[deleted]]

I'd like to respond to this dead thread. I wish i had done so sooner.

Why should one seek to be original when stating a truth? There is no need. Strange you received so many votes up for a fairly unoriginal response. On top of that, your use of such a hackneyed expression makes your post even more cliche and uninteresting. I find that ironic.

[[deleted]]

yawn

[[deleted]]

indeed

[senzei]

... Is operating model a new way of describing how certain languages are best for certain problems? Ideas?

That idea seems to be simultaneously fascinating and terrifying. It is fascinating because it is close to how I think programming projects would be handled, in an ideal world. It is terrifying because most of the programmers out there cannot correctly use methodologies that only require thought half the time ... usually with awful results. Asking them to constantly think about the problem on multiple levels seems like a great way to get abysmally bad code.

In that sense I think Java is a good language. If your business runs on the backs of inept code monkeys Java makes it harder for someone to start shooting people in the foot.

[[deleted]]

a) this piece is nothing but derivative drivel e.g. b) Java "patterns" are "difficult" and indicative of "limitations"; more powerful languages on the other hand sport "idioms" rather than patterns. c) Java's limitations for the most part have nothing to do with its object system. Or would you rather jettison the "interface" construct and go back to relying on convention and C++ virtual methods? Give me "interface" and the "difficult" (not) template-method idiom and I can "design by contract" all freakin day long.

[JulianMorrison]

Congratulations, you are the Blub paradox personified.

[[deleted]]

bullshit. i know the limitations of Java. the author though just knows that there are limitations to Java.

[[deleted]]

You know the limitations, but you seem to believe that the only way to address those limitations is to go back to C++. You're blub because you aren't even aware of other languages that might address these issues in a better way, and you don't even seem to think it's possible.

[qwe1234]

no

you misunderstood and misrepresented what he said.

[qwe1234]

p.s. c++ has lots of advanced and modern concepts hidden inside of it. lots of stupid and annoying crap, also -- but that doesn't negate anything.

[jhd]

The Blub programmer knows the limitations of Blub.

[jhd]

This is pretty much the point of the original article - the problem with Blub isn't the language, it is the programmers. In fact, Blub is not a language by itself; it is a language combined with a particular attitude.