@sqrtminusone What I mean specifically is that you look at your 100 lines of mostly imperative Go code and think, how can I make that better and more expressive?
Just to realize that in Go there is rarely such an opportunity, compared to many other languages, that allow you to learn more advanced functional concepts and abstraction patterns over time.
It took the Go devs 14 years to release a generic min/max function and slice/maps utility functions like Contains. I probably wrote thousands of rudimentary, ugly for loops because those did not exist.
@a13cui There is a middle ground, and in my opinion that is the #V language. It has a version of Go-like syntax that is as easy to comprehend but has all the "missing" features you would miss in Go.
@a13cui Actually a few months ago, when the Go telemetry shitshow happend, Nim was my choice #1 as a replacement. However, the library ecosystem is dire for serious web backend and database development. That was the reason I abondoned it.
That was, of course, before I decided to shred my head with Common Lisp 🙂
@louis@galdor@a13cui To be honest, I'm skeptical about defining "superiority" on the set of isomorphic representations of reasonable code.
Of course, there's the space of bad code, e.g. long hard-to-understand poorly-documented (take any) functions, spaghetti code, WET, unreadable constructs such as nested ternaries, etc., etc... And better programmers sample that space less, but it's substantial, even in more minimal languages.
I.e. I doubt you can write "better" code, you can write the code that is less bad perhaps.
Conversely, I'm in love with #elisp, so I know I can write the same iteration construct with mapcar & co, cl-loop, threading macros, seq-, dash functions, dolist, cl-do, cl-reduce & the rest of cl-, hmm, what else... And I don't feel like I've grown much because of that 🙂
By the way, it's kinda the same with the aforementioned darkness.js, with its countless _.chain(libraries) besides the built-in loop expressions, .map / .reduce / whatever, .forEach... A Scheme with C syntax indeed.
And next to the above, there's the space of memory/compute inefficient code... From my work with students, I often find it harder to explain that this code is O(n!) while it should be O(n^2).
Besides, there are principles of single responsibility, separation of concerns, which are mostly language-independent. And architectural decisions.
...maybe I'll change something in this stream of consciousness if I manage to work in the field for the next 20 years 🤷
Add comment