4 ms·

The problem with malleability of programming languages, is there is no upper limitation of how malleable it can be. I experienced this in both Clojure and Ruby

The problem with malleability of programming languages, is there is no upper limitation of how malleable it can be. I experienced this in both Clojure and Ruby as well. The fact that developers can spend countless of precious time, cycling through a loop of malleability, reforming an already functional product in production. It costs precious time and money, it is expensive. And more importantly, it is non-stop. Other programming languages like Go are very conservative with feature changes, and imposes hard limitations by choice, the team/company behind it thinks the same way, that a cycle of O(n) is destructive. And nowadays, you can't expect a developer to stay on a company for so long, so a sureball tooling to hit it hard, and precise, with less time and tinkering around is much needed than ever. On the future of programming languages, we will see languages being used not because it is malleable, but because it is sure, precise and right for the job.

unityByFreedom 6y ago
I tried Go and didn't like its opinionated nature. As a beginner, I disliked, - I have to use every variable I declare, otherwise it won't compile (b/c golang authors decided this produces better code) - Official docs confusingly suggest I structure imported files with the root as github.com/ (b/c golang assumes all code will be open sourced) - I can only import one file per folder - There is no built in map or reduce function. You're expected to use for loops everywhere because it is more explicit Once I discovered the last point I noped out.
- jjuliano 6y ago
  > - I have to use every variable I declare, otherwise it won't compile (b/c golang authors decided this produces better code) > - There is no built in map or reduce function. You're expected to use for loops everywhere because it is more explicit Go is an imperative language, where no implicit magic happens on the background, like auto creation of resources on runtime, every sequence needs to be manually defined by the programmer. "With imperative code, you’re telling your program how to do something. And with declarative code, you’re telling your program what you want to do. - Tyler Mcginnis, React Fundamentals", depends on the programmer, but I like to be in control.
  - unityByFreedom 6y ago
    Yeah I get that. I prefer declarative code. I really enjoy constraint programming, for example, which is anything but imperative. I had no idea there were folks who preferred imperative languages until I discovered the Go community. I always figured people choose imperative languages for lack of familiarity with more declarative ones.
wilsonthewhale 6y ago
Surprising that you mention this with Clojure. Do you find the churn to be from libraries or within the project code itself? The Clojure language and core library is extremely stable, almost uncannily so. I can't think of any major upheavals it's had for a long time. Transducers from 1.7 maybe? But those fit in with the rest of the core library and didn't cause any issues.
- jjuliano 6y ago
  The problem is not the language being stable or mature. I'm sure Ruby has been around since 1995, Lisp existed even before my parents. With Lisp, you can create a "Hello World" program in variety of multiple ways. Sure you can refactor it, starting with how to print the letter "H", throw UTF-16 support there as well. At the end of the day, you wasted precious time and resources printing "Hello World". Doing things in variety does not mean value. Doing it right the first time means value, now imagine if it's a team.
  - gnufx 6y ago
    I don't recognise the picture of Lisp programming qua Lisp. "Refactor" probably wasn't even a word you'd hear for most of Lisp's existence. The Common Lisp standard definition is clearly not churning. I used to have a mail signature when Python was relatively new There should be only one way to do it. -- Python There's more than one way to do it. -- Perl Do the right thing. -- Lisp

unityByFreedom 6y ago

I tried Go and didn't like its opinionated nature. As a beginner, I disliked, - I have to use every variable I declare, otherwise it won't compile (b/c golang authors decided this produces better code) - Official docs confusingly suggest I structure imported files with the root as github.com/ (b/c golang assumes all code will be open sourced) - I can only import one file per folder - There is no built in map or reduce function. You're expected to use for loops everywhere because it is more explicit Once I discovered the last point I noped out.

jjuliano 6y ago
> - I have to use every variable I declare, otherwise it won't compile (b/c golang authors decided this produces better code) > - There is no built in map or reduce function. You're expected to use for loops everywhere because it is more explicit Go is an imperative language, where no implicit magic happens on the background, like auto creation of resources on runtime, every sequence needs to be manually defined by the programmer. "With imperative code, you’re telling your program how to do something. And with declarative code, you’re telling your program what you want to do. - Tyler Mcginnis, React Fundamentals", depends on the programmer, but I like to be in control.
- unityByFreedom 6y ago
  Yeah I get that. I prefer declarative code. I really enjoy constraint programming, for example, which is anything but imperative. I had no idea there were folks who preferred imperative languages until I discovered the Go community. I always figured people choose imperative languages for lack of familiarity with more declarative ones.

wilsonthewhale 6y ago

Surprising that you mention this with Clojure. Do you find the churn to be from libraries or within the project code itself? The Clojure language and core library is extremely stable, almost uncannily so. I can't think of any major upheavals it's had for a long time. Transducers from 1.7 maybe? But those fit in with the rest of the core library and didn't cause any issues.

jjuliano 6y ago
The problem is not the language being stable or mature. I'm sure Ruby has been around since 1995, Lisp existed even before my parents. With Lisp, you can create a "Hello World" program in variety of multiple ways. Sure you can refactor it, starting with how to print the letter "H", throw UTF-16 support there as well. At the end of the day, you wasted precious time and resources printing "Hello World". Doing things in variety does not mean value. Doing it right the first time means value, now imagine if it's a team.
- gnufx 6y ago
  I don't recognise the picture of Lisp programming qua Lisp. "Refactor" probably wasn't even a word you'd hear for most of Lisp's existence. The Common Lisp standard definition is clearly not churning. I used to have a mail signature when Python was relatively new There should be only one way to do it. -- Python There's more than one way to do it. -- Perl Do the right thing. -- Lisp