5 ms·

I think you mean "characters". Rather than code. "public static void main()" isn't a lot of code. It's three keywords, and one identifier. You may consider it

I think you mean "characters". Rather than code. "public static void main()" isn't a lot of code. It's three keywords, and one identifier. You may consider it a lot of characters, but it's pretty rare that a programmers bottleneck is speed of typing. I wish people would stop confusing "number of characters" with "amount of code". And FWIW, I find your example far harder to decipher. I have to know what => means, # means, what : means, etc etc etc. Add to that, in your example, if you typo one of those characters, your code may well still run, but will fail. With Java, if you typo a single character, it's more likely the code just won't compile. We could all code in regular expressions or something akin to that, maybe perl one liners. But "number of characters" isn't a good aim. Readable, maintainable, well written code is.

latch 14y ago
The last part of your comment is just language bias. symbols and hashes are fundamental to ruby. Why would I use string concatenation like my parent, when the language support string interpolation. It's as unclear to you as generics or annotations might be to someone who didn't know Java. Surely you see that? I think you are being pedantic about characters vs code. But, for what it's worth, I disagree. You are having to create 2 classes, define a field, a constructor and use four framework specific annotation. I consider all of that code (made up of characters). Both versions should be unit tested. The unit test might be more important in the Ruby version, but so too will it be easier to write.
- mibbitier 14y ago
  I grew up reading assembly code listings. Being able to read code is a really really important skill IMHO. Something like Java is very very easy to read. It's mainly keyword based, rather than special character based. I'd much rather read a 1,000 line Java program, than a 100 line <concise language> program. The other point I'd make is that Java is probably about as verbose as english is. But we all manage, using English. We don't moan on and on that talking, writing, reading is so inefficient and we should all switch to something better. English also has odd grammar and spelling rules which are inconsistent and plain stupid sometimes. Yet, English works pretty well for what we use it for. Communicating.
  - Silhouette 14y ago
    The other point I'd make is that Java is probably about as verbose as english is. But we all manage, using English. We don't moan on and on that talking, writing, reading is so inefficient and we should all switch to something better. You've made this argument in multiple posts now, so I'm just going to point out here that people doing science and engineering use formal, mathematical notations precisely because they do offer more precise and concise ways of expressing the necessary technical concepts. There are plenty of reasons to criticise some of those notations with hindsight, but "not being English" is not among them.
  - pi18n 14y ago
    You'd much rather read a Java program because you are already biased towards it. Yes it's easy to read, but you need to acknowledge that many other skilled developers would find it easier to read Python, or Ruby, and indeed would rather read 1,000 lines of the same over 100 lines of Java. Otherwise you are simply being willfully ignorant. Why is Java considered inefficient and English not? Maybe because we don't need to create a new class for every concept in English. Yours is a pretty poor analogy; English vocabulary is extensive but it is not inherently verbose. Anyway I am only writing not to say you are wrong, but rather, since other people are arguing with you reasonably and you are dismissing them without consideration, your argumentation is wrong.
    - mibbitier 14y ago
      > "You'd much rather read a Java program because you are already biased towards it." No. I'd rather read "int foo; bar.printLn()" than "%foo => &bar :print" Less special characters. More words. Each to their own though.
      - koide 14y ago
        So you'd also rather read "An unordered tuple Z going from a1 to an is a defined as for every x in Z then x is a1 or x is a2 ... or x is an" than "An unordered tuple Z (a1,...,an) is defined as [x : x = a1 v x = a2 v ... x = an]"? I take that as not being (or not wanting to be) familiar with the language you are reading. If you'll read Ruby, at least browse a manual to know what {} and # mean.
