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.
#Lighttable get rid from history code#
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. 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)
