11 ms·

The Flub Paradox

98 points by iopq 11y ago

raverbashing 11y ago
Well, but the thing is, productivity is not only about power of the language, but several factors, including proficiency in the given languages, available libraries, ease of getting developers in the given language, etc. And of course, on the article "A disruptive startup is more likely to use Blub in creative ways, focusing on the idea, not the implementation. Facebook dominated its market - using PHP - which everyone agrees is crap. Google built up the world's biggest advertising agency using Java and C++; Android is a Java-like ecosystem that runs in most pockets these days." Personally I don't care (too much) about using the fanciest language, but rather something a little more mature and easy to use. Your startup is not going to make or break because your language support macros in the vast majority of cases. And even then you can come up with a service that encapsulate that part and code everything else in your "normal language" "The vitriol surronding JavaScript is interesting and revealing" Absolutely. Everybody hates it, but there isn't a right answer, but it got popular (because of its power) and it works. Every language is going to have something people will hate.
- smitherfield 11y ago
  Javascript didn't get popular because of "its power," it got popular because it was the only option* and because of inertia (all legacy scripts on the web were/are in Javascript, because it was/is the only option). Edit: * Yes, I'm aware of VBScript, Flash, Java applets and ActiveX, and I'm aware they were all worse than JavaScript. Doesn't then follow that JS is good, or that it won on a level playing field. Frankly, it says something that for all its many faults Flash was often the superior option until the late 2000s.
  - raverbashing 11y ago
    > Doesn't then follow that JS is good Of course not, and, sure, Flash was a better alternative for a lot of time (but mostly for things outside of JS like HTML5 capabilities) C is not great as well, but between something good that doesn't do what is needed and a bad one that does guess what is used in the end.
    - smitherfield 11y ago
      I knew C; C was a friend of mine. Javascript, you're no C! When it appeared, C was a revolution in programming languages. It offered a combination of performance and expressiveness that simply outclassed anything else available (still true today, 43 years later, if more narrowly). It instantly became the most popular and held that position to this day, becoming a major influence on virtually every other popular programming language that's come since. Now, of course, C is much better suited for, say, writing an operating system than it is for writing security-intensive internet services. (A concept which did not exist in 1972). But, all things considered, it was as close to perfection as a new programming language has ever come at the time of its introduction. JavaScript is not even in the same realm; much superior, existing scripting languages (Python, Ruby, even Perl or some Lisp dialects) were passed over in favor of a deliberately half-assed effort to advertise Java with a language that shared a name and a superficially similar syntax, which (almost accidentally) became the only VM that any web browsers implement.
      - raverbashing 11y ago
        > much superior, existing scripting languages (Python, Ruby, even Perl or some Lisp dialects) were passed over Python existed in 1995, but I doubt it was very known at the time. Ruby was created in 1995 Lisp is older, sure, but maybe there were concerns about the syntax and interpreter requirements? "But, all things considered, it was as close to perfection" Pascal didn't have a braindead way of dealing with strings. C's syntax is weird and prone to bugs, "if (a = 1)" being one example.
        smitherfield 11y ago
        Yes, C's string handling is pretty crappy (especially given how important a data type strings are in Unix). And its operator precedence rules aren't always the best. But just like 10 million Elvis fans can't be wrong, neither can a language that is to programming what Elvis, the Beatles, and Michael Jackson put together were to music be anything other than a triumph of engineering. Better string handling or not, just as surely as video killed the radio star at about the same time, C killed the Pascal programmer. And the FORTRAN programmer, and COBOL, and BASIC, and assembler, and pre-1972 Lisp, and all the other old programming languages that are nowadays too obscure for me even to list. And operator precedence or not, every non-Lisp programming language of any popularity today apes C's syntax, not Ada or BASIC or somesuch. I'm not saying C is perfect. I don't even particularly like coding in C; I'm just saying that it just was a huge breakthrough in programming language design at the time it came out, and was overall the best designed language ever to that point (which, Lisp fanatics and Donald Knuth aside, I think most would agree with). Certainly not something you could ever say about JavaScript with a straight face. My point re scripting languages was that if Netscape had wanted to be on the bleeding edge, they still had much better choices. JavaScript is a programming language created in one week, where one of the major design considerations was to be an advertisement for a different programming language, and it shows. It certainly showed in 1995, before we had 20 years, billions of dollars and millions of man-hours invested by all the major companies in optimizing VMs, improving the standard, creating libraries and all the other miscellaneous forms of putting lipstick on a pig.
- rwallace 11y ago
  Agreed with most of the above, with the caveat that I actually like JavaScript. Sure, I have grumbled about JavaScript more than about various niche languages that are in some ways more mathematically elegant, but that's for the same reason I have grumbled about C, C++ and Python - they are all languages that get enough of the important things right that I've ended up actually using them enough to run into the rough edges.
