36 ms·

Yukihiro Matsumoto: “Ruby is designed for humans, not machines”

248 points by Evrone 7y ago

vincent-toups 7y ago
I don't understand languages like Ruby and Perl and their supposed emphasis on "human design." My sense of what a human designed language would be is a lot more like Scheme: extremely simple, fundamental abstractions which, when composed, enable a variety of different strategies for solving problems. Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax. When I look at Ruby my eyes glaze over with all the unnecessary syntactic doodads and peculiar abstractions. Why anyone would want to complicate their lives with all that silliness is beyond me. And yet Scheme languishes and Ruby, for a time, anyway, burned brightly. I'm clearly the weird one.
- wolfgke 7y ago
  > I don't understand languages like Ruby and Perl and their supposed emphasis on "human design." [...] Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax. Sounds like a human (natural) language to me ...
  - cambalache 7y ago
    I had the same thought. "Simple" does not mean "easy" and "for humans" does not have to mean simple.
- hashmal 7y ago
  I can only recommend the "Simple Made Easy" talk by Rich Hickey. I suppose it can be said that Scheme is very simple but hard for many, while Ruby is very complex but easy for many.
  - mapgrep 7y ago
    I think Rails fits what Hickey says about easy complexity very well. Ruby not at all - I find it very much not “braided together” compared to other programming languages. It’s still object oriented, and Hickey’s talk is largely directed at showing how bare maps and immutability and functional style and so forth in Clojure are better than what he calls the “petty parochialisms” of class hierarchies. But among OO non Clojure languages I’d argue Ruby is among the closest to th ideals he espouses in that talk.
- chongli 7y ago
  Now I love Scheme but I would argue the exact opposite for the same reasons you listed. Scheme (Lisp, actually) is so simple and so cohesive that it feels like it was given to humanity by an advanced alien race. Languages like Perl, on the other hand, feel right at home with the English language. There’s a deep history of all these different things from many different places that have been bolted on over the years. It’s incredible that we can say anything at all, let alone write amazing works in it.
  - 0x445442 7y ago
    But once you learn the alien language you can understand all written forms in that language. When you speak of Perl, which dialect of Perl are you speaking of? I'm not singling out Perl here as I see the same issue in varying degrees with most general purpose languages.
- mapgrep 7y ago
  >Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax My experience is the precise opposite. Ruby seems more consistent and straightforward than any other non lisp language I’ve used. Ubiquitous blocks and “everything is an object” gets you very far. Compare nested list comprehensions in python to chained map/select calls in Ruby: lesson for lesson in [school.Lesson(downloaded) for downloaded in api.downloads()] if want(lesson)] vs api.downloads.map{|download| School.Lesson.new(download)}.select{|lesson| want(lesson)} Or compare the many varied required ways to do something with an array in python vs Ruby: len(array) “;”.join(array) array.append(x) Vs array.length array.join(“;”) array.append(x) Genuinely confused what you refer to with “unnecessary syntactic doodads.” Examples?
  - 0x445442 7y ago
    You answered your own question with your qualifier... "Ruby seems more consistent and straightforward than any other non lisp language I’ve used."
    - mapgrep 7y ago
      If OP just meant ruby is syntactically complex compared to lisp, there’s really no arguing with that! :-) it just applies to so many languages — any non lisp — and seems an odd thing to single out Ruby for. (Perl, on the other hand...)
    - hartator 7y ago
      He has replied with actual code samples. Which is valuable.
  - vincent-toups 7y ago
    Both sets of code samples look silly to me. In scheme all this syntactic nonsense would just be function calls and lambdas.
    - tomc1985 7y ago
      Beauty really is in the eye of the beholder, because I agree fully with parents' statements. Then again I write Ruby for a living...
- dragonwriter 7y ago
  > My sense of what a human designed language would be is a lot more like Scheme: extremely simple, fundamental abstractions which, when composed, enable a variety of different strategies for solving problems. “Human design” isn't “human designed” but “designed for humans”, and, more specifically, “deidned for the way human brains naturally work” rather than “deidgned for ivory-tower ideal of how brains should work” > Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax And, in that respect, is a lot like natural languages, which are quite often complex analytically/descriptively, with near-duplicate features, leveraging implication, etc., etc., etc.
- hinkley 7y ago
  As someone who studied the game of Go for a bit, simple rules can be deceptive. You can get whole bookshelves of books about things with rules that are too simple. “The Rules” that matter become the patterns that the simple rules allow or imply, and all the nuances of when one is better than another.
- int_19h 7y ago
  > My sense of what a human designed language would be is a lot more like Scheme: extremely simple, fundamental abstractions which, when composed, enable a variety of different strategies for solving problems. Consider the natural human languages- they're far from being straightforward uniform compositions of extremely simple abstractions. They have weird syntax, and a lot of redundancy. Now, some of it is historical legacy, but not all. The language doesn't just have to be easy to analyse semantically - it also has to be easy to parse. And while parsing identical nested brackets is easy for a machine, humans prefer more variety for their pattern matching inputs.
