5 ms·

You're perpetuating a myth. Verbosity doesn't equal less productivity. I would be really surprised if anyone here said their bottleneck in programming was the

by axod 16y ago

You're perpetuating a myth. Verbosity doesn't equal less productivity. I would be really surprised if anyone here said their bottleneck in programming was the speed they can type. Also, all languages have their needless verbosity - look at 'end' vs '}' (ruby vs java). Which is the more verbose?

clyfe 16y ago
Ruby can use both "{...}" and "do ... end", with a slight difference between the two (precedence): def some_method { ... } def some_method do ... end
- djacobs 16y ago
  I don't believe the second one works. Usually you'd define a method using: def some_method # do something end Usually you'll only use do after a method that's already defined, in order to pass a block of code to it.
  - steveklabnik 16y ago
    You are correct: ruby-1.9.2-p0 > def something; "hey" end => nil ruby-1.9.2-p0 > something => "hey" Adding the do makes it not work. def doesn't have a do.
mhd 16y ago
Verbosity and increased complexity in Java comes mainly for two reasons, none of which is about minor syntactical issues. Java doesn't abstract very well beyond objects and classes. This becomes pretty irritating in stuff like event handlers, where you'd really like to use something like a lambda/delegate, but the only option you have is an inner class. This might change in the future, but right now some minor language features would make it much easier, and you'd avoid hard to track down annotations and reflection. Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions… Having said that, there are lots of really good libraries and frameworks who don't fall into those traps (well, at last not too deeply). And maybe Oracle will bestow onto us some sparkly new bits that will cut down on some boiler plate and will alleviate the need for IDE wizards/code generators or stuff like lombok[1]. In some areas, languages like Perl, Python (or even Lisp) will still have advantages, but it would be nice if Java programmers could at least catch up a little to C#. [1]: http://projectlombok.org/ http://projectlombok.org/
- axod 16y ago
  >> Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions… I've been using Java for 10 years+, and never used any of that.
  - mhd 16y ago
    You never used checked exceptions?
    - axod 16y ago
      You're right, those are the only thing I do use, where appropriate. If you just avoid all the enterprisey crap, Java is a very nice place to be.
djd 16y ago
That would totally be on individual comfort wont it? i would love to type END instead of '}'with a shift
mkramlich 16y ago
> Verbosity doesn't equal less productivity. Disagree. And not based on myth. Based on direct experience over 25 years doing programming. Verbosity -- holding all other things equal -- does equal less productivity. To put the argument in thumbnail form: it takes about the same amount of time for me to devise a programming design for something in Python as in Java. But to type in, run and test that design? Much less time with Python than Java. The human is the bottleneck at development time, in general, not the computer, not the runtime execution speed. I also only have a finite amount of display screen real estate, so with a more concise language I can "see" more feature points on the screen, all at once, when looking at source code. And since there are less LOC if I ever have to do code surgery or cut-and-paste things around I can do that faster too, in general, with a more concise language. But all arguments aside -- because they are irrelevant in the face of direct experience -- I can say that I now personally avoid choosing Java in all the personal projects I've initiated, and I also bias to advising startups to avoid it (in general) in favor of a lighter language. The issue is more complex when you're dealing with an external client and somebody else's business, however, because sometimes the benefits of Java outweigh it's verbosity -- and there's nothing wrong with choosing it if those factors are critical and pertinent to any particular project. But when a design is clear, and my implementation choices are clear and fresh in my head, and I know almost exactly what LOC I'm going to write next, then yes I've found that "new line creation speed" does impact the overall time it's going to take to finish a particular feature or change. Years and years of observations backing this up.
- axod 16y ago
  > Disagree. And not based on myth. Based on direct experience over 25 years doing programming. Verbosity -- holding all other things equal -- does equal less productivity. Well, around 20 years here. If you look at the extreme. Regular expressions. They're concise to the extreme. That has distinct disadvantages. * It's hard to parse * Easy to create errors So clearly verbosity!=bad. I started with basic but quickly moved on to creating large programs in assembly. I think once you've done that for a few years you start to look past the lines of code and more into general program structure and flow. 'public static final' isn't verbose. They're keywords. They're flags. They're not meaningful program structure, so your brain skips over them unless it needs to check what the flags are. People often mistake keywords like the above for verbosity. The actual syntax of java code, eg {}(). etc is very concise.

