The answer is: the author’s idiosyncratic skillset and language familiarity, the state of the web application programming language ecosystem 9 years ago, and a series of extremely unconventional architectural decisions; all of which are nearly guaranteed not to apply to the reader.
Great summary. Also, given they were a 3 person startup I think they should have immediately reduced the candidate languages to the ones the author was already quite familiar with: Python and Common Lisp. Then out of those you think about how hard it would be to hire another engineer and get them up to speed without losing too much of your own velocity. Then you choose Python.
(And hopefully step back from disliking the GIL and realise it very rarely stopped anyone from running a website in the real world).
“I think they should have immediately reduced the candidate languages to the ones the author was already quite familiar with: Python and Common Lisp”
That’s exactly what the startup factories tell the founders to do, too. Makes sense given they need to be developing as fast as they can rather than learning a language/toolset and minimizing risks to their iterations.
I don’t know if language choice has anything to do with it, but the fact remains: the service is now dead. ;)
I agree in 2012 the state of Python3 support was a valid concern, and I have to admit actively discouraging people from learning it at the time, but luckily that part hasn’t aged well. I still want better FP support in Python of course.
My biggest problem with Common Lisp is that it’s a Lisp-2. Why would anyone want different namespaces for functions and other bindings in an ostensibly functional language?
Why would anyone want different namespaces for functions and other bindings in an ostensibly functional language?
According to this site, one of the arguments was “backwards compatibility”:
Common Lisp was the result of a compromise between a number of dialects of Lisp, most of which had separate namespaces.. [transitioning to a single namespace] would introduce a considerable amount of incompatibility..” There are really more than two namespaces, reducing either the benefit of collapsing these two or the cost of collapsing them all
which I don’t find that convincing, since there were plenty of lisps using dynamic scoping, despite CL using lexical scopes. But I agree, things like these together with, frankly wierd function names always annoy me. I’d guess that in the end, CL shouldn’t be seen as a functional language, since Lisp wasn’t even originally conceived as functional language.
I’d guess that in the end, CL shouldn’t be seen as a functional language, since Lisp wasn’t even originally conceived as functional language.
There’s a page which I can’t find now which makes the case that the term “functional programming language” evolves over time to mean “the most functional programming language which currently exists”, so different features rotate in and out of defining what it effectively means to be a functional programming language.
(I’d add that each generation has a different boogeyman idea, an idea which the Average Programmer regards as being “too complex” and which others write blog posts or the local equivalent to explain.)
The first generation was when Algol introduced recursion. Recursion is also the boogeyman idea of this era.
The second generation begins with “mature” Lisp (that is, Lisp implementations like MACLISP and Lisp Machine Lisps, not LISP 1.5) and, later, Scheme, where the defining feature is first-class functions and closures, and the boogeyman idea is Scheme’s continuations. Common features are strong dynamic typing and a universal feature is garbage collection. The new-school scripting languages (Perl, Python, Ruby) are languages of this type with object systems bolted on, and Java’s getting there, slowly.
The third generation is ML and everything after, including OCaml and Haskell. Now, functional programming includes strong, static type systems with algebraic types, Hindley-Milner type inference, and, at a syntactic level, pattern-matching as flow control. The boogeyman idea is monads, and, more specifically, requiring the use of monads to mark out side-effecting code, as Haskell does.
The underlying point is that “Functional programming is whatever your language of choice doesn’t have yet”: Recursion is now universal. It wasn’t when FORTRAN IV was “your language of choice” for a lot of programmers. Strong dynamic typing and garbage collection aren’t universal, but they’re not weird and wacky ideas only long-haired MIT AI Lab types can make sense of. Marking your side-effecting code in a machine-readable way is still weird and wacky… for now.
I’m pretty sure backwards compatibility with most existing implementations was exactly the goal. I’ve heard you can run early Lisp programs on CL with minimal modifications to this day, but I’ve never tried it myself.
It might be slightly easier to write tooling when you know what’s a function and what’s a variable.
On the other hand, if you use a Lisp-2 in functional style (which poorly suits Common Lisp), you still have the problem of full analysis between the boundary of namespaces + awkward syntax. It looks like Common Lisp is meant to be used in imperative style, without juggling functions as values.
Yeah, I guess it’s my expecation that the language is supposed to be functional that makes lisp-2 look so disappointing for me. It technically has everything for FP to work, so I feel cheated. ;)
The answer is: the author’s idiosyncratic skillset and language familiarity, the state of the web application programming language ecosystem 9 years ago, and a series of extremely unconventional architectural decisions; all of which are nearly guaranteed not to apply to the reader.
Great summary. Also, given they were a 3 person startup I think they should have immediately reduced the candidate languages to the ones the author was already quite familiar with: Python and Common Lisp. Then out of those you think about how hard it would be to hire another engineer and get them up to speed without losing too much of your own velocity. Then you choose Python.
(And hopefully step back from disliking the GIL and realise it very rarely stopped anyone from running a website in the real world).
“I think they should have immediately reduced the candidate languages to the ones the author was already quite familiar with: Python and Common Lisp”
That’s exactly what the startup factories tell the founders to do, too. Makes sense given they need to be developing as fast as they can rather than learning a language/toolset and minimizing risks to their iterations.
I don’t know if language choice has anything to do with it, but the fact remains: the service is now dead. ;)
I agree in 2012 the state of Python3 support was a valid concern, and I have to admit actively discouraging people from learning it at the time, but luckily that part hasn’t aged well. I still want better FP support in Python of course.
My biggest problem with Common Lisp is that it’s a Lisp-2. Why would anyone want different namespaces for functions and other bindings in an ostensibly functional language?
According to this site, one of the arguments was “backwards compatibility”:
which I don’t find that convincing, since there were plenty of lisps using dynamic scoping, despite CL using lexical scopes. But I agree, things like these together with, frankly wierd function names always annoy me. I’d guess that in the end, CL shouldn’t be seen as a functional language, since Lisp wasn’t even originally conceived as functional language.
There’s a page which I can’t find now which makes the case that the term “functional programming language” evolves over time to mean “the most functional programming language which currently exists”, so different features rotate in and out of defining what it effectively means to be a functional programming language.
(I’d add that each generation has a different boogeyman idea, an idea which the Average Programmer regards as being “too complex” and which others write blog posts or the local equivalent to explain.)
The first generation was when Algol introduced recursion. Recursion is also the boogeyman idea of this era.
The second generation begins with “mature” Lisp (that is, Lisp implementations like MACLISP and Lisp Machine Lisps, not LISP 1.5) and, later, Scheme, where the defining feature is first-class functions and closures, and the boogeyman idea is Scheme’s continuations. Common features are strong dynamic typing and a universal feature is garbage collection. The new-school scripting languages (Perl, Python, Ruby) are languages of this type with object systems bolted on, and Java’s getting there, slowly.
(Some pre-Common Lisp Lisps didn’t have closures. They had the upwards funarg problem, instead.)
The third generation is ML and everything after, including OCaml and Haskell. Now, functional programming includes strong, static type systems with algebraic types, Hindley-Milner type inference, and, at a syntactic level, pattern-matching as flow control. The boogeyman idea is monads, and, more specifically, requiring the use of monads to mark out side-effecting code, as Haskell does.
The underlying point is that “Functional programming is whatever your language of choice doesn’t have yet”: Recursion is now universal. It wasn’t when FORTRAN IV was “your language of choice” for a lot of programmers. Strong dynamic typing and garbage collection aren’t universal, but they’re not weird and wacky ideas only long-haired MIT AI Lab types can make sense of. Marking your side-effecting code in a machine-readable way is still weird and wacky… for now.
I wonder why backwards compatibility was a concern if CL could not run any of that old code unmodified. Ot could it?
Common Lisp could be implemented in terms of the Old Lisps with a library of functions and macros. That’s the kind of compatibility they were after.
I’m pretty sure backwards compatibility with most existing implementations was exactly the goal. I’ve heard you can run early Lisp programs on CL with minimal modifications to this day, but I’ve never tried it myself.
It might be slightly easier to write tooling when you know what’s a function and what’s a variable.
On the other hand, if you use a Lisp-2 in functional style (which poorly suits Common Lisp), you still have the problem of full analysis between the boundary of namespaces + awkward syntax. It looks like Common Lisp is meant to be used in imperative style, without juggling functions as values.
Yeah, I guess it’s my expecation that the language is supposed to be functional that makes lisp-2 look so disappointing for me. It technically has everything for FP to work, so I feel cheated. ;)
Does it really pose a significant problem?