7 ms·

Interesting story. I am not entirely convinced that all credit should go to the programming language here, though. My theory is that communicating abstraction

by smokel 2y ago

Interesting story. I am not entirely convinced that all credit should go to the programming language here, though. My theory is that communicating abstractions is hard. If you work on your own, or in a (very) small team, you can come up with powerful abstractions that allow you to build amazing systems, quickly. However, sharing the underlying ideas and philosophy with new team members can be daunting. As systems grow, and mistakes are made, it becomes more and more likely that you run into serious problems. This may also be why Java and similar object oriented programming languages are so successful for systems that have to be maintained for ages, by large teams of developers. There are but few abstractions and patterns, and it does not allow you to shoot yourself in the foot, nor to blow your whole leg off. Conversely, this may also be why complex frameworks, such as Spring, are not always so nice, because they introduce (too?) powerful abstractions, for example through annotations. It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam. Another theory is that not every developer is comfortable with abstract concepts, and that it simply takes a team of smart people to handle those.

j45 2y ago
Clojure has some interesting advantages - which doesn't mean others might not. Rapid application technologies, methedologies, or frameworks are not unusual. I know some wonderfully productive polyglot developers who by their own choice end up at Clojure. It doesn't have to be for everyone. I wouldn't rule out that Clojure doesn't deserve credit. I wouldn't think it's a good idea to discredit Clojure from not having tried it myself. I do hope someone with extensive Clojure experience can weigh in on the advantages. How easy something is a codebase grows is something to really consider. This product regardless of how it's built is pretty impressive. I'd be open to learning advantages and comparisons without denying it.
- pntripathi9417 2y ago
  This has actually been my experience. When I started with Clojure I was writing it badly. I came from NodeJS world. It even took me a week's time just to setup the working environment. With time you get to understand the power of simplicity. How to break the problem and compose the solutions to achieve your intended result.. That's where the power of Clojure came in for us.
skydhash 2y ago
Another theory is that C inspired languages are very mechanistic and easier to visualize. Same goes for OOP with the Animal->{Cat,Dog} explanation. But that's just surface level and once you get to the difficult part (memory management in C and software design in Java) where the ability to grasp abstractions is required, we're back to square one. I believe once you've got to some point, dealing with abstractions is a way of life. It's either in the language, the technical requirements, or the software design.
- bcrosby95 2y ago
  "Objects are the way we think" is one of the largest design traps ever laid in software development. Because if you design your program like it, unless in certain special circumstances, it will be shit.
  - mstipetic 2y ago
    I don’t think I’m terms of objects at all, I think it terms of how the data flows. That’s why I like Elixir so much
  - skydhash 2y ago
    There's the way we think about the problem and it's solution and there's the way that the machine can execute these solutions. More often there's no direct mapping other than a tower of abstractions. The issue is that the problem and our model are too fluid and it's best not to rely that much on a certain paradigm.
bsder 2y ago
> It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam. Languages need a window of opportunity, and many of those squandered it. Clojure won over Scala because at the time when people were loooking for an alternative JVM langauge, Clojure was more of a departure from Java and seemed to have better tooling (compile times and syntax support) than Scala. Smalltalk and Common Lisp wasted their moment by not being cheap/free to people using micros in the 1980s. Lisp, especially, very much wasted its moment with micros. The fact that no Lisper had the vision to dump a Lisp onto the bank switched micros (which makes GC really easy and useful) of the mid to late 1980s is a self-inflicted bullet wound. Lots of us hated doing assembly language programming but had no real alternative. This was a loss born of pure arrogance of Lispers who looked down on those micros as not being "real machines". I weep for all the hours I wasted doing assembly language as a teenager that I could have been writing Lisp. How much software could have been written that would have been <100 lines of Lisp if only someone had written that tool?
- lispm 2y ago
  > Lots of us hated doing assembly language programming but had no real alternative. I kind of fail to see Lisp as an alternative to assembler on mid 80s micros. Though, there were several cheap Lisps for PCs...
  - bsder 2y ago
    The bank switched memory architectures were basically unused in mid 80s micros (C128, CoCo3, etc.). Lots of utility software like spell checkers and the like still existed. These would be trivial to implement in Lisp but are really annoying in assembler. Lisp would have been really good relative to BASIC interpreters at the time--especially since you could have tokenized the atoms. It also would have freed people from line numbers. Linked lists work well on these kinds of machines. 64K is solid for a Lisp if you own the whole machine. You can run over a bank of 16K of memory for GC in about 50 milliseconds or so on those architectures. Had one of the Lisperati evangelized Lisp on micros, the world would look very different. Alas, they were off charging a gazillion bucks to government contracts. However, to be fair, only Hejlsberg had the correct insights from putting Pascal on the Nascom.
