4 ms·

I think that it is even simpler than that. There are languages for people who want to get things done, and languages for people who want the perfect language f

by btilly 7y ago

I think that it is even simpler than that. There are languages for people who want to get things done, and languages for people who want the perfect language for getting things done. The problem is that definitions of perfection differ between people, so people who are searching for perfect languages wind up in a small niche of people who agree, separated from people next door whose idea of perfection is just slightly different. In the meantime people whose focus is on getting things done go with a popular language which builds a critical mass of ways to get things done. And the availability of useful libraries makes them actually better to get stuff done with than languages that are theoretically nicer in some way. This is, of course, a worse is better kind of argument. See https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html for context on that.

reikonomusha 7y ago
I don’t like this argument and paints a picture that Lispers are overly concerned by some academic aspect of programming. Many people, myself included, use Lisp because it lets us get something done more quickly, more efficiently, more easily, or all three. It’s true. Importing flask in Python and starting a server takes about 1/2 as much code as in Lisp. Some extraordinarily routine stuff Python has down to a one-liner. A lot of people have also written more Python libraries, so chances are you’ll be able to cobble any random doodad together with a huge dependency tree. But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust.
- btilly 7y ago
  The following phrase is telling. "But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust." How many programmers would see Python's language implementation as "slapdash" or care? The fact that you both see it that way and care speaks volumes towards you fitting my characterization of the kind of person who uses a minority language. The other points likewise. Python's inefficiency is well-known and acceptable for most use cases. Where you need better, it lets you escape down to more efficient languages in libraries. Some good examples of this include pandas and various machine learning libraries. And as for deployment, it is more of an organizational challenge than technical one. The strategy of taking half your servers offline, deploying, then swapping and repeating worked fine 20 years ago. It works fine today. (You might have to do some ceremony with kubernetes. But the strategy remains conceptually similar.) This is only a significant pain point when there are other problems that interfere. The fact that these things bother you, and bother you enough to rewrite wheels that already exist, speaks volumes. The fact that people who agree with you on this then can't agree on whether strong typing is worthwhile (like Haskell), or continuations are good (like Scheme) or whether performance is critical (like Common Lisp) or whether access to the JVM toolset matters (like Clojure) causes you to not create a critical mass around a better toolset. And so the situation remains. You all agree that the popular languages are so terrible that you avoid them. But then can't agree on which unpopular language everyone should use instead, or why.
  - jacobwilliamroy 7y ago
    >cant agree on which unpopular language everyone should use All lispers agree everyone should use lisp. Any lisper that doesnt like lisp is welcome modify that lisp to make it something the lisper does like.
    - btilly 7y ago
      And that is the problem. Lispers wind up with a myriad of incompatible Lisps, and a solution written for one may or may not be portable to the next. Sure, you can call them all Lisp. But Common Lisp, Emacs Lisp, Clojure, and Racket are, syntactic similarities notwithstanding, actually different languages. A library written for one will generally not work for the others.
      - jacobwilliamroy 7y ago
        Then its only a ten-minute diversion to modify that library to work with my lisp. Or to build a library in my lisp which can work with that library.
        btilly 7y ago
        I disbelieve. A complex application written with CLOS will generally not be portable to Emacs Lisp. An application written in Emacs Lisp that takes advantage of dynamic scope won't be easy to port to Clojure. A library in Clojure that wraps something in the JVM ecosystem won't work in Racket. And something written in Racket using continuations or Pict generally won't be easy to port to Common Lisp. And even with closer Lisps than that, I have enough experience of "that should be easy to port" then blowing up over minor details to be suspicious. Sometimes it will be 10 minutes. Sometimes it will be several weeks and incomplete even then. The latter happens often enough that, the developer's confidence notwithstanding, the average is waaaay longer than the estimated 10 minutes. (The phenomena of tasks being rarely faster than we thought, but roadblocks can be unlimited in extent is generally true in programming. This is one of the reasons why our time estimates tend to be systemically low.)