echu_marbdan 11y ago
> Is BASIC more powerful than Assembly? I doubt it, you can do anything in assembly, and BASIC is deliberately limited [4]. Doesn't this definition make the "power" of all Turing-complete languages equal? > In other words, Lisp was the Flub of its day. A few years ago Flub was Haskell, and recently the new contender appears to be Rust, judging from the buzz. If the author thinks Haskell and, of all languages, Rust are most powerful, I think he has significantly misunderstood Graham's original essay. Among other things, they are statically checked with relatively difficult types that can take a long time to get right. That is obviously not the kind of language Graham had in mind for agily prototyping around corporate behemoths. The author seems to define Flub as "the most popular language among the elite". Lisp was rarely even that, however, and we also have painfully obvious evidence of the most popular not being the most powerful. As such, I think a large portion of this essay hinges on a strawman: he dismantles a definition of Flub that Graham never used. > The Flub Paradox can be stated like this: although Flub is self-evidently more powerful and productive than Blub, relatively few people use it and its effect on the real landscape of innovation appears minimal. Is this really a paradox anymore? We have so many examples of inferior products dominating through inertia that I've completely lost my faith in humanity at this point. I could add a few more points, but I think that would only be unnecessarily negative. I do like some points from the essay. I agree that we should take another look at Paul Graham's power continuum: for instance, the power of Lisp scales with lines of code (with low LOC, macros don't really enter the equation, and using a "batteries included" language with comprehensive libraries is probably faster). Haskell is easier than many agile languages to refactor, another important dimension to consider. And so on.
- stevedonovan 11y ago
  My mistake was to do exactly what PG did not do; name names. By Flub I mean any new language that its users would like to see displacing Blub. I mentioned Haskell and Rust as _examples_ of languages which have gone through popularity surges, and remain curious why they haven't made more of an impact, by PG's original logic: pick the most powerful language you know.
  - echu_marbdan 11y ago
baldfat 11y ago
> To use it effectively, however, requires using an IDE, and Flubbists hate IDEs, partly because their finger muscle memory has been overspecialized from spending too much time in Eighties power editors, but also because using an IDE is too closely associated with Blub practices. (People who can't ride a bicycle without training wheels, basically.) This also has an attitude. Certain things an IDE is almost required, for example Data Science with a REPL. IDEs like RStudio and Jupyter (AKA IPYthon) or for SML dialect Racket's REPL. Also this is anti VIM and EMACs?
- stevedonovan 11y ago
  Ever so slightly ;) I think it admirable that people invest a lot of time in the environments they spend so much time in, but a professional has to be flexible. (It is entirely possible that my sarcasm got out of control here.)
  - veddox 11y ago
    Just out of curiosity, what makes you say IDEs are bad?
    - baldfat 11y ago
      The article is negative about IDEs. I was stating that in fact IDE can be a valuable tool for specific areas.
    - marcosdumay 11y ago
      IDEs aren't bad, but... Automatic code generation is bad (unless its completely automatic in "you don't ever see it"), because code always have to change, and changes aren't automatic. Heavyweight building setup is bad, because you can not replicate or automate it. Long names everywhere hinder legibility. (Although long names on confusing or ambiguous places are a good thing.) And, finally, people learning to program should learn how to program without one at some point, so they know what they are doing. None of that makes IDEs bad. It just neuter their biggest selling points, but there are lots of small gains you can get from one.
olavk 11y ago
Is there even a meaningful definition of 'powerful'? I guess C# 4 is strictly more powerful than C# 2 since it only adds features, but how to compare the power of Haskell versus Rust? They are designed for different domains.
- stevedonovan 11y ago
  Of course, I wanted to emphasize that there is no single power continuum, so PG's argument rests on sand.
  - Retric 11y ago
    There is for each problem domain, spreadsheets for example are a great tool for a tiny set of problems. Lisp was incredibly well suited to solving ViaWeb's problems. The landscape changed and continues to evolve, but I can't use 2050's programming languages. So, picking the best language for each project based on when your starting it really is an important choice. Also of note, Lisp was an old language in the mid 90's so the compiler was a non issue.
Anderkent 11y ago
Is the idea of a single language that's clearly better than anything else, for everything, a common one? If one thinks of languages as tools, it seems pretty obvious that different languages will be the best tool for different kinds of tasks. Are you writing a REST wrapper around an existing java toolset? Clojure's your friend. A cryptographic, secure communication library? Rust is probably (going to be? in a couple months?) the way to go (unless you only care about the jvm). Or maybe you're gluing a couple unix tools together in a fairly complicated fashion, in which case something like python is likely the right choice.
- cousin_it 11y ago
  What if it's a large project where you have to do all these things? Would you run ten different language runtimes, each with its own garbage collector? Would you pay the cost of marshaling and unmarshaling data at the boundaries? What about training new programmers to understand and extend your system? What if you want to move some functionality from one part of the system into another, can you do it easily? Etc, etc. There's a lot of value in adopting one general purpose language as a company-wide standard, like Java. It doesn't have to be an excellent fit for every task, but it has to be adequate and not have any major flaws. That's harder than it sounds. I like the Rust approach (memory safety without GC), though Rust itself might not be the best possible realization of that approach.
  - iopq 11y ago
    The great thing about Rust is that it doesn't need to be garbage collected, so it's easy to use inside a Ruby project. That's why you can use Rust in a lot more places than you would use Java.
tempodox 11y ago
Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more formally defined beasts fed by mathematical concepts. That's one trend I expect to continue, but then also not ad infinitum. In my view, Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. I want more math in PLs, but I feel we haven't found a good balance yet. Maybe this turns out to be a moving target, too. There are two languages I expect to keep their (niche) places for the foreseeable future: C and Lisp. Both are such a peculiar mix of properties that they are incredibly hard to beat in their respective domains. Maybe the same goes for Ada and Java, I wouldn't want to do any injustice :)
- pron 11y ago
  There are a couple of things I disagree with. First, you are lumping together trends in academia with trends in the industry, and the two are not always in tandem, though they certainly influence one another. For example, Go, a language that certainly goes against this trend, is gaining popularity much faster than any academic or academically-influenced languages (of course, it's easy to grow fast when you're small, but it's more academically inspired languages are just as small). This mixing of the domains which in reality is quite complex is also apparent in your examples. C is one of the most popular languages in use, and has been for a few decades; Lisps have been around even longer and has never broken beyond around, say 1% of production projects (except maybe for a very short while in the eighties). Second, you say "I want more math in PLs" when referencing Haskell. While it is true that pure-FP, because of its relationship to some types of logic, lets you prove some properties about your code in the code itself, that does not make it any more mathematical than other languages and other approaches. For example (and I give this example often, but only because I'm really impressed by that language), Esterel, a language designed in the eighties is an imperative language with lots and lots of global side effects, yet it allows you to verify its correctness absolutely, and you don't even need to write the proof yourself (it verifies temporal properties that are especially hard to prove using PFP). Esterel and languages (mostly graphical languages) inspired by it have been used by the industry orders of magnitude more than PFP languages for domains where correctness is crucial. That PFP allows you to write some proofs in code does not mean that there aren't better ways to verify programs mathematically. PFP is the answer if what you're asking for is more second-order logic in your PL; it's just one of many if you're just asking for more math (in fact, it's just one of many even if you want more interesting type systems). Also, it's hard to trace influences, but I believe that the focus on immutability that is finding its way into more and more languages is actually inspired by Erlang and later Clojure, two languages that have little to do with PFP, and a lot to do with the design of multi-core and distributed systems. It was not the current academic trend of pursuing the Curry-Howard correspondence as a software verification technique, but an industry solution for the problem of handling concurrency.
tatterdemalion 11y ago
The description of Rust in this blog post is not accurate in my opinion. 1. Compile times aren't great right now, but 20s for 2400loc is a real anomaly, and improving compile time is a focus of the team now that the language is stable. This is the only specific painpoint the blog post mentions with Rust, and its just a single anecdote. 2. The idea that Rust is a premature optimization is a weird meme. Faster, safer, more expressive. Rust is at least 2/3 for pretty much every 'mainstream' language. I would rather write Rust than any other language I know, and I would be more productive in it. 3. Rust is not a Flub language struggling to overcome a niche - not yet. Rust is a language that became stable 3 weeks ago and time has not yet told whether it will be 'mainstream' or not. Rust has a memory model that includes some degree of manual management, like C (instead of malloc/free and pointer arithmetic, you have ownership and references). This makes it a poor first language, like C. But no one says C is a language for the 'elite' because you have to think about the memory model.
- stevedonovan 11y ago
  It was perhaps unfair to single Rust out given that it is so young, but there are costs to any innovation, and the first cost that leaped out at me was stories of long compile times. Besides, extraordinary claims require extraordinary evidence. Personal anecdotes of increased productivity remain anecdotal - it may be more a property of the programmer than the language. I don't personally have a horse in the race, but pointing out cost points is needed.
  - jerf 11y ago
    I really don't expect Rust to exhibit what most people mean by "increased productivity", ever. Most people mean something fairly local by that, or at most medium sized, that it allows them to take some task and write code faster than other languages that accomplishes the task. Rust is always going to labor under the disadvantage that it holds you to a higher degree of correctness than other languages, and at best it can tie with another language that doesn't hold you to those guarantees of correctness. Where it'll increase productivity or not is at larger scales. If Servo comes out at production quality in some reasonable time (call it 2 years or less from now, given where they are), able to function on the general web most of the time, and it's also faster than current renderers by a significant margin, and with some small fraction of the development effort (probably even if you include the entire Rust development effort; do not underestimate the effort poured into the existing engines!), I will consider Rust's story proved. We've now had many people take cracks at writing renderers, in the fastest language of the time for the task (C++), and I daresay they've converged at fairly similar levels of performance with little reason to believe the renderers are going to get much faster. Said renderers have had massive optimizations applied to them, and this Servo that I'm expecting to be much faster will actually be version 1.0, basically. If Rust is to work at all, there will very, very rapidly be a class of development that it will be actually insane to write in anything but Rust... but that will only be the very high-and-large end. (It will take many more years for this fact to penetrate through to the development community at large.)
