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).
Why Ruby Is More Readable Than Python
111–120 of 149 posts
Re: Why Ruby Is More Readable Than Python
#112Surely 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).
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
#113Until 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.
Re: Why Ruby Is More Readable Than Python
#114Ruby, 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…
Ruby is my favourite language!
Am I a haiku
Re: Why Ruby Is More Readable Than Python
#115Earlier 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
It's purely made up stuff.
Re: Why Ruby Is More Readable Than Python
#116Ruby, 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.
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
#117Earlier 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.
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
#118Did it miss the data science/ML boat?
Re: Why Ruby Is More Readable Than Python
#119in 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
#120Earlier 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…