dgb23 7y ago
I can only speak from the perspective of using Clojure, I toyed around with Racket and have no experience with CL. That said, I disagree with some of the points you make: > availability of useful libraries Clojure is embedded in both JS runtimes and the JVM. Both feature massive ecosystems. In terms of getting things done: Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling data-structures, manipulation and algorithms then they are far less expressive and productive than Clojure from my experience. I personally think the main issue really is the learning curve. There are quite a number of things that 'suck' about Clojure initially: 1. In a Lisp you are essentially manipulating an AST rather than writing statement-based text. Initially this is cumbersome and taxing both while reading and writing programs. 2. In a functional Lisp like Clojure (and other FP languages) there is a wide variety of commonly used functions which are used to manipulate and compose data-structures and other functions. Especially when reading code this can be daunting. 3. Setting up a environment correctly for REPL driven development as a beginner and tuning it as an intermediate user is quite an undertaking in comparison to many other languages. 4. Clojure specifically being a hosted language forces you to understand the hosted ecosystem as well plus the wiring between the host and Clojure. The payoff for all those four points is worth it: 1. Search for paredit visualizations like this one: http://danmidwood.com/content/2014/11/21/animated-paredit.html http://danmidwood.com/content/2014/11/21/animated-paredit.ht.... Manipulating code this way requires mechanical prowess and exercise but scales up really nicely, especially alongside better understanding of Lisp code in general. 2. The incredible variety of functional building blocks scales really well with your experience and understanding. You are programming with a series of descriptive expressions, rather than lower level statements. Code becomes more declarative, dense and expressive. Abstraction is much more fluent. 3. A nicely set-up environment enables very fast development cycles and allows for understanding pieces of code of any scope in isolation, because you can evaluate, change and test any expression instantly. 4. This is in my experience a necessary evil to get higher adoption and a the massive library ecosystems of JS and Java. I assume there are a lot of capable developers who simply cannot get over 1 possibly while being pushed back by 2-4. And I have to admit: If I wasn't already infected with Lisp at a younger age, I probably wouldn't have bothered with Clojure or any Lisp. But now it is my favorite for manipulating and modelling data AKA doing 'business-logic' and transformations between APIs.

by btilly 7y ago

reikonomusha 7y ago

I don’t like this argument and paints a picture that Lispers are overly concerned by some academic aspect of programming. Many people, myself included, use Lisp because it lets us get something done more quickly, more efficiently, more easily, or all three. It’s true. Importing flask in Python and starting a server takes about 1/2 as much code as in Lisp. Some extraordinarily routine stuff Python has down to a one-liner. A lot of people have also written more Python libraries, so chances are you’ll be able to cobble any random doodad together with a huge dependency tree. But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust.

