8 ms·

Reading the article, I'm a little bit curious - I've heard a lot that more productive languages become less productive over a certain team size, since productiv

Reading the article, I'm a little bit curious - I've heard a lot that more productive languages become less productive over a certain team size, since productivity typically comes from a lesser degree of strictness. Does lisp have similar problems?

loup-vaillant 9y ago
> productivity typically comes from a lesser degree of strictness Does it? Maybe it's the way I think, but I have observed that I could move faster when the compiler is strict, because I don't have to think about whole classes of errors—they're automagically checked. I like my compiler to be disciplined, so I don't have to.
- pasabagi 9y ago
  Me too, to be honest. Still, for example - I can see that dynamic types reduce a certain quantity of boilerplate. If you just don't make the kind of mistakes that make static checking necessary, then you could be more productive that way. I think a lot of boilerplate stuff is a bit like that. I wouldn't be - but still.
  - loup-vaillant 9y ago
    Explicit typing adds boilerplate. Static typing, not so much. Type inference is bloody effective at removing boilerplate. To the point where it can take you quite close to the best of the world: static checks, without boilerplate. Boilerplate isn't the reason why static typing might be worse than dynamic typing. Undecidability is. Inference algorithms tend to reject some correct programs. The real question is then, are we interested in those programs? So far, my experience has been "not really". I know of a few cumbersome exceptions, but overall, Hindley-Milner type inference basically lets me write the programs I want. It's not like Java is a worthy ambassador for static typing.
    - ScottBurson 9y ago
      The killer app for dynamic typing is when you want to develop the program concurrently with executing it. I don't know that it's technically impossible for a statically-typed language to support that usage mode, but I've never seen it done.
      - yyhhsj0521 9y ago
        I prototype and test with ghci a lot while I'm writing Haskell. Not really impossible.
        kqr 9y ago
        Does GHCi no longer flush the entire application state when you reload a module? I know it's not as much of a big deal in Haskell where mutable state is limited, but I still remember it being an annoyance to have to manually breakfast out my data to disk and then reload it again.
    - millstone 9y ago
      Boilerplate can happen at a higher level than just writing down type names. A good example is "variadic" functions. Consider computing the max of three numbers. Clojure's `max` takes any number of arguments, while Haskell has `max` that takes two arguments, or `maximum` that takes a list of arguments; both require some boilerplate to apply if you have exactly three. It's impossible to write down a Haskell function equivalent to Clojure's `apply`. You have to work around its absence, e.g. with awkward folds. Or for a more immediate example, compare Clojure's flexible `map` to Haskell's big 'zip' family: zip1, zip2, zip3, zipWith5...
      - tome 9y ago
        Meh. I hardly consider max [a, b, c] to be boilerplate.
      - loup-vaillant 9y ago
        The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. And at the implementation side, it's not like map's flexibility came from nowhere. I wouldn't be surprised to find out that Clojure's `map` is just as verbose as Haskell's entire 'zip' family. The whole concept of an `apply` function is a bit alien to me. I generally just call the damn function. Also, Haskell has an `apply` function. It's the `$` operator, defined thus (the first line is optional): `$` :: (a -> b) -> a -> b f $ x = f x It helps that Haskell functions all have one argument (that with being curried by default). If you want several arguments, just apply them one by one: f $ x $ y (This is sometimes used to avoid parentheses in some cases. I personally tend to just use the parentheses.)
marcosdumay 9y ago
Avoiding compiler verifications is one way to get some extra productivity on a class of problems. As you said, it does not come without downsides. But there are many language level tools that will help with your productivity. Some are all upside things, others come with different trade-offs. The article isn't even focused on compile-time verifications.
rerx 9y ago
Paul Graham's Viaweb was rewritten in C++ and Perl after the aquisition by Yahoo. I can imagine that this was easier to deal with for a large team than the original implementation in Lisp.
- deepaksurti 9y ago
  >> C++...this was easier to deal with for a large team This was safer for pointy haired bosses :)
- lispm 9y ago
  That's not unusual, historically some software had prototypes in Lisp. Some managed to get into production. Some even proved very hard to replace. But that was at a time when more people learned Lisp, there was less choice in tools and the eco-systems were smaller. In the 70s/80s one could buy ten years into the future with the right hardware/software and government/military was financing. Take for example the Connection Machine CM 1, an early massive-parallel computer with 2^16 processors. It was initially developed largely for and with Lisp. You could program it in *Lisp from a Lisp Machine - one of the most expensive co-processors. Fortran and C was added then for certain commercial users. Very expensive stuff and at least ten years ahead. Today the landscape looks different.
  - copper_think 9y ago
    The garbage collector for Microsoft's Common Language Runtime (CLR -- the VM for .NET) was written in Lisp originally and then transpiled into C.
    - erikj 9y ago
      Also, Apple's Interface Builder began its life as a Lisp program: http://vimeo.com/62618532 http://vimeo.com/62618532
      - mark_l_watson 9y ago
        +1 for mentioning my friend Denny. I wrote an application that Experteliigence sold for me - lots of fun. Expertelligence had a high talent density.

