4 ms·

Everything in Lisp, traditionally, is not extremely late bound. For this, look to COLA by Viewpoints Resaearch Institute. The no reader macro convention basic

Everything in Lisp, traditionally, is not extremely late bound. For this, look to COLA by Viewpoints Resaearch Institute. The no reader macro convention basically boils down to making it easier to design a language. If you want an acceptable Lisp, you effectively have to combine the best features of all Lisps. This is surprisingly difficult to do and ensure portability and stability. So your comments about "direction of Java" are puzzling, as it guarantees portability and stability to the extent the JVM is. Really the only downside is compatibility with type erasure, which is unfortunate but hey.

lispm 17y ago
The usual default is that Lisp is late bound. You would tell Lisp when or where you don't want that. If you use CLOS for example, any method can be removed or added at runtime. I'm not sure how not adding a reader macro mechanism makes the design easier. Actually the point of read macros is to enable incremental addition/change of syntactic elements of s-expressions.
- johnzabroski 17y ago
  Stability of any problem space makes reasoning about any problem space easier. The statement is a tautology. 'How' is a rabbit hole. I wish, though, that Clojure had a versioning system similar to Curl or even .NET's module system, or even OSGi/Jigsaw. Syntactically, I'm thinking of something like Curl.
andreyf 17y ago
For this, look to COLA by Viewpoints Resaearch Institute. linky: http://piumarta.com/software/cola/ http://piumarta.com/software/cola/ Thanks! I was thinking of dropping that into the post as an example of the late-binding philosophy going into the future, but I've been linking it quite a bit lately, and decided to go without it for once. In my view of it, Piumarta's COLA is very strongly "of The Lisp Philosophy". As a matter of fact, I would call it the future of Lisp (the philosophy) :) When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos. Allowing users (and creating tools) to modify syntax is fundamental to breaking this tribal idiocy around "languages" as atomic sets of programming system design decisions.
- johnzabroski 17y ago
  @When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos. I can't understand you. Can you rephrase? @Allowing users (and creating tools) to modify syntax is fundamental to breaking this tribal idiocy around "languages" as atomic sets of programming system design decisions. It's far from tribal idiocy, and has more to do with modularity and substitutability. Most programmers do not realize what heights of engineering .NET|Mono, the JVM, Smalltalk, Symbolics Genera all are. .NET's MSIL, in particular, is the most modular stack-based assembly language I know of... especially version 2. It's pretty impressive once you realize you can specify modules at the assembly level. Granted, even in the '90s people were designing typed assembly languages, like TAL/T, which supported run-time code generation and could be certified for safety at compile time, link time and run time. Really, I think talking about "not an acceptable Lisp" in broad strokes undermines attention to good engineering and striving to be great engineers.
  - andreyf 17y ago
    >> @When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos. > I can't understand you. Can you rephrase? Oops, think-o, that should have said "it makes as little sense to split computational abstractions into these language silos". To clarify: there are "languages" like Haskell/Ruby/Python/Java/C that make an enormous number of decisions about the kinds of abstractions we use to describe what it is a computer is to do. A "language" is a set of decisions about syntax, type systems, functional or object-oriented abstractions, memory allocation and garbage collection, call stack traversal. If one decides to compile to a VM instead of machine code, that introduces another set of variables - from JIT compilation techniques to the kind of VM specifications you publish (do you publish a reference VM like Squeak, or a bunch of papers and tests like the JVM). "The Java language" is a set of hundreds of those kinds of decisions. So is "the Python language". Comparing the two is really difficult, because for almost any problem, some subset of Java's decisions will be better, while another subset of Python's decisions will be better. But these sets of decisions aren't atomic (they can be split!). Every time you late-bind a decisions to the user, it removes a dimension from the decision space that the "language" lives in. It expands the power of the language to span that entire dimension. Hence, the most powerful language is one that makes the most irreversible decisions. talking [...] in broad strokes undermines attention to good engineering and striving to be great engineers That sounds right, and I should avoid it if it's needless. However, it's also important to always try to unify concepts to simplify our models of things. The important thing is to make sure the simpler model is just as accurate.

lispm 17y ago

The usual default is that Lisp is late bound. You would tell Lisp when or where you don't want that. If you use CLOS for example, any method can be removed or added at runtime. I'm not sure how not adding a reader macro mechanism makes the design easier. Actually the point of read macros is to enable incremental addition/change of syntactic elements of s-expressions.

johnzabroski 17y ago
Stability of any problem space makes reasoning about any problem space easier. The statement is a tautology. 'How' is a rabbit hole. I wish, though, that Clojure had a versioning system similar to Curl or even .NET's module system, or even OSGi/Jigsaw. Syntactically, I'm thinking of something like Curl.

andreyf 17y ago

For this, look to COLA by Viewpoints Resaearch Institute. linky: http://piumarta.com/software/cola/ http://piumarta.com/software/cola/ Thanks! I was thinking of dropping that into the post as an example of the late-binding philosophy going into the future, but I've been linking it quite a bit lately, and decided to go without it for once. In my view of it, Piumarta's COLA is very strongly "of The Lisp Philosophy". As a matter of fact, I would call it the future of Lisp (the philosophy) :) When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos. Allowing users (and creating tools) to modify syntax is fundamental to breaking this tribal idiocy around "languages" as atomic sets of programming system design decisions.

johnzabroski 17y ago
@When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos. I can't understand you. Can you rephrase? @Allowing users (and creating tools) to modify syntax is fundamental to breaking this tribal idiocy around "languages" as atomic sets of programming system design decisions. It's far from tribal idiocy, and has more to do with modularity and substitutability. Most programmers do not realize what heights of engineering .NET|Mono, the JVM, Smalltalk, Symbolics Genera all are. .NET's MSIL, in particular, is the most modular stack-based assembly language I know of... especially version 2. It's pretty impressive once you realize you can specify modules at the assembly level. Granted, even in the '90s people were designing typed assembly languages, like TAL/T, which supported run-time code generation and could be certified for safety at compile time, link time and run time. Really, I think talking about "not an acceptable Lisp" in broad strokes undermines attention to good engineering and striving to be great engineers.
- andreyf 17y ago
  >> @When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos. > I can't understand you. Can you rephrase? Oops, think-o, that should have said "it makes as little sense to split computational abstractions into these language silos". To clarify: there are "languages" like Haskell/Ruby/Python/Java/C that make an enormous number of decisions about the kinds of abstractions we use to describe what it is a computer is to do. A "language" is a set of decisions about syntax, type systems, functional or object-oriented abstractions, memory allocation and garbage collection, call stack traversal. If one decides to compile to a VM instead of machine code, that introduces another set of variables - from JIT compilation techniques to the kind of VM specifications you publish (do you publish a reference VM like Squeak, or a bunch of papers and tests like the JVM). "The Java language" is a set of hundreds of those kinds of decisions. So is "the Python language". Comparing the two is really difficult, because for almost any problem, some subset of Java's decisions will be better, while another subset of Python's decisions will be better. But these sets of decisions aren't atomic (they can be split!). Every time you late-bind a decisions to the user, it removes a dimension from the decision space that the "language" lives in. It expands the power of the language to span that entire dimension. Hence, the most powerful language is one that makes the most irreversible decisions. talking [...] in broad strokes undermines attention to good engineering and striving to be great engineers That sounds right, and I should avoid it if it's needless. However, it's also important to always try to unify concepts to simplify our models of things. The important thing is to make sure the simpler model is just as accurate.