I definitely agree that with computers we've not seen a lot of changes in essence. But I've often suspected that it is true because we've chosen not to look for them. We seem to stop at a specific level in our abstractions, refactor things a little, and then build back up to where we were.
My thinking behind that post (rightly or wrongly) was motivated by the sense that we prioritize code over data. Thus when we build, we consider the algorithms first then we retrofit the weirdness of the data in later. Thus the first issue that pops into most minds when considering a new program is what language to use. If we flip that, and consider the data as the primary element, then we can look for ideas that essentially make the code trivial. Users enter data, the system stores data, and we want to analyze the data. The code can be seen as just the way the data propagates through the system. In response to Ondřej, I would point out that although the ideas were loosely defined, I was thinking about a computational model, not just a specific technology. XML is essentially just a structural/markup way of moving data between the vertical silos. This model would replace the silos altogether. In essence, people don't assemble the system from smaller parts, the system itself assembles everything from its parts. It's the non-intelligent part of the process that I think we can automate. Still, I don't now if the ideas are feasible and although I didn't mention it, they will not work unless we can root them on truly dynamic data-stores. Much of the thinking that was been removed from the code ends up in the context in the form of extended types. It's a trade-off that I am not sure is possible due to scale and performance issues. I really just put it out there because it is different, and I felt that Uncle Bob had tunneled his vision way too early. It takes a long time for us to absorb new technologies and find maximal ways to use them. Computers are easily the most significant technology that we have physically created to date and we've only just begun to grasp what we've done. Waves like social networking are still growing and spreading, so it seems exceptionally premature to me to start talking about the 'last' anything (and of course there is that nagging little issue of Godel's work). Paul. --- On Tue, 7/19/11, BGB <[email protected]> wrote: From: BGB <[email protected]> Subject: Re: [fonc] Last programming language To: "Fundamentals of New Computing" <[email protected]> Received: Tuesday, July 19, 2011, 6:28 PM On 7/19/2011 8:24 AM, Ondřej Bílka wrote: > On Tue, Jul 19, 2011 at 05:16:24AM -0700, Casey Ransberger wrote: >> Even if it were possible to have a last language, it would be double plus >> ungood. >> >> On Mon, Jul 18, 2011 at 8:58 AM, Paul Homer<[1][email protected]> >> wrote: >> >> Realistically, I think Godel's Incompleteness Theorem implies that there can >> be no >> 'last' programming language (formal system). >> >> But I think it is possible for a fundamentally different paradigm make a >> huge leap in >> our ability to build complex systems. My thinking from a couple of years >> back: >> >> [2]http://theprogrammersparadox.blogspot.com/2009/04/end-of-coding-as-we-know-it.html > Sorry but it is very similar to XML will make everything interoperable > articlies yeah, most things tend to change in scale, but not really in essence... if the essence were changing, there would likely need to be a continual change in languages to retain viability. however, to a large degree this has not been the case, as many languages (such as C) retain their widespread viability after decades of use with only relatively modest changes to the core language, despite computing as a whole now being much different now than it was several decades ago. granted, improvements are likely to still exist, but when and where, and their extent, well, this has yet to be seen... but, for the time being, the world is as it is, and most effective is likely to act on what is already known to be the case. or such... _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
