Comment by sirclueless | Hacker News Reader

Comment by sirclueless | Hacker News Reader

Parent Full thread

    I'm genuinely curious because, as far as I know, none of the
    major languages were designed to be usable...

I think that's a little narrow-minded. Of course languages are designed to be usable. "Usable" is almost meaningless on its own, as every language is intended for use by developers to solve problems (toy languages notwithstanding).

As for your specific goals, "package management, interoperability, docs, and error messages," I think there are in fact major languages designed with very specific goals in those areas. Node.js for example was designed to leverage the immense popularity and familiarity with JavaScript, and it has a clear story for package management that has enabled an enormous ecosystem. Go is a language that from the get-go was designed with a coherent story of how to build large and maintainable systems, encompassing package management and the module system, language features chosen for their simplicity such as interfaces and the lack of generics, and a canonical source formatting tool to attempt to make the whole ecosystem more readable and understandable.

Rust of course has its own answers for usability. They too have a package system that can enable a thriving ecosystem. Their approach to memory management is a naked attempt to make their language "usable," an attempt to make programming more user-friendly language in contexts where interpreted languages, bytecode and even garbage collection are untenable. Their docs are coming along nicely, their error messages perhaps less so.

To say that no major languages are designed for usability is laughable. In fact, I would say that every major language since and including x86 machine code has been designed with usability concerns front and center. The more recent wave of languages especially -- practically no one is trying to beat C and C++ on technical capabilities. They are trying to beat them on ergonomics.

I wouldn't be so dismissive. For starters, we seem to have different definitions for "major" and "usable".

I'd say the major languages are C, C++, C#, Java, JavaScript, Objective-C, PHP, Python, and Visual Basic. I wasn't even thinking of Ruby in that list, and I definitely wasn't including the new kids on the block (Rust, Go, Elixir, etc.) I'm not trying to get into a huge argument about what is a major language -- this is just a rough list that I had in my head and not something I'm set on.

Of those, the newest (PHP, JavaScript, and Ruby) are now 20 years old.

I'm certain that none those came with the important usability features we think of now. I'd also like to think that the science around programming has improved in 20+ years, and we're designing better languages in the 2010s than we were in the 1990s.

Again, this isn't just about syntax or the standard library. The docs and tools around the languages above are mature now, but they didn't start out that way. Rust is interesting because, unlike any of those languages, it's trying to start out with the mature docs and tools we expect in 2015.

And although I can't speak for them, everything I've read suggests that Go was not primarily designed to be usable. The creators intentionally left things out (generics are the obvious example) in their attempt to favor simplicity over usability. I'm not saying it's a bad choice, but it is a polarizing one.

If Go isn't geared towards usability, I don't think it is same definition of usability most adhere to.

Having to write a ton of boilerplate is not "usable". There are several things in Go that I've never seen written in a way that doesn't use a lot of boilerplate.

In fact, if you search for criticism of Go, that's going to be near the top.

Another is that the packages don't have version-matching.

Edit: And, again, this is not to say Go is a bad language or that people shouldn't use it. I'm just pointing out one example of where the Go authors prioritized simplicity over usability. I'm not commenting on the whole language.

You started off this comment thread by asking what kind of research was done to achieve something that is usable. I like that tact because it implies that "usability" isn't something you can reason about from first principles and come up with the right answer to, "Is this software usable?" Instead, it acknowledges the fact that usability should be data driven. What do people using it think?

But your last few comments in this thread seem to have taken a different tact. You've projected some definition of usability that you hold instead of acknowledging that others may think differently. For examples, I can promise you that the Go authors don't think they "prioritized simplicity over usability." They would say that Go is very usable because it is simple.

You disagree, and that's totally cool, but we should be careful to frame it as a difference in perspective.

P.S. Rust and Go are very usable (to me). :-)

I can see where you're coming from, but I've posted a lot of comments on this topic, and I absolutely acknowledge that I don't feel certain about these things. For example, I'm not certain that I agree with Go authors that "simplicity = usability", but I really don't know. I plan to master Go, and then maybe I'll have a better idea.

I've also acknowledged that even my definition of "simplicity" isn't the same as everyone else's.

You seem to be reacting to my argument that boilerplate != usability, and I stand by that. Typing the same thing over and over is fragile, and it's antithetical to the concept of programming. If there's anything that I can say with absolute certainty is vital to usable programming, it's DRY.

Other than that, I really am curious to know what usability really means. I've seen a lot of interesting studies on HN that contradict commonly held notions (e.g. refactor often). It'd be so cool and important for a language to base itself entirely off of such research, rather than a small group's experiences.

Something being usable doesn't imply boilerplate being present or not. In fact I think most if not all languages have boilerplate. They might mitigate it with some macros, but the boilerplate is there.

Usability just means ease of use and learnability. In context of computers languages, I think having a smaller set of idioms/stuff to learn is more vital to usability than to have less stuff to type.

They say generics aren't usable because they aren't simple.

I don't understand them, but they say those words.

The creators of Go seem to think that simplicity is achieved by removing everything that isn't totally necessary.

I'm not sure if I agree philosophically. If I do, then I'm not sure I like that kind of simplicity for writing software. I'd rather have slightly DRYer code than slightly simpler code.

> The creators of Go seem to think that simplicity is achieved by removing everything that isn't totally necessary.

Not really. That path leads to a Forth, a Scheme, a Smalltalk.

There are plenty of things which are not necessary in Go. Many of them are eminently convenient, but could be libraried with generics: most of the built-in magically generic-even-though-the-language-doesn't-have-generic collections for a start. the special-cased multiple return values, the magical builtin functions (which generally exist as support for the aforementioned magical collections).

I've read it before, Go is not simple, it's simplistic. A simple language would by necessity give a lot of power to the developer, that's not what Go does.

There's a difficult balance to strike of course, get too simple and you end up with turing tarpit, and simple languages may make it harder to create cohesive communities. Still, calling Go simple is an insult to simple languages.

I'd guess that many of the worst parts of PHP, and some of the best, were introduced in order to make it more usable.

Reply on news.ycombinator.com