To Ruby from Python

https://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/

by mariuz • 4 years ago

210 293 4 years ago

boberoni• 4 years ago

Unlike Python, in Ruby… There are a number of shortcuts that, although give you more to remember, you quickly learn. They tend to make Ruby fun and very productive.

I use Python, but have never tried Ruby. The ecosystem for Python packaging is so chaotic that I’ve considered switching.

Any Pythonistas/Rubyists here that could point out some Ruby shortcuts that make you more productive?

batiste2• 4 years ago

It really doesn't... After years using Ruby my mind never managed to parse its complicated grammar.

travbrack• 4 years ago

Any examples? I always found it easy to grok but I'm not at a very high level so I'm curious where it gets hairy.

endorphine3• 4 years ago

What does this mean, concretely speaking? Do you mean you can't remember the right syntax when trying to program in it?

I know its syntax is complicated but I never felt this has caused me trouble. I guess writing a parser for it would be extremely hard, but that's another story.

DonHopkins6• 4 years ago

Guido van Rossum put it this way:

"Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils)."

https://www.artima.com/forums/flat.jsp?forum=106&thread=1461...

Then I decided to have a look at Ruby on Rails, just to see what I could learn from the competition. I watched two fascinating movies, but they went a bit too fast to really understand what was going on, and there seemed to be a fair amount of sleight of hand in the examples (a lot of default behavior that just happens to do the right thing for the chosen demo). Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils). I believe I heard Greg Stein say recently that if you are really good in Ruby, CSS, HTML and SQL, you can produce great websites quickly with Rails -- but if you don't, you produce lousy websites quickly (just like with PHP).

I quoted Guido's point about Ruby syntax 15 years ago in this lua-l discussion about Lua, Python, Lisp, and Ruby syntax, and the importance of not naming programming languages after naughty bits:

https://lua-l.lua.narkive.com/Ly6vITFE/justify-introducing-l...

Stephen Kellett 15 years ago
[...] A little story to explain why in house languages are bad:
Years ago I worked for a company that had an in-house language (90-94) called Lull. [...]
(*) Come be real, who uses Lisp for commercial projects? Great language, but too many parens and no one uses it. Its the equivalent of Esperanto. So much promise, so little delivery. [...]
Don Hopkins 15 years ago
I read your message about "Lull" and a Dutch guy sitting behind me laughed out loud when I said the name of your language. (My dictionary says "lul" means "prick" or "cock" in slang, so it's a bit more explicit than "dick"!) This just goes to prove that how you name a language is important (but not as important as designing the language so it doesn't suck...)!
On the "too many parens" excuse for disliking Lisp: so why do you use XML and HTML? They have TWICE the number of parens, which are pointy instead of rounded, but lots of people seem to use them anyway. So "too many parens" is just a convenient and shallow excuse for disliking Lisp that avoids examining the real issue.
The real problem that many people have with Lisp is because it's perceived as a homosexual programming language, which causes unconscious cognitive dissonance, so people have to grasp for more socially acceptable reasons for disliking the language (like "too many parens"). Nobody wants to just say "I hate Lisp because it sounds gay", so instead they say "too many parens", even though most other languages suffer from too few parens, and are much less readable than Lisp because of their insane hierarchies of precedence rules. Programming tips 101: ALWAYS use parens even if you're sure the precedence rules will make your expression do what you want, because 1) other people need to be able to read the code and 2) you may be wrong. Drop any copy of K&R on the table so it lands on the spine and opens to a commonly used page, and I bet it opens on the table of precedence rules, because that's the page everyone always turns to. Lisp code never suffers from this problem.
The first thing most typical homophobic Americans think of when they hear the word Lisp is the gay stereotype of speaking with a lisp, so it unconsciously terrifies them. And the fact that "lambda" signifies unity under oppression, and is used as the gay/lesbian/bisexual/transgendered symbol only reinforces that impression: http://en.wikipedia.org/wiki/LGBT_symbol#Lambda ...And then there's the purple cover of Structure and Interpretation of Computer Programs, with the two gay dudes on the cover.
Anyway, millions of people program in Lisp every day with C syntax, but they just call it JavaScript, and suffer without macros, because of the inferior C syntax.
-Don
Fabien 15 years ago
@Don: your theory is fine for US people, but lack of love for Lisp is also observed in non-English speaking places. I learned quite recently that the word "lisp" also had another meaning than "nail clippings in oatmeal".
My guess would rather be that Lisp doesn't encourage common idioms and development approaches across people and teams, which makes it hard to:
- get into code you didn't develop
- work with more than a couple of teammates
- find a library that addresses your problem
- if you have several problems and find a lib to address each of them, get those libs to work together despite their incompatible macro hacks.
That, and Lisp took waaaay too long to acknowledge its platforms. It pretended to be OS independent, which meant many non-standard, non-compatible ways to interface with OSes, and therefore, plenty of platform issues as soon as you wanted to port or deploy a non-trivial solution. As written somewhere by Paul Graham, "Unix has won, get used to it".
Don Hopkins 15 years ago
Now that's some spot-on criticism of Lisp, much better than the "too many parenthesis" excuse that gets thrown around by linguistic homophobes suffering from cognitive dissonance.
I'm still waiting to hear somebody claim that they refuse to use XML and HTML because they have too many parenthesis (angled brackets). Or for somebody who hates Lisp's parenthesis but tolerates XML and HTML to explain why <foo>bar</foo> is easier to read than (foo bar).
Perl and C++ have way too much punctuation in general, and Ruby made a cargo cult design mistake in imitating Perl syntax. I agree with Guido van Rossum's comment on Ruby: "I find Ruby's syntax grating (too many sigils)". http://www.artima.com/forums/flat.jsp?forum=106&thread=14614...
Wow, in what language does lisp mean nail clippings in oatmeal, and where can I get some of that stuff? It sounds delicious!
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -- Jamie Zawinski, on X-Windows toolkits.
-Don