mythz 14y ago
This is just a sad Stokholm defence - against languages that threatens your sacred cow - which is understandable since the Java code example got pwned. So rather than defending the code example on merit, you dive into pedantic nit-picking territory. I used to be defensive about my choice language as well, till I matured and realized holding onto sacred cows just hurts your ability to learn from others doing it better and being more productive; and just clouds your ability to choose the right tool for the job. More code = more code, to read, to decipher, that hides intent, that adds complexity, that can have bugs and can go wrong. Code-size is codes worst enemy. I don't even know Ruby, but it's implementation is vastly more readable and would look a lot closer to what the perfect DSL would look like for this task, than the Java example.

latch 14y ago

The last part of your comment is just language bias. symbols and hashes are fundamental to ruby. Why would I use string concatenation like my parent, when the language support string interpolation. It's as unclear to you as generics or annotations might be to someone who didn't know Java. Surely you see that? I think you are being pedantic about characters vs code. But, for what it's worth, I disagree. You are having to create 2 classes, define a field, a constructor and use four framework specific annotation. I consider all of that code (made up of characters). Both versions should be unit tested. The unit test might be more important in the Ruby version, but so too will it be easier to write.

mibbitier 14y ago
I grew up reading assembly code listings. Being able to read code is a really really important skill IMHO. Something like Java is very very easy to read. It's mainly keyword based, rather than special character based. I'd much rather read a 1,000 line Java program, than a 100 line <concise language> program. The other point I'd make is that Java is probably about as verbose as english is. But we all manage, using English. We don't moan on and on that talking, writing, reading is so inefficient and we should all switch to something better. English also has odd grammar and spelling rules which are inconsistent and plain stupid sometimes. Yet, English works pretty well for what we use it for. Communicating.
- Silhouette 14y ago
  The other point I'd make is that Java is probably about as verbose as english is. But we all manage, using English. We don't moan on and on that talking, writing, reading is so inefficient and we should all switch to something better. You've made this argument in multiple posts now, so I'm just going to point out here that people doing science and engineering use formal, mathematical notations precisely because they do offer more precise and concise ways of expressing the necessary technical concepts. There are plenty of reasons to criticise some of those notations with hindsight, but "not being English" is not among them.
- pi18n 14y ago
  You'd much rather read a Java program because you are already biased towards it. Yes it's easy to read, but you need to acknowledge that many other skilled developers would find it easier to read Python, or Ruby, and indeed would rather read 1,000 lines of the same over 100 lines of Java. Otherwise you are simply being willfully ignorant. Why is Java considered inefficient and English not? Maybe because we don't need to create a new class for every concept in English. Yours is a pretty poor analogy; English vocabulary is extensive but it is not inherently verbose. Anyway I am only writing not to say you are wrong, but rather, since other people are arguing with you reasonably and you are dismissing them without consideration, your argumentation is wrong.
  - mibbitier 14y ago
    > "You'd much rather read a Java program because you are already biased towards it." No. I'd rather read "int foo; bar.printLn()" than "%foo => &bar :print" Less special characters. More words. Each to their own though.
    - koide 14y ago
      So you'd also rather read "An unordered tuple Z going from a1 to an is a defined as for every x in Z then x is a1 or x is a2 ... or x is an" than "An unordered tuple Z (a1,...,an) is defined as [x : x = a1 v x = a2 v ... x = an]"? I take that as not being (or not wanting to be) familiar with the language you are reading. If you'll read Ruby, at least browse a manual to know what {} and # mean.

mythz 14y ago

This is just a sad Stokholm defence - against languages that threatens your sacred cow - which is understandable since the Java code example got pwned. So rather than defending the code example on merit, you dive into pedantic nit-picking territory. I used to be defensive about my choice language as well, till I matured and realized holding onto sacred cows just hurts your ability to learn from others doing it better and being more productive; and just clouds your ability to choose the right tool for the job. More code = more code, to read, to decipher, that hides intent, that adds complexity, that can have bugs and can go wrong. Code-size is codes worst enemy. I don't even know Ruby, but it's implementation is vastly more readable and would look a lot closer to what the perfect DSL would look like for this task, than the Java example.