4 ms·

Read all of it before I looked at the date. (The date was added to the title just before I posted this.) I thought it very interesting that Clojure and Scala

Read all of it before I looked at the date. (The date was added to the title just before I posted this.) I thought it very interesting that Clojure and Scala feature very prominently in the comments, and yet I just heard about them a few months ago. I feel like I've had my head stuck in the ground. As for codebase size... Yes, Java is going to have more lines due to the nature of the language. He noted that experienced Java programmers don't see all that excess any more... He claims that's a bad thing, but I think that's what makes the language tolerable for them. They just look over them. I also have to wonder how Mirah would stack up for him. I had high hopes for the language, but it uses the built-in Java types so all that verbosity is still there for anything that uses them. It doesn't really have all the syntactic sugar that Ruby does.

PaulHoule 15y ago
It's an important part of the Java problem that Java programmers aren't allowed to admit that verbosity is a vice and concision is a virtue. It goes hand and hand with a respect for "architecture" that too often can't say that the Emperor often has no clothes, and that a thick encrustation of barnacles often masquerades as an "architecture". Just to take an example, I wasted a few hours of my life trying to change the number of worker threads on a certain server written in Java. In a normal language with a healthy culture I should have been able to write server.setWorkerThreads(16); and I'd be done. But no, this is the land of the architecture astronauts, and if I want to set the worker threads I have to go find the undocumented classes so I can set the BlockingQueue and the ThreadPoolFactory and the fifteen other parameters that I don't care about (and will either set them in a way that is incorrect or suboptimal -- unless I spent two days researching each and every one of those parameters, checking the source code and doing experiments) Although the Java language is to blame for starting this fire, the Java culture perpetuates it. When you complain about this sort of thing, people don't listen, they just say you're a bad developer because you can't see the Emperor's clothes.
- deleted 15y ago
  [deleted]
- jbooth 15y ago
  Actually, a setter on an instantiated server object would prob be a bad idea there, unless you're proposing logic to scale up/down the number of threads dynamically. You probably want a constructor parameter.
  - PaulHoule 15y ago
    the trouble with the constructor parameter is you need one for each and every parameter. this might be a good answer if the language supports named parameters for the constructor, but Java doesn't. In this case, there's a ThreadPoolConfig object which you can set these things on. It turns out you can pass this to the constructor^h^h^h^h^h^h^h^h^h^h^h^h factory method AND you can pass it to a reconfigure() method on the ThreadPool -- so the (normal) static case and the (slightly odd) dynamic case are both covered. It wouldn't be so bad if there were reasonable defaults for the ThreadPoolConfig, but there aren't. If you take the defaults, the server complains that you've got the wrong ThreadFactory when you try to start it. In the end I was able to solve the problem by getting a copy of the thread pool configuration of the server (having to do two casts), changing the thread count, and then reconfiguring. The final answer wasn't that bad, but it wasn't that good either. And that's the trouble w/ the Java culture. The basic design is tolerable, but it's complex, which makes it hard to understand and hard to implement correctly. A little bit of attention to (i) sensible defaults, and (ii) documentation would go a long way. Given a fixed budget, complexity is the enemy of quality, since it creates more surface area for barnacles to accumulate.
    - jbooth 15y ago
      Well, it does sound like a bad design, because they should just be using an ExecutorService.. better implementation and industry-standard interface. Plus you could just do new Server(Executors.newCachingThreadPool(10)). Smart job skipping past my initial point to the deeper point, that constructor values would just accumulate, which creates a need for the builder pattern in the absence of named parameters (which would be sweet.. java 7 supposedly will give us map literals which can substitute).
      - 15y ago

PaulHoule 15y ago

It's an important part of the Java problem that Java programmers aren't allowed to admit that verbosity is a vice and concision is a virtue. It goes hand and hand with a respect for "architecture" that too often can't say that the Emperor often has no clothes, and that a thick encrustation of barnacles often masquerades as an "architecture". Just to take an example, I wasted a few hours of my life trying to change the number of worker threads on a certain server written in Java. In a normal language with a healthy culture I should have been able to write server.setWorkerThreads(16); and I'd be done. But no, this is the land of the architecture astronauts, and if I want to set the worker threads I have to go find the undocumented classes so I can set the BlockingQueue and the ThreadPoolFactory and the fifteen other parameters that I don't care about (and will either set them in a way that is incorrect or suboptimal -- unless I spent two days researching each and every one of those parameters, checking the source code and doing experiments) Although the Java language is to blame for starting this fire, the Java culture perpetuates it. When you complain about this sort of thing, people don't listen, they just say you're a bad developer because you can't see the Emperor's clothes.

deleted 15y ago
[deleted]
jbooth 15y ago
Actually, a setter on an instantiated server object would prob be a bad idea there, unless you're proposing logic to scale up/down the number of threads dynamically. You probably want a constructor parameter.
- PaulHoule 15y ago
  the trouble with the constructor parameter is you need one for each and every parameter. this might be a good answer if the language supports named parameters for the constructor, but Java doesn't. In this case, there's a ThreadPoolConfig object which you can set these things on. It turns out you can pass this to the constructor^h^h^h^h^h^h^h^h^h^h^h^h factory method AND you can pass it to a reconfigure() method on the ThreadPool -- so the (normal) static case and the (slightly odd) dynamic case are both covered. It wouldn't be so bad if there were reasonable defaults for the ThreadPoolConfig, but there aren't. If you take the defaults, the server complains that you've got the wrong ThreadFactory when you try to start it. In the end I was able to solve the problem by getting a copy of the thread pool configuration of the server (having to do two casts), changing the thread count, and then reconfiguring. The final answer wasn't that bad, but it wasn't that good either. And that's the trouble w/ the Java culture. The basic design is tolerable, but it's complex, which makes it hard to understand and hard to implement correctly. A little bit of attention to (i) sensible defaults, and (ii) documentation would go a long way. Given a fixed budget, complexity is the enemy of quality, since it creates more surface area for barnacles to accumulate.
  - jbooth 15y ago
    Well, it does sound like a bad design, because they should just be using an ExecutorService.. better implementation and industry-standard interface. Plus you could just do new Server(Executors.newCachingThreadPool(10)). Smart job skipping past my initial point to the deeper point, that constructor values would just accumulate, which creates a need for the builder pattern in the absence of named parameters (which would be sweet.. java 7 supposedly will give us map literals which can substitute).
    - 15y ago