2,666 karma · joined October 9, 2010
Co-founder of http://hamon.in
Personal website at http://nibrahim.net.in
Other projects http://emacsmovies.org http://calligraffiti.in
Kismet 782c4b
The good parts are that the inbuilt data structures and their apis are efficient and clean enough to write code that's mostly readable. Most of the heavy lifting is done in hand tuned C and performance intensive external modules are also written in C. There are several good projects that are written using it and while it's not theoretically perfect, it's useful enough. Like Stroustrup said - there are 2 kinds of the languages, ones that everyone complains about and ones that no one uses.
The bad parts are that it's very easy to use. Almost in a Visual Basic "producing crap just takes a squeeze" kind of way. It opened up programming to a lot of people (the genesis of Python was in the CP4E project - where this was the aim). This resulted in a lot of bad patterns, inefficient code, badly written but popular libraries. Also, the indentation idiom and other restrictions resulted in a lot of convoluted APIs.There's also a lot of baggage from the pre multi-core CPU era (threading etc.).
I still think of it as a great glue language. If there are libraries that are fast and can run well, a good FFI or wrapper which Python can leverage will amplify the reach and usability of the library.
On the overall, a language that's older than the venerable Java which people are still using (and hence complaining about) speaks to its longevity. So, atleast by that definition, it is successful.
My own memories of lan parties were much messier. People bringing their own assembled machines and running cables around the place to get this to work somehow, swapping cards etc.
$ which e
e () {
snippet="(nkv-find-file-and-jump \"$1\")"
emacsclient --no-wait -e $snippet
}The barrier and time between idea and usable implementation is almost zero now. I don't have to imagine. I can just write something and see it work before making larger decisions. I really like this. Many of my ideas were abandoned because I needed to study some obscure library. Now, I can learn the parts that I find interesting and just have the AI chew through the grunt parts easily. That's the good.
I started coding with a line editor on a small Casio handheld "computer" and used to keep programs in my head. I more or less knew what happened on each line without seeing the line. With larger programs, I had a mental model of what was going on where and a big part of the input to that was the effort of writing everything by hand. That's gone. It's not really important as far as the output of usable programs is concerned but there's a certain feeling of satisfaction that came with digesting a larger codebase and having it surrender it's secrets to you that's missing.
There was an interesting article which I read a long time. It's linked to from the post above called "How to Fit a Large Program into a Small Machine" published in 1980.
AGI, SCI, Scumm etc. were all larger and more capable versions of this.
I found a used book that was given to someone when he graduated top of his class in the early 1900s. There was an inscription from the principal of his college, signed and with a seal from the college. I stood there gazing at it and couldn't help imagining how he finished reading it, left it here and there in his house and finally, after his time, in the attic of the ancestral home. It was later discovered by his daughter or granddaughter and then when they were cleaning up, sold to a second hand book seller rather than just destroyed.
Contrast that to a PDF which is just as crisp and clean as it was when it was created (and which could, become a format for which we don't have a reader anymore).
MAny a times, the books I read don't have enough place to scribble so I keep a A5 half folded as a bookmark and write notes on that with page numbers. Once the book is over, I read through the points and try to reconstruct.
I use a mechanical pencil myself since I like the teeth and my handwriting is better when I use it. Also, ability to erase (not for cleanliness but more to avoid wastage of space) is useful.
Fast forward a few years, I gingerly took out the pad and pulled out a sheet. I didn't do it right and tore the sheet down the middle and had to take fresh one. Then I dropped my pen while writing (since I was so "careful" with the paper) and had ink droplets fall onto the sheet. Finally, when I put pen to the paper, I found that it had absorbed moisture from the air and the the ink bled into the paper ruining everything.
I never thought about blogging about it though. Perhaps something to consider.
I spoke to the CTO of a well funded company who was spending a few millions on AWS infrastructure per year with budget overshoots etc. I pitched the product to him with all the details and he understood it but at the end of the day, his response was that he'd rather pay AWS for the convenience rather than manage this by himself.
I recorded a video of the relevant part of the cutscene using dosbox and then split it into numbered frames using ffmpeg. Then I gave that + the spritesheet to Claude Code and asked it to figure it out and tell me which ones are at what position. I should probably have deduped it but in any case, it churned through the whole thing and got one or two out of 15 or 16 sprites right. The rest, it just dropped into random places. YMMV