I mentioned in my Hello, world! post that I built this site using Hanami. This site may seem simple on the surface; it is, after all, just a blog. However, the backend is packed with features that help me day to day. I have built a tool that lets me cross-post to both Bluesky and Mastodon. I have a private journal where I can keep notes throughout the day. There is a custom analytics engine to provide me with insights on how well my blog posts are doing. There is a messaging backend that lets readers reach me through my contact form without cluttering my inbox. I have also built a task manager that syncs with both Linear and GitHub Issues and helps me track what I need to do. Most importantly, I have built an activity feed that captures my GitHub commits, journal entries, blog posts, and tasks. It helps me answer the question "What did I do between ___ and ___ dates?", which, believe it or not, is hard for me to answer on my own, even for last week. The application is open source, and you can find it on GitHub.
Yeah, libraries. The library I’d point to that “modifies the language” more than ActiveSupport would be something like event machine. And so my question is more along the lines of did it work. I would say ActiveSupport worked. But EM didn’t and neither did Moose. Because you’re trying to make a library that changes the paradigm. EM: reactor, Moose: OOP.
Why didn’t EM work imo? Well, you had to find em-libraries for everything that hit that I/O or scheduling seam. So you had em-this, em-that. I consider this different than something that depended on ActiveSupport but this is just my thought-parallel.
I think my pushback on this standpoint is that it essentially posits that we can never learn from our mistakes and get better, that languages are what they are and cannot change, and that using different constructs requires a language change.
Anyone who’s been writing Ruby for a while understands that languages do change. The boundary between language experiments in a codebase to libraries to language support is porous. I will remind you: symbol-to-proc was just one sort of experiment that was elevated to a language feature.
I see it more from Joe Armstrong’s three laws of programming design. The things you messed up, those things don’t change. Matz “isn’t a threading guy” so you get EM. Ruby 7.0 could be compile to binary, some very different concurrency model as 1st and only citizen, pure functions or whatever other characteristics that would be significant enough for comparison and uniqueness to other languages but it probably won’t be. Whatever the reason.
Yes, Ruby has changed. I would say types most recently but I don’t know if it’s been successful. Has adding static types to Ruby been successful? Has it been complete? Is it an addon or type of thing like EM? I don’t know. “Oh, this repo is trying [ Reactor | type safety | pure functions ]” but it can’t commit to the paradigm because it’s like a soft-style inside of a language choice.
I don’t mean the syntax sugar or small things. I mean concurrency, paradigm, memory model, packaging, runtime performance tier as compared with other languages. I don’t think Ruby itself has changed, I can’t think of any language that has “shipped” is constrained by legacy that has changed a paradigm category. I think this is what Joe meant, or it’s my interpretation.
“What you get right, nobody mentions it.”
“What you get wrong, people [complain] about.”
“What is difficult to understand you have to explain to people over and over again.”
And so, if things are changeable and you learned a lesson then the language could change. But it doesn’t because of backwards compatibility. But also, the language itself has made a choice. In the major categories of language differentiation, you’re in one camp. I’m trying to think of a language that has switched camps, the language itself. Not a library. This is my point. Making a library to switch camps is imo historically difficult because of what Joe said.
In the major categories of language differentiation, you’re in one camp. I’m trying to think of a language that has switched camps, the language itself. Not a library. This is my point. Making a library to switch camps is imo historically difficult because of what Joe said.
I addressed this point in my original reply: Ruby is not fully in the OOP camp and never was. If you have that sense, it was because the OOP features previously got more emphasis than the functional ones. But Ruby began as a LISP VM, its functional bona fides are not new, and a greater emphasis on FP in Ruby is not “switching camps.” It’s a false binary.
Yeah, libraries. The library I’d point to that “modifies the language” more than ActiveSupport would be something like event machine. And so my question is more along the lines of did it work. I would say ActiveSupport worked. But EM didn’t and neither did Moose. Because you’re trying to make a library that changes the paradigm. EM: reactor, Moose: OOP.
Why didn’t EM work imo? Well, you had to find em-libraries for everything that hit that I/O or scheduling seam. So you had em-this, em-that. I consider this different than something that depended on ActiveSupport but this is just my thought-parallel.
score 1 · canonical
I think my pushback on this standpoint is that it essentially posits that we can never learn from our mistakes and get better, that languages are what they are and cannot change, and that using different constructs requires a language change.
Anyone who’s been writing Ruby for a while understands that languages do change. The boundary between language experiments in a codebase to libraries to language support is porous. I will remind you: symbol-to-proc was just one sort of experiment that was elevated to a language feature.
score 1 · canonical
I see it more from Joe Armstrong’s three laws of programming design. The things you messed up, those things don’t change. Matz “isn’t a threading guy” so you get EM. Ruby 7.0 could be compile to binary, some very different concurrency model as 1st and only citizen, pure functions or whatever other characteristics that would be significant enough for comparison and uniqueness to other languages but it probably won’t be. Whatever the reason.
Yes, Ruby has changed. I would say types most recently but I don’t know if it’s been successful. Has adding static types to Ruby been successful? Has it been complete? Is it an addon or type of thing like EM? I don’t know. “Oh, this repo is trying [ Reactor | type safety | pure functions ]” but it can’t commit to the paradigm because it’s like a soft-style inside of a language choice.
I don’t mean the syntax sugar or small things. I mean concurrency, paradigm, memory model, packaging, runtime performance tier as compared with other languages. I don’t think Ruby itself has changed, I can’t think of any language that has “shipped” is constrained by legacy that has changed a paradigm category. I think this is what Joe meant, or it’s my interpretation.
And so, if things are changeable and you learned a lesson then the language could change. But it doesn’t because of backwards compatibility. But also, the language itself has made a choice. In the major categories of language differentiation, you’re in one camp. I’m trying to think of a language that has switched camps, the language itself. Not a library. This is my point. Making a library to switch camps is imo historically difficult because of what Joe said.
score 1 · canonical
I addressed this point in my original reply: Ruby is not fully in the OOP camp and never was. If you have that sense, it was because the OOP features previously got more emphasis than the functional ones. But Ruby began as a LISP VM, its functional bona fides are not new, and a greater emphasis on FP in Ruby is not “switching camps.” It’s a false binary.
score 1 · canonical