[...]

Fabian: http://en.wikiquote.org/wiki/Larry_Wall look for "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in")

[...]

Hamuko• 4 years ago

You should probably try some 10-minute Ruby tutorial to see if the syntax doesn't completely scare you off.

Gordonjcp• 4 years ago

When I looked at Ruby (admittedly a long time ago now) everything was 10 minute videos. Is there any actual useful material on it now?

cycomachead5• 4 years ago

More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at.

But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity".

One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same.

Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.

ptx3• 4 years ago

For smallish scripts, I really like Ruby's backticks for easily executing shell commands.

Executing external commands is pretty convenient in Python these days, now that we have subprocess.run [1], and passing the command as a list rather than through the shell seems a lot safer.

Doesn't backticks open up the classic command injection issues (i.e. the same kind problem as SQL injection with non-parameterized queries) unless you're extremely careful to manually apply proper quoting in every single case?

[1] https://docs.python.org/3/library/subprocess.html#subprocess...

oezi• 4 years ago

I think with "shortcuts" they mean things such as $1 (first match group of a regex) or =~ (regex match operator).

I general I rarely feel like I am unproductive in Ruby (or bogged down in boilerplate typing).

cycomachead5• 4 years ago

In that case -- I definitely agree Ruby usually gets out of way. It's often my go to for hacking on something, unless it's data science-y.

I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend.

Many of these things are also incredibly easy to abuse - but they have their places.

[1] https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...

transfire• 4 years ago

I’m not sure what “shortcuts” the author is referring, but perhaps…

    x = y || z  # if y is falsy x = z

    x = f ? y : z  # ternary operator

    %w{one two three}  # array of words

And so on.

endorphine3• 4 years ago

Also:

    x ||= 1
    x &&= 1

and the various built-in methods from Array, Hash, Enumerable, String etc.

intuxikated• 4 years ago

These all exist in python, though you use or/and instead x = y or z x = f and y or z you can also use inline if/else x = y if f else z 3rd one just seems like an array of strings? ["One", "two", "three"] Not needing quotes for single words saves some typing tho.

pmontra3• 4 years ago

I loathe most shortcuts: too many things to remember and usually cryptic syntax. Maybe that's because I have to be a polyglot developer (Elixir, JavaScript, Ruby, Python) and I can't remember all the tiny details of each language.

If you want to give a try to Ruby, get to understand blocks quickly. Instead of

  for item in list:
    work_on(item)

which would work (with a closing end and no : ), the idiomatic way is

  list.each do |item|
    work_on(item)
  end

or the one liner

  list.each {|item| work_on(item)}

Check also map, select, each_with_index, each_with_object, etc. Blocks are fundamental to Ruby for reason that only practice can tell.

greenpeas8• 4 years ago

Or with numbered parameters (since ruby 3.0)

  list.each { work_on(_1) }

jjgreen3• 4 years ago

Since "work_on" takes a single argument which is a instance of Item, you'd be better off implementing it as an instance method, so item.work_on. Then you have the even more compact

    list.each(&:work_on)

shaicoleman2• 4 years ago

There are thousands of little things that make Ruby nice. They all add up to a more enjoyable experience. I'll give you one tiny example:

Python:

    from datetime import date
    if date.today().weekday() == 5:
      print("It's Saturday")

Ruby:

    require 'date'
    puts "It's Saturday" if Date.today.saturday?

ouija• 4 years ago

I prefer the Python code here. The import is explicit, so if you want to know where "date" comes from, that's easy. In a modern IDE I don't write imports manually anyway.

You could write it as a one-liner in Python as well, but I would prefer not to.

  print("It's Saturday") if date.today().weekday() == 5 else None

That the Python library doesn't define constants for days is unfortunate, but not a limitation of the language.

BiteCode_dev5• 4 years ago

I can't fathom optional parenthesis. In this code it makes it very hard to know if today is an attribute or a method without knowing the context, meaning I can't scan the code, I have to read it carefully.

politelemon• 4 years ago

If I only used Ruby I'd probably prefer the Ruby example. As someone who jumps across many languages, I prefer the first. I found Ruby's approach to things was at many times too clever, to the point of becoming unreadable and cryptic. Python prefers clearness over cleverness.

AnonymousPlanet• 4 years ago

How do you know which 'Date' your are using. How do you know it's the one from 'date'?

That's like using * imports in Python which is a huge pain once you done even minor refactoring.

tzs• 4 years ago

I think every language I've used has annoyed me in how it handles dates and times.

I've been tempted several times to sit down and repeatedly read Dershowitz and Reingold's book "Calendrical Calculations" [1] cover to cover until I thoroughly understand it, and then write my own date and time library and port it to every language I use.

That would mean that when I learn a new language I'd have to take some time to port my date and time library, but looking at the languages I already know that would have been less than the time it took me to find and learn to deal with the quirks and annoyances in their libraries. I see no reason to believe that this will be different for any future languages I decide to learn.

Yes, I know this would be annoying to whoever has to take over my code when I'm gone, but I tend to stick around on projects until they reach end of life and so there almost never is anyone that comes after me.

[1] https://www.amazon.com/Calendrical-Calculations-Ultimate-Edw...

bsaul• 4 years ago

From what i've seen ruby is definitely on the downward slope regarding adoption and python has become a defacto standard in some fields. Its ecosystem is much better in pretty much every domain, so i don't think there's any point switching at the moment, honestly.

jillesvangurp• 4 years ago

I've used both. I slightly prefer python over ruby. But I haven't used either recently.