loup-vaillant 9y ago

> productivity typically comes from a lesser degree of strictness Does it? Maybe it's the way I think, but I have observed that I could move faster when the compiler is strict, because I don't have to think about whole classes of errors—they're automagically checked. I like my compiler to be disciplined, so I don't have to.

pasabagi 9y ago
Me too, to be honest. Still, for example - I can see that dynamic types reduce a certain quantity of boilerplate. If you just don't make the kind of mistakes that make static checking necessary, then you could be more productive that way. I think a lot of boilerplate stuff is a bit like that. I wouldn't be - but still.
- loup-vaillant 9y ago
  Explicit typing adds boilerplate. Static typing, not so much. Type inference is bloody effective at removing boilerplate. To the point where it can take you quite close to the best of the world: static checks, without boilerplate. Boilerplate isn't the reason why static typing might be worse than dynamic typing. Undecidability is. Inference algorithms tend to reject some correct programs. The real question is then, are we interested in those programs? So far, my experience has been "not really". I know of a few cumbersome exceptions, but overall, Hindley-Milner type inference basically lets me write the programs I want. It's not like Java is a worthy ambassador for static typing.
  - ScottBurson 9y ago
    The killer app for dynamic typing is when you want to develop the program concurrently with executing it. I don't know that it's technically impossible for a statically-typed language to support that usage mode, but I've never seen it done.
    - yyhhsj0521 9y ago
      I prototype and test with ghci a lot while I'm writing Haskell. Not really impossible.
      - kqr 9y ago
        Does GHCi no longer flush the entire application state when you reload a module? I know it's not as much of a big deal in Haskell where mutable state is limited, but I still remember it being an annoyance to have to manually breakfast out my data to disk and then reload it again.
  - millstone 9y ago
    Boilerplate can happen at a higher level than just writing down type names. A good example is "variadic" functions. Consider computing the max of three numbers. Clojure's `max` takes any number of arguments, while Haskell has `max` that takes two arguments, or `maximum` that takes a list of arguments; both require some boilerplate to apply if you have exactly three. It's impossible to write down a Haskell function equivalent to Clojure's `apply`. You have to work around its absence, e.g. with awkward folds. Or for a more immediate example, compare Clojure's flexible `map` to Haskell's big 'zip' family: zip1, zip2, zip3, zipWith5...
    - tome 9y ago
      Meh. I hardly consider max [a, b, c] to be boilerplate.
    - loup-vaillant 9y ago
      The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. And at the implementation side, it's not like map's flexibility came from nowhere. I wouldn't be surprised to find out that Clojure's `map` is just as verbose as Haskell's entire 'zip' family. The whole concept of an `apply` function is a bit alien to me. I generally just call the damn function. Also, Haskell has an `apply` function. It's the `$` operator, defined thus (the first line is optional): `$` :: (a -> b) -> a -> b f $ x = f x It helps that Haskell functions all have one argument (that with being curried by default). If you want several arguments, just apply them one by one: f $ x $ y (This is sometimes used to avoid parentheses in some cases. I personally tend to just use the parentheses.)

marcosdumay 9y ago

Avoiding compiler verifications is one way to get some extra productivity on a class of problems. As you said, it does not come without downsides. But there are many language level tools that will help with your productivity. Some are all upside things, others come with different trade-offs. The article isn't even focused on compile-time verifications.

rerx 9y ago

Paul Graham's Viaweb was rewritten in C++ and Perl after the aquisition by Yahoo. I can imagine that this was easier to deal with for a large team than the original implementation in Lisp.

deepaksurti 9y ago
>> C++...this was easier to deal with for a large team This was safer for pointy haired bosses :)
lispm 9y ago
That's not unusual, historically some software had prototypes in Lisp. Some managed to get into production. Some even proved very hard to replace. But that was at a time when more people learned Lisp, there was less choice in tools and the eco-systems were smaller. In the 70s/80s one could buy ten years into the future with the right hardware/software and government/military was financing. Take for example the Connection Machine CM 1, an early massive-parallel computer with 2^16 processors. It was initially developed largely for and with Lisp. You could program it in *Lisp from a Lisp Machine - one of the most expensive co-processors. Fortran and C was added then for certain commercial users. Very expensive stuff and at least ten years ahead. Today the landscape looks different.
- copper_think 9y ago
  The garbage collector for Microsoft's Common Language Runtime (CLR -- the VM for .NET) was written in Lisp originally and then transpiled into C.
  - erikj 9y ago
    Also, Apple's Interface Builder began its life as a Lisp program: http://vimeo.com/62618532 http://vimeo.com/62618532
    - mark_l_watson 9y ago
      +1 for mentioning my friend Denny. I wrote an application that Experteliigence sold for me - lots of fun. Expertelligence had a high talent density.