| ▲ | libraryofbabel 9 hours ago |
| Or perhaps, just perhaps, the true higher-dimensional move is realizing that choice of programming language isn’t usually the critical factor in whether a project, system, or business succeeds or fails, and that obsessing over the One True Way is a trap. It might surprise the author to learn that there are many people who: 1) Have tried lisp and clojure 2) Liked their elegance and expressiveness 3) Have read through SICP and done most of the exercises 4) Would still choose plain old boring easy-to-read always-second-best Python for 90% of use-cases (and probably Rust for the last 10%) when building a real business in the real world. The article could really benefit from some steel-manning. Remove the cute Flatland metaphor and it is effectively arguing that lisp/clojure haven’t been universally adopted because most programmers haven’t Seen The Light in some sort of epiphany of parentheses and macros. The truth is more nuanced. |
|
| ▲ | logicprog 5 hours ago | parent | next [-] |
| "It might surprise the author to learn that there are many people who: 1) Have tried lisp and clojure 2) Liked their elegance and expressiveness 3) Have read through SICP and done most of the exercises 4) Would still choose plain old boring easy-to-read always-second-best Python for 90% of use-cases (and probably Rust for the last 10%) when building a real business in the real world." This is me to a T — even when I'm building hobby projects. The point of writing any code, for me, is most of all to see a certain idea to fruition, so I choose what will make me most productive getting where I want to go. And while I still worship at the altar of Common Lisp as an incredibly good language, the language matters much less than the libraries, ecosystem, and documentation for productivity (or even effective DSL style abstraction level!), so eventually I have had to make my peace with Python, TypeScript, and Rust. |
| |
| ▲ | Terr_ 5 hours ago | parent [-] | | Tacking on, part of seeing it to fruition, and continued lifetime, is to ensure you can communicate the intent and operation to a large group of potential successors and co-workers. An incredible epiphany that you can't transmit may not be as useful as a a moderately clever idea you can. | | |
| ▲ | logicprog 5 hours ago | parent [-] | | Yeah that's another good point. I always hope anything I make can be improved or understood by others. Now, does that happen? No. But it'd be nice |
|
|
|
| ▲ | AlotOfReading 9 hours ago | parent | prev | next [-] |
| The reality of modern software development is that most people focus on languages they use for work, and developers are statistically likely to be employed at companies with large numbers of other developers. The technical merits of languages just aren't relevant to choosing them for most developers, unless they're helping solve a people problem. "Artisanal" languages like Lisp, and Forth can be fantastic at solving problems elegantly, but that's not the most important thing to optimize for in big organizations where a large portion of your time is spent reading code written by people you've never met who may not have known what they were doing. Many of the tools that come from big tech are designed to ease the challenges of organizational scale. Golang enforces uniform styles so that you don't have idiosyncratic teams doing their own things. Bazel is a largely language agnostic build system, with amazing build farm support. Apple and Google have both contributed heavily to sanitizers and standard library hardening in order to detect/eliminate issues without reading the code. Facebook has poured vast resources into automatic static analysis. AWS built an entire organization around treating all their internal interfaces the same as external ones. |
| |
| ▲ | ModernMech 8 hours ago | parent [-] | | > "Artisanal" languages like Lisp, and Forth can be fantastic at solving problems elegantly, but that's not the most important thing to optimize for in big organizations ... Many of the tools that come from big tech are designed to ease the challenges of organizational scale. I think the field of programming languages has grown enough that we have to start acknowledging the future of programming largely won't be in the context of what it means for devs working at large corporations. One of my favorite talks is from Amy J. Ko called A Human View of Programming [1], which argues there are many other ways to look at programming than "tool for generating business activity" and "mathematical construct", which heretofore have been the dominant views of programming languages. Because there are so many other forms and purposes programming languages can and will take (she goes through them in the talk), so evaluating them and creating them solely on how well they are able to fit into a corporate R&D pipeline is a very narrow and short-term view of the field. Indeed, it's been the case for a long time now that most people who write programs are not in fact professional software developers. The most used language in the world is Excel, by several orders of magnitude, and it's the opposite of everything devs say a "proper" language must be. There's something we as a field still need to learn from that. [1]: https://www.youtube.com/watch?v=TjkzAls5fsI | | |
| ▲ | saltcured 4 hours ago | parent | next [-] | | I have very mixed feelings on this topic, starting with how you quantify and weigh something like "most used" for a programming language. To me, the claim feels almost as much a non sequitur as saying the most used building material in the western world is Legos blocks or Play-Doh... Is the most used bridge-building technique a plank over a small culvert, or the properly engineered bridge that carries constant, multi-lane highway traffic for a century? How do we weigh the usage of resulting products into the usage of a design and production method? Should we consider the number of program users? The users X hours of usage? Fundamentally, the software field is still just so young and we haven't teased apart the "obvious" different domains and domain rules that we have for production of different material goods. In some sense, the domains and domain rules for material goods emerge out of the connection to culture, economic roles, health, and safety aspects. Whether it falls into civil engineering, building codes, transporation rules, consumer product safety, food and drug, ... The self-similar way that software can be composed into systems also makes it confusing to categorize. Imagine if we talked about other crafts the same way, and conflated textile manufacturing, clothing design, tailoring, costume making, wardrobe management, scripting, choreography, acting, and dancing as a single field that coordinates the visual movement of fabric on a stage. | |
| ▲ | AlotOfReading 8 hours ago | parent | prev [-] | | As a member of the handmade community, I certainly hope that corporate constraints aren't the main future of the field. I just think it's a major part of the answer as it stands today. |
|
|
|
| ▲ | nine_k 9 hours ago | parent | prev | next [-] |
| Clojure is built on dynamic typing. This is pain. I wrote enough Python (pre-mypy), Javascript, and elisp to say this. Past certain size a dynamically typed codebase becomes needlessly hard to wrangle because of that. Hence the success of Python type annotations and Typescript. Instead, the world should have seen the light of Hindley-Milner type systems, ML-inspired languages, immutability, or at least not sharing mutable state. Did Haskell fail? Hmm, let's look at Typescript and Rust. Don't get me wrong, a Lisp is always a great and fun language, and you can write whatever DSL you might like on top of it. But the old joke that "a Lisp programmer knows the value of everything, and the cost of nothing" still has quite a bit of truth to it. |
| |
| ▲ | slifin 4 hours ago | parent | next [-] | | Plenty of ways to define complex data shapes in Clojure Spec is definitely underrated here considering it's built into the language and has a wider scope but for most people they want the intellisense experience which you can get with clj-kondo + mailli but is not built in so most teams don't use it, fair enough I'd like to move the goal posts though and say I want flowstorm in every (any other?!) language I can just run the program and scrub backwards and forwards through the execution and look at all the immutable values frame by frame with a high level UI with plenty of search/autocomplete options For program understanding there's nothing better The fact I can program against the timeline of values of my program and create custom UI on top is crazy One of the most mind blowing demos to me was Bret Victor's inventing on principle and having a programmable reverse debugger for your language makes those demos viable I built an emulator recently for work that replays what happens on live locally, combined with flowstorm I can go line by line and tell you exactly what happened and why, no print statements no reruns with my own custom UI customised to our apps interesting parts This is my appeal to anyone outside of Clojure please build flowstorm for JavaScript and or Python The design of flowstorm is definitely helped by the fact that 95% of Clojure programs are immutable but I don't think it's impossible to replicate just very difficult | | |
| ▲ | nine_k 15 minutes ago | parent [-] | | This indeed is one of the superpowers. I hope Elixir will eventually acquire it. |
| |
| ▲ | andersmurphy 7 hours ago | parent | prev | next [-] | | The big difference is Clojure is immutable by default. | |
| ▲ | wrs 7 hours ago | parent | prev [-] | | On the other hand, it would be easier to add type checking to a Lisp than it was to Python or JavaScript, and I don’t know any technical reason you couldn’t. A little Googling shows it’s been experimented with several times. | | |
| ▲ | nine_k 6 hours ago | parent | next [-] | | Well, Typed Clojure is a thing! But the real strength of Lisp is in the macros, the metaprogramming system. And I suspect that typing most macros properly would be a bit less trivial than even typing of complex generic types, like lenses. Not typing a macro, and only typechecking the macroexpansion would formally work, but, usability-wise, could be on par with C++ template error reporting. | | |
| ▲ | wrs 6 hours ago | parent [-] | | My point was that you could implement type checking with macros, not that you could type check macros. (Though that would be cool!) As opposed to having to change the language definition first (Python) or implement an entirely new compiler (TypeScript). | | |
| ▲ | nine_k 5 hours ago | parent [-] | | Certainly you can implement the typechecker with macros, but it should also work on macros, before expansion. That is, you likely want (-> ...) typechecked as written, not (only) as expanded, and typing errors reported on the non-expanded form. | | |
|
| |
| ▲ | teaearlgraycold 7 hours ago | parent | prev [-] | | That means little to a programmer unless they really want to spend thousands of hours building a type checker before starting a project. | | |
| ▲ | wrs 6 hours ago | parent [-] | | Talk about moving the goalposts! Did you implement TypeScript yourself before using it? | | |
|
|
|
|
| ▲ | zarzavat 3 hours ago | parent | prev | next [-] |
| There are several languages that I could use and be economically successful with, but I refuse to use because I consider them to be poorly designed. Using a bad language for 8 hours a day makes me irritable and it's impossible to prevent that irritability from overflowing into my interactions with other people. I'd rather that my conversations with the computer be joyful ones. |
|
| ▲ | mlinhares 2 hours ago | parent | prev | next [-] |
| Most of the time when someone adds these fancy languages what happens is that they leave and the ones left are the ones that have to deal with the shit that was produced. I'm going through this now, having to deal with code nobody wants to touch because it is overly complex, has no documentation, and is in a language no one else knows. Now, whenever i see an effort like this, to bring an exoteric language for absolutely no good reason, i try to kill it as fast as possible. I don't want to be the victim of this code in the future or have my team bear the cost of maintaining stuff they don't understand. |
|
| ▲ | miohtama 7 hours ago | parent | prev | next [-] |
| I have several decades of programming experience and would never choose Lisp, unless for funny one pagers. Programming language ergonomics matter and there is a reason why Lisp has so little adoption even after a half a century. |
|
| ▲ | attila-lendvai 3 hours ago | parent | prev | next [-] |
| yes. and as a long time lisper, i don't think that it's the macros. i think lisp's magic is a lot more cultural than most people think. i.e. how lispnicks implement lisps and the ecosystem around it. how easy it is to walk the entire ladder of abstractions from machine code to project specific DSL's. how pluggable its parsing pipeline is -- something that is not even exposed in most languages, let alone customizable. the language, the foundation, of course matters. but i think to a lesser extent than what people think. (hence the trend of trying to hire lispnicks to hard, but non-lisp positions?) and it's not even an obviously good culture... (just how abrasive common lispers are? need to have a thick skin if you ask a stupid question... or that grumpy, pervasive spirit of the lone wolf...?) maybe it's just a peculiar filter that gets together peculiar people who think and write code in peculiar ways. maybe it's not the macros, but the patterns in personality traits of the people who end up at lisp? |
|
| ▲ | wrs 9 hours ago | parent | prev | next [-] |
| While what you say is true (I’ve used Lisps for 40 years and here I am writing Rust), the people who consciously make that choice are a tiny niche. There are vastly more people who don’t and can’t make that choice because they don’t have 1-3. So the empirical evidence for what’s actually critical is pretty slim. |
|
| ▲ | zahlman 2 hours ago | parent | prev | next [-] |
| Reading SICP (and other such mind expansion) has definitely (gradually over a very long period) shaped how I write Python. |
|
| ▲ | somewhereoutth 35 minutes ago | parent | prev | next [-] |
| C for systems programming, javascript for everything else! |
|
| ▲ | anthk 3 hours ago | parent | prev | next [-] |
| Me with TCL instead of Python. TCL is the weird Unixy cousing. Instead of cons cells and lists, you get lists and strings. |
|
| ▲ | ModernMech 9 hours ago | parent | prev [-] |
| > The article could really benefit from some steel-manning. Remove the cute Flatland metaphor and it is effectively arguing that lisp/clojure haven’t been universally adopted because most programmers haven’t Seen The Light in some sort of epiphany of parentheses and macros. The truth is more nuanced. The talk I posted from Alan Kay is the steel man. I think you've missed the essence of TFA because it's not really about Clojure or lisp. |
| |
| ▲ | libraryofbabel 8 hours ago | parent [-] | | You may need to explain more? I don’t think I missed the big idea - the metaphor of a separate plane or higher dimension that contains ideas not expressible in the ordinary one is a nice metaphor, and does apply well to some things (Kuhn’s paradigms in history of science come to mind, e.g. Newtonian Mechanics versus Relativity). I just don’t think it really applies well here. What business concepts or thoughts can you express in Clojure that you can’t express in Python or Rust? | | |
| ▲ | xigoi 7 hours ago | parent | next [-] | | > What business concepts or thoughts can you express in Clojure that you can’t express in Python or Rust? If you only think about programming languages as a way to make money, the analogy of being stuck in Flatland is perfect. | | |
| ▲ | libraryofbabel 5 hours ago | parent | next [-] | | That's a bit of an ad feminam attack, isn't it? Just because I used the phrase "business concepts", somehow money is the only thing I care about when it comes to language choice? And yet, in my top-level post I said I went and learned lisp and clojure and read SCIP, and I will add that I did both of those things for fun. So no, I don't only think of programming languages as a way to make money. Elegance and expressiveness are interesting for their own sake. I trained as a mathematician; of course I think that. But TFA was riffing on Paul Graham's old essay Beating the Averages, which argued precisely that the expressiveness of Lisp gave his startup a business edge. That was the context of my comment. I'd add that most of what most of us do in our day jobs is to use programming languages to make money, and there's no shame in that at all. And if you want to talk about why certain languages get widespread adoption and others not, you have to talk about the corporate context: there is no way around it. But I'll rephrase my question, just for you: "what abstract problems can you solve or thoughts can you express in Clojure that you can’t express in Python or Rust?" | |
| ▲ | dap 5 hours ago | parent | prev | next [-] | | I’m sympathetic to looking down on the obsession with money. But there’s something deep and important about the monetary element. Engineering is about solving real-world, practical problems. The cost is a real factor in whether a potential solution is a useful one. I think the money question is a red herring here. I’d phrase it more like: what problem in a user’s problem space is expressible only like this? And if the only user is the programmer, that’s alright, but feels more aligned with pure academia. That’s important, too! But has a much smaller audience than engineering at large. | |
| ▲ | scragz 7 hours ago | parent | prev [-] | | some people only think about life as a way to make money. unfortunately coding was best-in-slot career for too long and these kinds of people hijacked the culture. |
| |
| ▲ | Chinjut 3 hours ago | parent | prev [-] | | Why are we limiting ourselves to business concepts? |
|
|