Thank you for your comment. I like Vonnegut (my favorite is Hocus Pocus) but hadn't read Bluebeard. I only started it and I'm already enjoying it significantly.

Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.

I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.

When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance.

Non-programmers read python and sometimes even Java and say "huh, this is something that could be figured out" - reading perl was reading line noise.

APL is probably one of the most powerful languages out there, but the characters in the syntax scare most away.

Agree, that was exactly my reaction. What a terrible introduction, wasting many words on such platitudes as telling me that the idea isn't new but it isn't old fashioned either, or that they want to provide "some respite for those who feel the internet has been disrupted enough already."

Jesus, god forbid someone share their motivation for a project for longer than it takes for a tiktok to play...

The link to the FAQ and spec is right there. If you have the attention span of a fruit fly (many such cases) I personally suggest trying to fix it, not feeling proud about it.

If this were an utterly pedestrian """deep dive""" about some AI thing it could have rambled as much as it liked that there wouldn't be this comment near the top, I assure you.

Wonder if you've tried spec driven development (as opposed to just prompting)?

I used to create requirement-oriented prompts and I felt something similar to what you describe. However, I've switched to generating parts of my source code from my specs in a semi-automated way and it made the process much more pleasant (and efficient, I think).

I wrote a bit about my current state here: https://alejo.ch/3hi - for my Duende project I generate 8821 lines of code (2940 of implementation, 5881 of tests) from 1553 lines in specifications.

I have. I get into the same head space, either way.

I also started building my own, it's fun and you get far quickly.

I'm now experimenting with letting the agent generate its own source code from a specification (currently generating 9K lines of Python code (3K of implementation, 6K of tests) from 1.5K lines in specifications (https://alejo.ch/3hi).

Just reading through your docs, and feeling inspired. What are you spending, token-wise? Order of magnitude.

Disagree. If some small adjustments to your workflow or expectations enable you to use LLMs to produce good, working, high-quality code much faster than you could otherwise, at some point you should absolutely welcome this, not stubbornly refuse change.

I think there's a mighty big assumption in there.

I see no reason to believe LLMs can write working let alone good or high-quality code, nor that the adjustments to my workflow or expectations will be small. But sure, if such a thing happened, I would probably welcome it.

Meanwhile, there are people who write good and high-quality working code faster than me, and they all write as much as possible on one line with the most bare-bones of text editors, so I will continue to learn from them, rather than the people who say LLMs are helping them. Maybe you should reconsider.

Somehow I don't think writing verbose English to communicate with an LLM is ever going to beat a language purpose-built for its particular niche. Being terse is the point and what makes it so useful. If people wanted to use python with their LLM instead, they have that option.

For what it's worth it, I'm still developing and using exclusively my own text-based editor/IDE: https://github.com/alefore/edge

I wrote recently a bit about my conclusions after ten years of developing it: https://github.com/alefore/weblog/blob/master/edge/README.md

Me too. It took ~4 months of development, but was fun.

https://github.com/ivanjermakov/hat

I wrote a somewhat related article, after running just this Friday into two blocks of code that were deliberately causing invariant violations (akin to the "max < min" situation) to be ignored silently: https://alejo.ch/3gk - Fail loudly: a plea to stop hiding bugs

I think of this as fail fast. Fail immediately so its easy to root cause the failure and not have it be hidden and cause more obscure side effects later.

I actually I'm somewhat torn on this.

In my blog, I do this in my poems, such as: https://alejo.ch/39l — I don't expect this to be controversial, makes sense for poems, right?

However, I'm also experimenting with rendering my prose with the same type of breaks, like https://alejo.ch/3gb or https://alejo.ch/3g9

My guess, reading this thread, is that most people would tell me that they find the breaks annoying and would rather read my prose without the breaks? Hmm. Would love to hear some feedback.

I’m clearly biased. But I enjoyed the format and it's risk like this that make me more likely to read the content where under different circumstance I may not even care about your professional experiences. The smaller font size mitigates any issues due to the line breaks because I can still see all the text.

Although I can get how someone else would feel that the text is too small and if the size was a conscious decision on your part to accommodate the line breaks they would hold you to blame further.

I think you’ve got a nice personal website overall. Even down to the drafts that lead to 404 errors; a nice touch even if unintentional.

Everybody wants personality to return to the Web again until they’ve got to deal with personalities.

You win some, you lose some.

Thank you for responding to my request for feedback, I appreciate it.

It's pretty annoying on a phone screen where there are additional line breaks: I actually lose the flow when I need to skip lines.

Maybe it'll be better on a larger screen, but due to more frequent line breaks, I would advise you to use a serif font.