Live data from Hacker News

Ruby 3.2.0 is from another dimension

tomaszs2.medium.com

251–260 of 341 posts

Re: Ruby 3.2.0 is from another dimension

#251
post #52

Earlier quoted context omitted.

You are obviously referring to Python and so I would like to note a few things. (I have nothing against Ruby) > Ruby ... its combined attributes of brevity, expressive power, and feature consistency. > [Python] lacks the elegance and consistency First I would argue Python is very consistent in its design, it aims to only have one obvious way to do things and so it's easy to guess how apis will work. It also aims for…

One aspect in which Ruby is much more consistent than Python: sorted(arr) arr.sort() versus arr.sort arr.sort!

I'm definitely a Python person, having used both fairly significantly - Python about ~12y, Ruby ~3y.

One thing I think Ruby gets right is the naming convention for methods that modify the object they're called on (.!) and callables in general that return a boolean (?).

My biggest gripe with Ruby is the class implementation. I find metaclasses a bit more difficult to understand in Ruby. I hate that I can't easy determine where a given method of an arbitrary object is defined.

I recall that it wasn't uncommon for popular libraries to "open up" a class that was an integral part of Rails and redefine methods, overriding the original implementation. I recall trying to figure out why the method I was calling wasn't returning the value I expected, even after reading the Rails source. Come to find out, some random library had overridden it. They'd matched the behavior of a previous Rails version, but the Rails behavior had since changed. I spent hours on that specific problem and still resent it to this day :P.

Re: Ruby 3.2.0 is from another dimension

#252
post #46

Earlier quoted context omitted.

I explored this topic a while ago on my blog [0] In essence, I don't think it has anything to do with elegance, syntax, or "easiness". It's more about timing + origin + corporate adoption: * Python was created in Europe, Ruby was created in Japan - when Ruby gained more recognition in English-speaking world (~2004), Python has already been present and used worldwide for a decade * Ruby was created as a personal, hobb…

For me personally, the killer was that python is typically pre-installed on linuxen while Ruby isn't, and if those environments are controlled or locked down in any way it can be a ballache to get ruby on there. Hence python is the path of least resistance.

This is absolutely a reason to choose Python. I’ve experienced this and made the same choice in the past.

In terms of pre installed options, especially on older systems, Python is the best choice for integrating and extending systems.

Re: Ruby 3.2.0 is from another dimension

#253
post #70

Earlier quoted context omitted.

Revisionist history. Python was huge before Google even existed.

??? Python was huge in the 90's? News to me. No one I knew knew about it until like 2010.

My first real professional programming project was written in Python, using Django 0.96, in 2007. It was at a large shipping company, and "under the radar" - i.e., the "business side" did it, as IT wouldn't support it.

Two years later the project had become an integral part of some critical business processes, and IT had to take it on. They decided to rewrite it in C#. I left the company at that point, and almost a decade later I got a call from a former coworker asking for help to fix the system. It turns out it was basically unchanged from when I left, and the address of the Exchange server that it relied on for auth had changed.

Re: Ruby 3.2.0 is from another dimension

#254
post #46

Earlier quoted context omitted.

I explored this topic a while ago on my blog [0] In essence, I don't think it has anything to do with elegance, syntax, or "easiness". It's more about timing + origin + corporate adoption: * Python was created in Europe, Ruby was created in Japan - when Ruby gained more recognition in English-speaking world (~2004), Python has already been present and used worldwide for a decade * Ruby was created as a personal, hobb…

I don't know about corporate adoption. I started programming around 2008 or so, and the first things I encountered outside of grad school were Ruby and Python. At first I used Ruby because I felt like anything I wrote "just worked", but later I switched to Python because there was just "one way to do things", and also because of NumPy/SciPy/Jupyter.

The thing is, the “one way” is not at all true now. Maybe it was then.

Today’s landscape is better but also very different. And when looking up how to do certain things in Python, Stackoverflow will show you a multitude of options.

The problem for me is that I dislike most of them.

Re: Ruby 3.2.0 is from another dimension

#255
post #216

Any recommendations for (Rails-oriented) tutorials that are current (e.g. Rails 7/Ruby 3). Haven't touched either since like Ruby 1.8/Rails 3

I cannot recommend something specific but I recommend this website https://rubyandrails.info (no affiliation) that has a lot of categories and among those one easy to follow free course could be this one https://rubyandrails.info/youtubes/creatorplatform-xyz

In case you want to stay up to date with what is happening in Ruby world I am curating a free weekly newsletter at https://newsletter.shortruby.com (I took a two weeks vacation but will be back soon with new editions).

Re: Ruby 3.2.0 is from another dimension

#256

Earlier quoted context omitted.

They did apparently manage to make their interpreter figure out where mismatched "end" statements are most likely to be, which was one several serious pain points for me with the language. I don't think the execution model you mention, which results in the absurdity of C style transitive includes polluting the global namespace, will ever be changed though.

> They did apparently manage to make their interpreter figure out where mismatched "end" statements are most likely to be, which was one several serious pain points for me with the language. Searching for a mismatched/missing _end_ is preferable to having a line or block get accidentally unindented and end up still "working" (running) while producing very confusing results. Moving blocks of code in Python requires gr…

> Moving blocks of code in Python requires great care, especially since the editor cannot reasonably guess which scope level the paste should go into.

