Live data from Hacker News

The Bipolar Lisp Programmer (2007)

marktarver.com

111–120 of 136 posts

Re: The Bipolar Lisp Programmer (2007)

#111
post #104

I wonder if I could write the story of the BBM once he left the university and went on to work in Corporate Land. My career (if may be called that) can be summarized by a constant swing. On one side, I have a "job" where I start well but after a while I fall out of grace from higher-ups because I inevitably end up calling out their bullshit and/or start seeing the pointlessness of it all and lose interest in progress…

> I inevitably end up calling out their bullshit and/or start seeing the pointlessness of it all The fundamental point to keep in mind is that it does not matter. The only thing you are entitled to in a corporation is your salary. Interesting projects and things making sense all over are just side perks. They are very nice perks, I have to say, but they don't pay your rent or put food on your table. Keep this is mind…

Don't you ever get a feeling that life is more than worrying about how to make rent or put food on the table?

Maybe it's just my (relatively) comfortable upbringing in Brazil or me living for over 10 years in Germany, where I see how the Welfare State affords me some peace of mind in knowing that my kids will be okay even if I give up on my career... but "I just better swallow this bullshit and do so for the majority of my productive life or I won't be able to pay rent" has never been a thought that crossed my mind.

Re: The Bipolar Lisp Programmer (2007)

#112
This tracks with my own experience, and I don’t believe he is literally saying people of this personality type are medically bipolar.

I used Common Lisp for a few years and then switched to Clojure for another four years. At the time, it seemed that Clojure’s ecosystem could overcome the lone-wolf problems that CL faced. In the end, Rich Hickey made it clear that Clojure was his toy that we were lucky to use, and so its ecosystem never took off like it could have. It’s a real pity and a terrible lost opportunity.

Since then I’ve gone all in on languages that I don’t particularly like, but whose ecosystems provide such value that the language itself is somewhat immaterial: JavaScript and Python.

But I do think about lone-wolfing sometimes, in the context of building new products for myself,

If I ever went down that path again, I’d choose Common Lisp over Clojure. Clojure is easier to use, has more libraries, and has JVM interop, but these benefits are outweighed by Clojure’s opinionated restrictions on the language itself. Ultimately, if I am going lone-wolf or nearly-lone-wolf, I might as well use the most powerful language that doesn’t force its opinions on me.

Re: The Bipolar Lisp Programmer (2007)

#113
post #85
post #71

Earlier quoted context omitted.

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 f…

> 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 a…

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

Re: The Bipolar Lisp Programmer (2007)

#114
post #95

I wonder if I could write the story of the BBM once he left the university and went on to work in Corporate Land. My career (if may be called that) can be summarized by a constant swing. On one side, I have a "job" where I start well but after a while I fall out of grace from higher-ups because I inevitably end up calling out their bullshit and/or start seeing the pointlessness of it all and lose interest in progress…

That pretty much describes my "career" of the past 20 years. Lately it's been getting harder and harder to get _any_ job. These days it's either web dev which has reached unbearable levels of idiocracy with its endless tail-chasing web frameworks, microservices and even the platform itself (DOM/CSS), or it's million-line C++ legacy-on-arrival abstraction shitfests written by OOP-heads. It feels like there's nowhere t…

I've found that "devops" is a pretty nice niche to fall into, even with all of its warts. And that means devops as in literally a developer who can also provision/manage infra and operations and not just a YAML jockey who gets a buzzword title. You can kind of pick your lane: dev-experience tooling, build systems, infrastructure automation, observability systems, etc.

It's a nice way to break out of the rat race of bad practices and questionable frameworks being used all over the place and it seems pretty secure because most of the tail-chasing framework types aren't exactly keen to learn the details of what actually takes code from 0 to production-grade so having the breadth of knowledge becomes an asset that lets you work on a variety of problems. Obviously there's a different slew of annoying things to deal with (wrangling cloud services, insane abstraction around infrastructure, etc.) but I think those are more pleasant to work around.

The infra-side of things also hasn't really slowed down in hiring like pure developer positions has.

Re: The Bipolar Lisp Programmer (2007)

#115
post #71
post #37

Earlier quoted context omitted.

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…

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 f…

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

Re: The Bipolar Lisp Programmer (2007)

#116
post #89

I remember this chestnut from back in the day. Sounds like a discipline issue. If Lisp really is the programming language that appeals to people with discipline issues, then were I a hiring manager a fondness for Lisp would be a no hire.

That's actually great, as you would be doing these people a favour by not hiring them.

Re: The Bipolar Lisp Programmer (2007)

#117
post #2

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…

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?

Re: The Bipolar Lisp Programmer (2007)

#118
"He can see far; further than in fact his strength allows him to travel. He conceives of brilliant ambitious projects requiring great resources, and he embarks on them only to run out of steam. It's not that he's lazy; its just that his resources are insufficient."

This speaks to me. As I get older, I am tempted to start curating a list of my "failed" (or abandoned) projects.

I have been fortunate enough to launch an open-source 3D graphics Lisp project late in life which has managed to keep my interest. Early on, I made a number of conscious decisions about how I would view this project and avoid some mistakes of my past.

- No comparing to existing 3D packages. It's evident that I can't compete with commercial packages with decades of programmer effort.

- No hunting for a "better" language (though this hasn't really been a problem). A goal of the project is to develop a system where I can bring the power of Common Lisp to bear on 3D graphics. In some ways this is a throwback of work I did developing 3D graphics on Symbolics Lisp Machines back at the MIT Media Lab [0]. Returning to my youth?

- Keep it simple. Or, does it need to be more complicated? Understandable code is a benefit, as is code you can (mostly) keep in your head. Avoid excessively clever code, which I have been guilty of in the past (macros, anyone?). Also (more controversially) avoid dependencies where possible; keep it in house.

- Build a community. Having others involved is the best way I have found for not running out of steam. My other projects have invariably been solo efforts. Now I am interested in creating something which will outlast me. Hence the decision to put the project on Github [1].

- This "thing" has value in and of itself, and doesn't need to be "better" than what is out there. By virtue of being different enough, it is a worthwhile project to bring into existence. The world probably doesn't need another browser-based JavaScript package.

- Keep the momentum going by working on whatever interests me at the time. Avoiding tedious development and yak shaving keeps me from losing motivation. I do realize the article touches on this as a weakness of the Lisp developer mindset, and I admit to not being motivated to build an industrial-strength system. E.g. my half-baked GUI built on top of raw OpenGL.

- Finally (have to stop sometime), don't overthink things. Enjoy the journey. I am enjoying enhancing the system while not fretting over who will use it or for what purpose. The journey is the destination.

[0] https://medium.com/@kaveh808/late-night-lisp-machine-hacking...

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

Re: The Bipolar Lisp Programmer (2007)

#119

Earlier quoted context omitted.

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 :)

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 y…

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.

Re: The Bipolar Lisp Programmer (2007)

#120

I’m fairly annoyed with myself on my worse days for heading into embedded as a career path when Lisp (clojure mainly) is the only development process I’ve really ever felt fit my brain. I’m positive that there is a Lispy language out there (actually in existence, or the aether) that is appropriate for embedded work, but the constraints of the target make it difficult to envision. I like C and assembly because they’re…

Lisp makes a spectacular high level assembler but you may have trouble using it in a team environment. Think writing assembly but with lisp as the macro layer.
Post reply on HN