Ruby's strength is internal DSLs. Python's strength is that it's simple to pick up for people. There's a large community of people that are not primarily programmers that use it. The reason for this is that it is a very easy language to get started with.

Both share the same problem: they are weakly typed scripting languages. Both have in common that type annotations have been retrofitted to the language. But it's an uncomfortable and awkward retrofit in both cases and their respective communities seem to regard using types as an optional and inconvenient thing. Ruby with types of course exists. E.g. Crystal is nice apparently. But I've not really seen that used in the wild.

Python is enormously popular; ruby's popularity seems to have declined a lot. I know a lot of former Ruby programmers that have moved to different languages and only a handful that still use it. It's not an obvious language to pick up for younger programmers. There are so many other languages to choose instead.

IMHO the key innovation in language design in recent years has been type inference. This has lead to a new breed of languages that keep most of what made python and ruby popular: the ability to write code with a minimum of verbosity but without sacrificing type safety. Whether you use Kotlin, Typescript, C#, or even Java: they have type inference now and it reduces the verbosity that comes with having types. Scripting vs. compiled languages is much murkier these days where scripting languages have compilers or transpilers and linters and compiled languages have REPLs and all languages can now run in a browser via WASM anyway. The distinction is just not that relevant anymore.

I write a lot of Kotlin, have dabbled a bit with typescript and I don't think I'll ever use languages without proper types again. Just not worth it for me. I don't see the value of not having a good typing system. Kotlin is interesting to me because internal DSLs are a thing with it; just like they were a thing with Ruby. And it can use javascript as a compilation target. Ruby has a slightly nicer syntax for DSLs than Kotlin for internal DSLs. But I don't mind curly braces and having strong typing enables a lot of good stuff. Like proper IDEs with refactoring, autocompletion, auto-fixes, etc. which are all very nice things to have in a DSL.

I use Kotlin DSLs for writing CSS, HTML components (we use kotlin-js), writing elasticsearch queries (I maintain the multi-platform kt-search library), gradle build files (which uses kotlin script), and quite a few more things. IMHO, it could do a lot of things that python is popular for as well.

keithalewis• 4 years ago

Good thinking. You might have to learn something new.

davidthewatson2• 4 years ago

I've been using python for two decades and ruby exactly one decade ago for a couple years.

Your comment on packaging is interesting.

My perspective is that packaging on ruby was in nearly the same state ten years ago as python is now.

My team switched ruby package managers several times during the ruby work and none of them ever worked reliably and was a regular root cause of fragility in our builds.

I hope that ruby packaging has settled in that time while python has the same kind of cultural noise that afflicted ruby during that period. Popularity has downsides. Political packaging wars is one of them.

I'm old school enough that I stick with tried and true pip, venv, and .env and its ilk.

There was a long battle in downstream packaging for a while that I just didn't want to be involved in having seen the same thing in ruby.

FWIW, if I were you I'd look at crystal, elixir, or nim. I was very productive in ruby but the near constant battle of wrestling with DSL's that are not concomitant with their parent is, IMHO, to be avoided. I've seen more than one team fall prey to that trap. Caveat emptor - pick your DSL's carefully.

kawsper• 4 years ago

What do you mean by switching packaging managers? Ruby uses Rubygems and Bundler to manage packages.

Are you referring to Ruby version managers that manages different versions of Ruby (rbenv, rvm, asdf, etc.)?

nickjj2• 4 years ago

Any Pythonistas/Rubyists here that could point out some Ruby shortcuts that make you more productive?

It depends on what you want to do.

If it's building web apps there's Ruby on Rails, which is written in Ruby. In my opinion there's no alternative to this in Python. Sure there's Django but it's not the same even though both are considered batteries included web frameworks.

One nice thing is you'll find both Python and Ruby SDKs for a ton of third party services (like Stripe, etc.). That goes a long ways for building things quickly and with confidence.

Ruby's package manager is also a lot better IMO. It supports proper lock files out of the box and everyone uses gems with bundler. In Python it's a mix of pip, pipenv, poetry, etc. all of which have their own unique issues. With Ruby I never felt like I had to battle this aspect of the language. You just bundle install what you want and creating gems is the same process.

lloeki3• 4 years ago

If one wants to get into Ruby, please stay away from Rails as a first step into Ruby-land.

Look into Rack and Sinatra first, then Rails. Even if it's a short trip it's going to be worth it.

MatthiasPortzel3• 4 years ago

Sure there's Django but it's not the same

Could you elaborate on this? I’ve used both Django and Rails and in my mind they’re direct parallels to each other. For example: in Rails you write migrations and then it generates a schema.rb, and in Django you update your model schema and then it generates migrations.

They have very different philosophies, sure (reading the Rails manifesto made that clear), but from a technical standpoint they have pretty good feature parity.

z9znz4• 4 years ago

Here's a rough list of benefits of Ruby compared to Python. It's not well organized and the examples are difficult to show in a comment box, but I have pages of notes of why Python is frankly a horrible language compared to Ruby.

Every expression returns a value, so you can assign the result of an if/else or switch statement to a variable. Within your conditional clauses, you don't have to repeat assignments or return values. If the logic goes down that branch, then the last value in that block is the return value.

This also means you don't have to have explicit 'return' statements in functions. Whatever the last value of the last expression is, that's your function return value. You can use an explicit return if you want to exit the function early, however.

Ruby has a switch (case/when) statement. Python finally has this in 3.11 I believe, but it took forever to get.

Hash.dig(). If you have nested hashes (dicts), you can myhash.dig(:top_key, :lower_key, :even_lower_key)

In objects, you can control which attributes can be read/written via attr_reader, attr_writer, attr_accessor. So you can make an attribute have a default getter if you use attr_reader :some_attribute, and then you can write your own setter if you want to control how it gets assigned to. You can even simply not have a setter, so you can effectively make an attribute read-only.