- mirchibajji 7y ago
  My impression is that human languages are more expressive - There is more than one way to do it. # For a bank, if ($authorised) { allow_entry(); } # vs. a shop: allow_entry() unless $person->is_smelly(); The language lends itself to how you may normally say it in English, emphasizing the common case. That isn't to say all the syntactic noise is justified, but I guess one's noise is other's attempt at being more expressive.
_em6m 7y ago
Kind of offtopic: I did some Ruby and I find some of the conventions really confusing; for example, the lack of “()” when calling a method. You never know if you’re accessing a property of calling a method until you grep the code. Am I the only one who feels this?
- mpartel 7y ago
  It's always a method in Ruby because you can only access @properties in method implementations. What you're describing holds in e.g. Scala, where it's by design: they feel it should be an easy-to-change implementation detail whether a name is backed by a direct field access or a method. IMO that's a reasonable stance in a functional(ish) world.
  - dragonwriter 7y ago
    @vars are data members, not properties. “Properties”, in most languages that have them, are an way to make method access look like access to data members (no parens, getters just use the name, setters use name + = with the new value on the right of the = instead of in parameter position.)
  - Nullabillity 7y ago
    But Scala still differentiates between `def shouldBePure: Foo` and `def probablyHasSideEffects(): Bar`.
- gunn 7y ago
  In ruby you are always calling a method, you can't access a property from outside a class with normal syntax.
  - dragonwriter 7y ago
    Ruby doesn't have properties except as an alias for a certain pattern of methods, and in languages that do have properties they are almost invariably just a layer over calling getter and setter methods. You seem to confusing “properties” with “data members” which, it is true, Ruby does not permit external access to except via method calls. But properties are a way of calling methods with a syntax that looks like direct member access, not actual direct member access.
torgian 7y ago
Honestly, I never could get into the Ruby language. I always kept making mistakes with the syntax and ended up gravitating towards python and relearning JavaScript
- Evrone 7y ago
  Why we choose Ruby for our projects https://evrone.com/why-ruby https://evrone.com/why-ruby
- Hamuko 7y ago
  Same. I always felt that Python was actually designed for humans and that Ruby had an incomprehensible syntax.
  - thaumasiotes 7y ago
    I never did much with Ruby beyond toy problems, but I was impressed by the lengths the language goes to to make it convenient to express what you want to do. There's one syntax for half-open ranges and another syntax for closed ranges. You can index an array any number of different ways: "get me the 5th element". "Get me the element three back from the end". "Get me elements 5 through 8 (inclusive)". "Get me 0 through 6 (exclusive)". "Get me the 3-length subarray starting at index 2". A hash table returns nil by default when you access a key that isn't stored. But you can change the default value as a property of the table itself. Users now don't need to remember to supply their own default value when they're looking in the hash table. Even more, you can specify a function that gets called when a nonexistent key is accessed, to do whatever is appropriate. All of those are great things. It's easy to translate your algorithm that says "take a stretch of three elements starting from i" into an access that looks like array[i..i+2]. But the semantics of your algorithm start slipping away as you make adjustments like that. If what you're doing is taking substretches of 3 elements each, there's a gain from being able to express it as array[i, 3], as semantically distinct from taking a substretch between two independent bounds that happen to be i and i+2. But the flip side of this is that if you're not regularly immersed in the language, it's really easy to lose track of precisely which bit of syntax does what.
- 7y ago
runeks 7y ago
And that’s why it relatively slow compared to e.g. C — which is designed for machines, not humans.
- jbverschoor 7y ago
  Replace ruby with crystal, and this comment can be removed.
  - ryanpetrich 7y ago
    Crystal is not Ruby, nor is it anywhere near as fast as C.
    - phaedryx 7y ago
      Really? Benchmarks I've seen put it in the same ballpark
retrobox 7y ago
I’ve been trying to get into Ruby for a new job and am finding it hard. Not being designed for machines is right - a lot of the IDEs seem bad and can’t even figure out where your methods come from. I don’t know how the interpreter manages to run it. Multiply the problem by 10 once you add rails and all the methods it generates. It makes for a good, rapidly developed monolith but most places I’ve worked in recent times are moving to services and micro services and it doesn’t seem cut out for that.
- kawsper 7y ago
  Generally, I think RubyMine is quite good as a Ruby IDE. You can also use IRb, Ruby's REPL, and #source_location to find definitions, it works for monkeypatches as well if your team is using those.
- deleted 7y ago
  [deleted]
- dgellow 7y ago
  Have you tried RubyMine from Jetbrains? It's the best dev environment I know for ruby. https://www.jetbrains.com/ruby/ https://www.jetbrains.com/ruby/
  - sosodev 7y ago
    I love Rails but even RubyMine struggles to understand the context of a Rails app. Everything being dynamically required seems to be the real thing that makes it hard to be context aware.
    - retrobox 7y ago
      This ^ Perhaps it’s fairer to say a lot of my struggle so far is with a Ruby on Rails project. I’ve had less exposure to Ruby without the Rails part, and maybe it’s regrettable that’s the case. I’ve used frameworks in other languages and mostly always been able to dig back to the original source of things but I’ve not had such a positive experience with Rails and any of the IDEs out there.