VLM 11y ago
Three observations, of the smallest fine tuning variety (its pretty good as is): The essay fluidly rotates between two points of view best expressed by two direct quotes: "Note: this is about tracking fashion, not a comment on the actual virtues of these languages." and "getting things done". I don't think those are synonyms or have much to do with each other so the close intermixing is a bit jarring. Often enough they oppose each other. They don't get along so its hard to use them as supporting arguments even if true. Another observation is hard to quote but boils down to languages and paradigms are synonyms, which I disagree with. A language is a pile of paradigms wrapped up in some syntax to formalize it. You can write FORTRAN or perl in any language. Or functional, at least somewhat. Its easier to write worse programs than the language and very hard to write better programs than the level of the language. In that way LISP is the master language above all the others because it can express seemingly anything therefore if everything is beneath it, its above everything. The third paragraph is closest to what I'm trying to express and it comes very close to hitting the mark. It would be interesting to see logic programming in a safety critical embedded space. I'm not sure if it would be "good" interesting or "train wreck" interesting. That would be an interesting suggestion for the second to last paragraph. If you define safety as solving a full set of safety constraints, then automating it would look like ...
kyllo 11y ago
The author holds up Yesod's low adoption rates (compared to what? Ruby on Rails? Ruby was arguably Flub a few years ago, and Yesod is much younger than Rails) as an example of how powerful programming languages aren't making as big of a dent as they should be. But the thing is that yesod is a CRUD web app framework, and although Haskell is quite capable at CRUD apps, they're not where it really shines. Look at Haskell (and OCaml and F#)'s adoption rates in the financial sector and you'll see "Flub" kicking some serious ass.
_lce0 11y ago
> The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. pg wrote that in 2003 nowadays, what would be the most frightening langs?
- Ygg2 11y ago
  Scala, Rust, Haskell, JavaScript, VHDL, ASM and PHP :P If joke languages count then Brainfuck and BS[1] [1]https://skillsmatter.com/skillscasts/6088-the-worst-programming-language-ever https://skillsmatter.com/skillscasts/6088-the-worst-programm...
- JanneVee 11y ago
  It is not the languages themselves that are scary. It is the people using them. So if the competition look for e.g. Erlang programmers and you don't for some kind of messaging app. Then you should be worried. If they use it for big files, then you should be less worried. Because they need to solve a few more limitations in Erlang/OTP to make it work well.
haddr 11y ago
You could also summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person. That means that not always the best one wins, but the one which has most appealing properties. And those are not necessarily the "beatifulness" or some academic aspects, but rather: popularity (and easyness of finding programmers), understandability, availability of 3rd party libraries, productivity and more...
- jasode 11y ago
  >summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person. I wouldn't summarize it that way. More accurate would be: "the effectiveness of a programming language is driven by multi-dimensional factors instead of a single factor such as expressiveness of syntax. One's expert usage of a language can lead him to overestimate its overall effectiveness." When people debate programming languages using words like "simple", "powerful", "better", it's not very precise. It's actually misleading. All those labels have multidimensional factors but people discuss them as if they are a single dimension scalar. E.g. "Golang is simple" -- it's simple in keyword count but not simple in terms of implementing a family of algorithms that differ only by type. The paradox of "simple" has contradictory conclusions because that word has multiple dimensions. Therefore, if one's typical use case of Go does not involve templated algorithms, it is perceived as "simple" and one would proceed to evangelize the language as "simple." Same type of analysis can be done for words like "power", "better", "easier", etc. Yes, languages like Haskell/Lisp/Ocaml/F# etc have more expressive syntax but there are other dimensions in creating software that can overwhelm that advantage. This is why PG can have reasonable opinion on the "power" of Lisp but Aaron Schwartz came to a different reasonable opinion[1] and determined Python in his case to be more appropriate for Reddit. Aaron was not stupid and he knew how to write Lisp. To understand Aaron's viewpoint, you have to notice that he's using different dimensions of the word "better". [1] http://www.aaronsw.com/weblog/rewritingreddit http://www.aaronsw.com/weblog/rewritingreddit
  - haddr 11y ago
    I agree, but then again, the market accounts for all those "multi-dimensional factors". Maybe what should be added is that there are external and interal factors that decide of which language is better. External factors have been already discussed. Internal ones are those that correspond to the company internal structure, culture, etc. For instance: If you have a team of people writing Java you wouldn't choose Python at all.
amelius 11y ago
> it is unlikely that major operating systems will emerge written entirely in Rust Why?
- dtech 11y ago
  It is unlikely that a major new operating system will emerge at all because of high investment cost, momentum and compatibility
camperman 11y ago
I just got back from a very positive strategy meeting with my partner (I do the code and he does the ops and the sales) and this essay struck a chord with me. Why are we making so much progress when I'm a decidedly average programmer? I think it's because I'm a decidedly average programmer in enough languages to know what their strengths and weaknesses are and thus to be able to pick the right tool for the job: - hardware-accelerated video decoding on the ARM - C obviously, with a small amount of ASM. - web server - Python using web2py - web interface prettiness - jquery and javascript - server processes and admin automation - Python - core apps - Luajit because it's so fast on the very limited ARM boxes we're using - customer data munging and reports - emacs lisp because it's right there - desktop apps for Windows, OSX and Linux - Python again - some bash and Perl for sysadmin stuff What Steve doesn't say - although it is implied - is that he knows enough languages at a practical level to make these kinds of judgement calls. And I know for a fact he's a far better coder than I am because I use his Penlight library for Lua every day. Perhaps Flub can never be a force for change the way Lisp was because modern languages are incorporating enough features from Lisp to bring them close enough to the top of the hierarchy not to matter as much as before.
- Dewie3 11y ago
  That's a nice kitchen sink full of languages.