nradov 2y ago
Powerful abstractions tend to come back and bite you a few years later when the industry trends shift and everyone else starts using a different set of abstractions. Now that small team is stuck maintaining those custom abstractions forever and is unable to take advantage of new abstractions from vendors or open source projects. So their progress stagnates while competitors race ahead. I've been on the wrong side of that before.
iLemming 2y ago
> object oriented programming languages are so successful for systems that have to be maintained for ages, ehmmm.... excuse me.... erghmm... what about Emacs? I'm sure, it absolutely can be count for a "successful system that have to be maintained for ages". For far, far longer than any Java-based project that ever existed. Even though Elisp lacks: - static typing - OOP class system (until relatively recently) - Modern package management (until ELPA/MELPA) - Multi-threading model - JIT compilation Perhaps "the secret sauce" of successful software is in simplicity? Maybe some programmers just get it, and for others, it is such an obscure and mysterious entity. Some programmers write "programs to program computers", and some may have realized that they are not trying to solve purely technological problems, but they are, in fact, tackling socio-technological problems, and they write programs to communicate their ideas to fellow human beings, not machines.
- brabel 2y ago
  It's embarassing to have to even say this , but a counterexample, or even a few, does not invalidate the argument. You would need some sort of representative sample of successful projects, and then figure out which paradigm was used for each one and see if there's any statistically significant pattern. Good luck doing that reliably though.
  - iLemming 2y ago
    While focusing on the first part of my comment it seems you completely ignored the [main] point in the last paragraph. All programming languages are man-made, human constructs and not a single one is the most ideal for the task of programming - just like not a single spoken language can claim absolute superiority for communication. The nature of programming often eludes clear categorization, challenging us to define whether it belongs to the domains of art, business, or engineering. Maybe it's all of these? Maybe it's none of it? We, programmers endlessly engage in passionate debates about language superiority, constructing complex arguments to defend our preferences. I'm not a musician, but can you imagine guitar players vehemently arguing with drummers that guitars are ultimately better instruments because, I dunno, one never can perform Für Elise using drums. And then some experienced drummer comes and performs it in way no one ever imagined. I think, the beauty of programming, like music, lies in its diversity. Instead of engaging in futile debates about superiority, we should celebrate how different languages and paradigms enrich our craft, each bringing its own unique perspective and elegance to the art of problem-solving. One of the things I feel grateful for after learning Clojure is that many, perhaps most people in the community are genuinely experienced, seasoned software developers, driven to Clojure by curiosity after many years spent in other programming languages. Clojure allowed me to fall in love with my trade once again. The combined malleability of Lisp that can emulate (almost) any known programming paradigm and the simplicity and data-centric design in Clojure helped me (truly) understand the core principles of programming. Ironically, after using numerous different languages for many years, spending years of grokking their syntactic features and idiosyncrasies, many stackoverflow threads and tutorials later, only after switching to Clojure did I feel like I understood those languages better. One peculiar aspect about Clojurians, that they don't typically engage in general debates about programming languages without specific context, subtly breaking the famous Perlis quote about Lispers knowing the value of everything and cost of nothing. Clojurians known for their grounded perspective and non-dogmatic approach to problem-solving. So, they typically don't bash on someone else's favorite language, instead they'd try to learn and steal some good ideas from it.
