21 ms·

"Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will ru

"Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves." Matz 2003 https://www.artima.com/intv/ruby.html https://www.artima.com/intv/ruby.html

jhvkjhk 6y ago
The cobbler’s children have no shoes. Matz bring them shoes.
- doodpants 6y ago
  Actually it was _why the lucky stiff who originally brought the world shoes [1]. :-) [1] http://shoesrb.com/ http://shoesrb.com/
mrmonkeyman 6y ago
As a computer engineer you need to focus on computers, not people. I know this is popular right now, but it sucks and it is wrong and leads to bad results. Yes, the current state of affairs is a "bad result", young ones. We expect civil engineers to account for people, but they think about materials, planning, math, etc. Stay close to your craft or you might see it and/or your position in it evaporate.
- jashmatthews 6y ago
  Working in a small civil engineering firm is almost exactly the same as working in software. It's all about people.
  - mrmonkeyman 6y ago
    I'd rather avoid the bridges you build then.
  - 0x445442 6y ago
    At the design level where stresses strains and loads are the considerations, it’s nothing about the people. I think that’s the level the parent was thinking of.
- dagi3d 6y ago
  I just find hilarious when people compare software engineering to other disciplines just because potatoes
- inopinatus 6y ago
  You might want to look up the definition of "civil".
cercatrova 6y ago
I have to agree with the dead comment here. Focusing just on people is how we got to the stage of having extremely fast CPUs that can compute billions if not trillions of operations and yet websites and apps lag. We can run full fledged games at 240 FPS and yet, websites and apps lag. It truly is heresy to not fully utilize the hardware we create, such a waste, simply because people don't optimize at every step of the process, useless abstraction on top of useless abstraction. In game engines they do, to some extent, because they have to, and so should they in general purpose applications as well.
- Santosh83 6y ago
  Apps and sites are pushed out fast, crammed with the everything including the kitchen sink and monetised to the hilt. This is more the reason why they suck these days, rather than because programmers are modelling abstractions from the human end rather than the machine end.
  - cercatrova 6y ago
    And yet Ruby has a global interpreter lock and is an interpreted language. Ruby, I assume as a language, has had all the time in the world to develop well. Why don't we fully utilize our hardware while still allowing for high usability such as with Rust with algebraic data types or (if you don't want to deal with a borrow checker) recent C++ with auto pointers, or Haskell which is garbage collected but is still quite fast and of course highly expressive?
    - pmontra 6y ago
      IMHO the answer is that Rust, C++ and Haskell are out there and anybody can use them to build a web site. Maybe the real question is why there are developers the prefer coding in Ruby. In my case, I barely used C++ in the mid 90s and only read some examples of Rust and Haskell. I can't really tell anything about Haskell. Rust and C++ look too hard to use, I don't want to care anymore about all that micromanagement stuff. I'm really with Matz on this. I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features. There are plenty of languages with that kind of typing, there is no need to have another one. Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.
stewbrew 6y ago
Dynamic typing never was in the interest of the human developer but in the interest of the lazy language designer. This release looks interesting. Let's see how type annotations work out in real life and if people use them.
- joelbluminator 6y ago
  Yay lets argue again about types vs dynamic! I'm sure throwing another opinion on this older than time debate would finally settle things.
  - pjmlp 6y ago
    The fact that all dynamic languages have adopted some kind of static verification tool has settled the discussion. It wouldn't be needed if unit tests were enough as it used to be sold.
    - joelbluminator 6y ago
      The fact that all static languages are adding an Any type means the discussion is settled. Lol. How has this settled anything? You think Ruby devs from now on are all gonna use Sorbet or RBS? I highly doubt it. Some very unique companies like Shopify or Github, which don't really represent the average Ruby shop, may make a limited use of these tools. The vast majority won't.
      - pjmlp 6y ago
        Actually they are catching up with Algol features.
      - stewbrew 6y ago
        Okay you convinced me to stick with my assessment of ruby. I regret every single time I have chosen to write something in ruby. I guess this release won't change that if nobody uses these features.
pmcollins 6y ago
reminds me of the quote by Martin Fowler > Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
- Rapzid 6y ago
  I agree. When I think Ruby it brings to mind the Chef code base. Massive amounts of indirection via one line, but only one time used?, methods. Mixin abuse requiring manually searching an ungodly number of files to figure out where behavior is coming from. Errors pointing to non-existent lines of code because somebody thought it was a good idea to generate classes in loop to avoid boiler plate. Sandi Metz' "come to Jesus" book. And I like Ruby. And I hate Ruby.
pdimitar 6y ago
I agree with the general sentiment but it has been brought to an extreme to the point that things in many dynamic languages are way too slow. Maybe some of the CS courses are to blame; people think "hey, let me make my own language and an interpreter!" -- and the rest is history. IMO a chunk of the programming world is entering a mature stage where much more work is put in the runtime of a language on not on the language itself. End of the day, you are going to have a call from an executive asking why the hosting bills are ballooning. I've saved some of my customers literal [tens of] thousands of $$$ a month by migrating a critical chunk of their services from Ruby on Rails to Elixir's Phoenix and, on one occasion, Rust's Rocket. Programmer ergonomy and happiness are important, don't get me wrong. But IMO we are fixating way too much on them in some languages / frameworks. Some pragmatism should be put back into the picture.
- bachmeier 6y ago
  > things in many dynamic languages are way too slow "No matter how fast or slow your language might be, there will always be some applications for which your language is fast enough and some for which it's not." -- Mark Twain