pwdisswordfish2 7y ago
“Ruby is designed for programmers, not end users” It's not machines who care about performance. It's the person who has to use the program written. It may sound gentle and altruistic, but when you actually think about it, putting “humans” first is actually an incredibly self-serving sentiment.
- smitty1e 7y ago
  When you actually think about it, “humans” is plural, and "self-serving" sure seems singular. Past that superficiality, a programming language is a mechanism. I am sincerely curious in what larger context one would evaluate this mechanism at all, and furthermore, deem it "an incredibly self-serving sentiment".
- darkerside 7y ago
  There is already an ideal programming language for computers. It's bytecode. All high level languages after built for people, not computers, to make it reasonable for us to collaborate and maintain our own code. The computer itself doesn't care for anything beyond 1s and 0s.
  - pwdisswordfish2 7y ago
    And computers are built for people, to make it reasonable for us to collaborate and maintain our own (non-programming) work. Dismissing performance concerns because you're designing a language “for humans” is actually glossing over a quite large number of other “humans” (i.e. non-programmers) who do have a stake in the choice, but not so much say in it besides “why is my computer so slow lately”. Well, it's slow because you thought type checking is for know-it-all ivory-tower academics and pedantic asshole compilers, so you chose JavaScript (or whatever “forgiving” language is in vogue these days; the OP is about Ruby, but it doesn't really matter), and so the user has to wait until the JS engine finishes JITting your code over and over again to infer type information that should have been available at compile time in the first place. Rinse and repeat for each app, and now they have to replace their laptop every few years to catch up with ever-growing (for no good reason!) RAM requirements. Claiming that a programming language is “designed for humans” much too often amounts to saying “my (programmer's) convenience and satisfaction is more important than yours (user's)”. And that is an incredibly arrogant thing to say, as superficially gentle as it may seem at first glance. I'm not arguing against high-level languages; I'm arguing against disregarding performance in the name of programmer convenience. It's quite possible to design a high-level language in a manner that doesn't stand in the way of making its implementations performant. There are some recent developments on that front. But if you ignore them, then it's not the “machine's” resources that you're wasting. It's the user's resources.
dlkf 7y ago
There's a lot of comments of the form "I tried getting into Ruby and it never clicked" that I want to respond to. I think that if you're just writing a script to solve a math problem or automate a task, there isn't really a strong argument as to whether you should use Ruby, Python, bash any other high level language. You should probably use whatever you're most comfortable with. But if you're making an application with a database, RoR is an extremely powerful tool. And this isn't just a case of Ruby having the best library (in the same way that Python has the best scientific computing library). It's a case of the library functionality and the language playing together really well. Ruby statements look more like natural language statements than those in other languages. This is a really helpful design choice when you're building a crud application. In that context, you're not thinking about X, Y, -Log(X + Y) or whatever. You're thinking about a new customer, or whether some old customer is a member? of some mailing list, etc In a weird way, it's similar to how Haskell users love the fact that statements in Haskell are mathematical truths. In the case of logic programming this is a handy feature to have. In the case of writing the business logic of a CRUD app, it's handy if your statements look like natural language statements about the underlying real world objects whose representation you are reasoning about.
- thrwaway69 7y ago
  I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency behaviour(I think this causes me to snap more than language syntax. Dependencies don't have clear code navigation guidelines, proper structure or docs than the language they are in). From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. If there are more js developers, then that means you can hire more for less overall. Obviously things are more complicated. If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Anything trendy will get too many breaking changes or fixes. Heck, having visible source code can be liability too in future. I may as well choose something that will be hard to decompile. Not to mention the external dependencies that you will need to mirror or even maintain. I think most businesses that are dependent on tech can be divided into short lived and very long lived ignoring certain type of software and industries. For short lived businesses or customers, your stack shouldn't matter much compared to the responsiveness of development. What incentive are there to provide quality software to companies that will live 5 years at best? (Note - quality here refers to ideal stack/code that programmers expect. Eg - unnecessarily performant, kubernetified, micro architecture) None. For long term businesses, software is an ongoing cost. They can afford to renew their software every 10 years so why should you write something that is expandable, easy to migrate and another team to take over. Beside, their requirements change drastically over time. It will end up being a monolith. I don't have to work right now but if I ever do, I am gonna work on the interesting bits while hiring someone in a third world country to outsource parts that I don't from my job. I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.
tomerbd 7y ago
Ruby is truly nice, I just wish I had the option for static typing built into the language, as a human I prefer it because then IDE support is much better for any refactor, etc and getting to maintain other people code.
- elliotlarson 7y ago
  You're not alone. Stripe has been working on adding types to Ruby with their static type checker, Sorbet: https://sorbet.org/ https://sorbet.org/. This seems to have a bit of momentum at this point. Assuming it continues in popularity I'm excited to see how this helps to improve Ruby work in an IDE.
  - tomerbd 7y ago
    Looks interesting! will have a look.
- Can_Not 7y ago
  Have you tried crystal?
pdimitar 7y ago
Strange takeaway in the title. Mine are: - He regrets introducing threads. He now prefers other parallelism/concurrency paradigms and is possibly looking into introducing them in Ruby 3 (that part wasn't clear in the interview). - He regrets adding global variables. - He regrets not focusing on immutability primitives earlier. - He and the maintainers team look at Python, JavaScript and Elixir for inspiration. - He seems a bit disappointed that Ruby is mostly used for web development only and would be happy if it was used in research and AI. - He regrets not investing even a little effort in static typing earlier but is now working on an optional typing system where you choose to describe types in a separate file. (Reminds me of C/C++ and OCaml header files.) I hope I’m not subconsciously emulating a sensationalistic journalist here but it doesn’t seem he’s very pleased with the current state of affairs. A lot of changes, indeed inspired from other languages, seem to be on their way to Ruby 3. --- I’m pretty indifferent to Ruby these days. I’ve worked 6 years with Rails to a moderate financial success back then but the problems were obvious almost from the start: too much magic and implied behaviour, too much global stuff changing below your feet, way too slow DB layer (it’s known that your DB will respond in 2ms and ActiveRecord will proceed to waste 100+ ms on serialisation before and after), managing bigger projects becomes huge pain, and a number of others. People just keep buying the promise of “but you get to make an MVP really quickly!”. Yeah well, but I want to maintain it past that stage too. Where I was doing with this is: Ruby is a very okay language and is very nice for sketching. It's readable, has libraries for a ton of stuff, and performs alright (especially without Rails). But I never found good use of it outside of small projects. Any serious business work becomes very painful to maintain and stay on top of for bigger projects. I’m aware there are practices that make it possible (Basecamp is a huge inspiration!) but I personally found them only half-working. YMMV, of course.
- norswap 7y ago
  Good points. Personally, it's a bit puzzling to me why the ML community ran with Python and why there isn't a popular alternative for Ruby. It's very capable in terms of making DSLs. My hunch is that the number-crunching libraries were better in Python (numpy etc).
  - 7y ago
Evrone 7y ago
We’re thrilled that our good friend Yukihiro Matsumoto, creator of the Ruby programming language, has been able to join us at RubyRussia 2019 as a speaker for the second time, having previously spoken three years ago at RubyRussia 2016. In the time that we’ve been holding the conference — now more than ten years — Ruby has undergone a great deal of evolution, and Evrone has grown and developed alongside it. Grigory Petrov, Developer Relations at Evrone, sat down with Mr Matsumoto to hear from him first-hand about being a star, the philosophy behind Ruby’s design and evolution, and a little about Japanese life and culture.
monadic2 7y ago
Shit, he should have considered the human cost of method_missing. Yes, I am serious, it’s a massive productivity drain. You encounter methods that you can’t google for, so your grep game better be good to get work done (grep for a portion of the name, and then method_missing itself if that fails). An IDE is useless in this case and your performance goes out the window. It’s much better to dynamically generate a finite number of methods you can see when inspecting objects.... I suspect those would jit better, too. Oh, you want to access the call stack on your server to figure out where that frame is? Jokes on you, ruby has no remote debugging mechanism aside from a core dump or building your own heap inspection access. Dang, why was this flagged?
emiliovesprini 7y ago
Reminds me of ''Programs are meant to be read by humans and only incidentally for computers to execute'' from Structure And Interpretation Of Computer Programs. What always gets me about that quote is that's it's obviously false. There are exceptions (such as space shuttle controls), but most software that's ''important'' is important because of how much it's run --Firefox is run a whole lot more than it is read-- and so this Incidental Execution stuff is nonsense. Performance and Readability are both important goals. Most of the time they're not even opposed as to justify pitching them against one another like this.
manoj_venkat92 7y ago
I was a RoR developer for two years and immensely enjoyed coding in Ruby, well technically, RoR(Ruby on Rails). It was in a startup and features were being developed at a rapid pace and it really felt like the right choice. But I also noticed that as companies grow they have problems with the maintenance of the code as well as the performance like twitter moving away.
sparker72678 7y ago
Dear everyone crapping on Ruby (and esp. Rails) in this thread (and every other time this comes up), If you don't like Ruby or Rails, that's okay! No, really. You can use something else. You won't hurt our feelings! Programming languages and their frameworks can actually be a preference, not a moral issue. We're here because we like it, and it's totally cool that you don't! Please use what you love; we are, and we know how powerful that can be. Cheers, — Every Ruby Developer
thunderbong 7y ago
I'm seriously not able to distinguish how many of these comments are about Ruby and how many are about Ruby on Rails (RoR). From the very beginning Ruby's popularity and criticism have hinged on RoR. And most people tend to conflate the two completely. Personally, I love Ruby but don't like RoR. RoR seems to bloated to me. Of course it does many things. But very rarely have I come across projects which require all those things. And even then, I'm quite sure, we wouldn't be able to use all that RoR has to offer. For many, many, years now, my stack has been Roda / Sinatra for routing and Sequel for DB access. And whenever, we've come across some requirement which needs heavy lifting, there are enough Ruby gems which do that without tying you up with the RoR framework.

248 points by Evrone 7y ago

I don't understand languages like Ruby and Perl and their supposed emphasis on "human design." My sense of what a human designed language would be is a lot more like Scheme: extremely simple, fundamental abstractions which, when composed, enable a variety of different strategies for solving problems. Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax. When I look at Ruby my eyes glaze over with all the unnecessary syntactic doodads and peculiar abstractions. Why anyone would want to complicate their lives with all that silliness is beyond me. And yet Scheme languishes and Ruby, for a time, anyway, burned brightly. I'm clearly the weird one.

wolfgke 7y ago
> I don't understand languages like Ruby and Perl and their supposed emphasis on "human design." [...] Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax. Sounds like a human (natural) language to me ...
- cambalache 7y ago
  I had the same thought. "Simple" does not mean "easy" and "for humans" does not have to mean simple.
hashmal 7y ago
I can only recommend the "Simple Made Easy" talk by Rich Hickey. I suppose it can be said that Scheme is very simple but hard for many, while Ruby is very complex but easy for many.
- mapgrep 7y ago
  I think Rails fits what Hickey says about easy complexity very well. Ruby not at all - I find it very much not “braided together” compared to other programming languages. It’s still object oriented, and Hickey’s talk is largely directed at showing how bare maps and immutability and functional style and so forth in Clojure are better than what he calls the “petty parochialisms” of class hierarchies. But among OO non Clojure languages I’d argue Ruby is among the closest to th ideals he espouses in that talk.
chongli 7y ago
Now I love Scheme but I would argue the exact opposite for the same reasons you listed. Scheme (Lisp, actually) is so simple and so cohesive that it feels like it was given to humanity by an advanced alien race. Languages like Perl, on the other hand, feel right at home with the English language. There’s a deep history of all these different things from many different places that have been bolted on over the years. It’s incredible that we can say anything at all, let alone write amazing works in it.
- 0x445442 7y ago
  But once you learn the alien language you can understand all written forms in that language. When you speak of Perl, which dialect of Perl are you speaking of? I'm not singling out Perl here as I see the same issue in varying degrees with most general purpose languages.
mapgrep 7y ago
>Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax My experience is the precise opposite. Ruby seems more consistent and straightforward than any other non lisp language I’ve used. Ubiquitous blocks and “everything is an object” gets you very far. Compare nested list comprehensions in python to chained map/select calls in Ruby: lesson for lesson in [school.Lesson(downloaded) for downloaded in api.downloads()] if want(lesson)] vs api.downloads.map{|download| School.Lesson.new(download)}.select{|lesson| want(lesson)} Or compare the many varied required ways to do something with an array in python vs Ruby: len(array) “;”.join(array) array.append(x) Vs array.length array.join(“;”) array.append(x) Genuinely confused what you refer to with “unnecessary syntactic doodads.” Examples?
- 0x445442 7y ago
  You answered your own question with your qualifier... "Ruby seems more consistent and straightforward than any other non lisp language I’ve used."
  - mapgrep 7y ago
    If OP just meant ruby is syntactically complex compared to lisp, there’s really no arguing with that! :-) it just applies to so many languages — any non lisp — and seems an odd thing to single out Ruby for. (Perl, on the other hand...)
  - hartator 7y ago
    He has replied with actual code samples. Which is valuable.
- vincent-toups 7y ago
  Both sets of code samples look silly to me. In scheme all this syntactic nonsense would just be function calls and lambdas.
  - tomc1985 7y ago
    Beauty really is in the eye of the beholder, because I agree fully with parents' statements. Then again I write Ruby for a living...
dragonwriter 7y ago
> My sense of what a human designed language would be is a lot more like Scheme: extremely simple, fundamental abstractions which, when composed, enable a variety of different strategies for solving problems. “Human design” isn't “human designed” but “designed for humans”, and, more specifically, “deidned for the way human brains naturally work” rather than “deidgned for ivory-tower ideal of how brains should work” > Ruby, in contrast, seems like an absurdly complicated concatenation of weird features and strange syntax And, in that respect, is a lot like natural languages, which are quite often complex analytically/descriptively, with near-duplicate features, leveraging implication, etc., etc., etc.
hinkley 7y ago
As someone who studied the game of Go for a bit, simple rules can be deceptive. You can get whole bookshelves of books about things with rules that are too simple. “The Rules” that matter become the patterns that the simple rules allow or imply, and all the nuances of when one is better than another.
int_19h 7y ago
> My sense of what a human designed language would be is a lot more like Scheme: extremely simple, fundamental abstractions which, when composed, enable a variety of different strategies for solving problems. Consider the natural human languages- they're far from being straightforward uniform compositions of extremely simple abstractions. They have weird syntax, and a lot of redundancy. Now, some of it is historical legacy, but not all. The language doesn't just have to be easy to analyse semantically - it also has to be easy to parse. And while parsing identical nested brackets is easy for a machine, humans prefer more variety for their pattern matching inputs.
mirchibajji 7y ago
My impression is that human languages are more expressive - There is more than one way to do it. # For a bank, if ($authorised) { allow_entry(); } # vs. a shop: allow_entry() unless $person->is_smelly(); The language lends itself to how you may normally say it in English, emphasizing the common case. That isn't to say all the syntactic noise is justified, but I guess one's noise is other's attempt at being more expressive.

_em6m 7y ago

Kind of offtopic: I did some Ruby and I find some of the conventions really confusing; for example, the lack of “()” when calling a method. You never know if you’re accessing a property of calling a method until you grep the code. Am I the only one who feels this?

mpartel 7y ago
It's always a method in Ruby because you can only access @properties in method implementations. What you're describing holds in e.g. Scala, where it's by design: they feel it should be an easy-to-change implementation detail whether a name is backed by a direct field access or a method. IMO that's a reasonable stance in a functional(ish) world.
- dragonwriter 7y ago
  @vars are data members, not properties. “Properties”, in most languages that have them, are an way to make method access look like access to data members (no parens, getters just use the name, setters use name + = with the new value on the right of the = instead of in parameter position.)
- Nullabillity 7y ago
  But Scala still differentiates between `def shouldBePure: Foo` and `def probablyHasSideEffects(): Bar`.
gunn 7y ago
In ruby you are always calling a method, you can't access a property from outside a class with normal syntax.
- dragonwriter 7y ago
  Ruby doesn't have properties except as an alias for a certain pattern of methods, and in languages that do have properties they are almost invariably just a layer over calling getter and setter methods. You seem to confusing “properties” with “data members” which, it is true, Ruby does not permit external access to except via method calls. But properties are a way of calling methods with a syntax that looks like direct member access, not actual direct member access.

torgian 7y ago

Honestly, I never could get into the Ruby language. I always kept making mistakes with the syntax and ended up gravitating towards python and relearning JavaScript

Evrone 7y ago
Why we choose Ruby for our projects https://evrone.com/why-ruby https://evrone.com/why-ruby
Hamuko 7y ago
Same. I always felt that Python was actually designed for humans and that Ruby had an incomprehensible syntax.
- thaumasiotes 7y ago
  I never did much with Ruby beyond toy problems, but I was impressed by the lengths the language goes to to make it convenient to express what you want to do. There's one syntax for half-open ranges and another syntax for closed ranges. You can index an array any number of different ways: "get me the 5th element". "Get me the element three back from the end". "Get me elements 5 through 8 (inclusive)". "Get me 0 through 6 (exclusive)". "Get me the 3-length subarray starting at index 2". A hash table returns nil by default when you access a key that isn't stored. But you can change the default value as a property of the table itself. Users now don't need to remember to supply their own default value when they're looking in the hash table. Even more, you can specify a function that gets called when a nonexistent key is accessed, to do whatever is appropriate. All of those are great things. It's easy to translate your algorithm that says "take a stretch of three elements starting from i" into an access that looks like array[i..i+2]. But the semantics of your algorithm start slipping away as you make adjustments like that. If what you're doing is taking substretches of 3 elements each, there's a gain from being able to express it as array[i, 3], as semantically distinct from taking a substretch between two independent bounds that happen to be i and i+2. But the flip side of this is that if you're not regularly immersed in the language, it's really easy to lose track of precisely which bit of syntax does what.
7y ago

runeks 7y ago

And that’s why it relatively slow compared to e.g. C — which is designed for machines, not humans.

jbverschoor 7y ago
Replace ruby with crystal, and this comment can be removed.
- ryanpetrich 7y ago
  Crystal is not Ruby, nor is it anywhere near as fast as C.
  - phaedryx 7y ago
    Really? Benchmarks I've seen put it in the same ballpark

retrobox 7y ago

I’ve been trying to get into Ruby for a new job and am finding it hard. Not being designed for machines is right - a lot of the IDEs seem bad and can’t even figure out where your methods come from. I don’t know how the interpreter manages to run it. Multiply the problem by 10 once you add rails and all the methods it generates. It makes for a good, rapidly developed monolith but most places I’ve worked in recent times are moving to services and micro services and it doesn’t seem cut out for that.

kawsper 7y ago
Generally, I think RubyMine is quite good as a Ruby IDE. You can also use IRb, Ruby's REPL, and #source_location to find definitions, it works for monkeypatches as well if your team is using those.
deleted 7y ago
[deleted]
dgellow 7y ago
Have you tried RubyMine from Jetbrains? It's the best dev environment I know for ruby. https://www.jetbrains.com/ruby/ https://www.jetbrains.com/ruby/
- sosodev 7y ago
  I love Rails but even RubyMine struggles to understand the context of a Rails app. Everything being dynamically required seems to be the real thing that makes it hard to be context aware.
  - retrobox 7y ago
    This ^ Perhaps it’s fairer to say a lot of my struggle so far is with a Ruby on Rails project. I’ve had less exposure to Ruby without the Rails part, and maybe it’s regrettable that’s the case. I’ve used frameworks in other languages and mostly always been able to dig back to the original source of things but I’ve not had such a positive experience with Rails and any of the IDEs out there.

pwdisswordfish2 7y ago

“Ruby is designed for programmers, not end users” It's not machines who care about performance. It's the person who has to use the program written. It may sound gentle and altruistic, but when you actually think about it, putting “humans” first is actually an incredibly self-serving sentiment.

smitty1e 7y ago
When you actually think about it, “humans” is plural, and "self-serving" sure seems singular. Past that superficiality, a programming language is a mechanism. I am sincerely curious in what larger context one would evaluate this mechanism at all, and furthermore, deem it "an incredibly self-serving sentiment".
darkerside 7y ago
There is already an ideal programming language for computers. It's bytecode. All high level languages after built for people, not computers, to make it reasonable for us to collaborate and maintain our own code. The computer itself doesn't care for anything beyond 1s and 0s.
- pwdisswordfish2 7y ago
  And computers are built for people, to make it reasonable for us to collaborate and maintain our own (non-programming) work. Dismissing performance concerns because you're designing a language “for humans” is actually glossing over a quite large number of other “humans” (i.e. non-programmers) who do have a stake in the choice, but not so much say in it besides “why is my computer so slow lately”. Well, it's slow because you thought type checking is for know-it-all ivory-tower academics and pedantic asshole compilers, so you chose JavaScript (or whatever “forgiving” language is in vogue these days; the OP is about Ruby, but it doesn't really matter), and so the user has to wait until the JS engine finishes JITting your code over and over again to infer type information that should have been available at compile time in the first place. Rinse and repeat for each app, and now they have to replace their laptop every few years to catch up with ever-growing (for no good reason!) RAM requirements. Claiming that a programming language is “designed for humans” much too often amounts to saying “my (programmer's) convenience and satisfaction is more important than yours (user's)”. And that is an incredibly arrogant thing to say, as superficially gentle as it may seem at first glance. I'm not arguing against high-level languages; I'm arguing against disregarding performance in the name of programmer convenience. It's quite possible to design a high-level language in a manner that doesn't stand in the way of making its implementations performant. There are some recent developments on that front. But if you ignore them, then it's not the “machine's” resources that you're wasting. It's the user's resources.

dlkf 7y ago

There's a lot of comments of the form "I tried getting into Ruby and it never clicked" that I want to respond to. I think that if you're just writing a script to solve a math problem or automate a task, there isn't really a strong argument as to whether you should use Ruby, Python, bash any other high level language. You should probably use whatever you're most comfortable with. But if you're making an application with a database, RoR is an extremely powerful tool. And this isn't just a case of Ruby having the best library (in the same way that Python has the best scientific computing library). It's a case of the library functionality and the language playing together really well. Ruby statements look more like natural language statements than those in other languages. This is a really helpful design choice when you're building a crud application. In that context, you're not thinking about X, Y, -Log(X + Y) or whatever. You're thinking about a new customer, or whether some old customer is a member? of some mailing list, etc In a weird way, it's similar to how Haskell users love the fact that statements in Haskell are mathematical truths. In the case of logic programming this is a handy feature to have. In the case of writing the business logic of a CRUD app, it's handy if your statements look like natural language statements about the underlying real world objects whose representation you are reasoning about.

thrwaway69 7y ago
I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency behaviour(I think this causes me to snap more than language syntax. Dependencies don't have clear code navigation guidelines, proper structure or docs than the language they are in). From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. If there are more js developers, then that means you can hire more for less overall. Obviously things are more complicated. If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Anything trendy will get too many breaking changes or fixes. Heck, having visible source code can be liability too in future. I may as well choose something that will be hard to decompile. Not to mention the external dependencies that you will need to mirror or even maintain. I think most businesses that are dependent on tech can be divided into short lived and very long lived ignoring certain type of software and industries. For short lived businesses or customers, your stack shouldn't matter much compared to the responsiveness of development. What incentive are there to provide quality software to companies that will live 5 years at best? (Note - quality here refers to ideal stack/code that programmers expect. Eg - unnecessarily performant, kubernetified, micro architecture) None. For long term businesses, software is an ongoing cost. They can afford to renew their software every 10 years so why should you write something that is expandable, easy to migrate and another team to take over. Beside, their requirements change drastically over time. It will end up being a monolith. I don't have to work right now but if I ever do, I am gonna work on the interesting bits while hiring someone in a third world country to outsource parts that I don't from my job. I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.

tomerbd 7y ago

Ruby is truly nice, I just wish I had the option for static typing built into the language, as a human I prefer it because then IDE support is much better for any refactor, etc and getting to maintain other people code.

elliotlarson 7y ago
You're not alone. Stripe has been working on adding types to Ruby with their static type checker, Sorbet: https://sorbet.org/ https://sorbet.org/. This seems to have a bit of momentum at this point. Assuming it continues in popularity I'm excited to see how this helps to improve Ruby work in an IDE.
- tomerbd 7y ago
  Looks interesting! will have a look.
Can_Not 7y ago
Have you tried crystal?

pdimitar 7y ago

Strange takeaway in the title. Mine are: - He regrets introducing threads. He now prefers other parallelism/concurrency paradigms and is possibly looking into introducing them in Ruby 3 (that part wasn't clear in the interview). - He regrets adding global variables. - He regrets not focusing on immutability primitives earlier. - He and the maintainers team look at Python, JavaScript and Elixir for inspiration. - He seems a bit disappointed that Ruby is mostly used for web development only and would be happy if it was used in research and AI. - He regrets not investing even a little effort in static typing earlier but is now working on an optional typing system where you choose to describe types in a separate file. (Reminds me of C/C++ and OCaml header files.) I hope I’m not subconsciously emulating a sensationalistic journalist here but it doesn’t seem he’s very pleased with the current state of affairs. A lot of changes, indeed inspired from other languages, seem to be on their way to Ruby 3. --- I’m pretty indifferent to Ruby these days. I’ve worked 6 years with Rails to a moderate financial success back then but the problems were obvious almost from the start: too much magic and implied behaviour, too much global stuff changing below your feet, way too slow DB layer (it’s known that your DB will respond in 2ms and ActiveRecord will proceed to waste 100+ ms on serialisation before and after), managing bigger projects becomes huge pain, and a number of others. People just keep buying the promise of “but you get to make an MVP really quickly!”. Yeah well, but I want to maintain it past that stage too. Where I was doing with this is: Ruby is a very okay language and is very nice for sketching. It's readable, has libraries for a ton of stuff, and performs alright (especially without Rails). But I never found good use of it outside of small projects. Any serious business work becomes very painful to maintain and stay on top of for bigger projects. I’m aware there are practices that make it possible (Basecamp is a huge inspiration!) but I personally found them only half-working. YMMV, of course.

norswap 7y ago
Good points. Personally, it's a bit puzzling to me why the ML community ran with Python and why there isn't a popular alternative for Ruby. It's very capable in terms of making DSLs. My hunch is that the number-crunching libraries were better in Python (numpy etc).
- 7y ago

Evrone 7y ago

We’re thrilled that our good friend Yukihiro Matsumoto, creator of the Ruby programming language, has been able to join us at RubyRussia 2019 as a speaker for the second time, having previously spoken three years ago at RubyRussia 2016. In the time that we’ve been holding the conference — now more than ten years — Ruby has undergone a great deal of evolution, and Evrone has grown and developed alongside it. Grigory Petrov, Developer Relations at Evrone, sat down with Mr Matsumoto to hear from him first-hand about being a star, the philosophy behind Ruby’s design and evolution, and a little about Japanese life and culture.

monadic2 7y ago

Shit, he should have considered the human cost of method_missing. Yes, I am serious, it’s a massive productivity drain. You encounter methods that you can’t google for, so your grep game better be good to get work done (grep for a portion of the name, and then method_missing itself if that fails). An IDE is useless in this case and your performance goes out the window. It’s much better to dynamically generate a finite number of methods you can see when inspecting objects.... I suspect those would jit better, too. Oh, you want to access the call stack on your server to figure out where that frame is? Jokes on you, ruby has no remote debugging mechanism aside from a core dump or building your own heap inspection access. Dang, why was this flagged?

emiliovesprini 7y ago

Reminds me of ''Programs are meant to be read by humans and only incidentally for computers to execute'' from Structure And Interpretation Of Computer Programs. What always gets me about that quote is that's it's obviously false. There are exceptions (such as space shuttle controls), but most software that's ''important'' is important because of how much it's run --Firefox is run a whole lot more than it is read-- and so this Incidental Execution stuff is nonsense. Performance and Readability are both important goals. Most of the time they're not even opposed as to justify pitching them against one another like this.

manoj_venkat92 7y ago

I was a RoR developer for two years and immensely enjoyed coding in Ruby, well technically, RoR(Ruby on Rails). It was in a startup and features were being developed at a rapid pace and it really felt like the right choice. But I also noticed that as companies grow they have problems with the maintenance of the code as well as the performance like twitter moving away.

sparker72678 7y ago

Dear everyone crapping on Ruby (and esp. Rails) in this thread (and every other time this comes up), If you don't like Ruby or Rails, that's okay! No, really. You can use something else. You won't hurt our feelings! Programming languages and their frameworks can actually be a preference, not a moral issue. We're here because we like it, and it's totally cool that you don't! Please use what you love; we are, and we know how powerful that can be. Cheers, — Every Ruby Developer

thunderbong 7y ago

I'm seriously not able to distinguish how many of these comments are about Ruby and how many are about Ruby on Rails (RoR). From the very beginning Ruby's popularity and criticism have hinged on RoR. And most people tend to conflate the two completely. Personally, I love Ruby but don't like RoR. RoR seems to bloated to me. Of course it does many things. But very rarely have I come across projects which require all those things. And even then, I'm quite sure, we wouldn't be able to use all that RoR has to offer. For many, many, years now, my stack has been Roda / Sinatra for routing and Sequel for DB access. And whenever, we've come across some requirement which needs heavy lifting, there are enough Ruby gems which do that without tying you up with the RoR framework.