Clean, simple hash initializers: h = Hash.new { |h, k| h[k] = { age: 0, nickname: k } }. So now you can just start assigning to values in h like h["bob"][:attr1] = 28, and now h["bob"] refers to a hash with age 28 and nickname "bob". Yes Python has defaultdict, but it's an extra thing you have to use, and it's clumsy compared to the Ruby approach.

Hash (dict) merging: It's a mess in Python. In ruby it's just h1.merge(h2), or even h1.merge(key_to_update: 123). And you get a new hash as the result. Or you can merge in place with merge!(), changing the original.

Function names with ! and ? greatly simplify function naming (and improve readability). So instead of is_foo(), you just have foo?(). And if you want to indicate that you are doing something destructive, you name it foo!(). This is a common pattern in Ruby libraries, and you often have functions which return a new value and functions with the same name followed by ! which modify the input value. String.strip() returns a new string without leading/trailing whitespace, while strip!() modifies the input string to the same effect.

Python's list comprehensions are arguably ugly and messy and harder to visually parse when reading. Ruby has consistent ways of doing operations on collections. This would take a full page to show examples.

Copying and pasting code in Python often results in new code which is indented wrong (in the wrong scope), and which you must manually fix. This is not a problem in Ruby, since there are actual 'end' statements. Editors know how to properly indent what you paste.

Safe navigation. myobj&.someattr&.foo will give you the value of foo or nil if myobj or someattr don't exist. You have to use ifs to do this in Python.

Array flattening. nested_arrays.flatten(). But in python, you have to use something like list(itertools.chain(*arr)), but that fails if the first element of the list is an int (not an iterable).

Gettings hash/dict keys. In Ruby, you just do myhash.keys and you're done. But in Python there are several ways to get the keys, none of which is as simple and obvious as just keys().

Not allowing typos to silently fail. With Python, you can take an object and assign a value to a non-existent attribute. You might do this accidentally if you have a typo when trying to set an actual attribute: myobj.first_Name = "bob". Python will happily do that, and you'll later debug and wonder why myobj.first_name == "" (and then notice that you have this similarly named attribute now called first_Name). Duh. I guess you could say it's convenient to be able to do this, but it's more a footgun. Ruby will bark at you if you try this.

List sorting in Python is in-place, so you can't non-destructively sort and get the sorted list returned. In Ruby you have a choice. sort() is non destructive, and sort!() is in-place.

I've got more, but this is enough.

maligree• 4 years ago

Using the sorted() built-in returns a new sorted array. Getting keys from a dictionary is literally just calling dict.keys(). Sorry, but I don't think you've used Python enough to offer lists like these.

AnthonBerg• 4 years ago

I like the RubyMine IDE a lot. The code intelligence is very good – it’s so good that it tends to teach you Ruby as you use it. Code intelligence as in code navigation, easy access to documentation on the fly, refactoring, code style suggestions.

The same goes for the tooling integration. It works with most of the development tools you’d use with Ruby and captures the integration pretty well in a UI and associated workflow.

Link for your convenience: https://www.jetbrains.com/ruby/

(No affilition except being a paying user.)

gls2ro11• 4 years ago

I am using both Vim and RubyMine and I strongly recommend RubyMine for anyone starting with Ruby.

Having the possibility to have a Go to definition for almost any method is great and most of the gems have great code comments with a lot of nice examples.

When I teach people to learn Ruby (I do this sometimes) among the first things I do is I explain to them how to open a gem, look at the source code, read it and then try to use it.

I cannot thank enough the maintainers of the most popular gems for doing such a great job in having great ruby code and good in-file documentation.

scotty792• 4 years ago

For me there wasn't ever question of "How?" only "Why?".

One time I landed on Ruby project and I didn't have any trouble fixing bugs and implementing minor functionalities without really learning Ruby only knowing some Python.

cortesoft3• 4 years ago

I feel similarly about python. I use ruby all the time, but can do things in Python just fine, especially if I have an existing code base that I am working on.

scotty792• 4 years ago

Tensorflow? Numpy?

No idea what else might be the reasons to learn Python when you know Ruby.

ptx3• 4 years ago

You can read docs on the command line (with the ri command instead of pydoc).

I've been using Python for a long time, but somehow I never learned about pydoc. It looks like a pretty handy tool!

helge9210• 4 years ago

On the surface, Ruby and Python are mostly equivalent languages.

Internally, memory management is done differently, for example.

Now add a magic of Ruby on Rails and ActiveSupport to one side and machine learning toolsets to the other.

viraptor• 4 years ago

Not just on the surface. See the ruby to python bytecode compiler: https://github.com/whymirror/unholy

DonHopkins6• 4 years ago

“Python is bash for mathematicians.” -Michael Slavitch

BiteCode_dev5• 4 years ago

Python is used for Web dev (Django), geography (all SIG), system components (part of Unix), pen testing (E.G: scapy), 3d modeling (Blender), sysadmin (ansible), etc.

I've been coded mostly in Python for 15 years and using the scientific stack is a very small parts of what people pay me of, if they ever do.

DonHopkins6• 4 years ago

You're misinterpreting that quote as criticism of Python instead of praise. He's not saying that's the ONLY thing that Python is good for.

I've also been programming in Python extensively for at least 20 years, including web application servers like Zope and TurboGears, embedding and extending apps and tools with the Python/C API and SWIG like SimCity, Gnu Radio, Big World MMPORG, robotics, simulations, Blender, Houdini, user interfaces like Tkinter and PyGTK and Sugar, XML processing, OLE integration, BeautifulSoup web page scraping, image processing, character animation, speech synthesis, system administration, infrastructure as code, machine learning, etc.

