4 ms·

This is a great perspective. I am not focus-challenged... at least I don't think I am, but your comment has been a revelation. I always had this nagging feeling

by distcs 3y ago

This is a great perspective. I am not focus-challenged... at least I don't think I am, but your comment has been a revelation. I always had this nagging feeling about myself that I don't find myself fully immersed in the problem domain when working Go, Python, Rust like the way I feel while working with Lisp. When I am programming in Lisp, I enter a sort of zen like state where my mind becomes one with the problem. Now don't get me wrong. I can write a lot of Go, Python, Rust, what have you on some days when I am working on a good problem and there are no meetings to distract me. On some days, I can do this for 6-10 hours straight with little breaks. So I don't think I have the ADHD problem that the parent or the OP is talking about. But I still have this nagging feeling with other mainstream languages that their tooling, their ecosystem, the breaking dependencies, the "making the compiler happy", the stupid language restrictions and such things distract me from my problem domain. But not so with Lisp. With Lisp, it's just me, the problem, the algorithms to solve it and the code. Nothing else. It is a feeling of hyperfocus (a word you so rightly chose). For some reason I cannot get into that state with other languages and I could never understand why. Your comment is on to something here and this might very well explain the zen-like hyperfocus feeling of immersing fully into the problem domain I get with Lisp.

sph 3y ago
Sure, the ADHD thing might be a bit on the nose, but the thing is... you've just become really good at being productive with languages that constantly interrupt you for inane reasons. You're productive DESPITE the terrible tooling we have to deal with everyday. Sometimes it's nice to shed all that bullshit and just create something. Sometimes, only on languages with the least amount of syntax and semantics you're able to sculpt that fleeting idea you had. Inspiration is very delicate, and it doesn't take a lot for it to die down because you forgot to update npm and your Emacs config is borked.
whartung 3y ago
> But I still have this nagging feeling with other mainstream languages that their tooling, their ecosystem, the breaking dependencies, the "making the compiler happy", the stupid language restrictions and such things distract me from my problem domain. I can relate to this in a different way. It seems the vast majority of work today is not "the problem", per se, it's the interface that exposes the problem (or solution) to others. Shoving stuff in and out of format (JSON, SQL, etc.), marshaling the data over interfaces, or building UIs to expose and work with it, etc. The problem domains themselves, for a lot of systems, can be pretty simple. But with CL, with the reader, and things like Emacs, a lot of that falls into the background -- with the caveat "as long as you're willing to work with native representations", i.e. S-expressions. I have an "application" in CL, and it's 1500 lines of code. Outside of a couple prints for debug, there is no I/O. No user interface. Nothing. It's all "just code". It's all "just problem". Meanwhile, I have a Java program I wrote. It wraps a 1000 line Java utility into a GUI. There's 4000 lines of code to present that GUI. It's a not quite fair comparison, as the entire purpose of the application is to expose this utility into a "usable form". But, with Java and other languages, there's always going to be some level of that. With CL, again if it fits within the confines of the REPL and S-expressions, you get all of that "for free". Trivial case with a simple Java command is you need some way to parse the command line options. Extended lambda lists give you that "for free" in CL. Named parameters, optional parameters, default values, etc. Arguably the entire point of the extended lambda list descends from their use within environments like Lisp Machines, where the function arguments WERE the "command line", and that's why its so robust. Those are all nice features when writing code, but they're really nice when you have to type stuff in all the time. And this ability to not worry so much about external representation, and moving and converting data, instead just focusing on what's being done to the data, in native terms, it's very liberating. There is no "impedance mismatch". Just code, just data, and code is data.

by distcs 3y ago

sph 3y ago

Sure, the ADHD thing might be a bit on the nose, but the thing is... you've just become really good at being productive with languages that constantly interrupt you for inane reasons. You're productive DESPITE the terrible tooling we have to deal with everyday. Sometimes it's nice to shed all that bullshit and just create something. Sometimes, only on languages with the least amount of syntax and semantics you're able to sculpt that fleeting idea you had. Inspiration is very delicate, and it doesn't take a lot for it to die down because you forgot to update npm and your Emacs config is borked.

whartung 3y ago

> But I still have this nagging feeling with other mainstream languages that their tooling, their ecosystem, the breaking dependencies, the "making the compiler happy", the stupid language restrictions and such things distract me from my problem domain. I can relate to this in a different way. It seems the vast majority of work today is not "the problem", per se, it's the interface that exposes the problem (or solution) to others. Shoving stuff in and out of format (JSON, SQL, etc.), marshaling the data over interfaces, or building UIs to expose and work with it, etc. The problem domains themselves, for a lot of systems, can be pretty simple. But with CL, with the reader, and things like Emacs, a lot of that falls into the background -- with the caveat "as long as you're willing to work with native representations", i.e. S-expressions. I have an "application" in CL, and it's 1500 lines of code. Outside of a couple prints for debug, there is no I/O. No user interface. Nothing. It's all "just code". It's all "just problem". Meanwhile, I have a Java program I wrote. It wraps a 1000 line Java utility into a GUI. There's 4000 lines of code to present that GUI. It's a not quite fair comparison, as the entire purpose of the application is to expose this utility into a "usable form". But, with Java and other languages, there's always going to be some level of that. With CL, again if it fits within the confines of the REPL and S-expressions, you get all of that "for free". Trivial case with a simple Java command is you need some way to parse the command line options. Extended lambda lists give you that "for free" in CL. Named parameters, optional parameters, default values, etc. Arguably the entire point of the extended lambda list descends from their use within environments like Lisp Machines, where the function arguments WERE the "command line", and that's why its so robust. Those are all nice features when writing code, but they're really nice when you have to type stuff in all the time. And this ability to not worry so much about external representation, and moving and converting data, instead just focusing on what's being done to the data, in native terms, it's very liberating. There is no "impedance mismatch". Just code, just data, and code is data.