3 ms·

We're reinventing things over and over again because we haven't yet learned to design platforms that can evolve. Because the platforms can't evolve, every time

by nnq 13y ago

We're reinventing things over and over again because we haven't yet learned to design platforms that can evolve. Because the platforms can't evolve, every time we have a new platform we have to reinvent the applications of the old platforms. The closest thing we ever got to "platforms that can evolve" were first Unix-like systems, that were too low level, limited and specific-machine-bound to be able to support the engelbartian applications that preceded them (probably this is why these applications and their concepts have been mostly forgotten, there was a "platform gap" over which they could not be ported so they had to wait for one more platform generation, but then people forgot all about them), then the Java platform (that should've been either the Lisp or the Smalltalk platform if market forces hadn't screwed up everything) and now the Web platform (you see, every platform moves up the abstraction ladder and away from the hardware - the annoying side effect is that you have to wait for the performance to catch up at every up step, like waiting 20 years to do in software in the 90s what you could do in hardware in the 70s, then waiting to do it on mobile devices etc.) - it's the closest that we ever got to having a "platform that can evolve", so we can gradually update the applications to evolve along with the platform, instead of porting them from one platform to another and loosing important pieces of them in the process...

contingencies 13y ago
Right. However, the platform is irrelevant if the programming is abstract enough, since you can essentially regenerate all previous programs for a new platform. Lisp can do this. Actually, any language can probably do this, but Lisp is said to be better suited for its IIRC introspective/reflective/code-data-indistinct (ie. ~typeless) purity. The main shift for programmers is looking at code not as instructions (procedural) but as a combined cognitive/computational model, from which to assemble useful lines of thought (codepaths) on an ad-hoc/JIT basis. It seems like the upshot is this: basically, code in Lisp. Use the code as a concrete, formalized model of abstract thought, don't enslave your cognitive capacities to attempting to model the computer's finite procedural logic. Wish I had time to embark :) Maybe I'm getting there. Over 15 years I've noticed my procedural code has shrunk to tinier and tinier, more and more reusable and rigidly independent snippets. Perhaps the diving board for the great pool of Lisp draws closer faster than anticipated? :)
- nnq 13y ago
  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.
  - contingencies 13y ago
    knowledge that (a) is not in the code That sounds like what documentation's for. (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.

by nnq 13y ago

contingencies 13y ago

Right. However, the platform is irrelevant if the programming is abstract enough, since you can essentially regenerate all previous programs for a new platform. Lisp can do this. Actually, any language can probably do this, but Lisp is said to be better suited for its IIRC introspective/reflective/code-data-indistinct (ie. ~typeless) purity. The main shift for programmers is looking at code not as instructions (procedural) but as a combined cognitive/computational model, from which to assemble useful lines of thought (codepaths) on an ad-hoc/JIT basis. It seems like the upshot is this: basically, code in Lisp. Use the code as a concrete, formalized model of abstract thought, don't enslave your cognitive capacities to attempting to model the computer's finite procedural logic. Wish I had time to embark :) Maybe I'm getting there. Over 15 years I've noticed my procedural code has shrunk to tinier and tinier, more and more reusable and rigidly independent snippets. Perhaps the diving board for the great pool of Lisp draws closer faster than anticipated? :)

nnq 13y ago
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.
- contingencies 13y ago
  knowledge that (a) is not in the code That sounds like what documentation's for. (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.