Python is of my primary programming languages, and I love it.

It's a GOOD thing that mathematicians use Python instead of Bash!

zem3• 4 years ago

as someone who has used ruby for years, and more recently got a job working in python, I think the most significant difference between the two languages is how they handle imports.

in python every file is also a module, and all imported symbols are namespaced within that module (unless you deliberately use "import *" to bring them into the current module's namespace). so you can define function foo in module bar and use it via "import bar; foo.bar()".

in ruby, modules/namespaces and files are two entirely orthogonal concepts; you define a module by enclosing code in a "module Foo; ...; end" block, and any file can open up the same module and add stuff to it. when you import a file it adds everything within it to the current global namespace, which makes it really hard to read a piece of ruby code and see where everything within it was defined.

for the most part where ruby and python differ I prefer the ruby way, but I feel like automatically namespaced imports is something python got right, and was a really big miss for ruby.

typeofhuman• 4 years ago

so you can define function foo in module bar and use it via "import bar; foo.bar()".

Wouldn't this be "import bar; bar.foo()"?

86J8oyZv• 4 years ago

In Ruby it’s “require” rather than “import.” But it would be more like “require bar; foo()”.

However, Ruby does have auto-loading conventions. So you could define “module Baz{ module Bar { def foo end; } }” in “baz/bar.rb” from the root of your project. You should then be able to call “Baz::Bar::foo()” from any other file in your project structure without a “require” at all. This is not standard Ruby IIRC, but Rails and other frameworks use it.

heartbreak2• 4 years ago

Yes, it looks like OP had a typo.

zem3• 4 years ago

right, that was my mistake

lloeki3• 4 years ago

The tradeoff is that you don't get to have open classes with a module oriented approach.

Shameless plug: toyed with the idea of imports and "packages" in Ruby some time ago. Recent facilities in 3.1 (or 3.2?) could make the implementation even easier.

https://github.com/lloeki/pak

https://github.com/lloeki/ruby-package

IIRC there's an issue somewhere at bugs.ruby-lang.org about that

EDIT: OMG 8 years ago! /me screams

dragonwriter6• 4 years ago

The tradeoff is that you don't get to have open classes with a module oriented approach.

A module oriented approach could still have open classes, and if you did an imported module could still mess with classes in other imported modules (it would just also have to import them.)

In fact, you can set variables in other modules and members (including methods) of other classes this way in Python.

zem3• 4 years ago

i like that! it definitely makes things cleaner in terms of being explicit about where everything comes from.

mountainriver6• 4 years ago

Agree Ruby code is super hard to understand, this seems largely overlooked by the community

gls2ro11• 4 years ago

(out of curiosity) What is hard to understand about Ruby?

tomc19854• 4 years ago

I have never had this issue, other than with some of its more complicated constructs (like class << self).

And amongst the community, this is not a complaint I hear very often.

I still think of Ruby as the language that maps closest to my thought process when programming.

What is troubling for you?

atmosx• 4 years ago

It can be, more than other languages, but doesn’t “have” to be. Complex code is a smell.

ufmace• 4 years ago

It's a possible smell in Ruby all right. Ideally, every file has its code in classes or modules that match the file name, so require 'foo' brings in the class Foo and nothing else. But it's possible to do some really ugly hacky stuff, so it more becomes please don't actually do that in a large production codebase.

Python's default of namespacing imports is nicer all right, though I've seen a decent amount of Python code in the wild that has a dozen import * at the top of every file so that grep is the only way to find out where a function is actually defined, just as bad as Ruby.

choward2• 4 years ago

Ruby modules and requires effectively just concatenate a bunch of files that have globals in them and have nothing to do with real modules.

jonnytran4• 4 years ago

This is simply false. Ruby modules are first class. They're objects that you can pass around like any other object. You can put them in a local variable. You can define methods on them. You can do metaprogramming using them. You can build classes by mixing modules together. You can create modules (and classes) at runtime. Many things that need to be built-in in other languages are just a library in Ruby.

Files and modules in Ruby are two distinct things. While Python makes files one-to-one with modules, Ruby allows you to define as many modules as you like in a file, zero or more.

It's true that if you define a constant at the top-level of a file, it uses the global namespace.

By convention, if you have a file named `foo.rb`, you'd write:

    module Foo
      # Code here
    end

and it's equivalent to what's done in Python. But it also has all the other features.

vault2• 4 years ago

deleted

greenpeas8• 4 years ago

What do you mean?

When tested for truth, only false and nil evaluate to a false value. Everything else is true (including 0, 0.0, "", and []).

In ruby only `false` and `nil` evaluate to false values. 0, [], "" all evaluate to true when used in `if` statements. In python (just like in C and JS) many things evaluate to false (including 0, 0.0, "", and []).

vault2• 4 years ago

Ah sorry I read "Unlike Ruby, in Python" instead of "Unlike Python, in Ruby"

thih9• 4 years ago

This page is old [1], is there any reason or context regarding why it is interesting now?

[1]: Archived in 2006: https://web.archive.org/web/20060925032432/https://www.ruby-...

Kwpolska• 4 years ago

The page has been slightly changed since then, but it is still quite outdated. Python 3.6 (2016) has formatted strings, and new/old-style classes thing isn’t relevant at all since Python 3, but wasn’t that much of a deal with Python 2 at the end of its lifetime (~everything was new-style by then).

sitkack• 4 years ago

Ruby is a neat language that I don’t know very well. Blocks are nice. The pattern matching in Python 3.10 compels me to stay.

wodenokoto• 4 years ago

There’s only one kind of list container (an Array), and it’s mutable.

What are the other kinds of list containers in Python? I only know of `list()`/`[]`, but maybe I just don’t realize that some other thing I use is also a list container.

uranusjr• 4 years ago

I’m guessing they’re implying tuple, it’s pretty common to consider that type as “immutable list” (although personally I very much dislike this categorisation)

masklinn• 4 years ago

although personally I very much dislike this categorisation

It’s not a categorisation, it’s literally the nature of the thing in Python. And while I agree that it’s distasteful the error was in the original introduction.

As things are, python tuples are immutable sequences with all that implies. They are iterable, indexable, sliceable, …

kevin_thibedeau• 4 years ago

array.array

zbentley• 4 years ago

array.array, as another commenter mentioned; numpy.array is popular for performance-oriented code (but not in the stdlib); collections.deque; queue.Queue; tuple; struct (though it's a bit of a pain to make one behave in an array-like way and is usually better to use array.array); heapq; and multiprocessing.shared_memory.ShareableList.

Out in pypi there are many additional esoteric list-like data structures: bitarray is one of my favorites, and there's also awkward-array, cyarray, tinyarray, fixedlist, blist, bigarray, sortedcontainers, and many many more.

mahathu• 4 years ago

I love Python and use it pretty much anywhere I can, especially as it's ubiquitous in scientific computing. Is there a good reason to switch to Ruby except to try something new?

nixpulvis3• 4 years ago

I would claim that Ruby as a language is much nicer to use, however it has less support for data science and other things which Python is much more well known for. If you ported over some libraries, you might find you like Ruby more in the end.

doix• 4 years ago

My biggest gripe with Ruby is how much syntax is optional and the "accepted" conventions by the community are to leave out a lot of optional syntax.

The worst offender (in my opinion of course) is leaving out of empty parentheses on method calls. It makes it impossible to know if something is a property or a function. The argument is that it doesn't matter if it's a property or a function, but I feel like it makes it very difficult to reason about performance. If I know something is a function, I'll look at the function and see what the performance implications are. Where as if something is a property, I assume it's "free" to access. This doesn't hold when reading Ruby code, and I basically have to look up everything all the time.

Just my opinion as someone that had to switch between python/ruby/perl to maintain tools written during different decades.

linuxftw• 4 years ago

As a non-ruby user, from my POV ruby is primarily related to webapps. While it's possible to use it for other types of software, nobody really does, except possibly people that already maintain large codebases of ruby webapps.

nixpulvis3• 4 years ago

The usual-style comments on the line(s) above things (instead of docstrings below them) are used for generating docs.

This is another thing about Python that I find very unsettling and wrong.

winstonsmith2• 4 years ago

[In Ruby] There is good support for functional programming with first-class functions, anonymous functions, and closures.

This seems like a blatantly false claim to me since as a Python programmer forced to use Ruby for Sketchup, I have been frustrated by the lack of first-class functions in Ruby.

tomstuart4• 4 years ago

I’m interested to learn what “first-class functions” means to you. Ruby has both `Proc` and `Method` which would appear to qualify. Is your frustration that you can’t `def foo … end` and then use bare `foo` to refer to it as a value (vs invoking it)?

winstonsmith2• 4 years ago

My frustration is that you can't pass foo as an argument to another function.

sinsterizme• 4 years ago

This is very good timing for me, I just left my python dev job and am starting a job where they use Ruby. I’m very excited to be using Ruby again, it’s a much nicer language to use for a variety of reasons I can’t possibly enumerate. Ruby’s stdlib and surrounding documentation is pristine, I vividly remember being appalled when trying Python for the first time and thinking where the rest of it was. The major issue I find with Ruby (and that I saw mentioned elsewhere in this thread) are imports / requires, which is much too magical in Ruby; Python’s import is way saner

fny4• 4 years ago

Ruby's imports aren't magical by default. Autoloading frameworks make them so.

khaledh2• 4 years ago

The fact that ruby makes this possible means the community will take advantage of it, to the point of abusing it sometimes. This hurts understandability of the code base. Too many times I would open a ruby code base and spend significant amount of time tracing where things are defined (mostly relying on suboptimal searching) because of the lack of explicit imports/requires.

byroot• 4 years ago

Even without an autoloader, Ruby has a single global namespace, so you have access to everything that has been required at any point from anywhere.

If anything autoloaders enforce that constant names match filenames, making it easier to locate the source.

xavdid• 4 years ago

Ha, I just did the same thing. It's definitely a bigger shift than I expected!

I think the biggest difference so far is the quality of dev tooling. Python's native type system has enabled a lot of really good editor functionality. Ruby has Sorbet, which seems good, but it's _much_ slower and more cumbersome. After a save to fix a red squiggly line, there's a 5 second delay before the typechecker / linter figures out the code has updated, run, and updated errors in-editor (note: this could be due to the size of the repo, but it's still a pretty tough experience)

In the company codebase it's pretty well set up and VSCode come pre-configured. But yesterday I tried setting up a little ruby project on my personal machine and couldn't figure out the combination of extensions to make basic auto-complete and jump-to-definition functionality work at all. To their credit, Microsoft has made Python development incredibly straightforward by giving a One Best Way To Do It and making sure there's good LSP support.

Python has its warts for sure, but I've grown to really appreciate the language and its ecosystem.

lloeki3• 4 years ago

For some reason it reminded me of _why's unholy:

https://github.com/devyn/unholy/blob/master/README

You know, it's crazy that Python and Ruby fans find themselves battling so much. While syntax is different, this exercise proves how close they are to each other! And, yes, I like Ruby's syntax and can think much better in it, but it would be nice to share libs with Python folk and not have to wait forever for a mythical VM that runs all possible languages.

tomc19854• 4 years ago

That's funny.

In a previous job I was the biggest Ruby supporter on a team of Pythonistas. To show them how similar the language was I translated a couple of their scripts from Python to Ruby... it was surprisingly easy and the linecount was about the same

teddyh2• 4 years ago

That is all good and well, but which was easier to read and debug?

mark_l_watson2• 4 years ago

I loved coding in Ruby. I also wrote a Ruby book for Apress, my last book for a major publisher before starting to self publish on leanpub.com/u/markwatson

Two factors made me leave Ruby behind: I am somewhat known for Common Lisp, and so CL jobs would come my way. Also, in the last 8 years, a huge amount of my work has been in deep learning and Python wins there.

Anyway, Ruby was designed to make programmers happy, and it is a big success at that.

Hackbraten• 4 years ago

I tried for many years to be happy with Ruby.

Ended up leaving it behind because more often than not, when I revisited a Ruby codebase after a while, Bundler would complain and tell me that I’m supposed to run `bundle install` something, and sure enough, doing just that sent me into a rabbit hole of errors.

Taikonerd• 4 years ago

If you switched to Python, then you probably traded your `bundle install` errors for `pip install` errors ;-)

