4 ms·

It's definitely good for prototyping. However, the real question is whether you're going to build it alone or have any plans to build a team around it and such.

It's definitely good for prototyping. However, the real question is whether you're going to build it alone or have any plans to build a team around it and such. If the latter is the case, think twice.

taeric 13y ago
Is this feeling just because there is a larger pool of choices that know other options? Or do you feel LISP is actually a bad choice for large teams?
- mike_ivanov 13y ago
  Lisp is a good choice for any team, as long as your team agrees with your choice. It's all about attitude. With Ruby/Python/PHP people rarely express strong sentiments over the language choice. Typically, you can easily convince the team going this or that way, depending on the task. Everybody understands those are just tools. However, when it comes to non-mainstream languages such as Lisp, people become more galvanized. Negative sentiments are likely to shift from 'meh, whatever' to 'you must be mad'. That's why I say think twice. You might alienate some people -- if that's something you care about.
  - cgag 13y ago
    But then the people you do hire are super into it. I can't imagine there are many people using a lisp at work begrudgingly when there are so many people who'd love to get to use it professionally.
- adwf 13y ago
  I think it's partly to do with the extreme flexibility of the language. When you have a large team programming in Java, you pretty much know that they're all going to be programming in roughly the same style. eg. They'll obviously be object oriented, they'll use the same major libraries, they'll be focusing on the design patterns, etc... Whereas in the Lisp world, you have so much flexibility that you can end up with all sorts: some people doing pure functional code, some OO, some using tail recursion wherever possible vs. some preferring more explicit representations, some going heavy on the macros, some using LOOP, some preferring recursive mappings of anonymous functions, etc... Ultimately, this can be fixed by using a decent style guide. Google has a good example since they acquired ITA: http://google-styleguide.googlecode.com/svn/trunk/lispguide.xml http://google-styleguide.googlecode.com/svn/trunk/lispguide.... In other languages it isn't so much of a problem - eg. I'm thinking of Python as an example where you are strongly encouraged that there is "only one way to do it". However, if you recognise from the beginning that you need to enforce a decent style guide, then I see no reason why large Lisp teams couldn't work.
  - fractallyte 13y ago
    I think this demonstrates just how much the growth of real software engineering has been stunted by half-solutions (like Java, and other mainstream languages). It's exciting! In the case of Lisp, it's not just about enforcing styles, but (as a team) coming up with the appropriate DSL for the task at hand. The classic 'bottom-up' paradigm (http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html), but done collaboratively. The analog has been done to death in object oriented languages, with concepts such as design patterns and frameworks. I'd love to see similar developments in a meta-language like Lisp, and with all the (potential) power that entails...

taeric 13y ago

Is this feeling just because there is a larger pool of choices that know other options? Or do you feel LISP is actually a bad choice for large teams?

mike_ivanov 13y ago
Lisp is a good choice for any team, as long as your team agrees with your choice. It's all about attitude. With Ruby/Python/PHP people rarely express strong sentiments over the language choice. Typically, you can easily convince the team going this or that way, depending on the task. Everybody understands those are just tools. However, when it comes to non-mainstream languages such as Lisp, people become more galvanized. Negative sentiments are likely to shift from 'meh, whatever' to 'you must be mad'. That's why I say think twice. You might alienate some people -- if that's something you care about.
- cgag 13y ago
  But then the people you do hire are super into it. I can't imagine there are many people using a lisp at work begrudgingly when there are so many people who'd love to get to use it professionally.
adwf 13y ago
I think it's partly to do with the extreme flexibility of the language. When you have a large team programming in Java, you pretty much know that they're all going to be programming in roughly the same style. eg. They'll obviously be object oriented, they'll use the same major libraries, they'll be focusing on the design patterns, etc... Whereas in the Lisp world, you have so much flexibility that you can end up with all sorts: some people doing pure functional code, some OO, some using tail recursion wherever possible vs. some preferring more explicit representations, some going heavy on the macros, some using LOOP, some preferring recursive mappings of anonymous functions, etc... Ultimately, this can be fixed by using a decent style guide. Google has a good example since they acquired ITA: http://google-styleguide.googlecode.com/svn/trunk/lispguide.xml http://google-styleguide.googlecode.com/svn/trunk/lispguide.... In other languages it isn't so much of a problem - eg. I'm thinking of Python as an example where you are strongly encouraged that there is "only one way to do it". However, if you recognise from the beginning that you need to enforce a decent style guide, then I see no reason why large Lisp teams couldn't work.
- fractallyte 13y ago
  I think this demonstrates just how much the growth of real software engineering has been stunted by half-solutions (like Java, and other mainstream languages). It's exciting! In the case of Lisp, it's not just about enforcing styles, but (as a team) coming up with the appropriate DSL for the task at hand. The classic 'bottom-up' paradigm (http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html), but done collaboratively. The analog has been done to death in object oriented languages, with concepts such as design patterns and frameworks. I'd love to see similar developments in a meta-language like Lisp, and with all the (potential) power that entails...