4 ms·

Michael Vanier: LFM and LFSP

60 points by jaydub 17y ago

mudge 17y ago
Great little article. Thanks.
mbrubeck 17y ago
A previous discussion (from 2007): http://news.ycombinator.com/item?id=33246 http://news.ycombinator.com/item?id=33246
gruseom 17y ago
I took a quick look. The piece is better than I remembered. It takes what is a (by now) common point and makes it uncommonly well. The second-last paragraph, in particular, brilliantly summarizes both what people like about LFMs and what (other) people hate about them. Surprisingly, it's fair to both sides. As for the distinction between LFM and LFSP itself, I believe it's fundamental -- or rather, the distinction between M and SP is fundamental. It explains important facts about the software industry that can't be explained any other way ("if X is so good then how come blah blah blah"). I think M vs. SP is fundamental because of a demographic fact: the population of SP is an order of magnitude smaller (at least) than the population of M. Combine that with the economic fact that the demand for software exceeds the supply of SP, and our world begins to make some sense. The only thing I'd change is that the terms "smart people" and "masses" are too judgmental. What we mean by "SP" is people with a high tolerance for abstraction. There are many individuals in M (i.e. who have a low tolerance for abstraction) who are plenty smart. Still, this is a venial flaw, because capacity for abstraction is a big part of being a smart programmer.
strlen 17y ago
While this seems to be an almost constant (and needless) discussion on this site for the last few months, I wonder how presence of LFSP on the JVM/CLR (Scala/F# for ML-style programming, Clojure for Lisp-style programming) going to change the picture)?
wheels 17y ago
Interestingly, this is almost identical to our language decisions. Our engine is C++, the webservices are a wrapper in Java and the stuff on the fringes is a mix of scripting languages. Instead of OCaml, I've been eyeing Scala as the thing I might use to rip out the Java. Before doing our webservices in Java, I'd never done much of it and assumed it to be a closer cousin to C++. Using it at length, at a time when I find myself frustrated with some of the lack of abstractions in C++ (notably missing lambda), it's whetted my appetite to drop in a slicker language at the medium level of our stack.
alrex021 17y ago
I introduced a bunch of Java developers today to applying predicates and mapping functions using the google-collections lib. Question that was asked the most was: "Will other java developers that do/will work on my project(s) understand this code?" How do you un-teach people the for () { if ... if .. if .. } for () { ... } ...
- mquander 17y ago
  In the short term? You don't. In the medium term? Companies and groups using the most productive tools will be more successful. If there are real, scalable advantages to assembling a team of great developers and using powerful techniques, then those will shine through over time. If you want to be in on this, you should probably open your mind to learning new things. In the long term? Once the effective techniques are proven, the developers who only know the old ways eventually die and are replaced by younger ones who have learned the better ones. Rinse and repeat.
  - mbrubeck 17y ago
    That's exactly right, and you can see it in history with the introduction of high-level languages (vs. assembly languages), structured programming, and object-oriented programming.
- joshhart 17y ago
  Google collections is used fairly extensively where I work now. At first, I didn't quite "get" it. A couple weeks later I started reading SICP and now I try my darnest to use predicates, maps, and filters as much as possible. When you've been working in a language like Java sometimes you stop trying to look for the higher abstraction.
showerst 17y ago
"Debugging is twice as hard as writing the program, so if you write the program as cleverly as you can, by definition, you won't be clever enough to debug it." - Kernighan's law (In reality I think that many smarter languages make debugging easier, not harder, but the point stands that the most interesting or fun solution isn't necessarily the best solution. A good, stable project often needs non-sexy infrastructure, and no language can completely abstract that out.)
va_coder 17y ago
I agree Java is verbose and old and should rarely be used on new projects. But this thing about smart people makes me cynical. You ever debug a terse Perl program written by a really "smart" person? What about maintenance? What about the dangers of over engineering? These things should not be overlooked.
- TwoBit 17y ago
  >> I agree Java is verbose and old and should rarely be used on new projects. People with attitudes like this scare the hell out of me.
  - mhansen 17y ago
    Explain please? Java is verbose, but although it is old, age isn't important.
