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?

Hey, don't be so pessimistic. We'll probably have another serialization protocol by then.

Ah, I understand now. That's a fair point! I agree that the excellent Go tooling is one of its strengths.

Right, but the entire point of my comment was that "takes up a significant part of the language spec, compiler, and VM" is not a good approximation of complexity. It can be related, but it is not necessarily true that something with a complex implementation has a complex interface.

    I can hold the whole language spec in my head while I'm programming

People love to say this about Go, but it's not something that, like, actually matters (and I doubt it's literally true). A language can be reasonably understandable such that you can effectively and productively program in it without being aggressively simple. Again, to use the case of Ruby, I might not remember every single syntactical construct or handling of every edge case, but the language is reasonably understandable such that I can write programs without constantly asking "what was the syntax for that?" or "how do I express this?" As a counter-example, I think the complexity of C++ is not just limited to its implementation, and leaks out to its interface.

    ...sacrifice the simplicity of the language, or make it any harder to read go code

These are two separate concerns which, while somewhat related, are not directly correlated. A simple language can make it more obvious which syntactical constructs are being used and what literal operations are being performed, but there are many more dimensions to reading code than just those.

I don't know what kind of stuff you all work on, but for the kind of things I work on if the interface isn't specifically designed and laid out after doing user research on the problem space, the whole project is a no-go, and is certainly not "getting work done."

I think you're confusing look with function. Two things need not look the same to "adhere to assumptions and pattern recognition," but rather need to function the same and have the same underlying conceptual language. If the web had better builtin widgets (combo boxes, dialogs, etc.), then you'd get this benefit, but because everybody is reinventing everything with JS, every site feels different.

> it's fun for designers to make up their own UIs

It's not just "fun," it's necessary to create an optimal user experience for every particular use-case. Have you ever played two video games which have the same UI? I'd be surprised if you have. Each and every one has its own interaction patterns, its own design language, and its own visual hierarchy.

I absolutely want the web to have better builtin widgets with common functionality and accessibility, but the point is not for them to look the same, but rather work the same.

To me, "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. The job of languages, imo, is to provide tools/features/syntax for expressing problems, whether their implementation is complex or not. Ruby is an incredible language to use, but its implementation is notoriously hairy. That internal complexity is not something that matters to me in the slightest.

I understand the Go team's reluctance to get the user-facing interface wrong, and end up with something like type-erasure in Java; that's slightly connected with implementation complexity, but saying "it's complex to implement and specify" doesn't seem enough to me.

[edit: made it clearer that this is my thought on the job of languages and not some universal truth]

That's true, I didn't even think of that! That makes it even more unfortunate

True, I was being a bit hyperbolic with "massive corp" :). Employee size isn't everything in determining how "big" an organization is, though. I really just meant that it, personally, makes me feel better to use something created by a small, scrappy team than something maintained by a multinational enterprise.

Frameworks like this are nice if a) you want your site to look exactly like every other site which uses this framework (rare) and b) every use of an element is for the exact same purpose (also rare).

I suppose if you're throwing together some hacky admin page that 2 people are going to use in a year, it makes sense. Otherwise I don't see why you don't just design your site.

Swift is an incredibly appealing language on so many fronts. It has an expressive and fairly robust type system, an excellent suite of built-in libraries, and moreso than many other languages I've used cares deeply about syntactical ergonomics (i.e. how a language construct or interface feels and reads to use).

It's so unfortunate that its tied up in the Apple ecosystem, then. Not that they don't care about it (they clearly do) but by being an Apple project first-and-foremost, it has virtually no community control—practically no community to speak of—and is unlikely to ever have real, first-class support for use-cases that Apple doesn't use it for, e.g. web apps/APIs or CLIs (where it's the most appealing, imo). This has some benefits, like adding features to the language when Apple-created designs are hard (e.g. SwiftUI), but it's overall a net negative.

Contrast this state with Rust, which has by far the best community I've encountered, and cares deeply about developer experience. Or compare it to JS, which has a clear, formal, and well-documented process for adding features to the language. If Swift were a truly open project, I'd have a hard time finding many things to dislike about it.

Drivers, customizations on top of Gnome (if you prefer them), App Store, flatpak instead of snap. Plus made by an indie company rather than some massive corp if you're into that sort of thing.

Probably were thinking of 'st', or some other project under the umbrella of software that certainly sucks more.

The thing I like about passing objects around is that the state inside the object is opaque :). Thus when changes to the internal details of Person happen, the behavior of which is depended on by Inbox and Message, as long as I have properly depended on its public behavior, I don't need to change anywhere else. If I was just using plain data values as is common in e.g. Clojure, every change to something's internal representation would require changes to places which depend on it.