Most poetry is like https://hitchhikers.fandom.com/wiki/Vogon_poetry.

And the worst is that I'm unable to do poetry.

---

I'm enthusiast about learning about languages, and enjoy everything I see about APL, Ruby, Scheme, Forth, Haskell, etc. I actually LIKE the concepts.

Is kind of relaxing take a look around the basic tutorial or read what the "good" poets say about that.

But my instinct tell me it will be torture to live like a poet.

So, for actual work, is much better (for me) all languages that have restriction and strict ideas about stuff.

- Python FORCE indentation? SOLD!

- Pascal DEMAND declare all before use? GIVE ME MORE!

- Rust SMASH YOUR HEAD at every keystroke? SHUT UP, TAKE MY MONEY!

Ruby is my favourite language!

Am I a haiku

has an extra syllable,

but that's fine by me :)

I spent a few years doing ruby in pair programming contexts and never had that problem. It was a great experience for me. I guess we didn't have that problem because pairing both gives you immediate feedback on "too clever" and because it's much easier to understand a clever thing if you do it with somebody rather than coming across it later in the code.

We are decades past "peak Lisp".

Lisp grew in capability and complexity at a voracious pace and required expensive, powerful hardware, always at the edge of the hardware envelope.

Then microcomputers happened, featuring the power and speed of big iron machines from 15-20 years prior.

Almost no software survived the transition from big iron to microcomputers. Pretty much no operating system, and few programming languages or applications---everything was "rebooted". Microcomputers went through their own cultural evolution, with entirely new software.

Customers were buying microcomputers, including lots of new customers that didn't have computers before, and you couldn't sell them software that wouldn't run (or fit) onto those.

Simple as that; nothing to do with macros.

(Unix jumped to microcomputers because it was a lean, resource-efficient minicomputer operating system; the lag between micros becoming as powerful as minis was not as great (decade or so) and basically dove tailed with the Unix timeline. Unix was ready just as micros were becoming ready.)

If it was about macros, we wouldn't be talking about Lisp; it would be entirely dead. HackerNews would be in written in Paul Graham's small dialect of PL/I or something, which would still be here due to not confusing anyone with macros.

> The expressive power of Lisp has drawbacks. There is no such thing as a free lunch. > - The Lisp Curse

[1]: http://winestockwebdesign.com/Essays/Lisp_Curse.html

It's purely made up stuff.

Not always transparent, but it should be solved with correct tooling. I think the bigger problem was LISP was far too long tied to LISP Machines, rather than being able to run independently on any hardware, which helped C and Pascal gain traction early

The "Unix workstation" of the 1980's was about the most powerful, expensive machine you could get your hands on that still qualified as a microcomputer. No wonder they got some sort of industrial Lisp to fit on it.

Unix ran on a lot less than that before that; what sort of Lisp was there for V7 Unix on a PDP-11, and what were its applications?

I never could quite articulate why Python doesn’t resonate with me without hyperbole or snark or both.

But that’s it. Python’s design includes inducing pain deliberately with the rational that I deserve it.

Don’t misunderstand me. I think Python is useful. It is just that I don’t find it enjoyable and I inflict enough pain on myself with my code.

If you're going to quote it, don't you think you should quote the whole thing? The whole point of making the pain threshold higher for certain kinds of metaprogramming painful and obvious.

I think that is a good thing. You can use it when you need to, but when it comes up in a code review, it's extremely obvious that you are reaching for a powerful tool which can (and in my experience, almost always) impedes ease of code readability and reasoning about behavior. These things are toxic to growing organizations with growing teams.

It sounds a reach to misconstrue that the design "includes inducing pain deliberately with the rational that I deserve it" -- it's not that you deserve it, per sé, but you may not be using it for the use case it was intended for.

My use cases have spanned decades of experience across dozens of organizations serving billions of dollars of industrial strength pressure. Having used other languages (including Ruby, Java, Go, Scala, Cxx), accounting for tradeoffs between ecosystem maturity and language flexibility, it remains my overall top choice for getting work done and building durable, maintainable codebases.

That someone thinks it’s good for me doesn’t justify the deliberate application of pain to me.

I don’t mind that “it works on your machine.”

My distaste for Python’s philosophy is my distaste.

I simply think my life is richer without aspirations to be Pythonic.

And now I can put my finger on why.

Thanks.

In the former case, I think that having a "distaste for it[Python]'s philosophy" where one's life is "richer without aspirations to be Pythonic" is pretty reasonable.

In the latter case, there isn't as much room for that. Instead, the more practical considerations I mentioned predominate: the question is how to get the most mileage out of language in a large organization to accomplish large, complex business goals with technology in a durable way.

It's not to say that one or the other is more important (I think there is plenty of space in this world for both), but I would say that the vast majority of ecosystem space around programming languages is and very likely always will be taken up by the latter use case. If you're curious about why things are the way they are (which you may not be, or which you may simply not care about, or which may simply not apply to you), then I think it's worth considering.