by axod 16y ago

clyfe 16y ago

Ruby can use both "{...}" and "do ... end", with a slight difference between the two (precedence): def some_method { ... } def some_method do ... end

djacobs 16y ago
I don't believe the second one works. Usually you'd define a method using: def some_method # do something end Usually you'll only use do after a method that's already defined, in order to pass a block of code to it.
- steveklabnik 16y ago
  You are correct: ruby-1.9.2-p0 > def something; "hey" end => nil ruby-1.9.2-p0 > something => "hey" Adding the do makes it not work. def doesn't have a do.

mhd 16y ago

Verbosity and increased complexity in Java comes mainly for two reasons, none of which is about minor syntactical issues. Java doesn't abstract very well beyond objects and classes. This becomes pretty irritating in stuff like event handlers, where you'd really like to use something like a lambda/delegate, but the only option you have is an inner class. This might change in the future, but right now some minor language features would make it much easier, and you'd avoid hard to track down annotations and reflection. Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions… Having said that, there are lots of really good libraries and frameworks who don't fall into those traps (well, at last not too deeply). And maybe Oracle will bestow onto us some sparkly new bits that will cut down on some boiler plate and will alleviate the need for IDE wizards/code generators or stuff like lombok[1]. In some areas, languages like Perl, Python (or even Lisp) will still have advantages, but it would be nice if Java programmers could at least catch up a little to C#. [1]: http://projectlombok.org/ http://projectlombok.org/

axod 16y ago
>> Also, Java library design often tends towards the obfuscated. [...]Adapters, [...]Implementations and [...]Factories, the usually bloated read/write beans, checked exceptions… I've been using Java for 10 years+, and never used any of that.
- mhd 16y ago
  You never used checked exceptions?
  - axod 16y ago
    You're right, those are the only thing I do use, where appropriate. If you just avoid all the enterprisey crap, Java is a very nice place to be.

djd 16y ago

That would totally be on individual comfort wont it? i would love to type END instead of '}'with a shift

mkramlich 16y ago

> Verbosity doesn't equal less productivity. Disagree. And not based on myth. Based on direct experience over 25 years doing programming. Verbosity -- holding all other things equal -- does equal less productivity. To put the argument in thumbnail form: it takes about the same amount of time for me to devise a programming design for something in Python as in Java. But to type in, run and test that design? Much less time with Python than Java. The human is the bottleneck at development time, in general, not the computer, not the runtime execution speed. I also only have a finite amount of display screen real estate, so with a more concise language I can "see" more feature points on the screen, all at once, when looking at source code. And since there are less LOC if I ever have to do code surgery or cut-and-paste things around I can do that faster too, in general, with a more concise language. But all arguments aside -- because they are irrelevant in the face of direct experience -- I can say that I now personally avoid choosing Java in all the personal projects I've initiated, and I also bias to advising startups to avoid it (in general) in favor of a lighter language. The issue is more complex when you're dealing with an external client and somebody else's business, however, because sometimes the benefits of Java outweigh it's verbosity -- and there's nothing wrong with choosing it if those factors are critical and pertinent to any particular project. But when a design is clear, and my implementation choices are clear and fresh in my head, and I know almost exactly what LOC I'm going to write next, then yes I've found that "new line creation speed" does impact the overall time it's going to take to finish a particular feature or change. Years and years of observations backing this up.

axod 16y ago
> Disagree. And not based on myth. Based on direct experience over 25 years doing programming. Verbosity -- holding all other things equal -- does equal less productivity. Well, around 20 years here. If you look at the extreme. Regular expressions. They're concise to the extreme. That has distinct disadvantages. * It's hard to parse * Easy to create errors So clearly verbosity!=bad. I started with basic but quickly moved on to creating large programs in assembly. I think once you've done that for a few years you start to look past the lines of code and more into general program structure and flow. 'public static final' isn't verbose. They're keywords. They're flags. They're not meaningful program structure, so your brain skips over them unless it needs to check what the flags are. People often mistake keywords like the above for verbosity. The actual syntax of java code, eg {}(). etc is very concise.