3 ms·

Being verbose is a plus. I really really really hate the terseness of Kotlin and how it's basically unreadable without an IDE. Languages should be dumb. Standa

Being verbose is a plus. I really really really hate the terseness of Kotlin and how it's basically unreadable without an IDE. Languages should be dumb. Standard libraries should be smart. Not the other way around. The number of syntax constructs that generate standard library calls when compiled should be minimized as much as possible. Edit: one more thing, operator overloading is extremely harmful for readability.

BMorearty 5y ago
Being verbose is one of the biggest negatives a programming language can have. When you’re working on a team with other programmers and reading someone else’s code, verbose code takes much longer to read and grok because you have more boilerplate code to read.
- grishka 5y ago
  But reading terse code requires a lot more prior knowledge, which you might not have. You learn to recognize patterns in the boilerplate and just glance over it, taking no additional time.
  - weatherlight 5y ago
    garbage collected programming languages are for people, not computers. Kotlin isn't terse.
  - BMorearty 5y ago
    It definitely does not take “no” additional time to read verbose boilerplate code. As for prior knowledge, that argument doesn’t fly. A lot of the verboseness of Java could be addressed VERY easily with clear syntax that doesn’t require a lot more prior knowledge. An example is getters and setters, which are very easy to understand in languages that have built-in support for concise syntax but Java has somehow ignored the advantage of concise syntax for 25 years. Besides, if your argument is that Java doesn’t require “prior knowledge,” I beg to differ. E.g., correct usage of arrays vs. ArrayList.
    - skneko 5y ago
      > E.g., correct usage of arrays vs. ArrayList. Arrays vs lists is a thing in all languages, not Java. They just have different names (list, vector, sequence...)
      - kayodelycaon 5y ago
        I don’t think Ruby or Python have linked lists, only arrays.
        skneko 5y ago
        ArrayList is not a linked list, it's an array-backed list like List in C# or other languages, like the name implies. Linked list is `java.util.LinkedList`.
        mattnewton 5y ago
        Ruby and python only have an equivalent to Java’s “array list.” It’s not in the standard library, but you can trivially make linked list nodes yourself if the problem calls for it; I don’t remember encountering a need for the data structure over the built in array-list type outside of interview questions anyways.
    - grishka 5y ago
      Heh, getters and setters. An unpopular opinion, but imo you don't need them most of the time. Usually, a getter just returns a field and a setter just assigns it. If that's the case, and unless you're writing a public API of a library, just make the field public. Make it public final if it's read-only. The difference between arrays and ArrayList is simple: an array has a constant size known at the time of allocation.
  - edoloughlin 5y ago
    I think I could make the same argument for terse code.
wyager 5y ago
The tradeoff space you’re describing doesn’t reflect reality. Adding more brackets and pointless keywords to a language doesn’t meaningfully improve the programmer experience in any way. There are plenty of terse languages that don’t require an IDE to understand. If anything, Java effectively requires an IDE to use because it’s so verbose. The things that I write in a computer program’s code should correspond as closely as possible to what the program means - nothing more and nothing less. Java is terrible at this.
- BMorearty 5y ago
  Excellent counterpoint about Java requiring an IDE because it’s so verbose. In fact when I complain about Java’s verboseness, Java fans tell me “who cares, just use your IDE’s ability to auto-generate code!” But of course that doesn’t help with the _reading_ of verbose code.
  - kaba0 5y ago
    Counterpoint counterpoint: an IDE is most definitely not required to write Java, but due to the ecosystem’s size, reliance on IDE and language’s simplicity (that does cause some additional verboseness), Java’s IDEs are top notch and I wager that you actually type less characters for the same codebase in Java than in some less verbose language due to them. So all in all, win-win with more readable code and less typing.
V-2 5y ago
If Kotlin is unreadable without an IDE, it's Kotlin done badly. You can misuse its features to obfuscate the code, but in and of itself it's an extremely clear language.
- grishka 5y ago
  Kotlin relies on the developer to write readable code, and just generally offers way too many ways of doing the same thing. Too much freedom of expression. Java, by virtue of being more verbose, requires writing everything out explicitly, so you really have to expend some extra effort to make your code unreadable.
  - V-2 5y ago
    "generally offers way too many ways of doing the same thing" Such as? "Java, by virtue of being more verbose, requires writing everything out explicitly, so you really have to expend some extra effort to make your code unreadable." Boilerplate is what makes code unreadable. Getters, setters, backing fields, all that noise, takes lots of space getting in the way of grasping the meaning of the code. Java is too much about how instead of what.
    - grishka 5y ago
      Incapsulation is very much overrated.
filoeleven 5y ago
> Languages should be dumb. Standard libraries should be smart. Not the other way around. This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures. Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: it’s fundamentally a sequential list of things or a key/value map of things. Everything else is a special case that only your program cares about, and it gives you the tools to build a system to work with them as generally or specifically as you need it to.
- kaba0 5y ago
  That is data. Not every problem is fundamentally about data though — the special case you mention may very well be the whole problem domain. Eg. what percent of data does a compositor work with vs state-holding objects with proper structures like WindowLayoutEngine and the like?
  - filoeleven 5y ago
    I’m not familiar with compositors, so unfortunately I don’t have a ready answer, only more questions. What makes a WindowLayoutEngine “a state-holding object with proper structures?” How is it different from “a data tree with proper structure,” except that the former includes methods inside the class instance while the latter relies on functions to operate on the data tree?