- btilly 17y ago
  You ever debug a terse Perl program written by a really "smart" person? Actually, yes I have. And I've found it an absolute joy. Oh, line for line it can take more work to understand. (Though often it is set up so that you can ignore most lines.) But compared to what the same code would have been written out in a more "straightforward" and repetitive fashion? However there are a lot of people who THINK they are smart but aren't. Working with their stuff can be a nightmare. The difference is painfully obvious once you dive into the code. If you're experienced in Perl, it is usually obvious at a glance.
  - WilliamLP 17y ago
    The problem is that most of the people who think that Java is too constraining are in that very group who think they are smarter than they are. (This is not to say that there aren't people who can be more productive with a language less constraining than Java.) Indeed, most people who think they are smart, aren't, including myself.
    - 17y ago
f00 17y ago
> It's pretty clear that the core simulation objects have to be written in C++. C is too painful, and anything else is going to give an unacceptable hit in speed The author lost me right here. C is too painful, and C++ is materially better? OOP is nice and all, but it's no panacea. I've worked plenty in both languages and find that both score roughly equally in 'pain quotient.' Interestingly, the "LFSP" theory breaks down when you consider memory management and pointers. Those two features of "LFM's" cause far more difficulty for average developers, IMO, than the abstractions available in "LFSP's."
panic 17y ago
I'm not sure if languages can be classified so easily. For example, is C++ a LFM or a LFSP? What about Javascript?
jbooth 17y ago
Well, I wouldn't want to get in the way of anyone telling themselves that they're smart, but take a look at any startup with scaling problems and what do you see? The web team's doing shopping carts and drill-down tables in Ruby. The platform team's doing ultra-low-latency, distributed, redundant key-value stores in Java, and build scripts in Ruby or whatever, possibly an ETL or two using hadoop to boot. Who're the smart people, again?
- jbooth 17y ago
  Not to be a crank - rails is better for web development than any of the 500 java web frameworks, and if you try to write a one-off script in Java, you're insane. I learned to program with Scheme just like a lot of people and it's a beautiful and elegant language. But Java has a lot of strengths, and the fact that it's the most popular language for enterprise development doesn't mean it's for "the masses" while the rest of us are "beautiful unique snowflakes". It's a tool to be used for its strengths like anything else.
fauigerzigerk 17y ago
This means that there is a glass ceiling of abstraction; your designs can only get this abstract and no more. This is reassuring to Joe Average, because he knows that he isn't going to see any code he can't understand. That's the intention, but the reality is quite different. When smart people really need to write more abstract code in a weak language they will go to great lengths, including on the fly byte code manipulation and all kinds of weird proxying hacks. Or look what they do with CSS. So, the abstractions are always possible, albeit in a way that is even more complex and definitely more brittle than if they had been implemented in a more powerful language.
RK 17y ago
I like the LFLP = languages for lazy people.

60 points by jaydub 17y ago

mudge 17y ago

Great little article. Thanks.

mbrubeck 17y ago

A previous discussion (from 2007): http://news.ycombinator.com/item?id=33246 http://news.ycombinator.com/item?id=33246

gruseom 17y ago

I took a quick look. The piece is better than I remembered. It takes what is a (by now) common point and makes it uncommonly well. The second-last paragraph, in particular, brilliantly summarizes both what people like about LFMs and what (other) people hate about them. Surprisingly, it's fair to both sides. As for the distinction between LFM and LFSP itself, I believe it's fundamental -- or rather, the distinction between M and SP is fundamental. It explains important facts about the software industry that can't be explained any other way ("if X is so good then how come blah blah blah"). I think M vs. SP is fundamental because of a demographic fact: the population of SP is an order of magnitude smaller (at least) than the population of M. Combine that with the economic fact that the demand for software exceeds the supply of SP, and our world begins to make some sense. The only thing I'd change is that the terms "smart people" and "masses" are too judgmental. What we mean by "SP" is people with a high tolerance for abstraction. There are many individuals in M (i.e. who have a low tolerance for abstraction) who are plenty smart. Still, this is a venial flaw, because capacity for abstraction is a big part of being a smart programmer.

strlen 17y ago

While this seems to be an almost constant (and needless) discussion on this site for the last few months, I wonder how presence of LFSP on the JVM/CLR (Scala/F# for ML-style programming, Clojure for Lisp-style programming) going to change the picture)?

wheels 17y ago

Interestingly, this is almost identical to our language decisions. Our engine is C++, the webservices are a wrapper in Java and the stuff on the fringes is a mix of scripting languages. Instead of OCaml, I've been eyeing Scala as the thing I might use to rip out the Java. Before doing our webservices in Java, I'd never done much of it and assumed it to be a closer cousin to C++. Using it at length, at a time when I find myself frustrated with some of the lack of abstractions in C++ (notably missing lambda), it's whetted my appetite to drop in a slicker language at the medium level of our stack.

alrex021 17y ago

I introduced a bunch of Java developers today to applying predicates and mapping functions using the google-collections lib. Question that was asked the most was: "Will other java developers that do/will work on my project(s) understand this code?" How do you un-teach people the for () { if ... if .. if .. } for () { ... } ...

mquander 17y ago
In the short term? You don't. In the medium term? Companies and groups using the most productive tools will be more successful. If there are real, scalable advantages to assembling a team of great developers and using powerful techniques, then those will shine through over time. If you want to be in on this, you should probably open your mind to learning new things. In the long term? Once the effective techniques are proven, the developers who only know the old ways eventually die and are replaced by younger ones who have learned the better ones. Rinse and repeat.
- mbrubeck 17y ago
  That's exactly right, and you can see it in history with the introduction of high-level languages (vs. assembly languages), structured programming, and object-oriented programming.
joshhart 17y ago
Google collections is used fairly extensively where I work now. At first, I didn't quite "get" it. A couple weeks later I started reading SICP and now I try my darnest to use predicates, maps, and filters as much as possible. When you've been working in a language like Java sometimes you stop trying to look for the higher abstraction.

showerst 17y ago

"Debugging is twice as hard as writing the program, so if you write the program as cleverly as you can, by definition, you won't be clever enough to debug it." - Kernighan's law (In reality I think that many smarter languages make debugging easier, not harder, but the point stands that the most interesting or fun solution isn't necessarily the best solution. A good, stable project often needs non-sexy infrastructure, and no language can completely abstract that out.)

va_coder 17y ago

I agree Java is verbose and old and should rarely be used on new projects. But this thing about smart people makes me cynical. You ever debug a terse Perl program written by a really "smart" person? What about maintenance? What about the dangers of over engineering? These things should not be overlooked.

TwoBit 17y ago
>> I agree Java is verbose and old and should rarely be used on new projects. People with attitudes like this scare the hell out of me.
- mhansen 17y ago
  Explain please? Java is verbose, but although it is old, age isn't important.
btilly 17y ago
You ever debug a terse Perl program written by a really "smart" person? Actually, yes I have. And I've found it an absolute joy. Oh, line for line it can take more work to understand. (Though often it is set up so that you can ignore most lines.) But compared to what the same code would have been written out in a more "straightforward" and repetitive fashion? However there are a lot of people who THINK they are smart but aren't. Working with their stuff can be a nightmare. The difference is painfully obvious once you dive into the code. If you're experienced in Perl, it is usually obvious at a glance.
- WilliamLP 17y ago
  The problem is that most of the people who think that Java is too constraining are in that very group who think they are smarter than they are. (This is not to say that there aren't people who can be more productive with a language less constraining than Java.) Indeed, most people who think they are smart, aren't, including myself.
  - 17y ago

f00 17y ago

> It's pretty clear that the core simulation objects have to be written in C++. C is too painful, and anything else is going to give an unacceptable hit in speed The author lost me right here. C is too painful, and C++ is materially better? OOP is nice and all, but it's no panacea. I've worked plenty in both languages and find that both score roughly equally in 'pain quotient.' Interestingly, the "LFSP" theory breaks down when you consider memory management and pointers. Those two features of "LFM's" cause far more difficulty for average developers, IMO, than the abstractions available in "LFSP's."

panic 17y ago

I'm not sure if languages can be classified so easily. For example, is C++ a LFM or a LFSP? What about Javascript?

jbooth 17y ago

Well, I wouldn't want to get in the way of anyone telling themselves that they're smart, but take a look at any startup with scaling problems and what do you see? The web team's doing shopping carts and drill-down tables in Ruby. The platform team's doing ultra-low-latency, distributed, redundant key-value stores in Java, and build scripts in Ruby or whatever, possibly an ETL or two using hadoop to boot. Who're the smart people, again?

jbooth 17y ago
Not to be a crank - rails is better for web development than any of the 500 java web frameworks, and if you try to write a one-off script in Java, you're insane. I learned to program with Scheme just like a lot of people and it's a beautiful and elegant language. But Java has a lot of strengths, and the fact that it's the most popular language for enterprise development doesn't mean it's for "the masses" while the rest of us are "beautiful unique snowflakes". It's a tool to be used for its strengths like anything else.

fauigerzigerk 17y ago

This means that there is a glass ceiling of abstraction; your designs can only get this abstract and no more. This is reassuring to Joe Average, because he knows that he isn't going to see any code he can't understand. That's the intention, but the reality is quite different. When smart people really need to write more abstract code in a weak language they will go to great lengths, including on the fly byte code manipulation and all kinds of weird proxying hacks. Or look what they do with CSS. So, the abstractions are always possible, albeit in a way that is even more complex and definitely more brittle than if they had been implemented in a more powerful language.

RK 17y ago

I like the LFLP = languages for lazy people.