pntripathi9417 2y ago
I agree. There's was one more section I planned to write about the community members. I decided to write as a separate post itself. In the end it's about designing abstraction, and community's focus on designing simple abstractions drove me in designing the whole system. Now once I have the working system, I am fairly sure it can be implemented in any language.

by smokel 2y ago

j45 2y ago

Clojure has some interesting advantages - which doesn't mean others might not. Rapid application technologies, methedologies, or frameworks are not unusual. I know some wonderfully productive polyglot developers who by their own choice end up at Clojure. It doesn't have to be for everyone. I wouldn't rule out that Clojure doesn't deserve credit. I wouldn't think it's a good idea to discredit Clojure from not having tried it myself. I do hope someone with extensive Clojure experience can weigh in on the advantages. How easy something is a codebase grows is something to really consider. This product regardless of how it's built is pretty impressive. I'd be open to learning advantages and comparisons without denying it.

pntripathi9417 2y ago
This has actually been my experience. When I started with Clojure I was writing it badly. I came from NodeJS world. It even took me a week's time just to setup the working environment. With time you get to understand the power of simplicity. How to break the problem and compose the solutions to achieve your intended result.. That's where the power of Clojure came in for us.

skydhash 2y ago

Another theory is that C inspired languages are very mechanistic and easier to visualize. Same goes for OOP with the Animal->{Cat,Dog} explanation. But that's just surface level and once you get to the difficult part (memory management in C and software design in Java) where the ability to grasp abstractions is required, we're back to square one. I believe once you've got to some point, dealing with abstractions is a way of life. It's either in the language, the technical requirements, or the software design.

bcrosby95 2y ago
"Objects are the way we think" is one of the largest design traps ever laid in software development. Because if you design your program like it, unless in certain special circumstances, it will be shit.
- mstipetic 2y ago
  I don’t think I’m terms of objects at all, I think it terms of how the data flows. That’s why I like Elixir so much
- skydhash 2y ago
  There's the way we think about the problem and it's solution and there's the way that the machine can execute these solutions. More often there's no direct mapping other than a tower of abstractions. The issue is that the problem and our model are too fluid and it's best not to rely that much on a certain paradigm.

bsder 2y ago

> It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam. Languages need a window of opportunity, and many of those squandered it. Clojure won over Scala because at the time when people were loooking for an alternative JVM langauge, Clojure was more of a departure from Java and seemed to have better tooling (compile times and syntax support) than Scala. Smalltalk and Common Lisp wasted their moment by not being cheap/free to people using micros in the 1980s. Lisp, especially, very much wasted its moment with micros. The fact that no Lisper had the vision to dump a Lisp onto the bank switched micros (which makes GC really easy and useful) of the mid to late 1980s is a self-inflicted bullet wound. Lots of us hated doing assembly language programming but had no real alternative. This was a loss born of pure arrogance of Lispers who looked down on those micros as not being "real machines". I weep for all the hours I wasted doing assembly language as a teenager that I could have been writing Lisp. How much software could have been written that would have been <100 lines of Lisp if only someone had written that tool?

lispm 2y ago
> Lots of us hated doing assembly language programming but had no real alternative. I kind of fail to see Lisp as an alternative to assembler on mid 80s micros. Though, there were several cheap Lisps for PCs...
- bsder 2y ago
  The bank switched memory architectures were basically unused in mid 80s micros (C128, CoCo3, etc.). Lots of utility software like spell checkers and the like still existed. These would be trivial to implement in Lisp but are really annoying in assembler. Lisp would have been really good relative to BASIC interpreters at the time--especially since you could have tokenized the atoms. It also would have freed people from line numbers. Linked lists work well on these kinds of machines. 64K is solid for a Lisp if you own the whole machine. You can run over a bank of 16K of memory for GC in about 50 milliseconds or so on those architectures. Had one of the Lisperati evangelized Lisp on micros, the world would look very different. Alas, they were off charging a gazillion bucks to government contracts. However, to be fair, only Hejlsberg had the correct insights from putting Pascal on the Nascom.