goatlover 5y ago
"The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important." - Notation as a Tool of Thought by Kenneth Iverson
aww_dang 5y ago
I like verbosity. I like knowing what I am getting. I like explicitly specifying the defaults, rather than assuming or having the details buried in the documentation. Solving problems and formulating a problem solving approach takes time. This is the important part of writing software. A few extra keystrokes are relatively minor in comparison. "I want to write software, but I don't want to type too much", never made sense for me.

BMorearty 5y ago

Being verbose is one of the biggest negatives a programming language can have. When you’re working on a team with other programmers and reading someone else’s code, verbose code takes much longer to read and grok because you have more boilerplate code to read.

grishka 5y ago
But reading terse code requires a lot more prior knowledge, which you might not have. You learn to recognize patterns in the boilerplate and just glance over it, taking no additional time.
- weatherlight 5y ago
  garbage collected programming languages are for people, not computers. Kotlin isn't terse.
- BMorearty 5y ago
  It definitely does not take “no” additional time to read verbose boilerplate code. As for prior knowledge, that argument doesn’t fly. A lot of the verboseness of Java could be addressed VERY easily with clear syntax that doesn’t require a lot more prior knowledge. An example is getters and setters, which are very easy to understand in languages that have built-in support for concise syntax but Java has somehow ignored the advantage of concise syntax for 25 years. Besides, if your argument is that Java doesn’t require “prior knowledge,” I beg to differ. E.g., correct usage of arrays vs. ArrayList.
  - skneko 5y ago
    > E.g., correct usage of arrays vs. ArrayList. Arrays vs lists is a thing in all languages, not Java. They just have different names (list, vector, sequence...)
    - kayodelycaon 5y ago
      I don’t think Ruby or Python have linked lists, only arrays.
      - skneko 5y ago
        ArrayList is not a linked list, it's an array-backed list like List in C# or other languages, like the name implies. Linked list is `java.util.LinkedList`.
      - mattnewton 5y ago
        Ruby and python only have an equivalent to Java’s “array list.” It’s not in the standard library, but you can trivially make linked list nodes yourself if the problem calls for it; I don’t remember encountering a need for the data structure over the built in array-list type outside of interview questions anyways.
  - grishka 5y ago
    Heh, getters and setters. An unpopular opinion, but imo you don't need them most of the time. Usually, a getter just returns a field and a setter just assigns it. If that's the case, and unless you're writing a public API of a library, just make the field public. Make it public final if it's read-only. The difference between arrays and ArrayList is simple: an array has a constant size known at the time of allocation.
- edoloughlin 5y ago
  I think I could make the same argument for terse code.

wyager 5y ago

The tradeoff space you’re describing doesn’t reflect reality. Adding more brackets and pointless keywords to a language doesn’t meaningfully improve the programmer experience in any way. There are plenty of terse languages that don’t require an IDE to understand. If anything, Java effectively requires an IDE to use because it’s so verbose. The things that I write in a computer program’s code should correspond as closely as possible to what the program means - nothing more and nothing less. Java is terrible at this.

BMorearty 5y ago
Excellent counterpoint about Java requiring an IDE because it’s so verbose. In fact when I complain about Java’s verboseness, Java fans tell me “who cares, just use your IDE’s ability to auto-generate code!” But of course that doesn’t help with the _reading_ of verbose code.
- kaba0 5y ago
  Counterpoint counterpoint: an IDE is most definitely not required to write Java, but due to the ecosystem’s size, reliance on IDE and language’s simplicity (that does cause some additional verboseness), Java’s IDEs are top notch and I wager that you actually type less characters for the same codebase in Java than in some less verbose language due to them. So all in all, win-win with more readable code and less typing.

V-2 5y ago

If Kotlin is unreadable without an IDE, it's Kotlin done badly. You can misuse its features to obfuscate the code, but in and of itself it's an extremely clear language.

grishka 5y ago
Kotlin relies on the developer to write readable code, and just generally offers way too many ways of doing the same thing. Too much freedom of expression. Java, by virtue of being more verbose, requires writing everything out explicitly, so you really have to expend some extra effort to make your code unreadable.
- V-2 5y ago
  "generally offers way too many ways of doing the same thing" Such as? "Java, by virtue of being more verbose, requires writing everything out explicitly, so you really have to expend some extra effort to make your code unreadable." Boilerplate is what makes code unreadable. Getters, setters, backing fields, all that noise, takes lots of space getting in the way of grasping the meaning of the code. Java is too much about how instead of what.
  - grishka 5y ago
    Incapsulation is very much overrated.

filoeleven 5y ago

> Languages should be dumb. Standard libraries should be smart. Not the other way around. This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures. Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: it’s fundamentally a sequential list of things or a key/value map of things. Everything else is a special case that only your program cares about, and it gives you the tools to build a system to work with them as generally or specifically as you need it to.

kaba0 5y ago
That is data. Not every problem is fundamentally about data though — the special case you mention may very well be the whole problem domain. Eg. what percent of data does a compositor work with vs state-holding objects with proper structures like WindowLayoutEngine and the like?
- filoeleven 5y ago
  I’m not familiar with compositors, so unfortunately I don’t have a ready answer, only more questions. What makes a WindowLayoutEngine “a state-holding object with proper structures?” How is it different from “a data tree with proper structure,” except that the former includes methods inside the class instance while the latter relies on functions to operate on the data tree?

goatlover 5y ago

"The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important." - Notation as a Tool of Thought by Kenneth Iverson

aww_dang 5y ago

I like verbosity. I like knowing what I am getting. I like explicitly specifying the defaults, rather than assuming or having the details buried in the documentation. Solving problems and formulating a problem solving approach takes time. This is the important part of writing software. A few extra keystrokes are relatively minor in comparison. "I want to write software, but I don't want to type too much", never made sense for me.