Brackets vs lighttable code#
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.įinally, lighttable is a proof-of-concept. 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. It depends on architecture, a good understanding of OOP (and its limitations), composition over inheritance. I can write verbose and ugly code in Clojure and write relatively concise and elegant code in Java. Yes, Java code can often be verbose, but this depends greatly on the kind of paradigms used.
It does what it is designed to do: be relatively easy to learn, a natural successor to C++ with a wide range of libraries.
I argue that Java is one of the most successful languages around nowadays. It works in most cases, and when it doesn't work, I believe other languages would fail as well. When using Java, I often change my program while it is running. I often use annotations which indicate how a method should be used, and those annotations are used by static analysis to validate correctness. Java's annotations could be seen as 'part of the environment' (whatever that may mean). And actually, when writing Clojure, I often program in quite a similar fashion with existing tools (VimClojure / Clojure.tmbundle / Cake). It's about interacting with your code directly and interactively. I have never used LightTable, but for me, what it represents is a different way of thinking about programming. 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 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. 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.Įssentially, your entire argument is based around the assumption that Java is the right set of design patterns. This way of doing things blows GDB completely out of the water. 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.
Brackets vs lighttable series#
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.Īdditionally, when programming in Clojure, you can do it interactively by modifying the environment on the fly. "This is the documentation, can be inspected on the fly"
In Clojure, documentation is part of the homoiconic code itself: 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. Instead, you're interacting directly with the language. 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. That means they're beautifully suited to an interactive environment such as that provided by LightTable. Conceptually, they're insanely different-Apple and Oranges, really.Ĭlojure, Lisp, and similar languages are homoiconic.
0 kommentar(er)
