You're comparing Java to Clojure. Conceptually, they're insanely different--Apple and Oranges, really.
Clojure, Lisp, and similar languages are homoiconic. That means they're beautifully suited to an interactive environment such as that provided by LightTable. Conceptually, unlike typical IDEs, LightTable is not a series of scripts that will attempt to help you deal with common development tasks such as looking up documentation and refactoring. Instead, you're interacting directly with the language.
I think it's quite telling that in Java, documentation is done through Javadoc comments, which are ignored by the compiler and sought out by a completely separate tool in order to build docs. In Clojure, documentation is part of the homoiconic code itself:
(defn my-fn
"This is the documentation, can be inspected on the fly"
[] …)
Instead of being a series of very reliable hacks on top of a language that doesn't support docs, docs are part of the environment.
Additionally, when programming in Clojure, you can do it interactively by modifying the environment on the fly. This was popularized by smalltalk, and is an extremely gratifying way to program: you can inspect and edit your program code while it's running, and have a fully-featured REPL into your program. This way of doing things blows GDB completely out of the water.
Note also that when coding functionally, files are often made up of many small single-purpose functions, which is actually much more maintainable than the example "real-world use case" function you provided.
Essentially, your entire argument is based around the assumption that Java is the right set of design patterns. I would argue that the Java language is deeply flawed, and leads to a 30:1 ratio of boilerplate code, markup, and structure to useful code. It's what makes Javadoc and IDE refactoring tools possible, but it's also what makes Java a nightmare to maintain and (for me) an extremely unpleasant language to work in.
I have never used LightTable, but for me, what it represents is a different way of thinking about programming. It's about interacting with your code directly and interactively. And actually, when writing Clojure, I often program in quite a similar fashion with existing tools (VimClojure / Clojure.tmbundle / Cake).
Java's annotations could be seen as 'part of the environment' (whatever that may mean). I often use annotations which indicate how a method should be used, and those annotations are used by static analysis to validate correctness.
When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as well.
You say Java is deeply flawed. I argue that Java is one of the most successful languages around nowadays. It does what it is designed to do: be relatively easy to learn, a natural successor to C++ with a wide range of libraries. Yes, Java code can often be verbose, but this depends greatly on the kind of paradigms used. I can write verbose and ugly code in Clojure and write relatively concise and elegant code in Java. It depends on architecture, a good understanding of OOP (and its limitations), composition over inheritance. The problem with Java is the sheer amount of 'bad' code written in it (because of all the leagues of beginner programmers), giving it a bad name. Have you seen Clojure code of a large product (equivalent to around 1M code lines of Java), produced by a team of diverse programmers and maintained by another team during a 10 year lifespan? You would cringe just as hard.
Finally, lighttable is a proof-of-concept... It's not there yet; there are no reviews; leagues of smart engineers have tried to reproduce something similar and could not escape the POC phase at all.
"When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as well."
I use Java fulltime at work and also have some problems where recompiling classes on the fly doesn't work. I never had the problem with Smalltalk. To assume the problems in one environment will be problems in another is exactly the problem with the original article. It assumes that because something similar exists in X, it would be the same in Y and have the same sorts of issues and rewards.
"Finally, lighttable is a proof-of-concept... It's not there yet; there are no reviews; leagues of smart engineers have tried to reproduce something similar and could not escape the POC phase at all."
A large chunk of what is in light table has existed in over a quarter century in Smalltalk environments and been used to build large and complex applications.
I use Java in my day job and I find annotations a real blight on the language. While I totally get the idea that they remove the need to write a lot of boilerplate code, I still find a lot of them too "voodoo" for my liking.
Agreed, they aren't the prettiest thing in Java and they only allow one 'layer' of annotating (you can't use expressions in annotations for example), they do prove it is possible to document your code in Java in a way that it becomes part of the 'environment' (again, 'environment' is ill-defined, so all arguments in this line are a bit frail).
> he problem with Java is the sheer amount of 'bad' code written in it
java was designed to influence code towards solving all problems with classes. the "bad code" you speak of is idiomatic java code.
Jane Street wrote about how they migrated core systems to java, abandoned it because "But somehow when coding in Java we built up a nest of classes that left people scratching their heads when they wanted to understand just what piece of code was actually being invoked when a given method was called"[1]. then, the same team moved to a functional language to great success.
Writing "good code" in java takes discipline and expertise to overcome Java's gravity towards classes. Without discipline and expertise, teams end up at the natural equlibrium you read about on thedailywtf.com. java did an awesome job of replacing C++ for the last 15 years, but there's something inherent about the design of java that doesn't scale well with the bigger, higher complexity problems we face today.
Clojure, Lisp, and similar languages are homoiconic. That means they're beautifully suited to an interactive environment such as that provided by LightTable. Conceptually, unlike typical IDEs, LightTable is not a series of scripts that will attempt to help you deal with common development tasks such as looking up documentation and refactoring. Instead, you're interacting directly with the language.
I think it's quite telling that in Java, documentation is done through Javadoc comments, which are ignored by the compiler and sought out by a completely separate tool in order to build docs. In Clojure, documentation is part of the homoiconic code itself:
Instead of being a series of very reliable hacks on top of a language that doesn't support docs, docs are part of the environment.Additionally, when programming in Clojure, you can do it interactively by modifying the environment on the fly. This was popularized by smalltalk, and is an extremely gratifying way to program: you can inspect and edit your program code while it's running, and have a fully-featured REPL into your program. This way of doing things blows GDB completely out of the water.
Note also that when coding functionally, files are often made up of many small single-purpose functions, which is actually much more maintainable than the example "real-world use case" function you provided.
Essentially, your entire argument is based around the assumption that Java is the right set of design patterns. I would argue that the Java language is deeply flawed, and leads to a 30:1 ratio of boilerplate code, markup, and structure to useful code. It's what makes Javadoc and IDE refactoring tools possible, but it's also what makes Java a nightmare to maintain and (for me) an extremely unpleasant language to work in.
I have never used LightTable, but for me, what it represents is a different way of thinking about programming. It's about interacting with your code directly and interactively. And actually, when writing Clojure, I often program in quite a similar fashion with existing tools (VimClojure / Clojure.tmbundle / Cake).