Hacker News Reader

I would say that Java has ~50% more code than Python due to types and braces. But I agree with you that it's worth it, because the compiler can check that a programmer satisfied a constraint, instead of relying on informal conventions or comments.

You can have a statically typed language without verbosity, via type inference (Haskell, newer Java, etc.). I wouldn't say I enjoy Java's verbosity, but I would take this over shooting myself in the foot because Python does little to protect me from my own silly type/name mistakes.

I do lament that Java falls short on being able to declare tuples, lists, and dictionaries easily.

Most Haskellers write out the types even though they can be inferred. In a pure language, signatures are extremely close to documentation (you know exactly what a function will do by its signature).

Java requires more code than Python or Haskell because it's extremely imperative and statement based. Python on the other hand includes a lot of functional, more expressive idioms like concise list comprehensions.

> Most Haskellers write out the types even though they can be inferred.

I don't think that's true. Idiomatic Haskell has explicit declarations only for top level functions and uses type inference for everything else.

I often copy paste the inferred type to top level declarations, so I’m a sense it is true

Types aren’t documentation, no matter how many Haskell users delude themselves thinking it is.

Documentation is more than a function definition. Types don’t explain rationales and how to use functions and programs. Types don’t give proper examples.

It's better documentation than no documentation

Types are really good documentation. I can tell I'm not deluded by thinking so because I can sit down with a Haskell library containing zero examples and write code that uses it. If your assertion was correct, that would be impossible. But it's not only possible, it's easy. Perhaps there is more to types than you realize.

Alice: Hey Bob, want to try my nifty new function?

Bob: Sure, Alice, what does it do?

Alice: It takes an object and it returns an object.

Bob: But what does it actually do?

Alice: I told you. It takes an object and it returns an object.

Bob: But what does it do with the object? What's it for? Why should I use it?

Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go use it.

Bob: Um, no thanks. I like to know more about what I'm getting myself in to.

Thankfully, Haskell supports much nicer types than only `Object`

Alice: Hey Bob, want to try my nifty new function?

Bob: Sure, Alice, what does it do?

Alice: It takes a string and it returns an integer.

Bob: But what does it actually do?

Alice: I told you. It takes a string and it returns an integer.

Bob: But what does it do with the string? What's it for? Why should I use it?

Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go use it.

Bob: Um, no thanks. I like to know more about what I'm getting myself in to.

I think you're criticizing a language you have no experience in. Haskell development is type driven. You start by defining and constraining your types until you get a DSL to write signatures in. See the Idris O'reilly book for more on type driven development.

By the time you've added type constrains through typeclasses, selected types named after the domain, and selected a suitable name for the function, it's possible to write against the signature with no knowledge of the body or comments.

You're also forgetting that signature includes the name of the function.

reverse :: [a] -> [a] is easy to understand by it's name and type.

I didn't critisize Haskell. I only criticized a statement about its type system.

> You're also forgetting that signature includes the name of the function.

That's what I wanted to point out. The name of a function is even more important than its types. Types alone seldomly give you the complete picture of what's going on in a function.

Of course the name can be wrong whereas types can't, but the name is less likely to be wrong than a comment.

Types are documentation. Documentation isn't types.

I suggest reading Type-Driven Development with Idris by Edwin Brady. I don't think you have enough experience writing Haskell to understand the outcome of type driven development.

In Haskell you start by defining your domain as types, and constrain those types with typeclasses. By the time you get to writing signatures, the implementations can almost be inferred (in Idris they actually can be inferred, the code literally writes itself).

In an imperative language with side effects, examples and documentation are a must because behavior is hidden in the body of a function; the signatures lie.

A journeyman Haskeller can write code that is completely self documenting. No examples are required, because the types coupled with the purity of the language allows us to tell the whole story.

This is (probably often) true for all those who can load a few dozen arbitrary type signatures into their active memory and start drawing conclusions. For the rest of us a few examples of how to do common things would help a lot. Please include documentation.

I have experienced what you're talking about with Haskell but it was a lot of uncomfortable work. But it's "technically" true that the types often describe how to use a library, sometimes so well that errors cannot happen.

>In a pure language, signatures are extremely close to documentation (you know exactly what a function will do by its signature).

The same can be true of tests. I've started generating API documentation from mine: e.g. https://hitchdev.com/strictyaml/using/alpha/scalar/email-and...

I tend to think of types and tests as attacking the same problem from opposite directions.

> StrictYAML can validate emails (using a simplified regex)

Public Service Announcement: don't validate emails with regex. Every time you do, god kills a kitten.

Just checking for the @ symbol is fair game. Anything beyond that is a bad idea.

Agreed :)

> Most Haskellers write out the types

Maybe that's partly because Haskell can easily become a bit too elegant. Between all the currying and combinators, the type helps to understand code "top down", i.e. when you don't have studied and memorized all "bottom up" component parts.

Tuples especially, and more specifically how the language supports their unwrapping.

for idx, entry in enumerate(list)

vs. list iterators in Java where you have to repeat complex types at least 3 times and get about 5-10 times more code when it would only have to be about 2 times to achieve static type safety. Lack of typedef and the resulting drive towards dummy classes is exacerbating this problem further.

Java is verbose, but it isn't expressive. In Java you talk a lot without ever saying anything. In an expression based language like Lisp or Rust, you can more compactly write your ideas into code, even though Rust might still be verbose syntactically like Java.

The kind of verbosity you describe isn't really the issue in my view. The contentious verbosity is theKindWhereVariableNamesLookLikeThis and "fluent" programming style that turns "assert(testRes == expected)" into "assertThat(testRes).isEqualTo(expected)". It's excessive and removes value most of the time.

Well the fluent style is more verbose, but has the advantage of telling you more information about what went wrong. You get a report telling you that "x was not equal to y" rather than "expected true". The verbosity is way more helpful to me.

or you can use a language with macros, then a testing library can report the code being evaluated and the values in it.

Even Java has testing libraries that provide optional failure case messages with asserts to provide specific context where necessary.

Swift is statically typed and a “Hello, World!” in Swift is just print(“Hello, World!”).

So going back to the original commenter's points: how does Swift handle top-level code? Where is it legal for me to write print("Hello, World")?

Anywhere outside of things like a class or structure definition, if you have a single-file project. In a multi-file project, only in main.swift.

> I'd rather have to type 20% more than spend 20% more time figuring out other people's code.

If that were the trade off, it would be a no brainer. But instead it feels like double the code, for no clarity (or negative clarity because the noise becomes obfuscation).

Can't you get all the same advantages of Java with less verbosity in languages like Go, Swift, Rust or Haskell?