Most of the things he praises — compact lambda syntax, Enumerable replacing “for” loops, everything is an object, MVC — came directly from Smalltalk-80. Often with exactly the same syntax. I think a lot of the genius of Ruby was to mold Smalltalk into a form that was more familiar looking and worked well as a scripting language. (ST-80 had no notion of a source file, nor of unbound functions nor top-level code not part of an object.)
When I was first introduced to Ruby in … 1998 I think, I was told “It’s like Perl, but OO.” And as a Smalltalk enthusiast, I thought “Well, I don’t want OO Perl. I want Smalltalk.” And passed without even looking.
The next person who introduced me to Ruby in, 2001 I think, told me “It’s basically a Smalltalk that knows how to interact with the rest of the world.” I looked, and was immediately hooked.
I consider Smalltalk and Lisp to be perfect*, and everything else is a compromise. Ruby provides what I consider to be the fewest compromises, while providing interoperability with the rest of the world. It’s situationally-perfect, I suppose.
* I often say “Smalltalk-80 is so named to commemorate the year in which it was perfected. Lisp doesn’t have a year modifier because it came out perfect.”
Every language has some core idea that inspired its creators to make it, instead of putting up with the other perfectly good languages that already existed. Sometimes, that idea is simple (“everything is an object” for Smalltalk, “everything is a cons cell” for LISP), and sometimes that idea is more complex (the way that Java is designed to scale to huge teams, or the way that Perl is “the Cliff’s Notes of Unix”).
The author’s idea is that the core idea of Ruby is (waves hands) for making domain-specific languages. It’s not the universal syntax for expressing all algorithms, but if you have an idea for how a particular algorithm should be expressed, you can probably bend Ruby into that shape, at least within a particular class or project.
The author’s lament is that Ruby’s core idea was never really named, and thus never advertised, and thus never formed part of Ruby’s reputation. As a result, it didn’t build up the audience of tinkerers and experimenters who could form a long-lived supportive community around it.
Instead, what it got was Rails, which was the opposite of that core idea: instead of bending Rails into a domain-specific language for the application you want to create, the idea is to bend your application to fit within the framework Rails provides. And since Rails became hugely popular, the vast majority of the Ruby community valued that framework-style approach and Ruby just became the incidental-complexity runtime for Rails instead of an interesting thing in its own right.
Can you expand a bit on the idea that Ruby is for DSLs? I feel like I’ve heard that here and there and it always seemed like a bit of a stretch. Ruby just doesn’t have things that I would think would be critical for truly writing DSLs, such as lazy evaluation and macros.
The vagrant config, for example, is a bunch of ruby code that calls itself a DSL but it really just feels like… writing ruby. Python, for instance, could do it just as well (see: SCons).
The instance_exec method allows for succinct DSLs whose syntax couldn’t be easily copied in other languages like Python. Basically, it allows you to evaluate blocks as if they were running in the scope of an arbitrary object’s methods — or to put it in Rubyist terms, it allows you to execute blocks with an arbitrary receiver. For (a completely contrived) example, in Python you might write:
worker = Library.worker do
config_file "foo.txt"
worker_processes 2
end
The interior of the Ruby block defining the worker feels in a certain sense like a DSL; these methods are not in global scope: they’re special methods that are accessible inside the block, running on an anonymous object. It’s sort of like having a domain-specific language with new keywords — config_file and worker_processes — that elegantly composes with standard Ruby.
Of course, really all it means is you can leave out repeated references to conf, since Library.worker makes everything run as if it’s in the scope of some method on conf (and Ruby has implicit self inside method calls, so you can write config_file instead of self.config_file). But ergonomically it can feel nice. It’s the same number of lines, but much less significant text.
To your point: until I read this comment, I had no idea that the Vagrant config was even supposed to be any kind of DSL. It just looked like ordinary Ruby to me.
Thanks for that. I never learned that about ruby because the first and only place I tried it was (gross) codecademy, before I’d started learning how to code.
That Ruby never gained traction for the face value of its expressiveness. I feel that this rant imply that the mix of semantic approach of Perl and the meta-approach of Lisp meeting in the right balance in Ruby have not been recognized and exploited fully to show what Ruby really is.
The way the author speaks about “phrase-based” reminds me of Perl, Raku, APL, dense language where you can express yourself in short understandable phrase. The author pushes the idea that this is the meaning of the mantra “Desifned for developer’s happiness”. To be happy, you have to be able to express yourself without convolution and Ruby provided that solid base and rich vocabulary to be expressive and precise.
I was once told (by an ex-SRE from google, before the wave of SRE was a thing) that I was exactly the kind of person who would love ruby.
The “everything is an object” is quite nice because it’s easy to use the language to introspect the language. You don’t need to reach for documentation if you can get your project into irb.
But, the metaprogramming (all I see are footguns), the performance, the loosey-goosey way that the language breaks in minor versions (requiring new version managers).
Idk. I think that guy was wrong, I do find joy in writing ruby. But, like Perl, I hate to maintain it.
I agree with a number of the points the author makes, but I’m not sure I would concede that Ruby has met the particular “sad fate”. Related to that, I could agree that Ruby has become less popular than it used to be, but I still use it nearly every day to pay my bills.
I restlessly wandered from language to language until I came to rest at Ruby, over a decade ago. Since then, no other language has made enough of an impression on me to displace me out of the local minimum that I’m comfortably nestled in. Sure, I’ve heard of the Haskells, Erlangs, Gos and Rusts of the world, but I’m just so content with Ruby, with no major pain points that make me want to wander again. I also write some Javascript from time to time, and it’s arguably a lot more popular than Ruby these days, but I still would prefer to use Ruby, given a choice.
I’m grateful to hear someone else say this, because this is what has happened to me as well (though over a shorter timeframe). I’ve worked in a handful of languages over the years, and of course through Lobsters I hear the virtues of other ones extolled, but nothing feels as easy as Ruby does. There have been a few occasions where I’ve been able to write some C# again, and I get to nestle into the comfortable folds of statically-typed compiled languages, but the satisfaction of writing Ruby is what keeps me happy to go back to it.
I appreciate the author mentioning that Ruby’s sort of “phrase-oriented programming” seems to have stemmed from how Enumerable is built, because that has been my gut feeling on why I like Ruby so much as well. It’s nice not having to write for loops and the brevity of Ruby’s syntax makes applying what are essentially lambdas to common list operations so simple.
I guess the author is disappointed by the community having forgotten the core value of the language as a mind expanding tool for exploring concepts and ideas, and being defined by its technical limitations and success cases? Idk.
I think that the author should look beyond and acknowledge the massive impact ruby had in this wave of new programming languages: rust, go, swift, zig, they all borrowed something from ruby. It’s a pretty powerful legacy.
Also, I think the author should look beyond rails and recognize those values in other tools of the ecosystem. They might not have a conf named after them, and capture less of the overall community, but they are nonetheless rarkavle examples of what can be achieved with ruby with a bit of creativity.
I’m very curious what features you think those languages borrowed from Ruby.
Ruby is effectively what happens when you wish Smalltalk could replace Perl. I expect most thngs are at very least borrowed from an ancestor, but even then Ruby and most ancestors are very dynamic and introspective and the languages in your list are all very much the opposite.
For sure Rust “borrowed” closure syntax from Ruby. In early designs for i in iter {} was even written as iter.each |i| {} AFAIK. Also some of the “core Ruby” people went to Rust, for example @steveklabnik.
I have no idea what @honeyryderchuck meant in other languages though. Swift maybe with the named arguments, but that comes from common ancestry in Smalltalk, not from Ruby itself.
What @hauleth said from rust. Swift syntax is full of rubyisms, and I felt it was a direct influence at the time of its announcement. Go’s structural typing with implicit interfaces has been many times described as “safe duck typing”; im not saying that it was directly influenced by the duck typing that ruby popularized, but the fact it was advertised as such, makes it suggest that an audience was being targeted. I also left out elixir, which is ruby lipstick on erlang/beam.
I might have pushed it with zig though, but I felt some UX brushes of ruby in the tutorials I’ve seen. Bu maybe that was my ruby brain deceiving me.
Ruby tooling has also been very influência in other communities. Take a look at bundler, which directly inspired yarn or cargo.
I know this is all subjective, so I’m just going to ask about the duck typing one. While I don’t know the timeline on the terminology, I feel like it’s so pervasive it can’t be mainly from Ruby, but maybe I’m wrong. Python and Javascript are duck-typed. Smalltalk of course. Any LISP with an object system (CLOS, GLOOP, etc) – and of course Haskell type classes etc are also the “safe duck typing” thing
You’re correct, python, and also other dynamic languages also fit the bill of duck typing. I just feel that no one was using it to describe that sort of loose type system before ruby popularized it. I certainly hadn’t before 2007. But it might have come from smalltalk, most definitely.
I just want to say that ruby isn’t done innovating yet. They just added static typing last year, which is a really big deal. For a language to start out as dynamic and gain optional static typing 20 years later is pretty cool. Also, it may not have a huge following now, but there have been a lot of newer languages created since ruby’s inception and ruby still has enough of a following to get pretty significant updates 20 years later.
I’m not sure why the author is so convinced that no one could be doing something new or fun in Ruby land or that if they did no one would talk to them…
Ins’t stuff the Andrew https://github.com/ankane build consider cool? He did lot of ML stuff. All of his gem integrate nicely without heavy external dependencies
Andrew is an absolute hero indeed, and there are several other groups working on ML gems; but in the scope of the point I’ve tried to make it is important to notice that
a) these gems typically have very low usage in the community (even if “considered cool”, it is more “Oh, it is a cool thing, I’ll bookmark it for the case somebody says Ruby doesn’t do ML on Reddit”); and
b) it is more of a “chasing the leader” kind of work (“Ruby now can do this and that too”).
Nothing wrong with chasing the leader, and it is work that needs to be done.
But my argument was about the fact that it is very hard to do something new in Ruby to be noticeable in the industry in general, not just mentioned in the “Ruby newsletter” or upvoted on /r/ruby—while Ruby’s traits are very suitable for this kind of work (inventing something “completely new” out of the blue).
I never understood ranting on other tools or languages.
If you don’t like it don’t use it.
If you think there’s a better tool or language for whatever it is you’re doing, use the better tool.
If you think there’s a better tool or language for whatever it is you’re doing, use the better tool.
That’s not always your choice. I got stuck for a few months writing golang at a job where I was originally hired to write Clojure, and that’s probably the rantiest I’ve ever been. I felt like I had to program with oven mitts on just to keep my job. Luckily I got moved to a new team before I completely lost it.
This seems to be totally normal at midrange to massive companies. The tools are chosen for you by architects you may never meet, considering primarily what languages the offshore and onshore teams both know.
It stops being about the technical fit, and becomes about the arguably harder human fit.
Which is hilarious since developer productivity, the argument made when you say “best tool for the job,” is an entirely human factor.
A language doesn’t stand on its own – its community affects the experience of using it. A language’s community:
Writes libraries for the language
Writes documentation for the language (in forums and Stack Overflow)
Devises new patterns to make working with the language more pleasant
As those benefits are correlated to the size of the community, it’s reasonable for someone to want to convince others to use their preferred programming language and thus become part of its community.
I think JavaScript isn’t intended to use as a desktop app language and a server side language. Yet, it diverse and eat into those market. people even use it for infrastructure like AWS CDK and Pulumi guys.
Ins’t that cool? When something is designed to be use in this but people use them in a different way.
I run an email forwarding service which its main purpose is to forward emails but a few users use it as a tool to preview their email rendering without forwarding out so that they can inspect and fix any issue. I never intended for it to be used that way. I think it’s great when people found another way to use the thing that you design. It doesn’t mean it’s a failure, to me, It means the thing is flexible enough to warrant their workload.
Samething with Go, they want to win over C but lots of Ruby/Python people started to pick up it.
I always like to think of Ruby as the attempt to bring bits of Smalltalk into a world dominated by PHP/Perl/Python.
While I’ve never been too much into Ruby, it’s interesting how with Rails, etc. it re-popularized the concept of MVC (stemming from Smalltalk) and also how it found its way into places, where I totally wouldn’t expect to find it, like Hashicorp’s Vagrant.
with Rails, etc. it re-popularized the concept of MVC (stemming from Smalltalk)
I think this is a fallacy: MVC in GUI in smalltalk and MVC in HTPP in Ruby are different patterns, which emerge in different contexts, and just happen to share a catchy name. See
Hey, thanks for sharing those. Very insightful. I however still wouldn’t say they just share the name. Yes, MVC as in Smalltalk isn’t really what we see in HTTP frameworks. However I’d still say that it is very much inspired by MVC in Smalltalk. Maybe saying it repopularized is bad wording though.
It’s similar when people talk about object oriented programming though. In Smalltalk it’s still clearer and different, also with class browser, message passing and the integration into a graphical environment. Just like the way debugging works is something some projects take inspiration from.
And when it comes to development in let’s say Java or C++ in real life projects, there’s very little resembling object oriented programming like in Smalltalk.
Hey, thanks for sharing those. Very insightful. I however still wouldn’t say they just share the name. Yes, MVC as in Smalltalk isn’t really what we see in HTTP frameworks. However I’d still say that it is very much inspired by MVC in Smalltalk. Maybe saying it repopularized is bad wording though.
It’s similar when people talk about object oriented programming though. In Smalltalk it’s still clearer and different, also with class browser, message passing and the integration into a graphical environment. Just like the way debugging works is something some projects take inspiration from.
And when it comes to development in let’s say Java or C++ in real life projects, there’s very little resembling object oriented programming like in Smalltalk.
Most of the things he praises — compact lambda syntax, Enumerable replacing “for” loops, everything is an object, MVC — came directly from Smalltalk-80. Often with exactly the same syntax. I think a lot of the genius of Ruby was to mold Smalltalk into a form that was more familiar looking and worked well as a scripting language. (ST-80 had no notion of a source file, nor of unbound functions nor top-level code not part of an object.)
When I was first introduced to Ruby in … 1998 I think, I was told “It’s like Perl, but OO.” And as a Smalltalk enthusiast, I thought “Well, I don’t want OO Perl. I want Smalltalk.” And passed without even looking.
The next person who introduced me to Ruby in, 2001 I think, told me “It’s basically a Smalltalk that knows how to interact with the rest of the world.” I looked, and was immediately hooked.
I consider Smalltalk and Lisp to be perfect*, and everything else is a compromise. Ruby provides what I consider to be the fewest compromises, while providing interoperability with the rest of the world. It’s situationally-perfect, I suppose.
* I often say “Smalltalk-80 is so named to commemorate the year in which it was perfected. Lisp doesn’t have a year modifier because it came out perfect.”
What do you think of Crystal?
I don’t dislike it. I think it’s a great compromise for people who care about the things it offers, but it doesn’t offer anything I care about.
Can someone explain me the point of the rant? I don’t really understand what it’s trying to say.
Every language has some core idea that inspired its creators to make it, instead of putting up with the other perfectly good languages that already existed. Sometimes, that idea is simple (“everything is an object” for Smalltalk, “everything is a cons cell” for LISP), and sometimes that idea is more complex (the way that Java is designed to scale to huge teams, or the way that Perl is “the Cliff’s Notes of Unix”).
The author’s idea is that the core idea of Ruby is (waves hands) for making domain-specific languages. It’s not the universal syntax for expressing all algorithms, but if you have an idea for how a particular algorithm should be expressed, you can probably bend Ruby into that shape, at least within a particular class or project.
The author’s lament is that Ruby’s core idea was never really named, and thus never advertised, and thus never formed part of Ruby’s reputation. As a result, it didn’t build up the audience of tinkerers and experimenters who could form a long-lived supportive community around it.
Instead, what it got was Rails, which was the opposite of that core idea: instead of bending Rails into a domain-specific language for the application you want to create, the idea is to bend your application to fit within the framework Rails provides. And since Rails became hugely popular, the vast majority of the Ruby community valued that framework-style approach and Ruby just became the incidental-complexity runtime for Rails instead of an interesting thing in its own right.
Brilliant summary. Well done.
The Ruby-on-Rails revolution and its consequences have been a disaster for the Ruby race.
Can you expand a bit on the idea that Ruby is for DSLs? I feel like I’ve heard that here and there and it always seemed like a bit of a stretch. Ruby just doesn’t have things that I would think would be critical for truly writing DSLs, such as lazy evaluation and macros.
The vagrant config, for example, is a bunch of ruby code that calls itself a DSL but it really just feels like… writing ruby. Python, for instance, could do it just as well (see: SCons).
The
instance_execmethod allows for succinct DSLs whose syntax couldn’t be easily copied in other languages like Python. Basically, it allows you to evaluate blocks as if they were running in the scope of an arbitrary object’s methods — or to put it in Rubyist terms, it allows you to execute blocks with an arbitrary receiver. For (a completely contrived) example, in Python you might write:Whereas a Ruby library might read:
The interior of the Ruby block defining the worker feels in a certain sense like a DSL; these methods are not in global scope: they’re special methods that are accessible inside the block, running on an anonymous object. It’s sort of like having a domain-specific language with new keywords —
config_fileandworker_processes— that elegantly composes with standard Ruby.Of course, really all it means is you can leave out repeated references to
conf, sinceLibrary.workermakes everything run as if it’s in the scope of some method onconf(and Ruby has implicitselfinside method calls, so you can writeconfig_fileinstead ofself.config_file). But ergonomically it can feel nice. It’s the same number of lines, but much less significant text.To your point: until I read this comment, I had no idea that the Vagrant config was even supposed to be any kind of DSL. It just looked like ordinary Ruby to me.
Thank you… Didn’t even bother reading the post - love your writing style too!
Thanks for that. I never learned that about ruby because the first and only place I tried it was (gross) codecademy, before I’d started learning how to code.
The author’s lament is that Ruby’s core idea was never really named, and thus never advertised
I know this is not your point, but I have a bunch of populer old books from ruby 1.9 times such as “metaprogramming ruby” and “rspec” which disagree.
That Ruby never gained traction for the face value of its expressiveness. I feel that this rant imply that the mix of semantic approach of Perl and the meta-approach of Lisp meeting in the right balance in Ruby have not been recognized and exploited fully to show what Ruby really is.
The way the author speaks about “phrase-based” reminds me of Perl, Raku, APL, dense language where you can express yourself in short understandable phrase. The author pushes the idea that this is the meaning of the mantra “Desifned for developer’s happiness”. To be happy, you have to be able to express yourself without convolution and Ruby provided that solid base and rich vocabulary to be expressive and precise.
Me neither. Wondering if I should flag this as off-topic.
I was once told (by an ex-SRE from google, before the wave of SRE was a thing) that I was exactly the kind of person who would love ruby.
The “everything is an object” is quite nice because it’s easy to use the language to introspect the language. You don’t need to reach for documentation if you can get your project into irb.
But, the metaprogramming (all I see are footguns), the performance, the loosey-goosey way that the language breaks in minor versions (requiring new version managers).
Idk. I think that guy was wrong, I do find joy in writing ruby. But, like Perl, I hate to maintain it.
I agree with a number of the points the author makes, but I’m not sure I would concede that Ruby has met the particular “sad fate”. Related to that, I could agree that Ruby has become less popular than it used to be, but I still use it nearly every day to pay my bills.
I restlessly wandered from language to language until I came to rest at Ruby, over a decade ago. Since then, no other language has made enough of an impression on me to displace me out of the local minimum that I’m comfortably nestled in. Sure, I’ve heard of the Haskells, Erlangs, Gos and Rusts of the world, but I’m just so content with Ruby, with no major pain points that make me want to wander again. I also write some Javascript from time to time, and it’s arguably a lot more popular than Ruby these days, but I still would prefer to use Ruby, given a choice.
I’m grateful to hear someone else say this, because this is what has happened to me as well (though over a shorter timeframe). I’ve worked in a handful of languages over the years, and of course through Lobsters I hear the virtues of other ones extolled, but nothing feels as easy as Ruby does. There have been a few occasions where I’ve been able to write some C# again, and I get to nestle into the comfortable folds of statically-typed compiled languages, but the satisfaction of writing Ruby is what keeps me happy to go back to it.
I appreciate the author mentioning that Ruby’s sort of “phrase-oriented programming” seems to have stemmed from how Enumerable is built, because that has been my gut feeling on why I like Ruby so much as well. It’s nice not having to write
forloops and the brevity of Ruby’s syntax makes applying what are essentially lambdas to common list operations so simple.I guess the author is disappointed by the community having forgotten the core value of the language as a mind expanding tool for exploring concepts and ideas, and being defined by its technical limitations and success cases? Idk.
I think that the author should look beyond and acknowledge the massive impact ruby had in this wave of new programming languages: rust, go, swift, zig, they all borrowed something from ruby. It’s a pretty powerful legacy.
Also, I think the author should look beyond rails and recognize those values in other tools of the ecosystem. They might not have a conf named after them, and capture less of the overall community, but they are nonetheless rarkavle examples of what can be achieved with ruby with a bit of creativity.
I’m very curious what features you think those languages borrowed from Ruby.
Ruby is effectively what happens when you wish Smalltalk could replace Perl. I expect most thngs are at very least borrowed from an ancestor, but even then Ruby and most ancestors are very dynamic and introspective and the languages in your list are all very much the opposite.
For sure Rust “borrowed” closure syntax from Ruby. In early designs
for i in iter {}was even written asiter.each |i| {}AFAIK. Also some of the “core Ruby” people went to Rust, for example @steveklabnik.I have no idea what @honeyryderchuck meant in other languages though. Swift maybe with the named arguments, but that comes from common ancestry in Smalltalk, not from Ruby itself.
What @hauleth said from rust. Swift syntax is full of rubyisms, and I felt it was a direct influence at the time of its announcement. Go’s structural typing with implicit interfaces has been many times described as “safe duck typing”; im not saying that it was directly influenced by the duck typing that ruby popularized, but the fact it was advertised as such, makes it suggest that an audience was being targeted. I also left out elixir, which is ruby lipstick on erlang/beam.
I might have pushed it with zig though, but I felt some UX brushes of ruby in the tutorials I’ve seen. Bu maybe that was my ruby brain deceiving me.
Ruby tooling has also been very influência in other communities. Take a look at bundler, which directly inspired yarn or cargo.
I know this is all subjective, so I’m just going to ask about the duck typing one. While I don’t know the timeline on the terminology, I feel like it’s so pervasive it can’t be mainly from Ruby, but maybe I’m wrong. Python and Javascript are duck-typed. Smalltalk of course. Any LISP with an object system (CLOS, GLOOP, etc) – and of course Haskell type classes etc are also the “safe duck typing” thing
You’re correct, python, and also other dynamic languages also fit the bill of duck typing. I just feel that no one was using it to describe that sort of loose type system before ruby popularized it. I certainly hadn’t before 2007. But it might have come from smalltalk, most definitely.
I just want to say that ruby isn’t done innovating yet. They just added static typing last year, which is a really big deal. For a language to start out as dynamic and gain optional static typing 20 years later is pretty cool. Also, it may not have a huge following now, but there have been a lot of newer languages created since ruby’s inception and ruby still has enough of a following to get pretty significant updates 20 years later.
I’m not sure why the author is so convinced that no one could be doing something new or fun in Ruby land or that if they did no one would talk to them…
Because he tried for many years, maybe? And observed the community for said years? ¯\_(ツ)_/¯
Ins’t stuff the Andrew https://github.com/ankane build consider cool? He did lot of ML stuff. All of his gem integrate nicely without heavy external dependencies
Same with https://github.com/ioquatix
Andrew is an absolute hero indeed, and there are several other groups working on ML gems; but in the scope of the point I’ve tried to make it is important to notice that
Nothing wrong with chasing the leader, and it is work that needs to be done.
But my argument was about the fact that it is very hard to do something new in Ruby to be noticeable in the industry in general, not just mentioned in the “Ruby newsletter” or upvoted on /r/ruby—while Ruby’s traits are very suitable for this kind of work (inventing something “completely new” out of the blue).
I never understood ranting on other tools or languages. If you don’t like it don’t use it. If you think there’s a better tool or language for whatever it is you’re doing, use the better tool.
That’s not always your choice. I got stuck for a few months writing golang at a job where I was originally hired to write Clojure, and that’s probably the rantiest I’ve ever been. I felt like I had to program with oven mitts on just to keep my job. Luckily I got moved to a new team before I completely lost it.
This seems to be totally normal at midrange to massive companies. The tools are chosen for you by architects you may never meet, considering primarily what languages the offshore and onshore teams both know.
It stops being about the technical fit, and becomes about the arguably harder human fit.
Which is hilarious since developer productivity, the argument made when you say “best tool for the job,” is an entirely human factor.
A language doesn’t stand on its own – its community affects the experience of using it. A language’s community:
As those benefits are correlated to the size of the community, it’s reasonable for someone to want to convince others to use their preferred programming language and thus become part of its community.
I think JavaScript isn’t intended to use as a desktop app language and a server side language. Yet, it diverse and eat into those market. people even use it for infrastructure like AWS CDK and Pulumi guys.
Ins’t that cool? When something is designed to be use in this but people use them in a different way.
I run an email forwarding service which its main purpose is to forward emails but a few users use it as a tool to preview their email rendering without forwarding out so that they can inspect and fix any issue. I never intended for it to be used that way. I think it’s great when people found another way to use the thing that you design. It doesn’t mean it’s a failure, to me, It means the thing is flexible enough to warrant their workload.
Samething with Go, they want to win over C but lots of Ruby/Python people started to pick up it.
My only interaction with Ruby was _why’s Poignant Guide. Boy, am I glad I never had to use it in industry! I probably would have gotten sick of it.
I always like to think of Ruby as the attempt to bring bits of Smalltalk into a world dominated by PHP/Perl/Python.
While I’ve never been too much into Ruby, it’s interesting how with Rails, etc. it re-popularized the concept of MVC (stemming from Smalltalk) and also how it found its way into places, where I totally wouldn’t expect to find it, like Hashicorp’s Vagrant.
I think this is a fallacy: MVC in GUI in smalltalk and MVC in HTPP in Ruby are different patterns, which emerge in different contexts, and just happen to share a catchy name. See
Hey, thanks for sharing those. Very insightful. I however still wouldn’t say they just share the name. Yes, MVC as in Smalltalk isn’t really what we see in HTTP frameworks. However I’d still say that it is very much inspired by MVC in Smalltalk. Maybe saying it repopularized is bad wording though.
It’s similar when people talk about object oriented programming though. In Smalltalk it’s still clearer and different, also with class browser, message passing and the integration into a graphical environment. Just like the way debugging works is something some projects take inspiration from.
And when it comes to development in let’s say Java or C++ in real life projects, there’s very little resembling object oriented programming like in Smalltalk.
Hey, thanks for sharing those. Very insightful. I however still wouldn’t say they just share the name. Yes, MVC as in Smalltalk isn’t really what we see in HTTP frameworks. However I’d still say that it is very much inspired by MVC in Smalltalk. Maybe saying it repopularized is bad wording though.
It’s similar when people talk about object oriented programming though. In Smalltalk it’s still clearer and different, also with class browser, message passing and the integration into a graphical environment. Just like the way debugging works is something some projects take inspiration from.
And when it comes to development in let’s say Java or C++ in real life projects, there’s very little resembling object oriented programming like in Smalltalk.