michaelochurch 11y ago
This is intelligently argued and articulate but the content is a bit lacking. First, Paul Graham isn't an expert on languages. He wrote a decent Lisp book, years ago. Relative to VCs, he's a technical genius. Relative to technical geniuses, he's a VC. I respect him for taking iconoclastic positions against the Establishment, and I miss that Paul Graham, but... he has serious blind spots when it comes to, say, statically typed languages. Now, PG probably intended "Blub" to mean a mediocre language du jour like C++ (in the early 1990s) or Java (since the late '90s) but Blub is more of an attitude than a language. Yes, there really are one-language programmers who can't think out of a specific paradigm. They exist, and they're the ones who write FactoryVisitorFactory classes because they haven't been exposed to functional programming and the right way of solving certain problems. That said, there are cases where C or Java is the absolute right language to use. Not many, for Java, but they exist. Not everyone who uses those "Blub languages" is a mediocre programmer; Java is not always Blub, and C is definitely not always Blub (in fact, it's out of fashion among the Blubanistas, who avoid low level programming because "it's too hard".) As for "Flub"... I don't even know where to begin. Just going to snipe specific points. 'Power' and 'Expressiveness' turn out to be separate concepts. In the end, there is no simple continuum that you can use to line programming languages up, nose to tail, feeble to awesome. I agree with this, whole-heartedly. Assembly and C, I would argue, are more powerful than Haskell because it makes it so much easier to create custom control flows and to manage memory explicitly. Haskell is more expressive. You trade some power, in exchange for a language that allows you to write very robust code, very quickly. But sometimes you need that power and C is the best option. To use it effectively, however, requires using an IDE, and Flubbists hate IDEs, partly because their finger muscle memory has been overspecialized from spending too much time in Eighties power editors, but also because using an IDE is too closely associated with Blub practices. No, we dislike IDEs (actually, we don't; we dislike broken languages and codebases that require us to use IDEs) because it's a lot easier to keep flow when you're using the keyboard only. Switching to the mouse to recompile breaks flow. IDEs also have a stigma because they're most useful when you're maintaining other peoples' code, which generally is a disliked sort of work given to juniors. So, IDEs tend to be associated with the second-class programmers who spend most of their time on maintenance work. I, personally, think the "reading code is for losers" attitude that many programmers cop is stupid and counterproductive. I enjoy reading good code and I wish that I had better tools for doing it. A disruptive startup is more likely to use Blub in creative ways, focusing on the idea, not the implementation. Facebook dominated its market - using PHP - which everyone agrees is crap. Google built up the world's biggest advertising agency using Java and C++; Android is a Java-like ecosystem that runs in most pockets these days. Oh, this shitty argument. "Your tech should be boring, your product should be interesting." Yawn. It's a bullshit argument and I'll tackle it another time. Google was originally written in Python, which was more of a reach than Haskell is now. Python sucked in 1998. Also, the late '90s were a time when PL was considered to be a dead field, so PL never worked its way into Google's DNA and it's stayed that way. They use C++ because it was the best choice in the late 1990s, and they tolerate Java in the context of acquisitions, and when they tried to come up with their own language... the best they could do is Go. Facebook started on PHP but is increasingly innovative on the language front, with Erlang, Ocaml, and Haskell getting a presence. You put a group of merely good Lisp programmers on a project, and embed them in a corporate environment, and the stellar results are likely to be not reproducible. (I don't doubt they will be more productive than Java programmers. But will the result blend?) "Will it blend?" I'm sorry, but I prefer not to think of my work as something that will be ground to a pulp. If that's the kind of work you want, then hire a Scrum drone, not someone like me. Big companies understand this problem well, and prefer Blub programmers, who are easier to source and come with less attitude. False. Do Haskell programmers come with more "attitude" than mediocre Java programmers? Yeah, there's probably a slight difference. However, the problem isn't "Haskell programmers" or "Java programmers" but people. People are just a pain in the ass: all of us, to some degree. Since you need 30 Java programmers to do the work of 5 Haskell programmers, you not only have more sources of "attitude" with the 30, but you have more politics and less per-person productivity on account of the larger team.
deleted 11y ago
[deleted]
- deleted 11y ago
  [deleted]
agentultra 11y ago
The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub program is non-trivial. In data-oriented design the mantra is, "the hardware is the platform." A given CPU comes with some instructions it understands and our job as programmers is to use those instructions to apply transformations to a stream of data. The optimal language is of course the assembly language of the target platform. However it's often more practical to use a language that compiles down to a target platform's instruction set with the fewest number of transformations (barring the presence of optimizations). Flub languages attempt to give programmers the tools to write programs which hold some provable invariant, provide denotational semantics, or some combination of these. The benefit of this is some reduced cognitive load, expressive power, and other "soft" features. This power is what lets small teams run circles around Blub programmers in the Blub/Flub paradox. However the utility of these features and whether they actually do allow small teams to get more work done in less time hasn't been proven to me yet. It may seem tedious to think to think of the statistically significant data-access pattern in a given operation and forming your data-structures and transformations to make that access pattern the fastest route for the target platform... but it has big wins in terms of execution speed of the programs and the maintainability of such programs. One still requires a significant amount of mathematical reasoning and understanding of what a compiler can and cannot do for you. I'm slowly coming to the opinion that there won't ever be a compiler or Flub language that will give you your cake and let you eat it too. In practice I've found re-usability to be a low-priority concern, generics to be a performance hindrance, and I've yet to find a convincing example of how type-safety is the future of mission-critical software (though there are some promising projects for sure). Thus in conclusion: I think Blub languages will continue to rule the roost. Flub will come and go and remain fashionable as the OP has alluded to. However I don't think it's the avenue worth pursuing in order to write better programs... too much abstraction makes it rather difficult to reason about what our programs are actually executing on the target platform and for many cases that can be critical. It always comes down to the data and at some-point one needs to consider the target platform anyway. Data-oriented design is one way to think of the data first and allows the programmer to choose the appropriate semantics for the necessary transformations to be expressed by their program. (I hope I'm making sense).
- 11y ago
apalmer 11y ago
No offense, but the whole essay hinges on some core concepts that are NOT logically robust, hence the ultimate 'paradox' is really simply an application of reductio ad absurdum Basically the premise of what it means to be 'powerful' is at best ill defined, and most likely is not logically consistent. More or less there is no clear qualitative definition for 'powerful', nor is 'powerful' meaningful across all developers, organizations, or application. Now by an empirical definition in this context the meaning of 'powerful' is clear. 'Powerful' means how strongly the program language selection correlates with successful projects... based on that the 'powerful' languages are pretty much the 'blub' languages. there are many many successful PHP, Java, and especially C projects.
RHSeeger 11y ago
> It could have easily been something much worse, like Tcl. Ouch. Tcl might not be the right choice for many situations, but it's a fantastic language for many. It is, by far, one of my favorite languages to work in.
markc 11y ago
>Clojure is an attempt at re-Flubbing Lisp. And it's a successful attempt - unless you require top tier adoption to qualify. >Where is Flub being used as a secret weapon, in the way described by Paul Graham? Why aren't its practitioners exploiting their natural advantage? Clojure is a good candidates for Flub not only because of its power and expressivity (and as a Lisp, its natural fit as a PG-style Flub), but because it is being exploited to advantage by those who've discovered it. A small sampling includes: Adzerk, Beanstalk, CircleCI, Cognitect, Consumer Reports, Daily Mail, Database Labs, Democracy Works, Deutsche Bank, eBay, Factual, FarmLogs, Groupon, Heroku, Intuit, LivingSocial, ViaSat, MixRadio, Netflix, Nubank, OpenTable, Pivotal, Precursor, Prismatic, Puppet Labs, RoomKey, Sonian, Soundcloud, Spotify, Staples, Teradata, ThoughtWorks, Cisco, Two Sigma, Upworthy, uSwitch, World Singles, Innovation Labs, Zendesk, ... (sorry If I left out your awesome Clojure-fueled project/company but the list is too long) The Clojure experience at these companies seems to mostly fall somewhere between gushingly effusive and merely enthusiastic. Sure, there's some self-selection, and it's hard to separate developer talent from language choice in those successes, but read a few case studies and you start to get the impression that Clojure itself is not only an advantage, but a significant one. That's not to say that Clojure is the only good candidate for flub; there are other powerful, productive, and pragmatic languages that can deliver high productivity in the right context. But if I had to pick one language to be dubbed Flub, it would be Clojure.

