Comment by commodoreboxer

Comment by commodoreboxer 2 days ago

14 replies

View on Hacker News

I agree with you, and I'll put it slightly stronger. Ruby is a better language than Python in every way except the very most important two:

- Imports in Ruby seriously suck compared to Python. Everything requires into a global scope and an ecosystem like bundler which encourages centralizing all imports for your entire codebase into one file.

- Python has docstrings encouraging in code documentation.

Add common ecosystem things like the Ruby community encouraging generated methods, magical "do what I mean" parameters, and REPL poke-driven development, and this leads to the effect that Python codebases are almost always well documented and easy to understand. You can tell where every symbol comes from, and you can usually find a documentation entry for every single method. It's not uncommon for a Ruby library, even a popular one, to be documented solely through a scattering of sparsely-explained examples with literally no real API documentation. Inheriting a long-lived Ruby project can be a serious ordeal just to discover where all the code that's running is running, why it's running, where things are preloaded into a builtin class, and with Rails and Railties, a Gem can auto insert behavior and Middleware just by existing, without ever being explicitly mentioned in any code or configs other than the Gemfile. It's an absolute headache.

My dream language would be Ruby with Python-style imports and docstrings.

Myrmornis 2 days ago

I think your comment needs to mention that Python has syntax for type annotations and two mature type checkers (mypy and pyright) with more under development. Python is thus very much part of the modern statically typed languages scene (moreso than Go) whereas Ruby isn't at all. Many people wouldn't touch Python today if it weren't for this.

Reply View 6 replies
  • pansa2 2 days ago

    > Python is thus very much part of the modern statically typed languages scene (moreso than Go)

    Python’s type system is substantially more complex than Go’s - it’s probably more complete, but given it’s optional nature, less sound.

    In “modern” type systems, is completeness considered more important than soundness? The success of TypeScript suggests it is.

    Reply View 1 reply
    • kaba0 2 days ago

      Since basically every single type system has escape hatches (casts), yes, I would say completeness is more important than soundness.

      Reply View 0 replies
  • pansa2 2 days ago

    > two mature type checkers

    I’ve never quite understood how this works. Surely a type system is absolutely fundamental to a language - how can you have multiple incompatible ones?

    Do you need to choose a particular type checker for each project? Are you limited to only using third-party libraries that use the same type checker?

    Reply View 2 replies
    • t43562 2 days ago

      I think Python was successful because it started off without a type system and you can still choose not to use it. Duck typing is the big feature really.

      It might float your boat to think about types but why would everyone have to want the same thing?

      Reply View 0 replies
    • baq 2 days ago

      Look at JavaScript and typescript - Python’s typing is maybe halfway to that gold standard but there were other typed languages based on js. Python is special in that it provides type hinting syntax which is not used by the interpreter, so writing types doesn’t require the Byzantine build systems of js.

      Reply View 0 replies
  • RMPR 2 days ago

    > syntax for type annotations and two mature type checkers (mypy and pyright)

    I would throw Pyre in there too

    Reply View 0 replies
antod 2 days ago

Hard agree on the global Ruby import issues. I remember inspecting large custom Rails or Capistrano codebases in pry and having thousands of names imported. That and monkey patching had me wishing for Python with imports only having module scope and being a lot more explicit.

Reply View 0 replies
nextos 2 days ago

It's a shame Python has a strong anti-FP stance with crippled lambdas. And an OO system that looks like it has been bolted in, compared to Ruby which is essentially a Smalltalk with Perl-like syntax and some Lisp influence.

These two issues would have been quite easy to fix and would have led to a completely different development experience. Python had a good implementation with a nice C FFI (CPython) right from the beginning, whereas Ruby MRI had lots of efficiency issues with long-running computations. IMHO this is one of the reasons why Python won. Building a numerics stack on top of MRI did not look very promising.

Reply View 5 replies
  • pansa2 2 days ago

    > an OO system that looks like it has been bolted in, compared to Ruby

    I think the two languages just have different design philosophies. In Python, functions are fundamental and classes are built on top of them. In Ruby, objects are fundamental and functions (i.e. Procs etc) are themselves objects.

    You could just as well claim that in Ruby, functions look like they have been bolted in. For example, you can’t call a Proc itself but need to call one of its methods.

    Reply View 4 replies
    • pmontra 2 days ago

      I agree. Python was designed in 1989 and it looks like the OOP we were doing in C (without the ++) back at the time. Objects were a struct with data and function pointers and we were passing them around as pointers. Python has self, explicit in function definition and implicit in function calls, and that self is really like the pointer to the struct. By the way, OO languages from the 90s (e.g. Java and Ruby) were designed to always hide that self, both in method definition and method call. They use it when there is a need to tell the difference between instance attributes and local variables with the same name.

      Maybe the explicit self was there to make C programmers feel at home. Functions as fundamental building blocks of the language also make C programmers feel at home. Developers got more familiar with OOP by mid 90s so the new languages could jump from functions-first to objects-first.

      Reply View 1 reply
      • nextos 2 days ago

        I think Python's OO is a bit suboptimal even if the goal was to have method-centric OOP like in C with classes. For example, mechanisms to hide information, a fundamental part of the OO paradigm, are hacky. You need to use name mangling.

        Same applies to FP, a few things are weird and crippled. IMHO, the net result is that Python code tends to look longer and much more algorithmic than in Ruby, Smalltalk or various Lisps, where the language favors lots of little functions that call each other.

        Things are changing a bit, though. For example, pattern matching (PEP 622) brings some conciseness. Fixing those other issues would be great.

        Reply View 0 replies
    • maple3142 2 days ago

      Isn't Python's functions are just objects with a __call__ method, and such objects has a syntax sugar allowed them to be called like a function.

      Reply View 1 reply
      • baq 2 days ago

        Functions are objects are functions are objects… heard that from a little schemer

        Reply View 0 replies