4 ms·

At some point, do we have to consider that the problem might be Clojure itself? Does LISP lend itself to "Rails" -- a Rails that people want to work with? I ask

by ttymck 4y ago

At some point, do we have to consider that the problem might be Clojure itself? Does LISP lend itself to "Rails" -- a Rails that people want to work with? I ask, genuinely, as a near-total outsider. The comparison to Elixir got me really thinking. I appreciate your "call to action", but community consensus gathering wasn't necessary for Phoenix to emerge as an option-of-choice, it gained traction because it is _good_. Surely there are large organizations using full stack Clojure, similar to the Lawrence World-Journal. Is there something about LISP that makes it hard for them to abstract their "framework" bits into an open source package?

duncan-donuts 4y ago
The something is probably more philosophical within lisp communities. I’m relatively new to lisp (writing clojure/cl for about a year) and from what I’ve seen people prefer to bolt on small things instead of big frameworks. The full stack frameworks exist but they’re hardly frameworks. They’re closer to project templates than anything.
mark_l_watson 4y ago
It might be that simply committing strongly to a language, any language, has benefits? Years ago, a long term consulting customer hired me on a short fire-drill job. He had also hired some Clojure celebrities like Stuart Sierra and Stuart Holloway. They were incredible productive and fast. It was a very long time ago, but as far a I remember they had a small set up libraries they used. BTW, I was hired for a few hours a week to help with dev ops, not code. EDIT: I am currently working (part time) with an all in Common Lisp company. It is really nice to see a group of people who all love a programming language using it. As much as I like virtually ALL Lisp languages, I do sometimes feel guilty not just using Python when there are much better libraries available (e.g., machine learning, linked data, etc.). When a programming language has 1000x as many developers you simply get a richer ecosystem.
- didibus 4y ago
  > When a programming language has 1000x as many developers you simply get a richer ecosystem Interesting comment given the article. That's the magic of Clojure being hosted, you get the rich Java ecosystem and get to use your Lisp that you love. The downside is you still need to deal with the rich ecosystem that isn't as nice as if there was a rich one in Clojure.
  - mark_l_watson 4y ago
    You are correct, Clojure does get Java’s rich ecosystem, and Python’s via pythonlib. There is some impedance mismatch that you don’t get using, for example, Python directly. It will be interesting to see what languages win out long term. I really don’t like programming with Rust but it is becoming wildly popular. I do like Swift, the language is intuitive to me, has good REPL support, and has awesome standard libraries for machine learning and just about everything else. All that said, I am an old man, I like Lisp languages, and that works for me.
  - cutler 4y ago
    He said 1000x developers not libraries. Big difference.
jayceedenton 4y ago
> Is there something about LISP that makes it hard for them to abstract their "framework" bits into an open source package? No. I don't know what else to tell you.
- ttymck 4y ago
  That's fair, I didn't intend to sound entitled, but "let's all decide what Rails-like to use" doesn't seem to be working for Clojurists, so I was hoping that poking at other avenues might spark some productive conversation.
  - simongray 4y ago
    It's not that it doesn't work, it's that most Clojure programmers do not see the benefit since the selection of data-oriented libraries we have is much superior in our minds. Some people (a small minority) are trying to "solve" this, but it garners little interest since most people don't see any problem.
