From Ruby to Python

I'm coming from a Ruby background but it seems like I have to learn Python3 for a new job..
At first I was missing all my cool Ruby features, but I realized I have to "empty my cup", leave all my Ruby knowledge behind and start over new and I already discovered a few pretty nifty features.


So long story short: what are the similarities / differences between Ruby and Python? Especially when it comes to the "mindset"?
What are some "must know" tricks / paradigms of Python?
Are those decorators really a thing (and where is it usefull) or is it just a memey feature?

Decorators are useful in pop/classes and certain frameworks

>What are some "must know" tricks / paradigms of Python?
Shorter is usually better, because the more work that can be performed internally by Python the better.
e.g. map/filter is much better than doing it the hard way.
filter(None, ...) can be nice.
Decorators are pretty big, but you should also get used to metaclasses.

Python has a lot of pretty deep rabbit holes, like instances/classes/metaclasses, attribute access, operators, and others.

this is so cool
listx = [1,2,3,4,5]
listy = [x**2 for x in listx]

ha, i'm going from python to ruby, but idk enough about ruby to really help. do you have a specific question?
post in the ruby general

everything is a list, and dictionary is the most powerful type. in ruby everything is an object, and if you understand good OO, you'll be able to do anything you want

I never heard of know "pop", did you mean "oop"?

Another nice one is being able to unpack tuples and lists into variables:
mylist = [1, 2, 3]
x, y, z = mylist

Thanks for your answer!
I see, so Python has it's own sort of meta programming..

Oh well, I don't expect do be a master pythonista in two weeks, but I feel like it's good to know what's there in the first place..

A lot of stuff is similar in Ruby/Python, i.e.:

# Ruby

listx = [1,2,3,4,5]
listy = []
for x in listx do listy

>So long story short: what are the similarities / differences between Ruby and Python?
They're basically the same language with slightly different syntax and programms who will insist on telling you otherwise.

All dynamically typed, runtime-interpreted, imperative object-oriented script langs are really the same language under the hood. Don't listen to anybody who will claim otherwise.

You are wasting your time trying to learn the differences, because you already know the language. The rest is just syntax fluff and forced conventions at best.

>runtime-interpreted
Not sure if Ruby is the same, but Python is compiled to bitecode then run in a VM similar to Java (at least in the "normal" implementation of Python).

That's just an implementation detail, it doesn't change the fact that the interpreter touches your source code at runtime.

>it doesn't change the fact that the interpreter touches your source code at runtime
It's just compiling and then running. It's entirely possible to run a program (other than the top-level file) using nothing but the compiled pyc files.

>They're basically the same language with slightly different syntax

That's what I thought as well. But as I wrote before, it doesn't work like this. Whenever I though "well, in Ruby I would do this and that" it was really difficult to make it work in python.

Then I realized the "python way" is not the "ruby way".

I don't know, it's difficult to describe, but my feeling is that in Pytho you work more step-by-step, while in Ruby I often "chain stuff" like in Java:

My Ruby often looks like this :
[blablabla] . filter_this . do_that . check_condition . map_result . (...)

My Python currently looks more like this:
with filter( [blablabla] )
check_condition
and map_result


It's only a detail, but it feels different.

Or wait, let me put it like this:

Ruby feels more like emacs, Python more like Vim:

Both are equally powerfull, but the way you do things is differnt. While emacs has a "special purpose power tripple action" key-combination for everything and is super customizable, vim is leaner and smaller. So in vim you would rather do swoosh/swoosh/swoosh/swoosh and in emac rather SKADOOSH-OMG-LOOK-MOM-NO-HANDS!!1!!

That's my feeling in python vs ruby, too.

>But as I wrote before, it doesn't work like this. Whenever I though "well, in Ruby I would do this and that" it was really difficult to make it work in python.
That's because you're a shitty programmer who gets confused by meaningless minor differences, I suppose

You have presented me two programs with identical semantics, the only difference is the syntax.

Wow, hot opinon buddy.

To me ruby feels much closer to Java then python. Also this function passing in python feels more like JS.

Maybe you are the shitty programmer here because you get distracted by "obvious stuff" like how to split a list. But the way you do abstraction is not similar. Ruby blocks/procs are a core principle of the langauge, in python you wouldn't write a complicated lambda function, would you?. Python is closer to Golang here, it breaks things down to the smallest possible unit.

I'm not seeing the whole picture in Python yet, but AFAIK in python you don't build funky big classes that redirects requests to other classes if you don't have a requested method. you don't aks objects "you have this method here?", you don't create domain-specific languages.

>Ruby blocks/procs are a core principle of the langauge, in python you wouldn't write a complicated lambda function, would you?
But they're both the same thing under the hood (dynamic dispatch lambda functions)

Maybe I'm just jaded from PL theory and compiler design, but I really couldn't care less about meaningless syntactical differences when the underlying languages are basically isomorphic.

Go look at something like Haskell or Prolog if you want examples of different languages.

>Not sure if Ruby is the same, but Python is compiled to bitecode then run in a VM similar to Java (at least in the "normal" implementation of Python).
Every interpreter that isn't total garbage works that way.
And no, that doesn't make Python even comparable fast as the JVM.

>So long story short: what are the similarities / differences between Ruby and Python? Especially when it comes to the "mindset"?
They are both developed by people that failed an interpreter building course. However, Python is worse, so embrace the quality downgrade.
>What are some "must know" tricks / paradigms of Python?
Nothing. What the community thinks is pythonic code is fucking garbage.
>Are those decorators really a thing (and where is it usefull) or is it just a memey feature?
Just a memey feature most % of the time.

