11 ms·

So on the front page they have in the center a graph that shows lisp doing better in practical applications. They are basically using one paper to claim perform

by lqdc13 11y ago

So on the front page they have in the center a graph that shows lisp doing better in practical applications. They are basically using one paper to claim performance/productivity improvements. This comes from this paper from 16 years ago: http://dl.acm.org.sci-hub.io/citation.cfm?doid=355137.355142 http://dl.acm.org.sci-hub.io/citation.cfm?doid=355137.355142 That paper has all kinds of issues including self-selected participants and a tiny sample size. We should really do a hackathon "study" mandatory for a specific group of people e.g. coworkers, something like a surprise pre-hackathon to a real hackathon or something else. Dev time is so expensive that nobody will ever do a real study it seems. What we have now is people selecting arbitrary technologies to use for their projects. There are so many different ones floating around that it's impossible to get proficient at all of them.

sspiff 11y ago
This was the first thing I noticed as well. I mean, that's from an age where Java and C++ libraries, frameworks and build systems were nowhere near as advanced as today. Scheme has seen little investment in their infrastructure and ecosystem in the past 15 years, whereas C++ and Java have seen millions of dollars and many man-years invested in libraries etc. I doubt this data is still valid today, even if it was a decade and a half ago.
- kryptiskt 11y ago
  Racket has a lovely environment, and as a language it has progressed far more than Java has. C++ remains nobody's idea of a language for rapid development.
  - cmrdporcupine 11y ago
    I find with the right choice of libraries, and using CLion IDE I'm as efficient in C++ as I was in Java. The introduction of c++11, along with modern refactoring IDEs for C++ has been a godsend. I prefer the Rust language, but until there's an IntelliJ/CLion class IDE for it, I don't know if I'd go down that route...
  - sspiff 11y ago
    Sure, the language has progressed, but the libraries, resources, documentation, ... haven't to the same degree as with more popular languages. Trying to do anything in Java and things go wrong? Google, click on the first StackOverflow result and you have the blueprint for a solution. The same can not be said about Racket, at least not with the same breadth of problems.
    - scrupulusalbion 11y ago
      Perhaps lisps do not benefit from progression in libraries; creation of new resources; and don't need to change often enough to warrant new documentation. What does it mean when a language becomes less and less useful without its specification being progressively changed, with the commensurate documentation changes? What does it mean that a language has tons of questions on Stack Overflow? It would seem that an ideal language is one whose specification is static so that old and new resources, libraries, and documentation remain perpetually useful. However, such a specificationally-static language can only be itself perpetually useful if it is properly flexible to the needs of the programmer. I hear that at least some Lisps are quite flexible, though I unfortunately don't have a good way to fathom/define what constitutes flexibility.
      - nickpsecurity 11y ago
        Not true: LISP would've benefited greatly from at least one core usage and set of libraries that were easy-to-use with lots of uptake. Call it the Python effect. How it's been used and expanded is quite amazing. LISP could've done more but wasn't restrained enough by community. The reasons for this are social, not technical. Probably best explained here: https://news.ycombinator.com/item?id=11174946 https://news.ycombinator.com/item?id=11174946 Meanwhile, languages like Ocaml, Haskell, and Python pick up the ball by trying to include plenty of power but in constrained and standardized ways that benefit from communities. Results are paying off. There's a few LISP's that do the same thing with better results than prior LISP's. Hopefully, those will keep getting uptake as I think powerful and constrained languages each have something to offer. Best to develop both in parallel, esp as one can implement the other. ;)
      - 11y ago
- wtbob 11y ago
  > This was the first thing I noticed as well. I mean, that's from an age where Java and C++ libraries, frameworks and build systems were nowhere near as advanced as today. > Scheme has seen little investment in their infrastructure and ecosystem in the past 15 years, whereas C++ and Java have seen millions of dollars and many man-years invested in libraries etc. I think that 15 years ago Java and C++ had more libraries than Scheme and Common Lisp, and that even with millions of dollars invested the infrastructure around Java and C++ isn't nearly as powerful as what Common Lisp provides in the standard.
nostrademons 11y ago
Here's the big secret about the tech industry: arbitrary technology is exactly what you want for your project. It doesn't actually matter. Any inherent differences in productivity are dwarfed by the effects of being emotionally invested in your work and having lots of other people emotionally invested in the outcome. Besides, regardless of what you choose, if it becomes successful it will be rewritten multiple times by multiple groups of people, and the effect of having them emotionally invested in their work will far outstrip any inherent differences in technologies. So pick whatever you want, and then let your employees pick whatever they want subject to the constraint that groups who work on the same codebase better agree on the same technology.
- lordnacho 11y ago
  Someone needs to tell this to recruiters. There's too many job adverts for jobs that any programmer could do in any language, but they WANT a Java/c#/etc guy.
  - arethuza 11y ago
    I don't think it's recruiters - hiring managers want someone who can "hit the ground running" so look for an exact match between the technology involved in their current project and the experience of an applicant. The same managers then wonder why their teams are reluctant to work with technology that isn't "hot"....
    - solipsism 11y ago
      Can't really blame them when it's part of our culture to start looking for a new job once we've been there a year, why would they want to invest significant amounts of resources into you? Then again, maybe you can blame them, as at least part of the reason for this part of our culture is that it's the best way to get high enough promotions to get up to our deserved salary (as defined subjectively by the engineer).
  - cmrdporcupine 11y ago
    95% of jobs are for maintaining an existing code base. So they just want the person who will jump in and start working on it with minimal bullshit. Honestly, learning the syntax of a language takes under a week. Learning the culture and APIs can take years. I've been having to do Objective C for the last year and a half. I don't like it, but it's my lot. I understand the language, but I can't say I understand all the tools and APIs, still.
