Live data from Hacker News

Why Ruby Is More Readable Than Python

confuzeus.com

111–120 of 149 posts

Re: Why Ruby Is More Readable Than Python

#111
post #66
post #53

Surely there's a correlation between ease of reading and ease of compilation? I'm thinking in terms of avoiding back-tracking in your syntax. E.g.: regices are hard as shit to read, and I don't think that back-tracking helps (ab + c)* Or *+(ab, c) The first says ab, no - it's the union of ab and something, something is c, no - it's one or more of those. The second says one-or-more of the union of (ab) and (c). Why ha…

> regices Please no. It's bad enough that people insist on using foreign plurals in English, let's not pretend "regex" is some latin word (it's just REGular EXpression).

Words are about the only damned thing where mere belief conjures existence.

Re: Why Ruby Is More Readable Than Python

#112
post #66
post #53

Surely there's a correlation between ease of reading and ease of compilation? I'm thinking in terms of avoiding back-tracking in your syntax. E.g.: regices are hard as shit to read, and I don't think that back-tracking helps (ab + c)* Or *+(ab, c) The first says ab, no - it's the union of ab and something, something is c, no - it's one or more of those. The second says one-or-more of the union of (ab) and (c). Why ha…

> regices Please no. It's bad enough that people insist on using foreign plurals in English, let's not pretend "regex" is some latin word (it's just REGular EXpression).

Also, if you're going to bother to reply, reply to the content - rather than the terrible pun that I through in for the sake of my own bored amusement.

I'm a fucking programmer (at very least I'm a dude commenting on HN) - I know what regex is short for.

Re: Why Ruby Is More Readable Than Python

#113
post #49
post #13

Until metaprogramming, autoloading, DSLs and everything that eventually makes Ruby code unreadable takes place due to personal preferences. Ruby is clever, it can be beautiful, but I've never seen a good codebase using it grow well without enforcing strictly opinionated ways of writing it to ensure maintainability. Which breaks a lot of the expectations of some Ruby developers that chose the language because they lik…

> without enforcing strictly opinionated ways of writing it to ensure maintainability But a team cannot have its own opinions with Python. They're already built in.

A team can absolutely have its own opinions about Python. “There should be one— and preferably only one —obvious way to do it” from the Zen is very much aspirational, rather than a declaration of an immutable truth about Python and it's ecosystem.

Re: Why Ruby Is More Readable Than Python

#114
post #94

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

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…

I can answer this.

Ruby is my favourite language!

Am I a haiku

Re: Why Ruby Is More Readable Than Python

#115
post #31

Earlier quoted context omitted.

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.

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.

Re: Why Ruby Is More Readable Than Python

#116
post #31

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

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.

Re: Why Ruby Is More Readable Than Python

#117
post #110

Earlier quoted context omitted.

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

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?

Re: Why Ruby Is More Readable Than Python

#119
to me it comes down to taste.

in those examples, python looks more readable to me (and easier to write) because it is more concise. the less code that i have to scroll through, the more readable it is. (to a degree. APL is compact but not concise because it uses short symbols for things that would be readable words in other languages)

getters and setters are boilerplate. if you want them, you can use them in python too. common operations should be easy, uncommon operations should be possible. python is doing that. ruby in this case forces me to treat a common operation the same as an uncommon one. personally, i only want getters or setters if they do something beyond plain return and assignment of the value, like a range or type check for example. that way, when they actually matter, they stand out in the code. the same goes for access to class variables.

i get it, there is some beauty in having every class look the same. you can just write it all down without much thinking. and when you need a custom setter, it's already there and easy to modify, whereas in python i may have to do some extra work, add the setter, and make sure its use is enforced. it's a trade-off.

+() vs __add__() to define a + operator? sure, +() looks more elegant, but in the end the code is the same, __add__() stands out well enough, and while i too would prefer +(), it's not something i'd bother complaining about. there are other things that are more irritating.

and finally, single inheritance vs multiple inheritance. an age-old discussion with good arguments on both sides. pick your preference.

Re: Why Ruby Is More Readable Than Python

#120
post #110

Earlier quoted context omitted.

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

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.
Post reply on HN