I never said Ruby and Python have nothing in common.. Both have a GIL, both use C underneath. But some details in langauge design can make a huge difference in the usage of that langauge..

>muh JVM

Guess what - the difference in performance is not that much about syntax/langauge design itself. The differnce lies in how much effort you put in to make it fast.

If some big company would start putting money in Ruby, paying a few engineers to work full-time on making Ruby faster, it would be fast as hell sooner or later. Of course you have some hard limits concerning complexity, but you can optimize A LOT if you're willing to put enough effort in the langauge.

>Guess what - the difference in performance is not that much about syntax/langauge design itself. The differnce lies in how much effort you put in to make it fast.
Correction: The difference in performance depends on how much of your language's semantics are static and how much are dynamic.

Feel free to prove me wrong. Every language with static typing performs orders of magnitude faster than languages with dynamic typing. The more dynamic bullshit (reflection, attributes, scope modification etc.) that a language has, the slower it runs.

Ruby is the ultimate example: By even allowing you to change the way the language parser itself works at runtime, it's forced to be extremely dynamic and therefore extremely slow.

The only reason these languages are slow are because all of the implementation have to have shittons of dynamic lookups, parsing and decision logic inside the critical path of every single statement BY DESIGN.

This is not just an implementation issue, this is a fundamental issue with the language.

>Feel free to prove me wrong. Every language with static typing performs orders of magnitude faster than languages with dynamic typing. The more dynamic bullshit (reflection, attributes, scope modification etc.) that a language has, the slower it runs.
Heck, even C# is a good example. Feel free to benchmark these three routines:

int foo1(int bar, int bat)
{
return bar + bat;
}

object foo2(object bar, object bat)
{
return (int)bar + (int)bat;
}

dynamic foo3(dynamic bar, dynamic bat)
{
return bar + bat;
}


The first one is roughly the equivalent of a staticaly typed, compiled language. The second one is roughly the equivalent of a dynamically typed language. The third one is roughly the equivalent of a fully dynamic language with runtime dynamic operator dispatch etc.

I can tell you already without having benchmarked them that they will perform something along the lines of 1 : 20 : 100, despite running with the exact same implementation made by the same people with the same amount of effort.

The difference here is that the increased dynamic semantics _force_ the implementation to do more at runtime. It's as simple as that.

Faggot, see And no, you can't make them fast just by adding a JIT compiler, that only works partially for semantically simple languages like Lua or JS.

Also, go look at JavaScript and asm.js for a great example of this in action.

Literally all that asm.js is is a restricted subset of JavaScript in which you can do less than you normally could. This restricted subset BY DESIGN allows JavaScript to run faster, because the interpreters can be significantly more up-front work and less dynamic work at runtime.

We're talking about the *same* javascript interpreter developed by the *same* people executing the *same* language being significantly faster simply because you turn a few features off.

You mad, bro??

I gues you didn't undestand what I said. I did not say "you could make Ruby as fast as assembler". But I did say "you could make it a lot faster by putting some money in it".

The JVM/hotspot is an incredibly complicated piece of technique. A lot of clever people worked for decades to "make it fast". You just don't optimize assembly code (Peephole optimization) after an into course in compilers.

And even though there is not an army of engineers behind ruby, they have things like dead code elimination. Of course if you don't wan't to have overflows with numbers because you work on a z domain you pay a price for that.

C is cosidered as "the fastest" langauge because you do every shit by yourself. So if you have 3 numbers and for 2 of them you are daed sure they never are out of range you can skip the checking and save time. But we were talking about scripting languages here, weren't we? Ruby is anything but "bad design", it is really fucking great. I can't talk about Python (yet) because I'm just starting it, but did you notice how many languages were influenced by Python or Ruby? Wether you learn JS(ecma6), rust, swift or even golang: everywhere you can find an influence.


So stop spouting bullshit here.

>But I did say "you could make it a lot faster by putting some money in it".
Max 10 times which isn't a lot.
>C is cosidered as "the fastest" langauge
it isnt
>because you do every shit by yourself.
that's not the reason

you're just some fedorable doing damage control

>Max 10 times which isn't a lot.

Wew, lad.

Ruby3 aims to be 3 times as fast as ruby is now, and who knows if it will be. But hey, "10 times faster are not a lot". Wew.

Also it's pretty dumb to talk about the "speed" of a langauge without any reference point. For example you can make a pidigits benchamrk were Ruby actually performs faster than Java. For 20 years C++ and Java guys battled each other with benchmarks because depending on the task you can plaky into Java's strengths or weaknesses.


But to quit this stupid discussion: If you really want to make super heavy computation in Ruby (why would you??) you could just use native C code and get the result back into ruby.

(I guess there's something similar in python, maybe that "numpy" project?)


>C is cosidered as "the fastest" langauge

Enlighten me then.


>that's not the reason

OK. So according to your (false) theory, the simplicity of a langauge is the single source of "speed". Could you tell me what Java Reflections do? Or wait, let's talk about Clojure. Clojure is a pure Lisp-1.

Now will you you argue that LISPs are "simple" langue? Even tough you can change code trees at compile time? And yet it's pretty fast. It needs some startup time, but then it's comparable to Java.

But this has NOTHING to do with the JVM, it's only about the """langauge complexity"""...

:^)

B T F O
T
F
O

>Ruby is anything but "bad design", it is really fucking great.
It's real great at being slow as shit, yes