gls2ro11• 4 years ago

I am sure it will not bring you back :) but in case others might read this and have the same issue the solution is to config bundler to install the gems locally inside a project folder (I usually go for ./vendor/bundle) and the add that to .gitignore

This way if you work with multiple projects each using different Ruby versions and different gem versions you don't keep to keep reinstall the gems whenever you switch the directory.

mpyne• 4 years ago

For what it's worth that's also been my experience with some Ruby projects I have. Usually bum-simple Jekyll web sites in response to a dependabot warning.

It's almost always a fight to get going again and it seems so needless. Like just reinstall the gems from scratch if you need to, jeez, this isn't even a CI I don't need the gems to be literally identical to what was here a year ago, I just need "bundle exec jekyll serve" to actually do something...

That all said I still like Ruby as a language, it brings the good stuff over from Perl while being as expressive as Python and pretty damn fast to boot. And I recognize Python also has similar dependency challenges. But this is very irritating.

jspash• 4 years ago

Leave a javascript project for more than 2 weeks and you'll get the same thing.

weaksauce2• 4 years ago

as an other perspective this happens because you are not pinning the versions correctly. your gemfile should have an explicit version of every major gem you use and the gemfile.lock should have the resolved dependencies already made out and committed. you should also have a particular version of ruby in mind and locked with a .ruby-version file in the project root. This should work flawless in all but the oddest edge cases.