eggy 11y ago
I am more impressed by the bevy of citations that go back to March 2010, and involve LambdaNative. That and the 10 countries and 100,000 subjects. The interfaces are not iOS/Android app polished, but very functional looking. I evaluated it last year, and I may look at it again. I think the market it targets isn't looking for the polish so prevalent in web tech apps, but function first. They could use help in that department, and it seems for a good cause. Hats off to the team!
MichaelGG 11y ago
This data might exist. YC has funded many startups, and pg supposedly has a very pro-LISP stance. By looking at the technology choices and results, wouldn't there be something interesting to be found? If they don't collect any sorts of stats (that'd be unfortunate), perhaps they could poll YC alumni and see if there are any trends.
nickpsecurity 11y ago
There have been a number of studies in the past showing LISP or other VHLL's outperform C-like 3GL's in productivity or defect ratios. There's been some consistency in results regardless of the methods. The consistency on those is more that C sucks than that LISP is great. ;) Java seemed to suck too except not as bad as C. I'd like to see a batteries-included LISP with dev environment put against Python, Ruby, etc by people with similar skill level in respective mindsets on same types of apps. Quite a lot of people. That would tell me more. Of course it will outperform C, C++, and Java in productivity: it's a safe-ish, malleable, dynamic language with macros. LISP beating scripting languages would speak volumes given it also compiles to efficient native code, was used in OS's, and can use dedicated CPU's.
- AnimalMuppet 11y ago
  I'd like to see that study, too, but have it maintained and enhanced for a decade by people who are not all members of the original team.
  - nickpsecurity 11y ago
    Now THAT would be a study!
jimbokun 11y ago
I loved the prominent placement of that graph. Makes a strong, unambiguous statement right off the bat as to why I should be interested in this project. If nothing else, shows me the project's goals and priorities are aligned in the right direction. Having said that, I suppose the best approach would be to randomly assign developers to learn a language/technology stack they haven't used before, then have them learn the technology and implement a project in the language. Would evaluate difficulty of learning the language, availability of resources, and the strength of the community. If you evaluate performance based on language/stack the developers already know, would be difficult to tease apart the correlation between technology stack and developer ability.

by lqdc13 11y ago

sspiff 11y ago

This was the first thing I noticed as well. I mean, that's from an age where Java and C++ libraries, frameworks and build systems were nowhere near as advanced as today. Scheme has seen little investment in their infrastructure and ecosystem in the past 15 years, whereas C++ and Java have seen millions of dollars and many man-years invested in libraries etc. I doubt this data is still valid today, even if it was a decade and a half ago.

kryptiskt 11y ago
Racket has a lovely environment, and as a language it has progressed far more than Java has. C++ remains nobody's idea of a language for rapid development.
- cmrdporcupine 11y ago
  I find with the right choice of libraries, and using CLion IDE I'm as efficient in C++ as I was in Java. The introduction of c++11, along with modern refactoring IDEs for C++ has been a godsend. I prefer the Rust language, but until there's an IntelliJ/CLion class IDE for it, I don't know if I'd go down that route...
- sspiff 11y ago
  Sure, the language has progressed, but the libraries, resources, documentation, ... haven't to the same degree as with more popular languages. Trying to do anything in Java and things go wrong? Google, click on the first StackOverflow result and you have the blueprint for a solution. The same can not be said about Racket, at least not with the same breadth of problems.
  - scrupulusalbion 11y ago
    Perhaps lisps do not benefit from progression in libraries; creation of new resources; and don't need to change often enough to warrant new documentation. What does it mean when a language becomes less and less useful without its specification being progressively changed, with the commensurate documentation changes? What does it mean that a language has tons of questions on Stack Overflow? It would seem that an ideal language is one whose specification is static so that old and new resources, libraries, and documentation remain perpetually useful. However, such a specificationally-static language can only be itself perpetually useful if it is properly flexible to the needs of the programmer. I hear that at least some Lisps are quite flexible, though I unfortunately don't have a good way to fathom/define what constitutes flexibility.
    - nickpsecurity 11y ago
      Not true: LISP would've benefited greatly from at least one core usage and set of libraries that were easy-to-use with lots of uptake. Call it the Python effect. How it's been used and expanded is quite amazing. LISP could've done more but wasn't restrained enough by community. The reasons for this are social, not technical. Probably best explained here: https://news.ycombinator.com/item?id=11174946 https://news.ycombinator.com/item?id=11174946 Meanwhile, languages like Ocaml, Haskell, and Python pick up the ball by trying to include plenty of power but in constrained and standardized ways that benefit from communities. Results are paying off. There's a few LISP's that do the same thing with better results than prior LISP's. Hopefully, those will keep getting uptake as I think powerful and constrained languages each have something to offer. Best to develop both in parallel, esp as one can implement the other. ;)
    - 11y ago
wtbob 11y ago
> This was the first thing I noticed as well. I mean, that's from an age where Java and C++ libraries, frameworks and build systems were nowhere near as advanced as today. > Scheme has seen little investment in their infrastructure and ecosystem in the past 15 years, whereas C++ and Java have seen millions of dollars and many man-years invested in libraries etc. I think that 15 years ago Java and C++ had more libraries than Scheme and Common Lisp, and that even with millions of dollars invested the infrastructure around Java and C++ isn't nearly as powerful as what Common Lisp provides in the standard.

nostrademons 11y ago

Here's the big secret about the tech industry: arbitrary technology is exactly what you want for your project. It doesn't actually matter. Any inherent differences in productivity are dwarfed by the effects of being emotionally invested in your work and having lots of other people emotionally invested in the outcome. Besides, regardless of what you choose, if it becomes successful it will be rewritten multiple times by multiple groups of people, and the effect of having them emotionally invested in their work will far outstrip any inherent differences in technologies. So pick whatever you want, and then let your employees pick whatever they want subject to the constraint that groups who work on the same codebase better agree on the same technology.

lordnacho 11y ago
Someone needs to tell this to recruiters. There's too many job adverts for jobs that any programmer could do in any language, but they WANT a Java/c#/etc guy.
- arethuza 11y ago
  I don't think it's recruiters - hiring managers want someone who can "hit the ground running" so look for an exact match between the technology involved in their current project and the experience of an applicant. The same managers then wonder why their teams are reluctant to work with technology that isn't "hot"....
  - solipsism 11y ago
    Can't really blame them when it's part of our culture to start looking for a new job once we've been there a year, why would they want to invest significant amounts of resources into you? Then again, maybe you can blame them, as at least part of the reason for this part of our culture is that it's the best way to get high enough promotions to get up to our deserved salary (as defined subjectively by the engineer).
- cmrdporcupine 11y ago
  95% of jobs are for maintaining an existing code base. So they just want the person who will jump in and start working on it with minimal bullshit. Honestly, learning the syntax of a language takes under a week. Learning the culture and APIs can take years. I've been having to do Objective C for the last year and a half. I don't like it, but it's my lot. I understand the language, but I can't say I understand all the tools and APIs, still.

eggy 11y ago

I am more impressed by the bevy of citations that go back to March 2010, and involve LambdaNative. That and the 10 countries and 100,000 subjects. The interfaces are not iOS/Android app polished, but very functional looking. I evaluated it last year, and I may look at it again. I think the market it targets isn't looking for the polish so prevalent in web tech apps, but function first. They could use help in that department, and it seems for a good cause. Hats off to the team!

MichaelGG 11y ago

This data might exist. YC has funded many startups, and pg supposedly has a very pro-LISP stance. By looking at the technology choices and results, wouldn't there be something interesting to be found? If they don't collect any sorts of stats (that'd be unfortunate), perhaps they could poll YC alumni and see if there are any trends.

nickpsecurity 11y ago

There have been a number of studies in the past showing LISP or other VHLL's outperform C-like 3GL's in productivity or defect ratios. There's been some consistency in results regardless of the methods. The consistency on those is more that C sucks than that LISP is great. ;) Java seemed to suck too except not as bad as C. I'd like to see a batteries-included LISP with dev environment put against Python, Ruby, etc by people with similar skill level in respective mindsets on same types of apps. Quite a lot of people. That would tell me more. Of course it will outperform C, C++, and Java in productivity: it's a safe-ish, malleable, dynamic language with macros. LISP beating scripting languages would speak volumes given it also compiles to efficient native code, was used in OS's, and can use dedicated CPU's.

AnimalMuppet 11y ago
I'd like to see that study, too, but have it maintained and enhanced for a decade by people who are not all members of the original team.
- nickpsecurity 11y ago
  Now THAT would be a study!

jimbokun 11y ago

I loved the prominent placement of that graph. Makes a strong, unambiguous statement right off the bat as to why I should be interested in this project. If nothing else, shows me the project's goals and priorities are aligned in the right direction. Having said that, I suppose the best approach would be to randomly assign developers to learn a language/technology stack they haven't used before, then have them learn the technology and implement a project in the language. Would evaluate difficulty of learning the language, availability of resources, and the strength of the community. If you evaluate performance based on language/stack the developers already know, would be difficult to tease apart the correlation between technology stack and developer ability.