98 points by iopq 11y ago

Well, but the thing is, productivity is not only about power of the language, but several factors, including proficiency in the given languages, available libraries, ease of getting developers in the given language, etc. And of course, on the article "A disruptive startup is more likely to use Blub in creative ways, focusing on the idea, not the implementation. Facebook dominated its market - using PHP - which everyone agrees is crap. Google built up the world's biggest advertising agency using Java and C++; Android is a Java-like ecosystem that runs in most pockets these days." Personally I don't care (too much) about using the fanciest language, but rather something a little more mature and easy to use. Your startup is not going to make or break because your language support macros in the vast majority of cases. And even then you can come up with a service that encapsulate that part and code everything else in your "normal language" "The vitriol surronding JavaScript is interesting and revealing" Absolutely. Everybody hates it, but there isn't a right answer, but it got popular (because of its power) and it works. Every language is going to have something people will hate.

smitherfield 11y ago
Javascript didn't get popular because of "its power," it got popular because it was the only option* and because of inertia (all legacy scripts on the web were/are in Javascript, because it was/is the only option). Edit: * Yes, I'm aware of VBScript, Flash, Java applets and ActiveX, and I'm aware they were all worse than JavaScript. Doesn't then follow that JS is good, or that it won on a level playing field. Frankly, it says something that for all its many faults Flash was often the superior option until the late 2000s.
- raverbashing 11y ago
  > Doesn't then follow that JS is good Of course not, and, sure, Flash was a better alternative for a lot of time (but mostly for things outside of JS like HTML5 capabilities) C is not great as well, but between something good that doesn't do what is needed and a bad one that does guess what is used in the end.
  - smitherfield 11y ago
    I knew C; C was a friend of mine. Javascript, you're no C! When it appeared, C was a revolution in programming languages. It offered a combination of performance and expressiveness that simply outclassed anything else available (still true today, 43 years later, if more narrowly). It instantly became the most popular and held that position to this day, becoming a major influence on virtually every other popular programming language that's come since. Now, of course, C is much better suited for, say, writing an operating system than it is for writing security-intensive internet services. (A concept which did not exist in 1972). But, all things considered, it was as close to perfection as a new programming language has ever come at the time of its introduction. JavaScript is not even in the same realm; much superior, existing scripting languages (Python, Ruby, even Perl or some Lisp dialects) were passed over in favor of a deliberately half-assed effort to advertise Java with a language that shared a name and a superficially similar syntax, which (almost accidentally) became the only VM that any web browsers implement.
    - raverbashing 11y ago
      > much superior, existing scripting languages (Python, Ruby, even Perl or some Lisp dialects) were passed over Python existed in 1995, but I doubt it was very known at the time. Ruby was created in 1995 Lisp is older, sure, but maybe there were concerns about the syntax and interpreter requirements? "But, all things considered, it was as close to perfection" Pascal didn't have a braindead way of dealing with strings. C's syntax is weird and prone to bugs, "if (a = 1)" being one example.
      - smitherfield 11y ago
        Yes, C's string handling is pretty crappy (especially given how important a data type strings are in Unix). And its operator precedence rules aren't always the best. But just like 10 million Elvis fans can't be wrong, neither can a language that is to programming what Elvis, the Beatles, and Michael Jackson put together were to music be anything other than a triumph of engineering. Better string handling or not, just as surely as video killed the radio star at about the same time, C killed the Pascal programmer. And the FORTRAN programmer, and COBOL, and BASIC, and assembler, and pre-1972 Lisp, and all the other old programming languages that are nowadays too obscure for me even to list. And operator precedence or not, every non-Lisp programming language of any popularity today apes C's syntax, not Ada or BASIC or somesuch. I'm not saying C is perfect. I don't even particularly like coding in C; I'm just saying that it just was a huge breakthrough in programming language design at the time it came out, and was overall the best designed language ever to that point (which, Lisp fanatics and Donald Knuth aside, I think most would agree with). Certainly not something you could ever say about JavaScript with a straight face. My point re scripting languages was that if Netscape had wanted to be on the bleeding edge, they still had much better choices. JavaScript is a programming language created in one week, where one of the major design considerations was to be an advertisement for a different programming language, and it shows. It certainly showed in 1995, before we had 20 years, billions of dollars and millions of man-hours invested by all the major companies in optimizing VMs, improving the standard, creating libraries and all the other miscellaneous forms of putting lipstick on a pig.
rwallace 11y ago
Agreed with most of the above, with the caveat that I actually like JavaScript. Sure, I have grumbled about JavaScript more than about various niche languages that are in some ways more mathematically elegant, but that's for the same reason I have grumbled about C, C++ and Python - they are all languages that get enough of the important things right that I've ended up actually using them enough to run into the rough edges.

echu_marbdan 11y ago

