5 ms·

Fair comment -- thanks for the feedback. I've received similar feedback from a friend who reviewed the post, and I completely agree. To be honest, I had to go

Fair comment -- thanks for the feedback. I've received similar feedback from a friend who reviewed the post, and I completely agree. To be honest, I had to go ahead and publish what I had or it would have remained in my drafts forever. However, I'd like to follow up in the future and address some of the points you raise.

jasode 12y ago
If you're taking feedback, I'd like to disagree on your examples of "accidental complexity". To me, accidental complexities are quirks of design that everyone would agree to do over differently if history replayed itself. Examples like that would be: -- Java calendar (and C Language ctime) months have index starting with 0 which means 0..11 for Jan..Dec but for days, it's index 1 which means 1..31 -- PHP inconsistencies such some functions being verb_obj while others are obj_verb and some have underscores and some do not -- MS Excel has incorrect leap year calculation for 1900 which means all other spreadsheets must duplicate this "bug" to be compatible Those are the types of "accidents" that arise out of ignorance or uncoordinated thinking. Andrei Alexandrescu (expert in C++ and D) has a similar concept he calls "unforced errors". On the other hand, you compared a Tomcat servlet container as being "accidental complexity" and Go as "reduced complexity" because the http hosting is all built into the exe. To me this is an example of moving complexity around so you don't feel it for your particular use cases of the Go language. In other words, if the Java community had a chance to do it again, I'm not convinced that Tomcat servlet would be baked into the standard Java distribution. If you bake it into the JVM, you've made the JVM Specification[1] more complex. If you leave it out of the JVM but include it as a standard class library, you've made the API library reference more complex[2] (Alternative universe: Why is the class library reference 3000 pages long?! Because it includes 200 pages to document a servlet container that most don't use.) Complexity (in totality) wasn't reduced. It was only shifted around. I'm not saying moving complexity around isn't desirable because it is (hence we have "abstractions") but it's not an example of solving accidental complexity. I think what happens is that we programmers find some language, or framework and if it matches our use cases, it's subjectively less complex. For the others who need generics to write algorithms, they write homegrown template code generators or resort to copy&paste which is more complex. So sure, Golang omits generics but it only makes it less complex from a language-specification perspective. However, it's actually more complex from a total project perspective. I think this explains all the contradictory posts about Django/Rails/etc being "simple" while other posts say it's "complex pulling teeth". At this point, I don't buy that golang without qualifiers of use-cases is objectively less complex. I'm writing server-side web services with golang and for that use case, I think it's less complex than other alternatives such as C++ or Nodejs. For Windows GUI apps, using C++ with Qt is less complex than Golang. [1]http://docs.oracle.com/javase/specs/jvms/se7/html/ http://docs.oracle.com/javase/specs/jvms/se7/html/ [2]http://docs.oracle.com/javase/7/docs/api/ http://docs.oracle.com/javase/7/docs/api/
- AnimalMuppet 12y ago
  I think you missed the author's point here. You have to have the webserver somewhere. That's inescapable complexity. It's in the language, or in the library, or in an external container like Tomcat. But if you're going to run a web app, you have to have a server somewhere. Where Go made things simpler is in the dependencies. The app now has all the dependencies compiled in, and so it's completely isolated from what libraries some other app in the container needed. That is a removal of accidental complexity. (Right up until you need to update all the apps to fix a bug in some library, and now you have to update each app, not just update one library in the container...)
  - jasode 12y ago
    >Where Go made things simpler is in the dependencies. The app now has all the dependencies compiled in, and so it's completely isolated from what libraries some other app in the container needed. That is a removal of accidental complexity. I agree with all that Golang simplification except for one thing: I don't call the previous state of affairs "accidental complexity". It's certainly "more complex" with more moving parts but it doesn't feel "accidental" to me. I maintain that the nature of complexity and location of it has changed. You yourself gave an example: >(Right up until you need to update all the apps to fix a bug in some library, and now you have to update each app, not just update one library in the container...) Complexity has now increased in deployment if there's a bug. If Tomcat has a security bug, you update it instead of all the servlets. If golang exe has a bug, you have to recompile all exes and redeploy. It doesn't mean the Java situation is overall better than Golang, it's just different.
  - bad_user 12y ago
    I don't get the comparison with the JVM. I've built web services with an embedded Jetty in which the deployment happened by copying and executing a single JAR file with everything included. It's actually really easy to do - http://www.eclipse.org/jetty/documentation/current/embedding-jetty.html http://www.eclipse.org/jetty/documentation/current/embedding... Now I'm building web services on top of Play Framework (and Scala), which comes with its own web server that has nothing to do with Servlets or Java EE and so it has nothing to do with application servers and WARs and containers. And it's been good for the Play framework to come with its own server, because Servlets is moving slowly (that's what happens to standards) and Play has been capable of WebSocket or asynchronous processing of requests long before Servlets was. This is actually an area for which I love the JVM - Java's Servlets is an objectively good standard with multiple implementations, other platforms can only dream about such a popular and good standard (Java EE on the whole arguably less so, but the Servlets part is OK) and you can totally decide to not use it. I personally love having choice and when I'm faced with a problem, it's much easier for me to search and learn a new library than a new language - I'm saying this after I've been working with about 6 languages on the job and played with about a dozen others. Also, here's another opinion - I personally started to hate languages coming with "batteries included". I like languages in which the standard library contains the core necessities. Like, immutable data-structures or abstractions for dealing with concurrency - completely fine to be in a standard library. JSON parsing, http handling - no freaking way.
