nauticacom

This isn't true; Ruby has no set literal. Sets are provided by a default gem but there is no built-in syntax for them.

I understand repr for debugging (though imo it's a deficiency of the language that custom objects don't have a repr which lists their attributes), but eq is a property of the domain itself; two objects are only equal if it makes sense in the domain logic for them to be equal, and in many cases that equality is more or less complicated than attribute equality.

I really, genuinely don't get the appeal. I don't follow the "less code = better" ideology so maybe that's a contributor but I really don't see how this:

    class Person:
        def __init__(self, name, age):
            self.name = name
            self.age = age

is any worse than this:

    @dataclass
    class Person:
        name: str
        age: int

I'm not writing an eq method or a repr method in most cases, so it just doesn't add much for the cost.

I've never understood the appeal of these "define struct-like-object" libraries (in any language; I've never understood using the standard library's "Struct" in Ruby). My preferred solution for addressing complexity is also to decompose the codebase into small, understandable, single-purpose objects, but so few of them end up being simple value objects like Point3D. Total ordering and value equality make sense for value objects but not much else, so it really doesn't improve understandability or maintenance that much. And concerns like validation I would never want to put in a library for object construction. In web forms where there are a limited subset of rules I always want to treat the same way, sure, but objects have much more complicated relationships with their dependencies that I don't see much value in validating them with libraries.

Overall, I really don't see the appeal. It makes the already simple cases simpler (was that Point3D implementation really that bad?) and does nothing for the more complicated cases which make up the majority of object relationships.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

I must be the only person on the planet who likes AppleScript :)

I definitely understand the argument that different human languages have different semantic patterns. The only non-English language I know (reading, not speaking) is classical Latin, which likes to have nouns and verbs at the opposite ends of phrases; after reading a lot, it just starts to "feel" right.

    account.deposit(Dollar.of(100))

I also know what this means, but somehow it just doesn't "feel" right. Maybe it's because all the other words are in English, so I want 100.dollars to follow English word order? But account.deposit(...) feels much better to me than deposit(into: account, ...), which is the "wrong" word order. I'm perfectly willing to accept that I just have a sense of what "feels" good to me and it's not necessarily logical or reasoned, just a general aesthetic of nouns playing in a world of data.

As an aside, I always find it funny when people use "monkey patching" in an attempt to decry giving language users expressive power. I love monkeys! I love monkey patching!

Just took a quick look at Rebol and it looks interesting! I love languages that push the boundary of what they allow programs to "naturally" express

    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.

Snippets like this:

    account deposit: 100 dollars.

are why I love Smalltalk (and its followers, e.g. Ruby). So much expressiveness, reading like a sentence. And Smalltalk even had the ingenuity to use period as a statement terminator, so it feels even more like a descriptive sentence describing the domain concept.

I don't enjoy writing Rust but its perspective on this is at least internally consistent. What are the alternatives for managing cyclic, linked data structures in other languages?

In languages with manual memory management you can do it, but it's incredibly easy to mess up. You either have to maintain the entire mental model of who owns what data and what data has been initialized in your head or write it down and risk that becoming out of date.

In languages with a GC, the implementors have assumed this complexity for you. Depending on what style of GC your language uses the exact strategy will be different, but on a GC is a comparatively complex piece of code, especially one which handles reference cycles well like we're talking about here.

Either way, the complexity is there somewhere. If you manage memory yourself, you deal with the complexity yourself in a hard-to-debug way. If you can accept the tradeoffs of a GC, then the complexity is abstracted behind the GC. Because Rust is designed for use-cases where you can't accept the tradeoffs of a GC, it has to surface that inherent complexity somewhere. It decides to surface it with ownership semantics, which at least make the rules you're following in manual languages explicit and (largely) unbreakable.

Yeah it's complex, but the underlying problem is complex. I can use GC languages, so I do, but you'd be no better off in C.

I understand that, but it's not as if they've really changed. They always used Rails to advertise Basecamp and vice-versa.

While I think the new site certainly looks appealing and includes a lot more helpful information than before, there's something about the old playful, hand-drawn design that felt more like it embodied the ethos of Rails.

The last point would be amazing, imo. It's unfortunate that, because of history, commands accept and parse arbitrary strings as input instead of formally specifying it like a function signature + docblock. If I could rewrite the universe, commands would use a central API for specifying the names, data types, descriptions, etc. for all the input they take. In our timeline, maybe some file format could be standardized that describes the particular inputs and options a command takes, and e.g. shells would hook into it. Kind of like header files, but distributed either in a community repository or by each of the tools themselves.

I've been thinking of throwing FreeBSD on an old Thinkpad and trying to use it normally. Right now I run Debian, with most of my work happening in Firefox or the shell.

Is there anything you didn't even think about that ended up being a problem, or noticeably worse? Or the opposite, something you thought would be an issue but wasn't?