Even when I was new to python, the only problem I ever really had with this is when I mess up and copy the first line starting at the the first nonwhitespace character so the relative indentation is wrong. When do you ever move a block and not know what scope you want it in? At most, with really long blocks, you fold the more deeply nested blocks before pasting.

> Also, the lack of an _end_ or bracket as with other languages means the editor cannot visually assist with identifying block boundaries.

No, it doesn’t. In practice, editors usually don’t, but they recognize the beginning and ending of blocks, and use it for folding, which means they could insert phantom labels (as editors often use for blame information, inferred type signatures, etc.) to provide informatiom about the block ending (and even align them to indicate the indentation level corresponding to each ending block.)

An existing line of text is not necessary for editors to provide feedback.

Re: Ruby 3.2.0 is from another dimension

#257
post #222

Earlier quoted context omitted.

PHP got popular coz it could get barely code-literate HTML/CSS web designer to write a dynamic app, and host it easily Ruby got popular coz Rails could get barely code-literate graduate to write CRUD app and so it was cheap (famous 15 minutes to blog tutorial) for companies. JS got popular coz, well you ain't got fucking choice on frontend and having your then-frontend JS/HTML/CSS designer be able to also do backend…

I'm gonna disagree with "Ruby got popular coz Rails could get barely code-literate graduate to write CRUD app and so it was cheap (famous 15 minutes to blog tutorial) for companies." That's not what happened, instead Ruby got popular with advanced web developers working in Java who saw that Rails was had better answers than J2EE. If you were barely code-literate graduate you wouldn't recognize that Rails was offering…

> advanced web developers working in Java who saw that Rails was had better answers than J2EE

I was not "advanced" at web development in 2006, but this is exactly what got me to try Ruby. Previously I had been reasonably happy with JSP and Java Servlets, but this Rails thing promised a better way. And it turned out for most of my needs, it was much better.

Also, the Rails Depot book was excellent, even back in the 1.x days (IIRC). It covered enough that you could build a fully working app with sessions, auth, crud, and reasonably abstracted layouts/views. Oh, and because Ruby was "simple", you honestly could start with that Rails book without knowing Ruby.

Re: Ruby 3.2.0 is from another dimension

#258
post #230
post #46

Earlier quoted context omitted.

I explored this topic a while ago on my blog [0] In essence, I don't think it has anything to do with elegance, syntax, or "easiness". It's more about timing + origin + corporate adoption: * Python was created in Europe, Ruby was created in Japan - when Ruby gained more recognition in English-speaking world (~2004), Python has already been present and used worldwide for a decade * Ruby was created as a personal, hobb…

I think Python was conveniently there when teaching was looking to switch away from Java. Each wave of students exiting their institutions with a Python background made Python more popular in the field.

> Python was conveniently there when teaching was looking to switch away from Java. Each wave of students exiting their institutions with a Python background made Python more popular in the field

This, plus what other commentors have noted regarding Pythons early developments in academia, have had multiplying effects on adoption.

The alternatives were C, C++, some "academic" language like Lisp (which I wish had really broken into commerce more), Prolog etc., and eventually Java. Python was at such a higher level that it definitely made more sense as a first language for many people... especially since it was capable enough to be more than just a first language.

Re: Ruby 3.2.0 is from another dimension

#259
post #41

Earlier quoted context omitted.

Same trick as perl5 changed to recently. Not related to re2 at all.

Yes, but there is an interesting clarification here. RE2 has used the "caching" approach documented in the Ruby bug ticket linked for quite some time (since its birth?): https://github.com/google/re2/blob/954656f47fe8fb505d4818da1... It is mentioned only briefly in Cox's article on regex matching in the wild. Look for the word "bitstate": https://swtch.com/~rsc/regexp/regexp3.html I didn't know Perl had implemented t…

OK, now that I have access to the paper, it does very briefly acknowledge RE2:

> while caching is used to accelerate backtracking in Perl and a rare path in RE2.

Although I wouldn't call it rare. It's probably used every time one wants capturing groups and the regex isn't one pass (pretty common) and the input isn't too big (like, say, a line in a log file).

The actual part of the paper that contains the key contribution (memoization but with less space) is fairly dense and I don't have the time right now to look more closely. But it looks like it might be applicable to RE2, Go's regexp package and Rust's regex crate. All three already use already use bounded backtracking (i.e., "full caching"), but if the space usage could be cut back, then it would increase the opportunity of using the bounded backtracker. Namely, all three put a bound on `size(regex) * size(haystack)`. If the search needs something bigger than that bound, then the backtracker isn't used. But if memory usage were instead much less than `size(regex) * size(haystack)`, then the backtracker could be used more often. (Which is a good thing since it's generally faster than a full Thompson NFA simulation.)

Re: Ruby 3.2.0 is from another dimension

#260

Earlier quoted context omitted.

Before Ruby introduced filter_map: res = (1..10).select { |x| x != 5 }.map { |x| x ** 2 } With filter_map: res = (1..10).filter_map { |x| x ** 2 if x != 5 } In both cases, I think the Ruby solution is more readable. Python list comprehensions invert the subject (data) and the verb (action). You see what will be done before you see what the subject is. I would argue that showing the subject first allows easier code re…

> I think the Ruby solution is more readable. I disagree and I’ve used both professionally for about the same amount of code.

And yet, in the production Python codebases I've worked with, list comprehensions are rarely seen. Usually it's typical loop iterations. I wonder why that is?...
Post reply on HN