brudgers• 4 years ago

Genuinely curious, would Ruby be your desert-island-with-only-one-language language?

If not, what would your language be?

Of course, you could - at least in theory - take any language and implement some other in it...so I guess maybe there’s a question of is it easier to write Lisp in Ruby or Python in Lisp, etc.?

x86x872• 4 years ago

probably you would want C on a desert island. you could write your own ruby or python or anything in it.

mark_l_watson2• 4 years ago

That would be Common Lisp.

itake9• 4 years ago

Anyway, Ruby was designed to make programmers happy, and it is a big success at that.

I switched to golang from ruby and I definitely don't miss the ctrl+f hunts to figure out the source code of functions in ruby programs. its even worse when dynamic programming is used to create 'helper' methods (e.g. `{attribute_name}_changed?`) that you have to read through lines and lines of code to find anything.

jshen2• 4 years ago

I find most things by jumping into pry at a break point and inspecting it. Works really well, but isn’t something that’s common in other languages so people don’t think to do it.

jkogara• 4 years ago

I use ctags that are rebuilt in the background on each commit or pull, makes find source code of definitions trivial.

msbarnett5• 4 years ago

If anyone very finds themselves hunting around for a method definition like this,

    method(:blah_changed?).source_location

is your new best friend.

weatherlite2• 4 years ago

It's not like Golang doesn't come with its own set of frustration. Several things I miss from Ruby/Rails

1) An interactive shell. It's sometimes super convenient to run Rails c and just call whatever worker or model method you want...not really doable in Go.

2) Ruby's Enumerable. Even with Generics, manipulating and finding elements or sorting collections in Go is much harder and more verbose than Ruby. In web apps we do only this most of the time.

3) Rails. I just miss one big batteries included framework. No such thing in Go afaik.

4) Expressiveness. There is no ternary operator in Go for example, as the philosophy of Go is to reduce language keywords as much as possible. As a result you generally have more code and are less expressive. While there are pros to this I personally see this as more of a con.

rco87865• 4 years ago

This is my least favorite part of Ruby (coming from a Ruby fanboy) and I actively avoid patterns that make methods hard to find when writing it. Though I think I’m probably in the minority here.

mountainriver6• 4 years ago

Really the only reason to use Python is ML, but that is the future of everything so….

goatlover3• 4 years ago

Really the only reason to use Python is ML

Not the other scientific and statistical libraries?

but that is the future of everything so….

So is fusion and flying cars. Maybe one day AGI will be here, but I doubt we humans will be using Python ML libraries at that point.

mountainriver6• 4 years ago

In the next 5-10 years, ML will likely write most of our code and that will almost certainly come from Python

x86x872• 4 years ago

nah. ML is not the future of everything. in fact I believe that as things are going to evolve ML as we see it today is going to be only a tiny fraction of what is going to be used

mountainriver6• 4 years ago

yeah but the ML of tomorrow will write all of the code

revskill• 4 years ago

Ruby eventually failed in term of quantity of developers, means OOP will eventually died. It's not Ruby's fault, it's just the failure of OOP in general.

My prediction, in about 4 years or more, OOP is just an abandon concept for all programmers.

tomc19854• 4 years ago

So, C++ and Java have just a couple of years of life left?

damagednoob• 4 years ago

Not too mention C#, Python and for some, Javascript.

gls2ro11• 4 years ago