nradov 2y ago

Powerful abstractions tend to come back and bite you a few years later when the industry trends shift and everyone else starts using a different set of abstractions. Now that small team is stuck maintaining those custom abstractions forever and is unable to take advantage of new abstractions from vendors or open source projects. So their progress stagnates while competitors race ahead. I've been on the wrong side of that before.

iLemming 2y ago

> object oriented programming languages are so successful for systems that have to be maintained for ages, ehmmm.... excuse me.... erghmm... what about Emacs? I'm sure, it absolutely can be count for a "successful system that have to be maintained for ages". For far, far longer than any Java-based project that ever existed. Even though Elisp lacks: - static typing - OOP class system (until relatively recently) - Modern package management (until ELPA/MELPA) - Multi-threading model - JIT compilation Perhaps "the secret sauce" of successful software is in simplicity? Maybe some programmers just get it, and for others, it is such an obscure and mysterious entity. Some programmers write "programs to program computers", and some may have realized that they are not trying to solve purely technological problems, but they are, in fact, tackling socio-technological problems, and they write programs to communicate their ideas to fellow human beings, not machines.

brabel 2y ago
It's embarassing to have to even say this , but a counterexample, or even a few, does not invalidate the argument. You would need some sort of representative sample of successful projects, and then figure out which paradigm was used for each one and see if there's any statistically significant pattern. Good luck doing that reliably though.
- iLemming 2y ago
  While focusing on the first part of my comment it seems you completely ignored the [main] point in the last paragraph. All programming languages are man-made, human constructs and not a single one is the most ideal for the task of programming - just like not a single spoken language can claim absolute superiority for communication. The nature of programming often eludes clear categorization, challenging us to define whether it belongs to the domains of art, business, or engineering. Maybe it's all of these? Maybe it's none of it? We, programmers endlessly engage in passionate debates about language superiority, constructing complex arguments to defend our preferences. I'm not a musician, but can you imagine guitar players vehemently arguing with drummers that guitars are ultimately better instruments because, I dunno, one never can perform Für Elise using drums. And then some experienced drummer comes and performs it in way no one ever imagined. I think, the beauty of programming, like music, lies in its diversity. Instead of engaging in futile debates about superiority, we should celebrate how different languages and paradigms enrich our craft, each bringing its own unique perspective and elegance to the art of problem-solving. One of the things I feel grateful for after learning Clojure is that many, perhaps most people in the community are genuinely experienced, seasoned software developers, driven to Clojure by curiosity after many years spent in other programming languages. Clojure allowed me to fall in love with my trade once again. The combined malleability of Lisp that can emulate (almost) any known programming paradigm and the simplicity and data-centric design in Clojure helped me (truly) understand the core principles of programming. Ironically, after using numerous different languages for many years, spending years of grokking their syntactic features and idiosyncrasies, many stackoverflow threads and tutorials later, only after switching to Clojure did I feel like I understood those languages better. One peculiar aspect about Clojurians, that they don't typically engage in general debates about programming languages without specific context, subtly breaking the famous Perlis quote about Lispers knowing the value of everything and cost of nothing. Clojurians known for their grounded perspective and non-dogmatic approach to problem-solving. So, they typically don't bash on someone else's favorite language, instead they'd try to learn and steal some good ideas from it.

pntripathi9417 2y ago

I agree. There's was one more section I planned to write about the community members. I decided to write as a separate post itself. In the end it's about designing abstraction, and community's focus on designing simple abstractions drove me in designing the whole system. Now once I have the working system, I am fairly sure it can be implemented in any language.