Hacker News Reader

Comment by sph | Hacker News Reader

I quite enjoyed this article, but I reckon they're talking about ADHD rather than "bipolar" mind. Seen under that lens, I resonate with his caricature.

Focus is a precious, rare resource outside my control. Mainstream languages, made for collaboration in big teams rather than maximum personal freedom, soon impose restrictions that kill hyperfocus. The "unused variable is an error" is the most egregious of them that I hate with a passion. The separation between compilation and running is another that seemingly inescapable today. With languages like Lisp, I can code at the speed of thought from prototype to production.

These days tech is advanced by FAANGs, so no one cares about removing the safeties from our languages; this is the reason the focus-challenged among us still go back to Lisp and other lost languages (Forth, Smalltalk, Self) that have disappeared from the mainstream.

Rust, C++, Go, Python, etc. are good, but they're not made for us.

View on HN

ADDENDUM: I love Lisp but I want to clarify that its secret sauce is that it enables exploratory programming: programming from inside the system.

While most languages are akin to preparing a detailed blueprint and executing it (then stop to update the blueprint and try again), exploratory programming is like sculpture. You have an unformed mass full of unrealised potential, and you slowly carve it to shape.

The ADHD/Bipolar mind of the article isn't great at making plans, it's great at following its gut instinct, making shit up step by step.

Lisp enables this flow, but also Forth, Smalltalk, Self, etc., which I've been deeply obsessed with lately. Sadly, all we have today on the mainstream are basic REPLs which are a harmless, defanged version of these old environments promoting creativity and flow state.

"The ADHD/Bipolar mind of the article isn't great at making plans, it's great at following its gut instinct, making shit up step by step."

Which is why I do best with the command line, piping outputs and rapidly iterating to get the output I want.

And why I struggled so much writing Python in a larger, more complex script/app. I wanted to constantly run and rerun the smaller parts to get each one just right. Unfortunately that doesn't work great when you're interacting with a half dozen different APIs that take minutes to run each time. Until I realized what was slowing me down, I was just getting more and frustrated.

Now I am at least aware of the issue. Part and parcel of growing from sysadmin to DevOps to coder, I guess? Now I know to look for shims or stubs that help me. Now I can write tests that isolate and verify, rather than run the whole damn thing end to end.

It helps me to think of objects as those command line tools. Their method parameters are the stdin that get passed through pipes. I apologize that this isn't particularly profound, but sometimes epiphanies are made from smaller realizations.

Maybe I should have tried writing part of my most recent script in Lisp? Just to see if it resonated like described in this thread?

> I wanted to constantly run and rerun the smaller parts to get each one just right.

> Maybe I should have tried writing part of my most recent script in Lisp?

90% of Lisp programming is selecting an expression in your editor and pressing C-x C-e to execute it. And continue until you are satisfied it operates as you want, then integrate it in the larger system.

> I wanted to constantly run and rerun the smaller parts to get each one just right.

One one hand, as you alluded too, I've found unit tests are a great solution to this. Kill two birds with one stone - rapidly iterate on a chunk of code and come out of it with solid test coverage.

It's too bad that's not very feasible in gamedev most of the time with so much going on in the world, but over time I think that environment improved my skills to where it's less of a problem.

what about gnumeric, observablehq, jupyter, the unix shell, and the browser console (firebug and its clones)

admittedly it's hard to save the state of the page after you hack on it in the browser console, but jupyter doesn't really have that problem

> programming from inside the system.

Can you elaborate on that? I think you are saying that REPLs in other languages don't do what you can do in Lisp, but I don't think I know enough to fully understand why.

Imagine this:

You start a fresh REPL session with a vague idea of something you want to build. You have good tooling that enables you to write code in your favourite editor and pipe it to the REPL through a socket. You write a couple of functions and send them to the REPL. You call them a few times with some test arguments, maybe define a couple global variables while testing, and realize one of the functions doesn't quite behave the way you want. You tweak the code and send it again to the REPL. The function is redefined and works properly now.

