4 ms·

I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is. It seems like i

I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is. It seems like it has every syntax in there somewhere.

api 5y ago
That's a problem with LISP-style languages too. Too much flexibility and dynamic syntax leads to write-only languages, or at least languages that are write-only-by-the-original-author. You can see the opposite end of that spectrum in Go, which can be readily read by anyone since there's generally only one good way to do anything.
ferdowsi 5y ago
The only way I've seen Ruby work professionally is by using tooling that prevents developers from getting too clever with creating write-only code.
nauticacom 5y ago
I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is I'd say this is a plus, at least in certain dimensions. One of the best descriptions I've heard of Rails' ActiveSupport (a collection of extensions to built-in types included in Rails) is as a dialect of Ruby, one specific for developing web applications. Other domains could and should use different dialects.
snek_case 5y ago
IMO that's one of the biggest weaknesses of Ruby. The language offers lots of different ways to do the same thing. You can say that makes the language more expressive. Sure, but it also means as a newcomer, there's a lot more language features to learn about. It makes the language less approachable to outsiders. Python and Ruby occupy similar niches. Python has many more libraries, so people will say, that's why Python has been more successful, but IMO, even if Python and Ruby had as many useful libraries, most people would still choose Python, because it's a simpler and easier to learn language. That may have contributed to Python getting a headstart in the beginning. I'm sure some people would say that's a case of "worse is better", but I think you also have to have some empathy for other programmers. When collaborating on a programming project, having a project that is easier for others to understand is easier. Having a language with less weirdness, less peculiarities and less complexity is a plus.
- setpatchaddress 5y ago
  I think it’s much simpler than that. Ruby didn’t have good documentation in English until the mid-2000’s. Python was in use by the English-speaking world before the turn of the century. Documentation + you can generally understand it at a glance == total Python dominance. Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
  - Jtsummers 5y ago
    > Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features. My inkling is that this is because it is hard to have a general purpose language that lends itself to both novices and experts, and to small scale and large scale. Not impossible, but hard. Those categories desire/need different things, and will use the language in vastly different ways. BASIC (for all its problems) was a better first language for many people than C or Fortran, but BASIC also didn't scale well to larger systems (structured variants scaling better). Then you start getting BASICs supporting OO and other features which complicate them and lose the appeal to novices, but more effectively meet the needs of intermediate-to-advanced users and maintainers of medium-to-large scale systems. See also Pascal and its evolution. From a small language to a still small but not as small language in Delphi and others. For the novices, they can still use that small core. But it's now harder for them to onboard with a larger project or a project developed by more advanced users of the language. Especially as the standard library (for the language implementation, if not the language proper) grows. Scheme, over the various revisions, has seen a similar conflict, culminating in the effective rejection of R6RS and the division into small and large for R7RS. And those are languages that were largely meant to support novices and learners. Python started off similarly. Now it's older, and its users have aged, and they want to do more powerful things with it and maintain larger and larger systems with it. On the small vs large side, look at the evolution of JavaScript. It was literally meant for in-page scripting, to do small things and not be the larger system, but a mere component. Like a shell script that copies two files contrasted with the actual OS or shell implementation. But now 25 years or so later it's a vastly different language, and people are building distributed systems on top of it.

I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is. It seems like it has every syntax in there somewhere.

api 5y ago

That's a problem with LISP-style languages too. Too much flexibility and dynamic syntax leads to write-only languages, or at least languages that are write-only-by-the-original-author. You can see the opposite end of that spectrum in Go, which can be readily read by anyone since there's generally only one good way to do anything.

ferdowsi 5y ago

The only way I've seen Ruby work professionally is by using tooling that prevents developers from getting too clever with creating write-only code.

nauticacom 5y ago

I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is I'd say this is a plus, at least in certain dimensions. One of the best descriptions I've heard of Rails' ActiveSupport (a collection of extensions to built-in types included in Rails) is as a dialect of Ruby, one specific for developing web applications. Other domains could and should use different dialects.

snek_case 5y ago

IMO that's one of the biggest weaknesses of Ruby. The language offers lots of different ways to do the same thing. You can say that makes the language more expressive. Sure, but it also means as a newcomer, there's a lot more language features to learn about. It makes the language less approachable to outsiders. Python and Ruby occupy similar niches. Python has many more libraries, so people will say, that's why Python has been more successful, but IMO, even if Python and Ruby had as many useful libraries, most people would still choose Python, because it's a simpler and easier to learn language. That may have contributed to Python getting a headstart in the beginning. I'm sure some people would say that's a case of "worse is better", but I think you also have to have some empathy for other programmers. When collaborating on a programming project, having a project that is easier for others to understand is easier. Having a language with less weirdness, less peculiarities and less complexity is a plus.

setpatchaddress 5y ago
I think it’s much simpler than that. Ruby didn’t have good documentation in English until the mid-2000’s. Python was in use by the English-speaking world before the turn of the century. Documentation + you can generally understand it at a glance == total Python dominance. Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
- Jtsummers 5y ago
  > Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features. My inkling is that this is because it is hard to have a general purpose language that lends itself to both novices and experts, and to small scale and large scale. Not impossible, but hard. Those categories desire/need different things, and will use the language in vastly different ways. BASIC (for all its problems) was a better first language for many people than C or Fortran, but BASIC also didn't scale well to larger systems (structured variants scaling better). Then you start getting BASICs supporting OO and other features which complicate them and lose the appeal to novices, but more effectively meet the needs of intermediate-to-advanced users and maintainers of medium-to-large scale systems. See also Pascal and its evolution. From a small language to a still small but not as small language in Delphi and others. For the novices, they can still use that small core. But it's now harder for them to onboard with a larger project or a project developed by more advanced users of the language. Especially as the standard library (for the language implementation, if not the language proper) grows. Scheme, over the various revisions, has seen a similar conflict, culminating in the effective rejection of R6RS and the division into small and large for R7RS. And those are languages that were largely meant to support novices and learners. Python started off similarly. Now it's older, and its users have aged, and they want to do more powerful things with it and maintain larger and larger systems with it. On the small vs large side, look at the evolution of JavaScript. It was literally meant for in-page scripting, to do small things and not be the larger system, but a mere component. Like a shell script that copies two files contrasted with the actual OS or shell implementation. But now 25 years or so later it's a vastly different language, and people are building distributed systems on top of it.