jmcgough 4y ago
"community consensus gathering wasn't necessary for Phoenix to emerge as an option-of-choice, it gained traction because it is _good_" I think it also because there's two camps of elixir devs - those who came from Ruby and those who came from Erlang. The Rubyists have a fairly easy time being productive quickly with Phoenix because it (at a glance) is very similar to Rails. From there you learn about supervisor trees, genserver, etc.
deleted 4y ago
[deleted]
didibus 4y ago
> Surely there are large organizations using full stack Clojure, similar to the Lawrence World-Journal. Is there something about LISP that makes it hard for them to abstract their "framework" bits into an open source package? There's a fundamental model shift that's not as compatible to frameworks. Lisp optimizes for it to be really fast to implement perfectly tailored custom solutions, with your own DSL (domain specific language) that best fit your problem. Iterations are quick, development is fast, you can automate away repetitions and ceremony trivially. The need for scaffolding and for complicated code-gen, which is half of what most web-frameworks provide, is just not there, because Lisps are already meta-programmable. The other thing is Clojure's functional nature. Objects and Actors and Modules, these things naturally expand to become Singleton state or behavior containers that you call upon. They also naturally lend to a plugin architecture, where configuration setups a chain of implementing interfaces called into by standard modules from the framework, etc. The functional, higher order, immutable, and data driven nature of Clojure doesn't fit well here either. What happens instead is that libraries, not frameworks, tend to work better in Clojure. Things you can call and use as you want, instead of things that call you and ask of very specific extension and configuration from your part. So the Clojure web stack is still full of reusable code, they're just exposed as libraries. When you know what to do, you can easily put together a Clojure website together, in no less time then it takes using a framework in another language, and you similarly reuse almost as much code as in any other language. The difference is that because you need to use the libraries, you also need to figure out how to use them and where and what to do to glue all of that stuff together. In a framework, you can't choose how to glue them all, it's forced on you, that's both the issue with frameworks, and the benefit. So when you don't know how to build a website, a framework really helps, it guides you, and you just follow its strict structure and plug what needs to be plugged, and configure what needs to be configured. With the library approach, that's left up to you, much harder to get started with, but not any less productive ounce you know. Finally, a framework forces everything to be a monolith, that is built and designed within the rules of the framework itself. All behavior you'd want to reuse needs to be framework aware and compatible. This means that slowly people grow an ecosystem of compatible libraries all around the framework. Again, with the library approach, the various libraries you choose to use were all independently designed and built, they weren't built to work together, so again, you have to find how to glue and connect them and map between them yourself. You could still have a framework, but the mental model a framework follows is often contrary to the mental model Clojure enables, people often choose Clojure because you can quickly customize things to your liking and connect various independent building blocks together in the way you prefer and that works best for you. That means whenever someone made their code structure available to others as a framework, everyone else went, I don't like the way you did it, so nevermind, I'll just use my way. If the libraries all only worked with their structure though, it be too much effort to go your own way, but not so in Clojure, because all the building blocks are exposed as libraries, so you can easily structure it however you prefer.

by ttymck 4y ago

duncan-donuts 4y ago

The something is probably more philosophical within lisp communities. I’m relatively new to lisp (writing clojure/cl for about a year) and from what I’ve seen people prefer to bolt on small things instead of big frameworks. The full stack frameworks exist but they’re hardly frameworks. They’re closer to project templates than anything.

mark_l_watson 4y ago

It might be that simply committing strongly to a language, any language, has benefits? Years ago, a long term consulting customer hired me on a short fire-drill job. He had also hired some Clojure celebrities like Stuart Sierra and Stuart Holloway. They were incredible productive and fast. It was a very long time ago, but as far a I remember they had a small set up libraries they used. BTW, I was hired for a few hours a week to help with dev ops, not code. EDIT: I am currently working (part time) with an all in Common Lisp company. It is really nice to see a group of people who all love a programming language using it. As much as I like virtually ALL Lisp languages, I do sometimes feel guilty not just using Python when there are much better libraries available (e.g., machine learning, linked data, etc.). When a programming language has 1000x as many developers you simply get a richer ecosystem.

didibus 4y ago
> When a programming language has 1000x as many developers you simply get a richer ecosystem Interesting comment given the article. That's the magic of Clojure being hosted, you get the rich Java ecosystem and get to use your Lisp that you love. The downside is you still need to deal with the rich ecosystem that isn't as nice as if there was a rich one in Clojure.
- mark_l_watson 4y ago
  You are correct, Clojure does get Java’s rich ecosystem, and Python’s via pythonlib. There is some impedance mismatch that you don’t get using, for example, Python directly. It will be interesting to see what languages win out long term. I really don’t like programming with Rust but it is becoming wildly popular. I do like Swift, the language is intuitive to me, has good REPL support, and has awesome standard libraries for machine learning and just about everything else. All that said, I am an old man, I like Lisp languages, and that works for me.