You're happy with what you have for now, so you save the entire current environment of the REPL, functions and global variables and all, into a file (called an image) on your disk. The next day, you come up with a great new feature so you load up the image and continue exactly where you left off yesterday, with all your functions and even global variables as they were defined previously. You add your new feature, all while testing and tweaking your functions interactively, and then you save the new environment into an updated image. Any other code that loads that image will be able to take advantage of your updated functions and variables now.

The power of lisp is not just the fact that there's a REPL — a lot of languages have that now. It's the ability to save and reload the entire current state of the REPL (interactively or programmatically), which enables the powerful interactive development that so many lispers, including myself, rave about.

What happens when you want to share the thing you built with somebody else? If I type a defun into a REPL, is there a good way to get source code back out again?

Because there's a problem I've run into several times when writing Lisp (I use SLIME): I decide to refactor some stuff, so I rewrite some stuff, maybe remove a function or two from the source as part of that. Things seem to be working fine. I save my .lisp files and then at some point end up restarting the Lisp process (often because McCLIM can be kind of flaky and lose its connection to the X server). When I go to load my code back in, I get errors, because oops I was actually still calling that deleted function somewhere -- it "worked" before because the old function was still hanging out in the image.

When I develop in a compiled language, I just accept that I'm going to be re-building the entire thing from scratch (equivalent to restarting the lisp process & re-loading the source files) every time I want to try a change; if I broke something, I'll find out the next time I run make/go build/whatever. When I'm developing in Lisp, and I'll freely accept that my Lisp dev flow probably isn't ideal, it's so easy to screw up but be unaware of it for hours if not days: I write some code, I'm happy, I close Emacs, then a week later I come back and try to load my package and it's just broken.

I could solve it for myself by just using images: the "deleted" function would persist in the image, and every time I started working again it would be there. But if I ever want to let somebody look at the code, hack on it, make changes, what's that look like?

> When I develop in a compiled language

"batch compiled from scratch"

OTOH, most usage of Common Lisp is compiled, often by an incremental in-image compiler

> because oops I was actually still calling that deleted function somewhere

Typically Lisp IDEs have features like Edit Callers and/or List Callers. I would

1) "Edit Callers" -> this walks me through all functions which use this function, I change the functions and I can edit/compile them

2) When I'm done, I use "Undefine Function", which then undefines the function from the running Lisp.

> "Undefine Function"

That's the key; if you delete a function make sure to undefine it so it's not sticking around in the image.

In slime you can use `C-c C-u` which is bound to FMAKUNBOUND.

> If I type a defun into a REPL, is there a good way to get source code back out again?

