Well, you say that a flexible and high level enough language ca span all platforms and be itself a platform. The JVM is close to such a platform and Clojure is good lisp for it, so you "only" have to figure the abstractions right... the thing is that "use the code as a concrete, formalized model of abstract thought" is kinda hard-to-impossible, even in the most cross-platform language with the best meta-programming facilities, you'll end up with knowledge that (a) is not in the code (like everything about how Engelbart's prototypes interacted with humans to really augment their capabilities), which is not a problem in and of itself, but you also have (b) platform dependent knowledge and code that cannot be abstracted away, and (a) and (b) inevitably overlap making a total mess, because the interaction/usage related knowledge that's no in the code actually relates most to the platform specific code that's can't be abstracted well.
Anyway, my point is the platforms and programming languages are orthogonal: having the best cross-platform language in the world won't get you any closer to a "platform that can evolve well", and all programs will have platform specific code that won't benefit from the language at all.
And a "platform that can evolve well" can manage to do so even with crappy languages as defaults. Our best such platform, the Web, has Javascript, a language that I imagine will keep evolving because it has the weird characteristic of "you can always ducktape more stuff to it" (I imagine future versions of Javascript with optional advanced static typing, concurrency features ala Clojure, macros ala Lisp or Scala etc.). A better language will not necessarily be "a better language for the platform" ie "something that will help the platform evolve better" (the "platform" I'm referring to here is HTML/Javascript/JSON/REST/HTTP/etc.), it will solve a different set of problems and maybe it will or maybe it won't be adopted as the "platform's first class language".
If you like Lisp, work to make Parenscript or Clojure-script better (I hope you pick the 2nd and let CL die and rot... it taught us a lot, but it's time to let it rest... there's no chance in hell it will ever gain any traction again), as this is the only way we'll have a decent Lisp for the Web.
(b) platform dependent knowledge and code that cannot be abstracted away
Can you give an example of this platform specific code that's can't be abstracted well? I am less than convinced.
a "platform that can evolve well" can manage to do so even with crappy languages as defaults. Our best such platform, the Web
Sorry, I don't think that the web is a well evolving platform. I think it's a butt ugly duct-tape driven just-still-hobbling-along type of platform that is rife with security holes, trust issues, unneeded complexity, cross platform issues, unexpected but effective centralization of power, and many other issues. I am not sure how you can hold it up as a great example of a technical offering, really.
If you like Lisp, work to make Parenscript or Clojure-script better
Clojure-script seems pretty full-featured already. To be honest, though, I'm not sure that a Javascript VM is the place to implement complex code. GUI-related code is probably most of JS, and that is probably easier to generate from a model than rewrite with an additional layer of syntax abstraction in an effectively new language... particularly given the rate at which new JS related functionality appears.
orthogonal
I am going to come clean: I hate it when people use this word because I'm never quite sure what they mean. Often, I think, neither are they. To me, what you said seems to be "x and y are not the same". Others use it differently. I hereby wish we could just use familiar, regular-human language instead of latter-day tech hubbub. Ta.
ok, it got well offtopic but my prev comment was confusing indeed, so:
- you're right, that's what documentation is for, but people rarely document things like use cases and workflows and I've rarely seen comments like "this complex optimization is here because a delay longer than X ms is intolerable for workflows like ... or because otherwise you'll have inconsistent data when connectivity to external service Y breaks at the same time as service Z crashes ... and this actually happens very often because the user tends to do N and P at the same time and almost always ignores warning/error Q"
- "platform dependent knowledge and code that cannot be abstracted away": if you write a tablet app, you will need to take into consideration things like touch ui, impermanent internet connectivity and so on, if you consider the "platform" to be the devices. At other levels, if your "platform" is the browsers you'll have code that reacts to browser differences. If you use Ruby your platform will be the ruby interpreter and you'll also have code that is written somehow because of the platform limitation (gc problems, multithreading problems)
...I'm talking about the kinds of applications where 80% of the code is actually the UI code. If your balance differs, you can probably have good abstractions in your no-UI code. But for interface heavy applications (it doesn't have to be UI, it can be interfaces with lots of external web APIs), porting will always be a nightmare and you'll lose stuff at every porting and have to rediscover/reinvent it.
- "orthogonal" - my bad, I should have just said "they are independent" or "I don't think they really influence each other's evolution", I thought this word has already grown roots in the tech vocabulary and it's a nice engineery metaphor that I really like (I just think of perpendicular vectors and independent dimensions and since I'm more of a picture thinker that only later translates his thought in words it just seems intuitive to me - http://en.wikipedia.org/wiki/Orthogonality)
- the Web: I agree, it's "butt ugly duct-tape driven" indeed but that's the thing with things that evolve, you don't get to control the evolution, nobody really gets to do this, we all pull in different direction and some organic emergent behavior appears... hopefully it will crawl out of the current state to a less chaotic state that would enable more sane workflows for developers
Anyway, my point is the platforms and programming languages are orthogonal: having the best cross-platform language in the world won't get you any closer to a "platform that can evolve well", and all programs will have platform specific code that won't benefit from the language at all.
And a "platform that can evolve well" can manage to do so even with crappy languages as defaults. Our best such platform, the Web, has Javascript, a language that I imagine will keep evolving because it has the weird characteristic of "you can always ducktape more stuff to it" (I imagine future versions of Javascript with optional advanced static typing, concurrency features ala Clojure, macros ala Lisp or Scala etc.). A better language will not necessarily be "a better language for the platform" ie "something that will help the platform evolve better" (the "platform" I'm referring to here is HTML/Javascript/JSON/REST/HTTP/etc.), it will solve a different set of problems and maybe it will or maybe it won't be adopted as the "platform's first class language".
If you like Lisp, work to make Parenscript or Clojure-script better (I hope you pick the 2nd and let CL die and rot... it taught us a lot, but it's time to let it rest... there's no chance in hell it will ever gain any traction again), as this is the only way we'll have a decent Lisp for the Web.