> Is BASIC more powerful than Assembly? I doubt it, you can do anything in assembly, and BASIC is deliberately limited [4]. Doesn't this definition make the "power" of all Turing-complete languages equal? > In other words, Lisp was the Flub of its day. A few years ago Flub was Haskell, and recently the new contender appears to be Rust, judging from the buzz. If the author thinks Haskell and, of all languages, Rust are most powerful, I think he has significantly misunderstood Graham's original essay. Among other things, they are statically checked with relatively difficult types that can take a long time to get right. That is obviously not the kind of language Graham had in mind for agily prototyping around corporate behemoths. The author seems to define Flub as "the most popular language among the elite". Lisp was rarely even that, however, and we also have painfully obvious evidence of the most popular not being the most powerful. As such, I think a large portion of this essay hinges on a strawman: he dismantles a definition of Flub that Graham never used. > The Flub Paradox can be stated like this: although Flub is self-evidently more powerful and productive than Blub, relatively few people use it and its effect on the real landscape of innovation appears minimal. Is this really a paradox anymore? We have so many examples of inferior products dominating through inertia that I've completely lost my faith in humanity at this point. I could add a few more points, but I think that would only be unnecessarily negative. I do like some points from the essay. I agree that we should take another look at Paul Graham's power continuum: for instance, the power of Lisp scales with lines of code (with low LOC, macros don't really enter the equation, and using a "batteries included" language with comprehensive libraries is probably faster). Haskell is easier than many agile languages to refactor, another important dimension to consider. And so on.

stevedonovan 11y ago
My mistake was to do exactly what PG did not do; name names. By Flub I mean any new language that its users would like to see displacing Blub. I mentioned Haskell and Rust as _examples_ of languages which have gone through popularity surges, and remain curious why they haven't made more of an impact, by PG's original logic: pick the most powerful language you know.
- echu_marbdan 11y ago

baldfat 11y ago

> To use it effectively, however, requires using an IDE, and Flubbists hate IDEs, partly because their finger muscle memory has been overspecialized from spending too much time in Eighties power editors, but also because using an IDE is too closely associated with Blub practices. (People who can't ride a bicycle without training wheels, basically.) This also has an attitude. Certain things an IDE is almost required, for example Data Science with a REPL. IDEs like RStudio and Jupyter (AKA IPYthon) or for SML dialect Racket's REPL. Also this is anti VIM and EMACs?

stevedonovan 11y ago
Ever so slightly ;) I think it admirable that people invest a lot of time in the environments they spend so much time in, but a professional has to be flexible. (It is entirely possible that my sarcasm got out of control here.)
- veddox 11y ago
  Just out of curiosity, what makes you say IDEs are bad?
  - baldfat 11y ago
    The article is negative about IDEs. I was stating that in fact IDE can be a valuable tool for specific areas.
  - marcosdumay 11y ago
    IDEs aren't bad, but... Automatic code generation is bad (unless its completely automatic in "you don't ever see it"), because code always have to change, and changes aren't automatic. Heavyweight building setup is bad, because you can not replicate or automate it. Long names everywhere hinder legibility. (Although long names on confusing or ambiguous places are a good thing.) And, finally, people learning to program should learn how to program without one at some point, so they know what they are doing. None of that makes IDEs bad. It just neuter their biggest selling points, but there are lots of small gains you can get from one.

olavk 11y ago

Is there even a meaningful definition of 'powerful'? I guess C# 4 is strictly more powerful than C# 2 since it only adds features, but how to compare the power of Haskell versus Rust? They are designed for different domains.

stevedonovan 11y ago
Of course, I wanted to emphasize that there is no single power continuum, so PG's argument rests on sand.
- Retric 11y ago
  There is for each problem domain, spreadsheets for example are a great tool for a tiny set of problems. Lisp was incredibly well suited to solving ViaWeb's problems. The landscape changed and continues to evolve, but I can't use 2050's programming languages. So, picking the best language for each project based on when your starting it really is an important choice. Also of note, Lisp was an old language in the mid 90's so the compiler was a non issue.

Anderkent 11y ago

Is the idea of a single language that's clearly better than anything else, for everything, a common one? If one thinks of languages as tools, it seems pretty obvious that different languages will be the best tool for different kinds of tasks. Are you writing a REST wrapper around an existing java toolset? Clojure's your friend. A cryptographic, secure communication library? Rust is probably (going to be? in a couple months?) the way to go (unless you only care about the jvm). Or maybe you're gluing a couple unix tools together in a fairly complicated fashion, in which case something like python is likely the right choice.

cousin_it 11y ago
What if it's a large project where you have to do all these things? Would you run ten different language runtimes, each with its own garbage collector? Would you pay the cost of marshaling and unmarshaling data at the boundaries? What about training new programmers to understand and extend your system? What if you want to move some functionality from one part of the system into another, can you do it easily? Etc, etc. There's a lot of value in adopting one general purpose language as a company-wide standard, like Java. It doesn't have to be an excellent fit for every task, but it has to be adequate and not have any major flaws. That's harder than it sounds. I like the Rust approach (memory safety without GC), though Rust itself might not be the best possible realization of that approach.
- iopq 11y ago
  The great thing about Rust is that it doesn't need to be garbage collected, so it's easy to use inside a Ruby project. That's why you can use Rust in a lot more places than you would use Java.

tempodox 11y ago

Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more formally defined beasts fed by mathematical concepts. That's one trend I expect to continue, but then also not ad infinitum. In my view, Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. I want more math in PLs, but I feel we haven't found a good balance yet. Maybe this turns out to be a moving target, too. There are two languages I expect to keep their (niche) places for the foreseeable future: C and Lisp. Both are such a peculiar mix of properties that they are incredibly hard to beat in their respective domains. Maybe the same goes for Ada and Java, I wouldn't want to do any injustice :)

pron 11y ago
There are a couple of things I disagree with. First, you are lumping together trends in academia with trends in the industry, and the two are not always in tandem, though they certainly influence one another. For example, Go, a language that certainly goes against this trend, is gaining popularity much faster than any academic or academically-influenced languages (of course, it's easy to grow fast when you're small, but it's more academically inspired languages are just as small). This mixing of the domains which in reality is quite complex is also apparent in your examples. C is one of the most popular languages in use, and has been for a few decades; Lisps have been around even longer and has never broken beyond around, say 1% of production projects (except maybe for a very short while in the eighties). Second, you say "I want more math in PLs" when referencing Haskell. While it is true that pure-FP, because of its relationship to some types of logic, lets you prove some properties about your code in the code itself, that does not make it any more mathematical than other languages and other approaches. For example (and I give this example often, but only because I'm really impressed by that language), Esterel, a language designed in the eighties is an imperative language with lots and lots of global side effects, yet it allows you to verify its correctness absolutely, and you don't even need to write the proof yourself (it verifies temporal properties that are especially hard to prove using PFP). Esterel and languages (mostly graphical languages) inspired by it have been used by the industry orders of magnitude more than PFP languages for domains where correctness is crucial. That PFP allows you to write some proofs in code does not mean that there aren't better ways to verify programs mathematically. PFP is the answer if what you're asking for is more second-order logic in your PL; it's just one of many if you're just asking for more math (in fact, it's just one of many even if you want more interesting type systems). Also, it's hard to trace influences, but I believe that the focus on immutability that is finding its way into more and more languages is actually inspired by Erlang and later Clojure, two languages that have little to do with PFP, and a lot to do with the design of multi-core and distributed systems. It was not the current academic trend of pursuing the Curry-Howard correspondence as a software verification technique, but an industry solution for the problem of handling concurrency.

tatterdemalion 11y ago

The description of Rust in this blog post is not accurate in my opinion. 1. Compile times aren't great right now, but 20s for 2400loc is a real anomaly, and improving compile time is a focus of the team now that the language is stable. This is the only specific painpoint the blog post mentions with Rust, and its just a single anecdote. 2. The idea that Rust is a premature optimization is a weird meme. Faster, safer, more expressive. Rust is at least 2/3 for pretty much every 'mainstream' language. I would rather write Rust than any other language I know, and I would be more productive in it. 3. Rust is not a Flub language struggling to overcome a niche - not yet. Rust is a language that became stable 3 weeks ago and time has not yet told whether it will be 'mainstream' or not. Rust has a memory model that includes some degree of manual management, like C (instead of malloc/free and pointer arithmetic, you have ownership and references). This makes it a poor first language, like C. But no one says C is a language for the 'elite' because you have to think about the memory model.

stevedonovan 11y ago
It was perhaps unfair to single Rust out given that it is so young, but there are costs to any innovation, and the first cost that leaped out at me was stories of long compile times. Besides, extraordinary claims require extraordinary evidence. Personal anecdotes of increased productivity remain anecdotal - it may be more a property of the programmer than the language. I don't personally have a horse in the race, but pointing out cost points is needed.
- jerf 11y ago
  I really don't expect Rust to exhibit what most people mean by "increased productivity", ever. Most people mean something fairly local by that, or at most medium sized, that it allows them to take some task and write code faster than other languages that accomplishes the task. Rust is always going to labor under the disadvantage that it holds you to a higher degree of correctness than other languages, and at best it can tie with another language that doesn't hold you to those guarantees of correctness. Where it'll increase productivity or not is at larger scales. If Servo comes out at production quality in some reasonable time (call it 2 years or less from now, given where they are), able to function on the general web most of the time, and it's also faster than current renderers by a significant margin, and with some small fraction of the development effort (probably even if you include the entire Rust development effort; do not underestimate the effort poured into the existing engines!), I will consider Rust's story proved. We've now had many people take cracks at writing renderers, in the fastest language of the time for the task (C++), and I daresay they've converged at fairly similar levels of performance with little reason to believe the renderers are going to get much faster. Said renderers have had massive optimizations applied to them, and this Servo that I'm expecting to be much faster will actually be version 1.0, basically. If Rust is to work at all, there will very, very rapidly be a class of development that it will be actually insane to write in anything but Rust... but that will only be the very high-and-large end. (It will take many more years for this fact to penetrate through to the development community at large.)