this used to be the normal way of programming in lisp repls (like in 01980) but maybe this is good enough

    * (defun tri (n) (loop for i from 1 to n summing n))
    TRI
    * (describe 'tri)
    COMMON-LISP-USER::TRI
      [symbol]

    TRI names a compiled function:
      Lambda-list: (N)
      Derived type: (FUNCTION (T) (VALUES NUMBER &OPTIONAL))
      Source form:
        (LAMBDA (N)
          (BLOCK TRI
            (LOOP FOR I FROM 1 TO N
                  SUMMING N)))

> When I go to load my code back in, I get errors, because oops I was actually still calling that deleted function somewhere -- it "worked" before because the old function was still hanging out in the image.

so a thing you can do in that case is to delete it from the image at the same time

well, you can't really delete it from the image, but you can remove the function binding of the symbol, and since normally in common lisp implementations function calls indirect through the symbol (which is why you can replace the definition with a newer one) deleting the function binding is enough

    * (defun tri0 (n) (tri (1+ n)))
    TRI0
    * (tri0 4)
    25
    * (tri0 5)
    36
    * (fmakunbound 'tri)
    TRI
    * (tri0 5)

    debugger invoked on a UNDEFINED-FUNCTION @52A00674 in thread
    #<THREAD "main thread" RUNNING {1001348003}>:
      The function COMMON-LISP-USER::TRI is undefined.

    Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

    restarts (invokable by number or by possibly-abbreviated name):
      0: [CONTINUE      ] Retry calling TRI.
      1: [USE-VALUE     ] Call specified function.
      2: [RETURN-VALUE  ] Return specified values.
      3: [RETURN-NOTHING] Return zero values.
      4: [ABORT         ] Exit debugger, returning to top level.

    ("undefined function" 6)
    0]

as rainer pointed out, slime has a command for this (i barely use cl myself, you know much more than i do)

I work in a slightly different way by always saving my code in emacs and loading it fresh each session (though I have gone a couple of weeks with a live image/session on my laptop). I am fortunate that my 3D system [0] compiles and loads in a few seconds.

I also use the REPL for quick tests, and evaluate new code by writing it in emacs and compiling it one function at a time (C-c C-c).

Finally, I keep files of tutorial/demo/test cases which work a bit like a notebook, allowing me to quickly verify that existing 3D scenes still work.

[0] https://github.com/kaveh808/kons-9

About 15 or 20 years ago I had a work flow using SBCL Common Lisp where I saved images and always restarted a new work session where I left off. Easy to do.

I was motivated to do this because I had a ton of linguistic and text data in my environment which back then took a little while to load. Now, I organize everything I do into small or sometimes tiny Quicklisp projects/libraries and that is much more convenient for me.

If you want to really get into image based programming, the open source Pharo Smalltalk is very good.

This is the kind of thing that should be included in language tutorials!

It particularly resonates with me because I think so many project teams neglect the Developer Experience. In my opinion DevOps should be more about making coding, testing and deploying as frictionless as possible.

when this term first came out, it really seemed like that was the point

now it just seems like a hundred children you have to pacify and get to bed before you can even start working

That is very helpful. Thank you. Most of my exposure to Lisp has been Scheme and Racket and minimal at that. Are these images you describe something that is part of a particular distribution of Common Lisp?

Images are pretty routine amongst most of them (though not all).

In the end what you have is a base image, and then a set of code and instructions to transform that image into your runtime image, then you distribute that image as your "application".

I have never needed to do this, as all of my work has been utilitarian in nature, rather than some kind of monolith distributed to others. I simply load my code on to the stock image and go from there.

But even then, for folks that do that, they may well load up the stock image with useful and common, personal, utilities, and snapshot that. Their "application" is their essential working environment.

Smalltalk does, and Forth can work from this concept of an image.

Schemes tend to not be this way. They are interactive, but the image concept is not as ingrained in the Scheme world. Instead, it's more like doing development in something like Bash -- an interactive environment to be sure, but one that always resets to the baseline state and must be reloaded when started. There are certainly Schemes that can do this, it's just not as routine.

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.

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.

  > 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.

> The "unused variable is an error" is the most egregious of them that I hate with a passion.

Same. That has tripped me so many times when trying out something simple in golang.

I get why they are undesirable in the long run, but in the short run I'm often trying out a fragment and don't have the users of every variable written yet.

Your comment and the grandparent comment have both really validated me. I know that's weird to say, but I really thought I was just Wrong about the linters/LSPs and unfinished lines or unused variables. Thank you :)

Those that implemented the unused variable feature are completely unaware that there are two modalities of programming: exploring a problem space, and building a solid product.

When you're exploring, you don't want your compiler to stop you in your tracks to warn you about pedantic nonsense. It's not a syntax error that prevents your compiler from understanding, it's just arbitrary restriction that the compiler decides to pester your about, a sort of a robotic grammar nazi.

Computers are obtuse, the worst thing they can do is ignore your perfectly parseable and valid instructions for arbitrary reasons. Machine, if you know I'm not using a variable, kindly let me know and carry on doing your job.

I'm certain they're aware of the second modality; I just think that Go is narrowly focused in design and it's not really for that other kind of user.

it is vanishingly unlikely that ken thompson and rob pike are unaware that people sometimes program to explore a problem space

Ken's first language is pretty tolerant of programmer silliness, maybe too much.

do you mean ibm 709 assembly or what

i don't actually know what he was hacking on at berkeley

You are wrong, just like these other people.

You guys want to have your cake and eat it too -- to be correct despite being lazy and sloppy.

It makes no sense. Bite the bullet. Don't have unused variables. There's no such thing as "exploration". After you've "explored" enough (where "explored" means "coded sloppily"), you've quickly exhausted your mental buffer, and it's suddenly expensive to go back and polish what you've done, making yesterday's exploration today's (hopefully not too creaky) foundation.

It is trivial to ignore unused variables, early returns leaving dead code and so forth while editing and then check&reject them before applying to production. Fix whitespace in the same git hook.

This is one where faster local development (because you don't have to repeatedly, jarringly stop what you're doing and patch up something that doesn't matter) and clean source in a common repo are both possible and very easy to achieve.

But whatever. Yay go.

My hype for Zig died the day Andrew decided to push for that nonsense.

For it was the use of @, Objective-C style, and not having an answer for use-after-free.

If I need to use analysers to fix that, I already have those for C and C++ for the last 30 years.

I do wonder if I’d be diagnosed with ADHD if I didn’t already have a fairly obscure neurological disorder. My visual cortex can’t filter its own noise out properly which causes a bunch of mostly migraine-like neurological issues including apparently making my focus unreliable and forcing me to work in a very “burst-then-rest” kind of fashion, but I was already that way beforehand it just got much worse when I contracted the disorder.

Either way this comment makes me want to try a LISP! I might give Clojure a go, I daily drive another alt-JVM language at the moment so it’s a natural choice.

This is super interesting. Thank you. Feels similar to subtle patterns in my next of kin and their inner workings. So I can read more, would you mind sharing the name of the disorder?

The disorder’s called visual snow syndrome, it’s named after the main symptom that differentiates it from other disorders which is TV-static like visual distortion but it sometimes causes a lot of other things typically associated with migraine to the point before it was studied in its own right it was assumed to be an uncommon variation of migraine; unlike migraine though for many people it doesn’t produce any pain at all, just other migraine aura like neurological symptoms. I’m not so fortunate, I get a permanent one-sided headache, brain fog, occasional derealisation episodes, photophobia (that one’s fun but fortunately I live in usually grey Britain), and that general kind of thing. It was a migraine specialist researching the condition in the UK who eventually diagnosed which was good as at the time there was a fair bit of rubbish on the internet about the condition (though that’s a lot better than it used to be, I was sixteen when I got it and all the doctors could tell me at the time was ‘we have no idea what this is but it’s not going to kill you’).

As for treatments there basically isn’t one. Among other things I experimentally microdosed quetiapine against it (under the theory dopamine might be involved) under the supervision of a doctor which basically cured the visual distortion but not the pain, but I quickly built a tolerance and binned it off because the side effects aren’t great. Some people benefit from anti-seizure medications but not everyone and the side effects can also be bleak. Fortunately medical cannabis is legal in the UK and it’s very effective against the pain, the amount of unsuccessful things I’ve tried qualifies me for it and the pain’s only a problem on very bad days now. Coding with the monofur font helps me too!

Of course everyone has some noise in their visual system, a little bit of TV static isn’t necessarily indicative of disease. For reference I struggle to read when it’s bad, and my night vision is impaired quite a bit compared to what it was before so you’d definitely notice if it was problematic.

Just a intuitive thought, a bit unresponsible maybe, so consider on your own risk: you researched the effects of ketamine and its derivatives on your disorder? Din't know why I think of this; probably because they are know to also affect obscure pain stuff like phantom pains and generally interact with perception (I feel it reduces oversensitivities like not beeing able to bare some stimulus and such) currently researched as an fast acting and lasting over its acute effects treatments for depression.

If I'm ever eligible for a study into it I'd definitely at least consider the idea, though it's not something I'd want to do outside of medical supervision given the mechanism of my condition is not well characterised yet.

One anecdotal thing from support groups etc that makes me cautious is that while some people are born with it and some people contract it spontaneously later in life (this was my case), other people can contract it after taking various types of drug. Typically these are serotonergic drugs like antidepressants, psychedelics, and that sort of thing which aren't in the same category so it'd probably be okay but it's definitely possible I can make things worse as well as better.

Ah. Funny. I probably have this. That was unexpected. Thank you.

> but I reckon they're talking about ADHD rather than "bipolar" mind

I think while some of the people he describes may have ADHD, very few people with ADHD are this person. His description resonated with me as a particular archetype, one that often makes their way into grad school eventually. Often enough to be recognizable.

I also don't think the author meant these people are bipolar in a medical sense, but used "bipolar" as the success+failure designation, perhaps unfortunate terminology.

I don't think the kind of student the author is talking about has ADHD symptoms or any sort of mental illness. I think they just have different personalities - and having a certain personality than the majority of people shouldn't be considered a mental illness or disorder. People are not all the same... at what threshold do we count difference in personalities as an issue?? As long as the person can keep functioning in society without major side effects (crime, extreme isolation, depression) the person is just "normal" even if they tend to work and act differently from the average.

Deleted comment

I like to think I'm ADH, I've got everything ADHD except for the disorder

It's not necessarily technically impossible to make this work in Rust/C++/Python. Using something like rr, completely disabling all optimizations, and making all functions virtual should make this possible in theory, as long as you don't change data structures. I'm sure it is going to be extremely hard in practice, though.

If you're interested in trying to make this work, we can try implementing it first in Python using a shim annotation on every function and making some changes to an existing debugger plugin, it will definitely be difficult to integrate but it should be doable.

For C++, something similar can be done by hacking the compiler to make all functions virtual and then hooking up NativeJIT to recompile functions as-needed. Eventually using something like rr we can even replay execution after we change data structures.

I really resonate with the idea of exploratory programming and find myself in a similar position to you - but I can't use Lisp for most of my work, so given the possibility, I really do think that making tooling that makes this kind of development environment possible is the best option, and I'm pretty sure it's possible to do it, so why not have the best of both worlds?

> Rust, C++, Go, Python, etc. are good, but they're not made for us.

I also don't see any technical reason you couldn't have the best of both worlds. E.g. a dynamic runtime environment that allows recompiling functions on the fly etc., but also have a separate batch compiler that can type check the program as a whole, do whole program optimizations, etc.

So you can do exploratory programming while developing, and the run the batch compiler before committing changes, when doing releases, etc.

I think the biggest challenge is simply the amount of effort required to design and implement it (and of course someone who's interested enough in it to do it).

Okay, you made me want to try Lisp.

The sibling comment suggests Clojure, and last time I tried I lost all patience after having to deal with setting up Java, lein (it's been quite a while).

If you want the least amount of friction possible, install Racket and run DrRacket. Here's a tutorial: https://docs.racket-lang.org/quick/index.html and one to make web apps: https://docs.racket-lang.org/more/index.html

(I don't mean to disparage Clojure, I'm sure it's great, but a newbie needs something easy to get excited about, not having to mess with JDK and setting up Emacs)

I had the same experience. Spent over an hour trying to strap all the components into a working system just for it to trow error after error. So I gave up learning Clojure and instead went into Pharo. Self-contained environment trivial to set-up, same live environment typical of lisps, but approached from the Smalltalk side. I enjoy it.

and moving from Racket to Clojure is an easier step than straight to clojure.

Clojure sucks.

Go with Lisp instead. Or OCaml. Both are purer and leaner than the JVM-addled morass that is Clojure.

For a quick start, can recommend Clojure using VSCode as editor (with the Calva plugin).

I was wondering whether this sounded more like ADHD or ASD than "bipolar", then decided that he wasn't using the word in that sense and let it go.

Ruby could be a good compromise. Unfortunately it lost the battle long time ago.

Which battle is that?

The battle for relevance. A language that isn't growing is dying.

"Lost the battle?" Ruby is a far better ecosystem now than it was when it was getting popular. C is "dying" according to your definition. It's number 2 on the TIOBE index, while Ruby is in the top twenty. I'm using Common Lisp do build my product, and that one is long dead and buried according to popularity.

Maybe there are business reasons to avoid less popular programming languages, but there aren't any programming reasons to avoid them. Maybe we should stop treating tools as if they were candidates for homecoming king and queen.

This comment is certainly true for me. The article really resonated for me.

Reply on news.ycombinator.com