- cpuguy83 6y ago
  Did you not read the goals of Ruby 3.0? (Hint, it's performance, specifically the goal was 3x increase over 2.0).
  - pdimitar 6y ago
    I did, but even in this thread people pointed out that the gains are not 3x, more like 1.2x - 1.4x. Which is still a progress.

jhvkjhk 6y ago

The cobbler’s children have no shoes. Matz bring them shoes.

doodpants 6y ago
Actually it was _why the lucky stiff who originally brought the world shoes [1]. :-) [1] http://shoesrb.com/ http://shoesrb.com/

mrmonkeyman 6y ago

As a computer engineer you need to focus on computers, not people. I know this is popular right now, but it sucks and it is wrong and leads to bad results. Yes, the current state of affairs is a "bad result", young ones. We expect civil engineers to account for people, but they think about materials, planning, math, etc. Stay close to your craft or you might see it and/or your position in it evaporate.

jashmatthews 6y ago
Working in a small civil engineering firm is almost exactly the same as working in software. It's all about people.
- mrmonkeyman 6y ago
  I'd rather avoid the bridges you build then.
- 0x445442 6y ago
  At the design level where stresses strains and loads are the considerations, it’s nothing about the people. I think that’s the level the parent was thinking of.
dagi3d 6y ago
I just find hilarious when people compare software engineering to other disciplines just because potatoes
inopinatus 6y ago
You might want to look up the definition of "civil".

cercatrova 6y ago

I have to agree with the dead comment here. Focusing just on people is how we got to the stage of having extremely fast CPUs that can compute billions if not trillions of operations and yet websites and apps lag. We can run full fledged games at 240 FPS and yet, websites and apps lag. It truly is heresy to not fully utilize the hardware we create, such a waste, simply because people don't optimize at every step of the process, useless abstraction on top of useless abstraction. In game engines they do, to some extent, because they have to, and so should they in general purpose applications as well.

Santosh83 6y ago
Apps and sites are pushed out fast, crammed with the everything including the kitchen sink and monetised to the hilt. This is more the reason why they suck these days, rather than because programmers are modelling abstractions from the human end rather than the machine end.
- cercatrova 6y ago
  And yet Ruby has a global interpreter lock and is an interpreted language. Ruby, I assume as a language, has had all the time in the world to develop well. Why don't we fully utilize our hardware while still allowing for high usability such as with Rust with algebraic data types or (if you don't want to deal with a borrow checker) recent C++ with auto pointers, or Haskell which is garbage collected but is still quite fast and of course highly expressive?
  - pmontra 6y ago
    IMHO the answer is that Rust, C++ and Haskell are out there and anybody can use them to build a web site. Maybe the real question is why there are developers the prefer coding in Ruby. In my case, I barely used C++ in the mid 90s and only read some examples of Rust and Haskell. I can't really tell anything about Haskell. Rust and C++ look too hard to use, I don't want to care anymore about all that micromanagement stuff. I'm really with Matz on this. I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features. There are plenty of languages with that kind of typing, there is no need to have another one. Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.

stewbrew 6y ago

Dynamic typing never was in the interest of the human developer but in the interest of the lazy language designer. This release looks interesting. Let's see how type annotations work out in real life and if people use them.

joelbluminator 6y ago
Yay lets argue again about types vs dynamic! I'm sure throwing another opinion on this older than time debate would finally settle things.
- pjmlp 6y ago
  The fact that all dynamic languages have adopted some kind of static verification tool has settled the discussion. It wouldn't be needed if unit tests were enough as it used to be sold.
  - joelbluminator 6y ago
    The fact that all static languages are adding an Any type means the discussion is settled. Lol. How has this settled anything? You think Ruby devs from now on are all gonna use Sorbet or RBS? I highly doubt it. Some very unique companies like Shopify or Github, which don't really represent the average Ruby shop, may make a limited use of these tools. The vast majority won't.
    - pjmlp 6y ago
      Actually they are catching up with Algol features.
    - stewbrew 6y ago
      Okay you convinced me to stick with my assessment of ruby. I regret every single time I have chosen to write something in ruby. I guess this release won't change that if nobody uses these features.

pmcollins 6y ago

reminds me of the quote by Martin Fowler > Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Rapzid 6y ago
I agree. When I think Ruby it brings to mind the Chef code base. Massive amounts of indirection via one line, but only one time used?, methods. Mixin abuse requiring manually searching an ungodly number of files to figure out where behavior is coming from. Errors pointing to non-existent lines of code because somebody thought it was a good idea to generate classes in loop to avoid boiler plate. Sandi Metz' "come to Jesus" book. And I like Ruby. And I hate Ruby.

pdimitar 6y ago

I agree with the general sentiment but it has been brought to an extreme to the point that things in many dynamic languages are way too slow. Maybe some of the CS courses are to blame; people think "hey, let me make my own language and an interpreter!" -- and the rest is history. IMO a chunk of the programming world is entering a mature stage where much more work is put in the runtime of a language on not on the language itself. End of the day, you are going to have a call from an executive asking why the hosting bills are ballooning. I've saved some of my customers literal [tens of] thousands of $$$ a month by migrating a critical chunk of their services from Ruby on Rails to Elixir's Phoenix and, on one occasion, Rust's Rocket. Programmer ergonomy and happiness are important, don't get me wrong. But IMO we are fixating way too much on them in some languages / frameworks. Some pragmatism should be put back into the picture.

bachmeier 6y ago
> things in many dynamic languages are way too slow "No matter how fast or slow your language might be, there will always be some applications for which your language is fast enough and some for which it's not." -- Mark Twain
cpuguy83 6y ago
Did you not read the goals of Ruby 3.0? (Hint, it's performance, specifically the goal was 3x increase over 2.0).
- pdimitar 6y ago
  I did, but even in this thread people pointed out that the gains are not 3x, more like 1.2x - 1.4x. Which is still a progress.