Hacker News Reader

Comment by woodruffw | Hacker News Reader

Ruby, like so many other good things, is best enjoyed alone :-)

I've loved every Ruby codebase that I've written. I still consider it one of my favorite programming languages, and (in pedagogical terms) one of the best languages for learning "practical" functional programming (point-free style, blocks as intuitive closures, &c.). But when I work with others, I find that all of the things that I love are obnoxiously clever to others, and that the things they love are obnoxiously clever to me.

Python isn't immune to that kind of cleverness, but subjectively it's not as common. I chalk that up to the higher pain threshold for doing really obnoxious metaprogramming in Python, a lower community tolerance for unidiomatic interfaces, and (broadly) better QA tooling (RuboCop is great, but MyPy + isort + Black + flake8 is really hard to beat).

View on HN

Yeah, Ruby is like poetry.

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!

I can answer this.

Ruby is my favourite language!

Am I a haiku

Well, the second verse

has an extra syllable,

but that's fine by me :)

Interesting!

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.

Yeah, I think pair programming (and constructive review) go a long way towards ameliorating this issue.

My theory is this is also why Lisp never took off. Powerful macros are wonderful for the solo programmer but difficult for a large team to reason about.

Lisp absolutely took off and had a heyday.

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.

You're not the only one, "The Lisp Curse"[1] essentially says the same thing (but spends a lot more time praising/criticizing the "lisp hacker").

> 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

The author of Lisp Curse had no experience with Lisp even in solo work, let alone in a team of two or more people.

It's purely made up stuff.

I think this is a tooling problem, as far as LISPs go, because unlike C, you (as far as I remember, perhaps I'm wrong) aren't relying on the compiler to fill in the bits, the macro is just a shortcut, if you will, to functionality.

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

Lisp itself precedes the Lisp Machines for about 20 years, and was available in UNIX workstations as well, in fact that is where Allegro Common Lisp started.

Lisp wasn't necessarily tied to specific hardware, like Lisp machines, but to powerful hardware with lots of RAM and processing power.

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?

PDP-11 could hardly run something like Multics or VMS, adopted a programming language whose genesis was to Bootstrap CPL compiler, let alone having a Lisp.

Programmers are not Computer Scientists, and the world is poorer for their conceit.

People keep saying this (especially here, lately) but it's a nonsense strawman argument. People can do stupid and sufficiently unreadable things in any language. Further, at sufficient scale - a large, long lived proprietary codebase - it hardly matters, it becomes the local dialect.

I chalk that up to the higher pain threshold

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.

> I chalk that up to the higher pain threshold for doing really obnoxious metaprogramming in Python

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.

The important thing for me is that the pain is by design.

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.

It sounds like we're talking past each other. It appears to me (and I may be wrong here) that for you, writing code is an activity that you partake in for pleasure, or otherwise aesthetic or artistic reasons. For me, while there are elements of writing code that are pleasurable, I predominantly engage in it in a professional setting, to get business goals accomplished.

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.

It’s not that you “deserve it”… it’s more like having an electric fence, the non lethal kind used by farmers all around the world to stop various livestock from knocking over fences in an attempt to eat the grass or mate with the animals in the next field over. It’s a strong discouragement. It’s unpleasant enough that collectively everyone just avoids it, why put yourself through the pain to do it that way when there’s another way to get it done that’s not going to hurt.

I’d rather eat well and get laid. YMMV.

Reply on news.ycombinator.com