Mind you that (let's say) the modern concept of OOP was invented around second part of 60s (with Simula I think) and I think functional a bit earlier maybe in the beginning of 50s (with LISP I think).

Both paradigms have a lot of years of practice and saying that anyone of them will die in 4 years is I think a bit of exaggeration.

Why do you think that in 4 years OOP will be abandoned by programmers? What is the basis for your assertion?

I think it is more probable that we will have a kind of cross-pollination between these two paradigms with maybe newer languages (or evolving existing languages) to borrow concepts and best practices while still providing the core way to design solutions. This is already happening in smaller scale in multiple languages as far as I see it.

goatlover3• 4 years ago

Uh huh. And static typing will replace dynamic for all programmers, functional will replace all uses of imperative, nobody will use whitespace indentation, and all emacs users will switch to vim. Also, every programmer will abandon Windows and macOS for Linux.

cutler3• 4 years ago

Most of the non-system languages on the rise (Kotlin, Swift, Dart, JS, Python, C#) are a mixture of OOP and functional so I don't see OOP dying anytime soon.

by_the_bay3• 4 years ago

One of my biggest complaints about Ruby is that that it’s so much harder to drop into a debugger. In python it’s as easy as import pdb; pdb.set_trace(), but for ruby (at least the versions on our build systems), you need to figure out how to add the dependency for pry/byebug first which is non trivial.

tomstuart4• 4 years ago

A fair complaint, but FYI it’s outdated as of Ruby 3.0 (released in 2020) which includes the `debug` gem [0]. So in Ruby 3.0 onwards it’s as easy as `require 'debug'; debugger` just like you want. Hopefully your build systems will upgrade to a newer Ruby before too long.

[0] https://stdgems.org/debug/

bamboozled• 4 years ago

Forget all of it and use Go :)

entropie3• 4 years ago

Probably not a bad advice.

Most of the ruby enthusiasts I know from the old days took a deeper dive into go.

goatlover3• 4 years ago

I would think Elixir or Crystal would have been the more natural transistion for Rubyists. Or even Common Lisp. Go's philosophy is very much at odds with Ruby's.

jonnytran4• 4 years ago

The only thing I disliked more than moving from Ruby to Python was moving to Go. All the things I love about Ruby are the antithesis of Go.

amerine• 4 years ago

Ruby seems to have cemented itself in my head as one of my favorites. I’ve built a career from it and am eternally grateful.

RomanPushkin• 4 years ago

If you're learning Ruby, there is a free copy of my book available (CC BY 4.0 license):

https://leanpub.com/rubyisforfun/ - English

https://leanpub.com/rubyisforfun_ru/ - По-русски

(if you found typos, you can update the manuscipt https://github.com/ro31337/rubyisforfun)

jbverschoor3• 4 years ago

I'm missing the best part - In ruby we have an intuitive and extensive standard library

aendruk• 4 years ago

Of all measures to compare by that seems a particularly ill choice. One of the few things I know about Python is its longstanding reputation for having batteries included.

(But yes, you can pry Enumerable from my cold, dead hands.)

hawkeyedan2• 4 years ago

Arguments about the “superiority” of Python vs Ruby always sound a bit like arguments about the “superiority” of Italian vs Spanish. If you squint a bit they’re basically the same.

(By that simile, Lisp would be Sanskrit?)

thebigspacefuck• 4 years ago

True, but 85 million Italian speakers vs 500 million Spanish speakers so that tells you something. Sure the Roman Empire was big back in the day but the time has passed.

hawkeyedan2• 4 years ago

And yet I can only read Dante’s original work in Italian!

submeta• 4 years ago

Ruby is a beautiful language, but it lost the race against Python long ago. - When I first looked into both some ten years ago, I was undecided what to choose. But even back then googling problems led to much more professionally written blogs / articles about Python. Articles about Ruby were not as profound. That’s when I decided to go with Python. And it was the right choice.

## Edit

What I miss in Python: Ruby always returns a value and does not change structures in place. For instance `data.sort()` in Python will return `None` and change the order in `data`. Ruby won‘t do that and will return a sorted copy. Like Scheme (a Lisp dialect). In Scheme methods changing data have an exclamation mark as suffix: `(sort! data)` vs `(sort data)`, and it will always return a value. Unlike Python.

msbarnett5• 4 years ago

What “lost”? They’re both Top 10 most used languages with tens of thousands of open positions currently available for someone competent in either.

Python’s the more frequently used of the two industry-wide, but it seems like they both won, just with different crowds.

disgruntledphd23• 4 years ago

As a professional data scientist, I kinda wish ruby had won for this area, as it's much closer to R conceptually.

Python is fine, the metaobject model is pretty nice, and I've stopped noticing the double underscores ;)

dehrmann2• 4 years ago

I think it's that Ruby has mostly been relegated to Rails, while Python sees use in backend systems, data science, scripts, and as a popular first language.

tomstuart4• 4 years ago

You may be making a point about what happens by default (and perhaps Ruby’s similarity to Scheme?), but in Ruby you can also say `data.sort!` if you want the `data` array modified in-place. It’s still returned, though.

disgruntledphd23• 4 years ago

The hardest thing for me to understand in Python was the baffling tendency of methods to return None.

cortesoft3• 4 years ago

Ruby always returns a value and does not change structures in place

The not changing structures in place bit is only for std library things… nothing is stopping code you write from modifying structures in place.

Ruby has the ‘! means it mutates’ convention as well, and the built in methods use it (for example, .sort! on an array modifies the array in place just like your Scheme example). However, again it is just a convention… nothing stops a ruby developer from modifying something in place without a !, or making a method that ends in ! that doesn’t modify in place.

The common theme in Ruby is ‘nothing stops you from…’

To Ruby from Python

Related Stories