- cutler 4y ago
  He said 1000x developers not libraries. Big difference.

jayceedenton 4y ago

> Is there something about LISP that makes it hard for them to abstract their "framework" bits into an open source package? No. I don't know what else to tell you.

ttymck 4y ago
That's fair, I didn't intend to sound entitled, but "let's all decide what Rails-like to use" doesn't seem to be working for Clojurists, so I was hoping that poking at other avenues might spark some productive conversation.
- simongray 4y ago
  It's not that it doesn't work, it's that most Clojure programmers do not see the benefit since the selection of data-oriented libraries we have is much superior in our minds. Some people (a small minority) are trying to "solve" this, but it garners little interest since most people don't see any problem.

jmcgough 4y ago

"community consensus gathering wasn't necessary for Phoenix to emerge as an option-of-choice, it gained traction because it is _good_" I think it also because there's two camps of elixir devs - those who came from Ruby and those who came from Erlang. The Rubyists have a fairly easy time being productive quickly with Phoenix because it (at a glance) is very similar to Rails. From there you learn about supervisor trees, genserver, etc.

deleted 4y ago

[deleted]

didibus 4y ago

> Surely there are large organizations using full stack Clojure, similar to the Lawrence World-Journal. Is there something about LISP that makes it hard for them to abstract their "framework" bits into an open source package? There's a fundamental model shift that's not as compatible to frameworks. Lisp optimizes for it to be really fast to implement perfectly tailored custom solutions, with your own DSL (domain specific language) that best fit your problem. Iterations are quick, development is fast, you can automate away repetitions and ceremony trivially. The need for scaffolding and for complicated code-gen, which is half of what most web-frameworks provide, is just not there, because Lisps are already meta-programmable. The other thing is Clojure's functional nature. Objects and Actors and Modules, these things naturally expand to become Singleton state or behavior containers that you call upon. They also naturally lend to a plugin architecture, where configuration setups a chain of implementing interfaces called into by standard modules from the framework, etc. The functional, higher order, immutable, and data driven nature of Clojure doesn't fit well here either. What happens instead is that libraries, not frameworks, tend to work better in Clojure. Things you can call and use as you want, instead of things that call you and ask of very specific extension and configuration from your part. So the Clojure web stack is still full of reusable code, they're just exposed as libraries. When you know what to do, you can easily put together a Clojure website together, in no less time then it takes using a framework in another language, and you similarly reuse almost as much code as in any other language. The difference is that because you need to use the libraries, you also need to figure out how to use them and where and what to do to glue all of that stuff together. In a framework, you can't choose how to glue them all, it's forced on you, that's both the issue with frameworks, and the benefit. So when you don't know how to build a website, a framework really helps, it guides you, and you just follow its strict structure and plug what needs to be plugged, and configure what needs to be configured. With the library approach, that's left up to you, much harder to get started with, but not any less productive ounce you know. Finally, a framework forces everything to be a monolith, that is built and designed within the rules of the framework itself. All behavior you'd want to reuse needs to be framework aware and compatible. This means that slowly people grow an ecosystem of compatible libraries all around the framework. Again, with the library approach, the various libraries you choose to use were all independently designed and built, they weren't built to work together, so again, you have to find how to glue and connect them and map between them yourself. You could still have a framework, but the mental model a framework follows is often contrary to the mental model Clojure enables, people often choose Clojure because you can quickly customize things to your liking and connect various independent building blocks together in the way you prefer and that works best for you. That means whenever someone made their code structure available to others as a framework, everyone else went, I don't like the way you did it, so nevermind, I'll just use my way. If the libraries all only worked with their structure though, it be too much effort to go your own way, but not so in Clojure, because all the building blocks are exposed as libraries, so you can easily structure it however you prefer.