VLM 11y ago

Three observations, of the smallest fine tuning variety (its pretty good as is): The essay fluidly rotates between two points of view best expressed by two direct quotes: "Note: this is about tracking fashion, not a comment on the actual virtues of these languages." and "getting things done". I don't think those are synonyms or have much to do with each other so the close intermixing is a bit jarring. Often enough they oppose each other. They don't get along so its hard to use them as supporting arguments even if true. Another observation is hard to quote but boils down to languages and paradigms are synonyms, which I disagree with. A language is a pile of paradigms wrapped up in some syntax to formalize it. You can write FORTRAN or perl in any language. Or functional, at least somewhat. Its easier to write worse programs than the language and very hard to write better programs than the level of the language. In that way LISP is the master language above all the others because it can express seemingly anything therefore if everything is beneath it, its above everything. The third paragraph is closest to what I'm trying to express and it comes very close to hitting the mark. It would be interesting to see logic programming in a safety critical embedded space. I'm not sure if it would be "good" interesting or "train wreck" interesting. That would be an interesting suggestion for the second to last paragraph. If you define safety as solving a full set of safety constraints, then automating it would look like ...

kyllo 11y ago

The author holds up Yesod's low adoption rates (compared to what? Ruby on Rails? Ruby was arguably Flub a few years ago, and Yesod is much younger than Rails) as an example of how powerful programming languages aren't making as big of a dent as they should be. But the thing is that yesod is a CRUD web app framework, and although Haskell is quite capable at CRUD apps, they're not where it really shines. Look at Haskell (and OCaml and F#)'s adoption rates in the financial sector and you'll see "Flub" kicking some serious ass.

_lce0 11y ago

> The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. pg wrote that in 2003 nowadays, what would be the most frightening langs?

Ygg2 11y ago
Scala, Rust, Haskell, JavaScript, VHDL, ASM and PHP :P If joke languages count then Brainfuck and BS[1] [1]https://skillsmatter.com/skillscasts/6088-the-worst-programming-language-ever https://skillsmatter.com/skillscasts/6088-the-worst-programm...
JanneVee 11y ago
It is not the languages themselves that are scary. It is the people using them. So if the competition look for e.g. Erlang programmers and you don't for some kind of messaging app. Then you should be worried. If they use it for big files, then you should be less worried. Because they need to solve a few more limitations in Erlang/OTP to make it work well.

haddr 11y ago

You could also summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person. That means that not always the best one wins, but the one which has most appealing properties. And those are not necessarily the "beatifulness" or some academic aspects, but rather: popularity (and easyness of finding programmers), understandability, availability of 3rd party libraries, productivity and more...

jasode 11y ago
>summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person. I wouldn't summarize it that way. More accurate would be: "the effectiveness of a programming language is driven by multi-dimensional factors instead of a single factor such as expressiveness of syntax. One's expert usage of a language can lead him to overestimate its overall effectiveness." When people debate programming languages using words like "simple", "powerful", "better", it's not very precise. It's actually misleading. All those labels have multidimensional factors but people discuss them as if they are a single dimension scalar. E.g. "Golang is simple" -- it's simple in keyword count but not simple in terms of implementing a family of algorithms that differ only by type. The paradox of "simple" has contradictory conclusions because that word has multiple dimensions. Therefore, if one's typical use case of Go does not involve templated algorithms, it is perceived as "simple" and one would proceed to evangelize the language as "simple." Same type of analysis can be done for words like "power", "better", "easier", etc. Yes, languages like Haskell/Lisp/Ocaml/F# etc have more expressive syntax but there are other dimensions in creating software that can overwhelm that advantage. This is why PG can have reasonable opinion on the "power" of Lisp but Aaron Schwartz came to a different reasonable opinion[1] and determined Python in his case to be more appropriate for Reddit. Aaron was not stupid and he knew how to write Lisp. To understand Aaron's viewpoint, you have to notice that he's using different dimensions of the word "better". [1] http://www.aaronsw.com/weblog/rewritingreddit http://www.aaronsw.com/weblog/rewritingreddit
- haddr 11y ago
  I agree, but then again, the market accounts for all those "multi-dimensional factors". Maybe what should be added is that there are external and interal factors that decide of which language is better. External factors have been already discussed. Internal ones are those that correspond to the company internal structure, culture, etc. For instance: If you have a team of people writing Java you wouldn't choose Python at all.

amelius 11y ago

> it is unlikely that major operating systems will emerge written entirely in Rust Why?

dtech 11y ago
It is unlikely that a major new operating system will emerge at all because of high investment cost, momentum and compatibility

camperman 11y ago

I just got back from a very positive strategy meeting with my partner (I do the code and he does the ops and the sales) and this essay struck a chord with me. Why are we making so much progress when I'm a decidedly average programmer? I think it's because I'm a decidedly average programmer in enough languages to know what their strengths and weaknesses are and thus to be able to pick the right tool for the job: - hardware-accelerated video decoding on the ARM - C obviously, with a small amount of ASM. - web server - Python using web2py - web interface prettiness - jquery and javascript - server processes and admin automation - Python - core apps - Luajit because it's so fast on the very limited ARM boxes we're using - customer data munging and reports - emacs lisp because it's right there - desktop apps for Windows, OSX and Linux - Python again - some bash and Perl for sysadmin stuff What Steve doesn't say - although it is implied - is that he knows enough languages at a practical level to make these kinds of judgement calls. And I know for a fact he's a far better coder than I am because I use his Penlight library for Lua every day. Perhaps Flub can never be a force for change the way Lisp was because modern languages are incorporating enough features from Lisp to bring them close enough to the top of the hierarchy not to matter as much as before.

Dewie3 11y ago
That's a nice kitchen sink full of languages.

michaelochurch 11y ago

