Whatever Happened to the Ruby Programming Language? (infoworld.com) 148
Three years after Rails was introduced in 2005, InfoWorld asked whether it might the successor to Java.
That didn't happen. So this week InfoWorld "spoke to current and former Ruby programmers to try to trace the language's rise and fall." Some responses: "Rails came along at the cusp of a period of transformation and growth for the web," says Matthew Boeh, a Ruby developer since 2006. "It both benefited from and fueled that growth, but it was a foregone conclusion that it wasn't going to be the only success story." Boeh recently took a job as a senior staff software engineer at Lattice, a TypeScript shop. "You could say that Ruby has been a victim of its own success, in that its community was a major driving force in the command-line renaissance of recent years," he says. "In the early '00s it was introducing REPL-driven development to people who had never heard of Lisp, package management to people who would have been scared off by Perl's CPAN, test-driven development to people outside the highly corporate Java world, and so on. This is all stuff that is considered table stakes today. Ruby didn't originate any of it, but it was all popularized and made accessible by Rubyists...."
"The JavaScript ecosystem in its current form would have been unimaginable in 2004 — it needed both the command line renaissance and the takeoff of the web platform," adds Lattice's Boeh. "Did you know it took a full decade, 1999 to 2009, to release a single new version of the JavaScript standard? We get one yearly now. Rails became a big deal in the very last time period where it was possible to be a full-stack developer without knowing JavaScript...."
[W]hen it comes to data science, Python has a leg up because of the ready availability of libraries like TensorFlow and Keras. "These frameworks make it easy for coders to build data visualizations and write programs for machine learning," says Pulkit Bhardwaj, e-commerce coach at BoutiqueSetup.net. JavaScript, meanwhile, has spawned seemingly endless libraries that developers can easily download and adapt for just about any purpose. "As a technologist, you can go on your own hero's journey following whatever niche thing you think is the right way to go," says Trowbridge. But when it comes to JavaScript, "these libraries are excellent. Why ignore all of that?"
Many of those libraries were developed by community members, which inspired others to contribute in a snowball effect familiar to anyone involved in open source. But one big player has had an outsized influence here. Python's TensorFlow, which Bhardwaj called a "game-changer," was released by Google, which has followed academia's lead and made Python its internal scripting language. Google, as the maker of the dominant web browser, also has an obvious interest in boosting JavaScript, and Trowbridge gives Google much of the credit for making JavaScript much faster and more memory efficient than it once was: "In some ways it feels almost like a low level language," he says. Meanwhile, Ruby is widely acknowledged to be lagging in performance, in part because it lacks the same sort of corporate sponsor with resources for improving it.
That didn't happen. So this week InfoWorld "spoke to current and former Ruby programmers to try to trace the language's rise and fall." Some responses: "Rails came along at the cusp of a period of transformation and growth for the web," says Matthew Boeh, a Ruby developer since 2006. "It both benefited from and fueled that growth, but it was a foregone conclusion that it wasn't going to be the only success story." Boeh recently took a job as a senior staff software engineer at Lattice, a TypeScript shop. "You could say that Ruby has been a victim of its own success, in that its community was a major driving force in the command-line renaissance of recent years," he says. "In the early '00s it was introducing REPL-driven development to people who had never heard of Lisp, package management to people who would have been scared off by Perl's CPAN, test-driven development to people outside the highly corporate Java world, and so on. This is all stuff that is considered table stakes today. Ruby didn't originate any of it, but it was all popularized and made accessible by Rubyists...."
"The JavaScript ecosystem in its current form would have been unimaginable in 2004 — it needed both the command line renaissance and the takeoff of the web platform," adds Lattice's Boeh. "Did you know it took a full decade, 1999 to 2009, to release a single new version of the JavaScript standard? We get one yearly now. Rails became a big deal in the very last time period where it was possible to be a full-stack developer without knowing JavaScript...."
[W]hen it comes to data science, Python has a leg up because of the ready availability of libraries like TensorFlow and Keras. "These frameworks make it easy for coders to build data visualizations and write programs for machine learning," says Pulkit Bhardwaj, e-commerce coach at BoutiqueSetup.net. JavaScript, meanwhile, has spawned seemingly endless libraries that developers can easily download and adapt for just about any purpose. "As a technologist, you can go on your own hero's journey following whatever niche thing you think is the right way to go," says Trowbridge. But when it comes to JavaScript, "these libraries are excellent. Why ignore all of that?"
Many of those libraries were developed by community members, which inspired others to contribute in a snowball effect familiar to anyone involved in open source. But one big player has had an outsized influence here. Python's TensorFlow, which Bhardwaj called a "game-changer," was released by Google, which has followed academia's lead and made Python its internal scripting language. Google, as the maker of the dominant web browser, also has an obvious interest in boosting JavaScript, and Trowbridge gives Google much of the credit for making JavaScript much faster and more memory efficient than it once was: "In some ways it feels almost like a low level language," he says. Meanwhile, Ruby is widely acknowledged to be lagging in performance, in part because it lacks the same sort of corporate sponsor with resources for improving it.
What happened is obvious (Score:5, Funny)
It went off the rails. /rimshot
Not a lot of Ruby in this Ruby article? (Score:2)
Re: (Score:3)
I could get done in a week with rails which any other language would take over a month.
I feel like that with Coldfusion, especially because of the libraries I've written for it over time.
Re:What happened is obvious (Score:5, Interesting)
After Twitter moved away from Ruby (to Scala), it turned out the problem wasn't the language at all (or Rails, which has all the advantages and drawbacks of any ORM, which can be overcome). The problem was Twitter's incompetence at writing database queries.
Eventually, Twitter solved their database problems, got bought by Elon Musk, and Ruby is still here and a great solution. For the backend it's much better than Javascript. (For the frontend, you still mostly have no choice but Javascript or raw HTML, but that is slowly changing [fermyon.com].)
Re: (Score:3)
You can't really blame Twitter here. Ruby is weird, over-complicated, and needlessly obtuse. I honestly don't see the appeal, and it looks like I'm not alone.
I don't want to sit here and pick on it, it's not that important to me, so I'll just toss out one thing that I think gets at the core of what's wrong with Ruby: Blocks, procs, and lambdas ... just ... why? It's absolutely baffling. Who in their right mind would choose make a mess like that instead of just first-class functions?
For the backend it's much better than Javascript.
What makes you say t
Pull the other one (Score:2, Funny)
Re: What happened is obvious (Score:2)
Re: (Score:2)
I honestly don't see the appeal, and it looks like I'm not alone.
OK, then you should try to understand the appeal. You're basically declaring your ignorance here.
Re: What happened is obvious (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I took a very quick look at that absurdity. An early claim is that Ruby is easy to read, which is laughable, given the bizarre and inconsistent syntax.
I'm glad you like it. Try to understand why so many go out of their way to avoid it.
Re: (Score:2)
Why's Poignant Guide is a treasure, but a good reason to use Ruby for serious (commercial) work it is not.
Re: (Score:2)
Who in their right mind would choose make a mess like that instead of just first-class functions?
A hobbyist, who "designs" a language.
Re: (Score:2)
This function does NOT return from the main function, even though it LOOKS like it should.
I don't understand your confusion here. Did you not notice that you had create a function? I'm guessing you copied that from somewhere without understanding what was actually happening. Though I should point out that you'll have an easier time with JS if you avoid most of ES6, which was a huge mistake.
That particular problem with ES6 is exactly the kind of problem that you seen all over Ruby. Pointless redundancy, occasionally with minor changes that you shouldn't want in the first place.
Remember, Python did not HAVE any higher-order ANYTHING 15 years ago,
Who's defending
Re: (Score:2)
Re: (Score:2)
I think I defined it pretty well. Incredibly simple and at the same time very powerful. Readability, you'll notice, wasn't a requirement. Neither was "compact". Putting those two together seems odd to me, as those two thing often work against one another! A lot of languages happily exchange readability for terseness, which seems insane to me. Maybe the designers have math envy?
Though if you want readability, Ruby is right out. This is what one user [ycombinator.com] decided to offer as an example of Ruby's "elegance":
Re: (Score:3)
Unfortunately, you do have to keep state in the backend, so we confine it all to the database (or a series of databases). What that means in essence is that your database is the bottlene
Re: (Score:2)
I liked Ruby for small projects, like a mailing list management system I wrote with it, but Rails was unusable for me. It would take 60 seconds to get Rails loaded and once it was it NEVER worked the way the docs said it would. They'd say "oh the system will do for you so you don't have to". Nope, I had to do it regardless. I gave up on Ruby and Rails in 2008 or so when someone suggested Python as a replacement. It's not perfect but it at least doesn't make claims it can't backup.
Re: (Score:2)
Re: (Score:2)
What happened to Ruby is the same question of "what happened to Perl" and "what happened to Java"
The developers of the language took it in a direction that the users didn't want.
Perl stopped being useful the minute PHP came out. With PHP3, every site that was running mod_perl switched to mod_php, and then eventually by PHP5 mod_fcgid to run php.
Ruby relied on the latter functionality. But since it was not regularly installed on servers, it had to be installed by things like Cpanel. Which would only install
Java games (Score:2)
RuneScape was made in Java. I suspect it was eventually ported to something else when it became impossible to run an applet in a browser. Jagex had a suite of other Java games (FunOrb) but let them die rather than try to port them. In that case the issue wasn't so much bitrot as active hostility against the environment needed to execute the games.
The website javagaming.org reckoned with the same issue. It used to have an annual demo-scene-type contest for applets [wikipedia.org], tried alternatives when it became harder to
Re: (Score:2)
Perl stopped being useful the minute PHP came out.
That is nonsense. Perl and PHP have hardly anything to do with each other.
Hint: /. is written in Perl, and there is no real reason to port it to PHP.
Look at Java, how many games are made in Java? One. Minecraft.
There are hundreds of games written in Java.
I suggest to google a bit, lol.
rails was the strong point, but became irrelecant (Score:5, Interesting)
Rails was the only good reason for Ruby to have a success trajectory. It's an object oriented language with mixin and monkey-patch support -- Python can do this too, as well as several other introspective languages, even Go if you aren't scared (surprise!). The thread and memory models aren't innovative enough to write home about, so no new points there. The switch from jquery to react basically broke Rails and caused a bit of a chasm, which was eventually filled, but it wasn't as pretty as it was before (imho).
The language itself still has some utility, just by nature of the HUGE number of really solid Gems out there (I think the Ruby community created way better libraries than the JS community, but that's subjective).
If you're looking to start a new project and thinking "Maybe Ruby" -- don't. Use Python, or Go, or even Rust. Use a language that has a solid community, that a lot of people know, and enjoy using (okay, so probably not Python then ;)
Re: (Score:2)
Ruby is still in heavy use for DevOps: Both Puppet and Chef rely on it.
Rails was never great, and as projects using it grew large and unwieldy, developers figured that out. Its database abstractions were especially troublesome when interacting with large, complex data sets.
Re: (Score:2)
And redmine. I mean updating anything is a horror show, but redmine.
Re: (Score:2)
Puppet and Chef could just have easily used Python or literally anything else. I think those use cases were riding coat tails for publicity.
One of the strongest points of Rails was the database abstractions. The framework make the data schema a first class citizen, forced you to keep your data models simple (you could break this rule via Gems though), make schema migrations via CI a simple action, and I've yet to find many contenders of equal prowess.
Have you written anything of size on Rails? I have, and y
Re:rails was the strong point, but became irreleca (Score:4, Insightful)
forced you to keep your data models simple
You mean ActiveRecord? That's because it was abysmal and too cumbersome for anything by the simplest cases.
Re: (Score:3)
Activerecord was a mess. Its lead dev had publically stated that he didn't believe that referential integrity constraints belonged in the database which was an *immediate* red flag that perhaps there was something a bit brainbroke about the whole project.
And don't even get me started on autopluralization. That was a horrifying antipattern (That rails spent the next decade and a half trying to bury but never quite succeded)
Its a shame, I liked the rest of Rails, but compared to Djangos magnificent ORM, Activ
Re: (Score:2)
You know what the answer is? Don't encode your business login in complex relational database structures!!
Less facetiously, I'm not sure why it happened (perhaps as a result of sounding convincing to dumb ass managers?) but at a certain point the whole industry decided (incorrectly) that it was axiomatic that business logic belonged in the relational database. This is just asinine and was driven by DBA's desire to rule the world (in my humble opinion).
As soon as you look at what is possible with DB tech like
Re: (Score:2)
but at a certain point the whole industry decided (incorrectly) that it was axiomatic that business logic belonged in the relational database.
On which side of the planet did "the whole industry" decide that?
I actually never saw such a monstrosity, but some people tried hard to put as much business logic as possible into stored procedures :P There actually speaks nothing against it: if it makes sense.
What makes sense and what not is sometimes not easy to know from the start on. I propose usually not to use
Ansible, Ansistrano FTW! (Score:2)
Re: (Score:2)
Re: (Score:3)
Ruby feels like a better Python than Python in a lot of ways. Ruby borrowed heavy from Smalltalk, THE object oriented language, and feels better at it than Python. Although Ruby and Python are extremely similar from my view point; if you can write in one you can write in the other. I've never used Python libraries, you can never rely on the machines having them or being able to tell people how to install them, and Python really broke compatibility with release 3 which was a shame so a double hassle to get
Re: rails was the strong point, but became irrelec (Score:2)
Tie with duck tape. Yup, welcome to the world of the web "dev".
Re: (Score:2)
If you're using tuck tape to "tie" things, then there's a second problem. Both using the wrong tool for the job, plus using the tool wrong.
Re: (Score:2)
filled a non existent niche ? (Score:3)
I love Perl and I love python. Perl is a text woodchipper and a sysadmins wet dream for bash script replacement. Python is better for objects and structured large programs and with numpy and jupyter notebooks it's a wonderful data analysis package. Ruby seems to be Perl with tidier rules and syntax and like a ghetto python upgrade. Why would I want ruby when Perl and python have both ends of the spectrum covered better?
What was its niche ?
Re: (Score:2)
It's niche was what Python, Go, and rust are better at .. they learnt a lot from it...
Re: (Score:2)
What was its niche ?
Writing DSLs. E.g. RAILS, the DB abstraction layer is a DSL.
Re: (Score:2)
Hipsters (Score:3, Insightful)
Re: Hipsters (Score:2)
Why is python so corny and square?
The Hipsters are alive and kicking. (Score:3)
You should check out the Node camp. Those folks are so far off the charts on the Hipster metric it's actually quite fascinating. They even got some really crazy ideas that actually work. Radical de-normalisation that's truely more of a "What's normalisation?", using Github directly as package archive, the VDOM craze or Utility CSS with crazy sh*t like Tailwind that throws HTML/CSS semantic purists into instant beserk mode. The whole show is actually pretty entertaining to watch, you should definitely chec
Paving the way for Rust (Score:4, Insightful)
Rusty Rails will be the new programming language.
Re: (Score:2)
Ruby and Rails are still great (Score:4, Interesting)
Re: (Score:2)
The main problem with Ruby is that it doesn't have a Google or a Microsoft behind it
I count that as an advantage.
Re: (Score:2)
In many cases the performance is quite good
Are you sure you're talking about Ruby?
Re: (Score:2)
Oh? Because here in reality [vercel.app], it's laughably slow, even timing out on many tests.
Unbelievable as it may be, it's even worse than python [vercel.app], which is shamefully slow.
Re: (Score:2)
"It didn't give the results I wanted, therefore, the test is wrong!"
Ruby is slow. That's just reality. You can wish things were different, but that's just the way things are. It'll be okay.
Re: (Score:2)
If you have something better, present it. I've given you another benchmark as well that shows the same thing: Ruby is slow.
That's pretty well established. You'll have a hard time even finding other Ruby fans that refuse to acknowledge the serious performance issues. The only person who seems to disagree with reality here is you.
Re: (Score:2)
it's actually selecting for languages with good parallel threading support and concurrency in general
Umm... The languages I compared it against were Python and JavaScript.
Anyhow, good on you for noticing a deficiency in Ruby. Your last post made you look pretty delusional.
Re: (Score:2)
Now you're sounding delusional again. Do you have alternative benchmarks from a reputable source that contradict what I've posted, or just specious arguments about how the test must be wrong or unfair to Ruby?
If you don't like the first link, fine. Here's another one [debian.net]
No details on this one, sadly, but I found this line funny: [careerkarma.com]
JavaScript isn’t fast, not when compared to speedier, compiled languages, like C++. However, Ruby makes JavaScript look like a Ferrari. By benchmark, Ruby holds an average speed that is 50% to 200% slower than JavaScript (running with node.js). Some things that take under 30 seconds in JavaScript can take Ruby around eight minutes to finish.
They also acknowledge the Ruby apologists:
In the real world when building a web app you won’t always need to solve Mandelbrot fractals. In this sense, many Ruby fans argue that Ruby is fast enough—that it’s only slow when compared to other languages
Too funny. It's only slow if you compare it against other languages. I can see you saying something like that.
The main problem with Ruby is (Score:2)
That's not better (Score:3)
Did you know it took a full decade, 1999 to 2009, to release a single new version of the JavaScript standard? We get one yearly now
Yearly releases are not better.
Re: (Score:2)
Exactly, languages are something that should be stable. Any change in a language that isn't backwards compatible will incur high maintainance costs at the developer. Changes in a language that are backwards compatible will lead to software products using "all" the features of the language, making the code unmaintainable.
Therefore it's best to have as little changes to a programming language as possible.
Re: (Score:2)
Re: (Score:3)
I disagree. A language that can't change and evolve with the times, or make improvements... that just sounds like a dead language to me.
Languages change because there is pressure to fix issues and make improvements. Breaking changes should, IMO, be reserved for very early in the language's life. Adoption is still minimal, and the language designers are getting valuable feedback from users, so the benefits are worth the drawbacks. Once adoption hits a critical mass, backwards compatibility should be the
The same thing that will happen to Rust (Score:4, Funny)
Once the hype is over, it will go away while still needlessly increasing the size of our core operating system as a critical dependency.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
The runtime, standard libraries, and whatever other infrastructure it needs must be included as long as any package in the OS uses the language.
Re: (Score:2)
Re: (Score:2)
It's not just disk and RAM storage, it is also maintainer attention and system complexity and rebuild time.
Occasionally the OS will migrate to a newer C compiler or C library or something else, and those typically trigger rebuilds of every package in the OS. Unless the other languages have fully self-hosted compilers, their compiler and runtime will also get rebuilt.
Re: (Score:2)
The problem is low powered devices that lack the resources to build rust.
Re: (Score:2)
Are these devices not going to be cross-compiled for?
Re: (Score:2)
"Hard drives are cheap" only has meaning for archiving--not performance.
Cache-miss is time expensive, the processor wastes 10,000's of cycles waiting.
The smaller the program, the more likely it will stay in cache.
In general: smaller program equals better performance, escpecially in a server enviroment.
Re: (Score:2)
That depends on whether Rust ends up fulfilling a niche of it's own or not. Ruby was playing is playing in a very busy territory. Rust perhaps less so.
There have been many languages aimed at replacing, or even rivalling C. All have failed so far. But it will happen eventually. Maybe Rust, maybe not.
Well from what I could tell (Score:5, Insightful)
From my brief brush with Ruby on Rails software, they did do several things wrong.
First of all, features like "Money Patching" may sound great at first, but when abused, they can cause terrible software. That combined with lots of inexperienced programmers trying their hand at it, lead to disaster.
Then the libraries were bad. Switching to a new version broke old code. To counteract this, Ruby comes with its own dependency management system. This might seem like a way to solve that problem, but then all the heavy lifting is done by libraries external to the Ruby universe. In effect you can easily end up with a system that depends on a version of OpenSSL that has the Heartbleed Bug.
In addition to all of that, the code was completely interpreted. You would see syntax errors only when the code was executed. Still startup times were measured in multiples of seconds. To add to that, the abstractions provided don't actually help that much, but make debugging very hard.
Re: Well from what I could tell (Score:3)
No, you definitely get syntax errors at code load time. The interpreter needs to parse an AST from text as the first thing before it can interpret anything.
Re: (Score:2)
Well at least in that project which I had to maintain, it only showed me syntax errors when executing the code. It may have been very old as the guy who did it originally just copied over their Ruby environment from one machine to another.
Re: Well from what I could tell (Score:2)
Well obviously Ruby does not have a compiler, but the code is parsed before it is executed. It may have some dynamic loading of modules which defers this to later in execution, but so do other interpreted languages.
Re: (Score:2)
Re: (Score:2)
Yes, that was a typo.
If you want to know what happened to Ruby (Score:3, Interesting)
Try to install Redmine. Once you're done with the nightmare of super-specific ruby and gems version number matching, and decoding the cryptic error messages, you'll know.
Ruby can rot in hell.
Re: (Score:2)
Ruby lost to Python (Score:4, Interesting)
Ruby is still there, getting updates, getting better. But there are a ton of programming languages out there, and Ruby just hasn't become as widely used as others. It's close enough to Python that going for both is extra effort to little benefit, and between the two, many organizations and most of the world seems to have settled on Python. For a while, it looked like Ruby had found a niche of its own with Rails, and to this day people generally associate the two, but people have moved on from Rails, and Ruby is back to relative obscurity. Shame, because I actually really like Ruby.
Ruby was overhyped, cocky and incomplete / buggy. (Score:5, Interesting)
It just got to fame because the Java grandpas finally discovered that scripting and Convention over Configuration was orders of magnitude better than their sh*tty "We can and must configure everthing with truckloads of XML" approach. The Ruby crowd overhyped Rails that just reinvented the wheel of countless already matured, tried and testen web frameworks, to the sound of PHP already squishing JSP, ASP and whatnot like little pillbugs. They discovered that with with a bad version of Python that couldn't handle UTF-8 - in a time where that already was a dealbreaker - and that didn't have a functioning stateless Apache mod.
I still clearly remember the hype here on slashdot and even made some well received Funnyposts about it. Some others did too I recall. "I just rebuild windows in Rails this morning. Doom 3 still runs a little sluggish, but I'll get to that after lunch." was one that had me laughing in particular. :-)
Ruby and Rails came way too late to the party got what it asked for, just like many others before and after: They got their ass handed to them by a little crazy stateless web templating language with training wheels that to this very days still runs circles around anything else in the serverside web, rules supreme and probably will do so until the universe ends or something. PHP.
Too slow (Score:3)
Ruby on Rails was touted as allowing rapid application development but the code just didn't scale as many companies found out. And Ruby was probably the slowest popular high level language, even slower than Python. Version 3 supposedly speeds up a bit but it's probably too late by this point to expect new adoption.
Everyone can create a programming language (Score:5, Informative)
For anyone who has been in the software industry for more than a decade this is obvious stuff. Everybody can create a new programming language in about a days work, that is not the hard part. The real use of a programming language is in the development support and libraries that are available. Even if you have the best programming language in the world, if you don't have a good development environment and third party libraries that you can use, then that programming language is completely useless. This is why it's always best to use an older language until a new language has matured to the point of being actually usable.
Puppet (Score:5, Interesting)
Ruby lives on in Puppet. I drop down to Ruby code every once in a while to bang out a function that interacts with the system libraries.
Generally I don't care what language I write in, and Ruby idioms are always strange, but it gets the job done.
Puppet's DSL borrows heavily from Ruby, Perl, and others, and if you already have your head around functional programming it's quite usable.
Unfortunately the onramp is steep and the documentation sparse, but learning by examples works out OK.
I can't imagine ever trading that for trying to maintain geographically diverse clusters with a procedural language. There be demons there.
Re: (Score:2)
Ruby lives on in Puppet.
Whatever happened to Puppet?
Also Elastic (Score:2)
The filters for logstash also use a Ruby plugin which appears to be a very common setup for the platform. And is what I am forced to use at work. It's a bit naff.
You can only have so many languages.. (Score:2)
We already have C, C++ and Java as the dinosaurs still more or less successfully roaming the earth. Perl sort of completely collapsed, so there was a slot to be taken.
Ruby never appeared to have a real shot at it because it only had its claim to fame as a quick prototyping language with rails, but with its duck typing it is at most solving esoteric gripes that hardly any real devs struggle with in daily work. You can have a rails like prototype system in any language.
Python looked much more promising and ha
Knew it. (Score:2)
Apparently a Ruby can Rust.
Twitter's migration started the downfall (Score:2)
Rails was good for quick and dirty, but hard to maintain for large and longevous, eventually other languages and frameworks caught up quickly and development moved to the client side for UI and APIs on the backend, mobile grew, so the advantage wasn't there anymore.
Too hard to cheat (Score:3)
My observation from the outside is that it was too hard to pretend to do OOP and too hard to just ignore TDD in Ruby. Almost all the Python code I see has neither object orientation nor any sign of decent tests. It often looks very like Bash - just a list of calls to something else and then a marshalling of the results.
People writing short throw-away scripts like that. "proper" coding has an overhead that doesn't pay off on little scribbled scripts to solve some text processing issue you have this morning because a customer did some data entry on a foreign keyboard and its littered with things that look like comas but are not in fact comas. Python's 'sort of OOPs' works fine for people who need that - maybe not as well as Perl or Bash, but the language you know is infinitely more valuable than some better language you don't know.
Ruby itself also dropped the ball on the OO part, failing to make booleans and control flow object oriented, throwing away a lot of the expressiveness that they should have inherited from Smalltalk.
Smalltalk itself, of course, was killed by Xerox's greed and continues to lie in the grave due to the inability to make it support multiple cores (or lack of interest, perhaps). On paper, it's still one of the the best languages out there.
It was orders of magnitude more slow (Score:2)
It was orders of magnitude more slow, because everything was an object that could be "monkey patched" at runtime. When the topic came up, I used to joke about serving web pages from an integer. I believe it also had scaling issues, and the first rev of Twitter was written in it and had to be re-written. That may have been the turning point, but I don't care enough to google the history. I'm just glad that it's not too popular any more; but just the other day I saw something about Mastodon using it. Ma
Module names (Score:2)
The ruby library names were all pathological, Celery, Thor, Capybara, and so on give zero clue what there things are. ... end around blocks instead of using simple braces was just wrong.
Putting then
Rudy was very ugly, or what they called idiomatic Ruby was very ugly.
Also the performance was not so great.
No one wants accessible programming languages (Score:3)
You can do great work in any tool. However, it takes experience and training to write applications that scale and can be maintained after your leave the project. These easy-to-use languages like Ruby were hot with non-programmers who wrote horrible prototypes that worked...but were a nightmare to maintain, secure, or scale, so every company that hired them had to hire Java devs to rewrite the application so it can scale and be handed off. I think it's unfair to blame Ruby...I blame the type of people who are drawn to it. People don't respect programming as a trade or occupation as much as they should. It takes a lot of experience and learning to figure out how to do things well and both know the best practices and understand why they're best practices so you can make decisions when you find a problem that has conflicting best practices. However, it takes a lot less skill to just get things working...you just don't find out until much later.
It's like carpentry. All those building codes seem strange to an outsider and I am sure I could build a structure that resembles a house because I know my way around the tools. It may even be a nice looking house that works fine for awhile, but will it survive a rainstorm?...will it survive the winter?...will the roof collapse if we get freezing rain?...will a small earthquake or just big truck driving by make it collapse?...can it be repaired easily?...will it be prone to early rot?....what about UV damage? It turns out building a house is a lot more difficult than building walls out of 2x4s and screwing sheet rock on the inside and siding on the outside and placing a roof on top. The same applies to writing applications.
Also, historically, the more easy-to-use and loosely typed a language is, the worse the performance and scalability are. IMO, that's a correlation, not causation. I think someone could make an easy-to-use language that scales well and is easy to use. Unfortunately, if you attract a bunch of people whose only training is reading a few blog posts and aggressive StackOverflow querying, the odds are not in your favor they'll do a good job. It's a bit elitist, but it's true.
People that have had to learn more to do their work tend to do a better job. The average senior Java programmer does better work than the average JavaScript equivalent. The average C programmer does better than the average Java equivalent. Perhaps the average assembly programmer does better than their C equivalent? I don't know because I've never met anyone making a living writing assembly, but would believe you if you told me that was the case. We can debate the cause, I am not confident I know the answer. I just have seen the results.
It's still chugging along in a lot of places (Score:2)
Good riddance (Score:2)
For years, incdluding several after the team lead left, I had to make sure *not* to update ruby (working at a civilian sector federal gov't agency), as anything other than - I'm trying to remember from like 8 years ago - 192 broke the entire application.
Re: The language by one guy died? Shocking! (Score:4)
Lots of successful languages start that way. Like JavaScript was created by Brenden Eich. I suppose it technically had corporate backing, but it was just one guy who did it.
As the language grows, it needs to attract new people, though. For example, D was created by Walter Bright, but has now mostly passed on to Andrei Alexandrescu, and other people are more focused on the standard lib.
I think this might harder for high-level languages, though, like Ruby. The users of the language are not generally the right people to hack the language itself. Which is a good reason to have things like Pypy (or whatever it's calle; Python written in Python).
Re: (Score:2)
Re: The language by one guy died? Shocking! (Score:2)
D stands for Dead end. Or maybe just Dead. It has zero traction in the to the metal and systems programming space that C and C++ inhabit.
Re: The language by one guy died? Shocking! (Score:2)
According to data, it's at 0.6% and climbing in languages overall. Given the large number of languages out there (and the fact that these metrics include more than just system languages), that's nothing to sneeze at.
Is it more popular than the C flavors? No. But it's the next most popular system language Kernighan and Ritchie weren't involved in.
Re: (Score:2)
I'd take those measurements with a huge cellar of salt. They go by hobbiest usage on github and questions asked on various forums, they don't survey companies who actually use these languages to do real work. I've never once seen a job ad asking for 'D' experience and I look for these sorts of roles being a C++ dev. Rust on the other hand is definately appearing in the job ads now.
Re: (Score:2)
Truly it was Smalltalk for the 21st century.
Re: (Score:2)