mserdarsanli 12y ago
> ... I had to go ahead and publish what I had or it would have remained in my drafts forever. ... It wouldn't be a loss if you have deleted it forever, you didn't need to keep it in your drafts.
rubiquity 12y ago
Thank you for taking my criticism well. Writing is hard and exhausting. I struggle with writing all of the time, even when I make goals to do it. I hope I haven't discouraged you from writing more.

jasode 12y ago

If you're taking feedback, I'd like to disagree on your examples of "accidental complexity". To me, accidental complexities are quirks of design that everyone would agree to do over differently if history replayed itself. Examples like that would be: -- Java calendar (and C Language ctime) months have index starting with 0 which means 0..11 for Jan..Dec but for days, it's index 1 which means 1..31 -- PHP inconsistencies such some functions being verb_obj while others are obj_verb and some have underscores and some do not -- MS Excel has incorrect leap year calculation for 1900 which means all other spreadsheets must duplicate this "bug" to be compatible Those are the types of "accidents" that arise out of ignorance or uncoordinated thinking. Andrei Alexandrescu (expert in C++ and D) has a similar concept he calls "unforced errors". On the other hand, you compared a Tomcat servlet container as being "accidental complexity" and Go as "reduced complexity" because the http hosting is all built into the exe. To me this is an example of moving complexity around so you don't feel it for your particular use cases of the Go language. In other words, if the Java community had a chance to do it again, I'm not convinced that Tomcat servlet would be baked into the standard Java distribution. If you bake it into the JVM, you've made the JVM Specification[1] more complex. If you leave it out of the JVM but include it as a standard class library, you've made the API library reference more complex[2] (Alternative universe: Why is the class library reference 3000 pages long?! Because it includes 200 pages to document a servlet container that most don't use.) Complexity (in totality) wasn't reduced. It was only shifted around. I'm not saying moving complexity around isn't desirable because it is (hence we have "abstractions") but it's not an example of solving accidental complexity. I think what happens is that we programmers find some language, or framework and if it matches our use cases, it's subjectively less complex. For the others who need generics to write algorithms, they write homegrown template code generators or resort to copy&paste which is more complex. So sure, Golang omits generics but it only makes it less complex from a language-specification perspective. However, it's actually more complex from a total project perspective. I think this explains all the contradictory posts about Django/Rails/etc being "simple" while other posts say it's "complex pulling teeth". At this point, I don't buy that golang without qualifiers of use-cases is objectively less complex. I'm writing server-side web services with golang and for that use case, I think it's less complex than other alternatives such as C++ or Nodejs. For Windows GUI apps, using C++ with Qt is less complex than Golang. [1]http://docs.oracle.com/javase/specs/jvms/se7/html/ http://docs.oracle.com/javase/specs/jvms/se7/html/ [2]http://docs.oracle.com/javase/7/docs/api/ http://docs.oracle.com/javase/7/docs/api/

AnimalMuppet 12y ago
I think you missed the author's point here. You have to have the webserver somewhere. That's inescapable complexity. It's in the language, or in the library, or in an external container like Tomcat. But if you're going to run a web app, you have to have a server somewhere. Where Go made things simpler is in the dependencies. The app now has all the dependencies compiled in, and so it's completely isolated from what libraries some other app in the container needed. That is a removal of accidental complexity. (Right up until you need to update all the apps to fix a bug in some library, and now you have to update each app, not just update one library in the container...)
- jasode 12y ago
  >Where Go made things simpler is in the dependencies. The app now has all the dependencies compiled in, and so it's completely isolated from what libraries some other app in the container needed. That is a removal of accidental complexity. I agree with all that Golang simplification except for one thing: I don't call the previous state of affairs "accidental complexity". It's certainly "more complex" with more moving parts but it doesn't feel "accidental" to me. I maintain that the nature of complexity and location of it has changed. You yourself gave an example: >(Right up until you need to update all the apps to fix a bug in some library, and now you have to update each app, not just update one library in the container...) Complexity has now increased in deployment if there's a bug. If Tomcat has a security bug, you update it instead of all the servlets. If golang exe has a bug, you have to recompile all exes and redeploy. It doesn't mean the Java situation is overall better than Golang, it's just different.
- bad_user 12y ago
  I don't get the comparison with the JVM. I've built web services with an embedded Jetty in which the deployment happened by copying and executing a single JAR file with everything included. It's actually really easy to do - http://www.eclipse.org/jetty/documentation/current/embedding-jetty.html http://www.eclipse.org/jetty/documentation/current/embedding... Now I'm building web services on top of Play Framework (and Scala), which comes with its own web server that has nothing to do with Servlets or Java EE and so it has nothing to do with application servers and WARs and containers. And it's been good for the Play framework to come with its own server, because Servlets is moving slowly (that's what happens to standards) and Play has been capable of WebSocket or asynchronous processing of requests long before Servlets was. This is actually an area for which I love the JVM - Java's Servlets is an objectively good standard with multiple implementations, other platforms can only dream about such a popular and good standard (Java EE on the whole arguably less so, but the Servlets part is OK) and you can totally decide to not use it. I personally love having choice and when I'm faced with a problem, it's much easier for me to search and learn a new library than a new language - I'm saying this after I've been working with about 6 languages on the job and played with about a dozen others. Also, here's another opinion - I personally started to hate languages coming with "batteries included". I like languages in which the standard library contains the core necessities. Like, immutable data-structures or abstractions for dealing with concurrency - completely fine to be in a standard library. JSON parsing, http handling - no freaking way.

mserdarsanli 12y ago

> ... I had to go ahead and publish what I had or it would have remained in my drafts forever. ... It wouldn't be a loss if you have deleted it forever, you didn't need to keep it in your drafts.

rubiquity 12y ago

Thank you for taking my criticism well. Writing is hard and exhausting. I struggle with writing all of the time, even when I make goals to do it. I hope I haven't discouraged you from writing more.