This is intelligently argued and articulate but the content is a bit lacking. First, Paul Graham isn't an expert on languages. He wrote a decent Lisp book, years ago. Relative to VCs, he's a technical genius. Relative to technical geniuses, he's a VC. I respect him for taking iconoclastic positions against the Establishment, and I miss that Paul Graham, but... he has serious blind spots when it comes to, say, statically typed languages. Now, PG probably intended "Blub" to mean a mediocre language du jour like C++ (in the early 1990s) or Java (since the late '90s) but Blub is more of an attitude than a language. Yes, there really are one-language programmers who can't think out of a specific paradigm. They exist, and they're the ones who write FactoryVisitorFactory classes because they haven't been exposed to functional programming and the right way of solving certain problems. That said, there are cases where C or Java is the absolute right language to use. Not many, for Java, but they exist. Not everyone who uses those "Blub languages" is a mediocre programmer; Java is not always Blub, and C is definitely not always Blub (in fact, it's out of fashion among the Blubanistas, who avoid low level programming because "it's too hard".) As for "Flub"... I don't even know where to begin. Just going to snipe specific points. 'Power' and 'Expressiveness' turn out to be separate concepts. In the end, there is no simple continuum that you can use to line programming languages up, nose to tail, feeble to awesome. I agree with this, whole-heartedly. Assembly and C, I would argue, are more powerful than Haskell because it makes it so much easier to create custom control flows and to manage memory explicitly. Haskell is more expressive. You trade some power, in exchange for a language that allows you to write very robust code, very quickly. But sometimes you need that power and C is the best option. To use it effectively, however, requires using an IDE, and Flubbists hate IDEs, partly because their finger muscle memory has been overspecialized from spending too much time in Eighties power editors, but also because using an IDE is too closely associated with Blub practices. No, we dislike IDEs (actually, we don't; we dislike broken languages and codebases that require us to use IDEs) because it's a lot easier to keep flow when you're using the keyboard only. Switching to the mouse to recompile breaks flow. IDEs also have a stigma because they're most useful when you're maintaining other peoples' code, which generally is a disliked sort of work given to juniors. So, IDEs tend to be associated with the second-class programmers who spend most of their time on maintenance work. I, personally, think the "reading code is for losers" attitude that many programmers cop is stupid and counterproductive. I enjoy reading good code and I wish that I had better tools for doing it. A disruptive startup is more likely to use Blub in creative ways, focusing on the idea, not the implementation. Facebook dominated its market - using PHP - which everyone agrees is crap. Google built up the world's biggest advertising agency using Java and C++; Android is a Java-like ecosystem that runs in most pockets these days. Oh, this shitty argument. "Your tech should be boring, your product should be interesting." Yawn. It's a bullshit argument and I'll tackle it another time. Google was originally written in Python, which was more of a reach than Haskell is now. Python sucked in 1998. Also, the late '90s were a time when PL was considered to be a dead field, so PL never worked its way into Google's DNA and it's stayed that way. They use C++ because it was the best choice in the late 1990s, and they tolerate Java in the context of acquisitions, and when they tried to come up with their own language... the best they could do is Go. Facebook started on PHP but is increasingly innovative on the language front, with Erlang, Ocaml, and Haskell getting a presence. You put a group of merely good Lisp programmers on a project, and embed them in a corporate environment, and the stellar results are likely to be not reproducible. (I don't doubt they will be more productive than Java programmers. But will the result blend?) "Will it blend?" I'm sorry, but I prefer not to think of my work as something that will be ground to a pulp. If that's the kind of work you want, then hire a Scrum drone, not someone like me. Big companies understand this problem well, and prefer Blub programmers, who are easier to source and come with less attitude. False. Do Haskell programmers come with more "attitude" than mediocre Java programmers? Yeah, there's probably a slight difference. However, the problem isn't "Haskell programmers" or "Java programmers" but people. People are just a pain in the ass: all of us, to some degree. Since you need 30 Java programmers to do the work of 5 Haskell programmers, you not only have more sources of "attitude" with the 30, but you have more politics and less per-person productivity on account of the larger team.

deleted 11y ago

[deleted]

deleted 11y ago
[deleted]

agentultra 11y ago

The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub program is non-trivial. In data-oriented design the mantra is, "the hardware is the platform." A given CPU comes with some instructions it understands and our job as programmers is to use those instructions to apply transformations to a stream of data. The optimal language is of course the assembly language of the target platform. However it's often more practical to use a language that compiles down to a target platform's instruction set with the fewest number of transformations (barring the presence of optimizations). Flub languages attempt to give programmers the tools to write programs which hold some provable invariant, provide denotational semantics, or some combination of these. The benefit of this is some reduced cognitive load, expressive power, and other "soft" features. This power is what lets small teams run circles around Blub programmers in the Blub/Flub paradox. However the utility of these features and whether they actually do allow small teams to get more work done in less time hasn't been proven to me yet. It may seem tedious to think to think of the statistically significant data-access pattern in a given operation and forming your data-structures and transformations to make that access pattern the fastest route for the target platform... but it has big wins in terms of execution speed of the programs and the maintainability of such programs. One still requires a significant amount of mathematical reasoning and understanding of what a compiler can and cannot do for you. I'm slowly coming to the opinion that there won't ever be a compiler or Flub language that will give you your cake and let you eat it too. In practice I've found re-usability to be a low-priority concern, generics to be a performance hindrance, and I've yet to find a convincing example of how type-safety is the future of mission-critical software (though there are some promising projects for sure). Thus in conclusion: I think Blub languages will continue to rule the roost. Flub will come and go and remain fashionable as the OP has alluded to. However I don't think it's the avenue worth pursuing in order to write better programs... too much abstraction makes it rather difficult to reason about what our programs are actually executing on the target platform and for many cases that can be critical. It always comes down to the data and at some-point one needs to consider the target platform anyway. Data-oriented design is one way to think of the data first and allows the programmer to choose the appropriate semantics for the necessary transformations to be expressed by their program. (I hope I'm making sense).

11y ago

apalmer 11y ago

No offense, but the whole essay hinges on some core concepts that are NOT logically robust, hence the ultimate 'paradox' is really simply an application of reductio ad absurdum Basically the premise of what it means to be 'powerful' is at best ill defined, and most likely is not logically consistent. More or less there is no clear qualitative definition for 'powerful', nor is 'powerful' meaningful across all developers, organizations, or application. Now by an empirical definition in this context the meaning of 'powerful' is clear. 'Powerful' means how strongly the program language selection correlates with successful projects... based on that the 'powerful' languages are pretty much the 'blub' languages. there are many many successful PHP, Java, and especially C projects.

RHSeeger 11y ago

> It could have easily been something much worse, like Tcl. Ouch. Tcl might not be the right choice for many situations, but it's a fantastic language for many. It is, by far, one of my favorite languages to work in.

markc 11y ago

>Clojure is an attempt at re-Flubbing Lisp. And it's a successful attempt - unless you require top tier adoption to qualify. >Where is Flub being used as a secret weapon, in the way described by Paul Graham? Why aren't its practitioners exploiting their natural advantage? Clojure is a good candidates for Flub not only because of its power and expressivity (and as a Lisp, its natural fit as a PG-style Flub), but because it is being exploited to advantage by those who've discovered it. A small sampling includes: Adzerk, Beanstalk, CircleCI, Cognitect, Consumer Reports, Daily Mail, Database Labs, Democracy Works, Deutsche Bank, eBay, Factual, FarmLogs, Groupon, Heroku, Intuit, LivingSocial, ViaSat, MixRadio, Netflix, Nubank, OpenTable, Pivotal, Precursor, Prismatic, Puppet Labs, RoomKey, Sonian, Soundcloud, Spotify, Staples, Teradata, ThoughtWorks, Cisco, Two Sigma, Upworthy, uSwitch, World Singles, Innovation Labs, Zendesk, ... (sorry If I left out your awesome Clojure-fueled project/company but the list is too long) The Clojure experience at these companies seems to mostly fall somewhere between gushingly effusive and merely enthusiastic. Sure, there's some self-selection, and it's hard to separate developer talent from language choice in those successes, but read a few case studies and you start to get the impression that Clojure itself is not only an advantage, but a significant one. That's not to say that Clojure is the only good candidate for flub; there are other powerful, productive, and pragmatic languages that can deliver high productivity in the right context. But if I had to pick one language to be dubbed Flub, it would be Clojure.