btilly 7y ago
The following phrase is telling. "But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust." How many programmers would see Python's language implementation as "slapdash" or care? The fact that you both see it that way and care speaks volumes towards you fitting my characterization of the kind of person who uses a minority language. The other points likewise. Python's inefficiency is well-known and acceptable for most use cases. Where you need better, it lets you escape down to more efficient languages in libraries. Some good examples of this include pandas and various machine learning libraries. And as for deployment, it is more of an organizational challenge than technical one. The strategy of taking half your servers offline, deploying, then swapping and repeating worked fine 20 years ago. It works fine today. (You might have to do some ceremony with kubernetes. But the strategy remains conceptually similar.) This is only a significant pain point when there are other problems that interfere. The fact that these things bother you, and bother you enough to rewrite wheels that already exist, speaks volumes. The fact that people who agree with you on this then can't agree on whether strong typing is worthwhile (like Haskell), or continuations are good (like Scheme) or whether performance is critical (like Common Lisp) or whether access to the JVM toolset matters (like Clojure) causes you to not create a critical mass around a better toolset. And so the situation remains. You all agree that the popular languages are so terrible that you avoid them. But then can't agree on which unpopular language everyone should use instead, or why.
- jacobwilliamroy 7y ago
  >cant agree on which unpopular language everyone should use All lispers agree everyone should use lisp. Any lisper that doesnt like lisp is welcome modify that lisp to make it something the lisper does like.
  - btilly 7y ago
    And that is the problem. Lispers wind up with a myriad of incompatible Lisps, and a solution written for one may or may not be portable to the next. Sure, you can call them all Lisp. But Common Lisp, Emacs Lisp, Clojure, and Racket are, syntactic similarities notwithstanding, actually different languages. A library written for one will generally not work for the others.
    - jacobwilliamroy 7y ago
      Then its only a ten-minute diversion to modify that library to work with my lisp. Or to build a library in my lisp which can work with that library.
      - btilly 7y ago
        I disbelieve. A complex application written with CLOS will generally not be portable to Emacs Lisp. An application written in Emacs Lisp that takes advantage of dynamic scope won't be easy to port to Clojure. A library in Clojure that wraps something in the JVM ecosystem won't work in Racket. And something written in Racket using continuations or Pict generally won't be easy to port to Common Lisp. And even with closer Lisps than that, I have enough experience of "that should be easy to port" then blowing up over minor details to be suspicious. Sometimes it will be 10 minutes. Sometimes it will be several weeks and incomplete even then. The latter happens often enough that, the developer's confidence notwithstanding, the average is waaaay longer than the estimated 10 minutes. (The phenomena of tasks being rarely faster than we thought, but roadblocks can be unlimited in extent is generally true in programming. This is one of the reasons why our time estimates tend to be systemically low.)

dgb23 7y ago

I can only speak from the perspective of using Clojure, I toyed around with Racket and have no experience with CL. That said, I disagree with some of the points you make: > availability of useful libraries Clojure is embedded in both JS runtimes and the JVM. Both feature massive ecosystems. In terms of getting things done: Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling data-structures, manipulation and algorithms then they are far less expressive and productive than Clojure from my experience. I personally think the main issue really is the learning curve. There are quite a number of things that 'suck' about Clojure initially: 1. In a Lisp you are essentially manipulating an AST rather than writing statement-based text. Initially this is cumbersome and taxing both while reading and writing programs. 2. In a functional Lisp like Clojure (and other FP languages) there is a wide variety of commonly used functions which are used to manipulate and compose data-structures and other functions. Especially when reading code this can be daunting. 3. Setting up a environment correctly for REPL driven development as a beginner and tuning it as an intermediate user is quite an undertaking in comparison to many other languages. 4. Clojure specifically being a hosted language forces you to understand the hosted ecosystem as well plus the wiring between the host and Clojure. The payoff for all those four points is worth it: 1. Search for paredit visualizations like this one: http://danmidwood.com/content/2014/11/21/animated-paredit.html http://danmidwood.com/content/2014/11/21/animated-paredit.ht.... Manipulating code this way requires mechanical prowess and exercise but scales up really nicely, especially alongside better understanding of Lisp code in general. 2. The incredible variety of functional building blocks scales really well with your experience and understanding. You are programming with a series of descriptive expressions, rather than lower level statements. Code becomes more declarative, dense and expressive. Abstraction is much more fluent. 3. A nicely set-up environment enables very fast development cycles and allows for understanding pieces of code of any scope in isolation, because you can evaluate, change and test any expression instantly. 4. This is in my experience a necessary evil to get higher adoption and a the massive library ecosystems of JS and Java. I assume there are a lot of capable developers who simply cannot get over 1 possibly while being pushed back by 2-4. And I have to admit: If I wasn't already infected with Lisp at a younger age, I probably wouldn't have bothered with Clojure or any Lisp. But now it is my favorite for manipulating and modelling data AKA doing 'business-logic' and transformations between APIs.