Re: [fonc] Last programming language
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 paul_ho...@yahoo.ca 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: http://theprogrammersparadox.blogspot.com/2009/04/end-of-coding-as-we-know-it.html Paul. --- On *Mon, 7/18/11, BGB cr88...@gmail.com* wrote: From: BGB cr88...@gmail.com Subject: Re: [fonc] Last programming language To: Fundamentals of New Computing fonc@vpri.org Received: Monday, July 18, 2011, 6:28 AM On 7/18/2011 2:56 AM, Casey Ransberger wrote: Smells like Kool-Aide. I smell bullshit. Dude is selling a book tour or something. Let's just pick the POS we have now and run with it? Seriously? How many times has that gone well? Dude is on a book-tour or something. Let him have it. for most people and most projects, advice like just pick C or Java or C# or similar generally aligns fairly well with the path to highest likely productivity (get code written and out the door to customers, ...). if it is something common, then there is less likely to be slowdowns or similar due to some of the development team members getting confused, or having area of responsibility confusion or similar. the bigger question is what can be done which hasn't already been done? and more so, why does it necessarily matter? and, if there is something great waiting, how does one best go about finding and it and making productive use of it? ... one potentially overlooked issue in the video: 40 years ago, threads and multiprocessor systems were not exactly common; now they are pretty much everywhere, but the most common languages tend to be fairly incompetent of effectively utilizing them. though not fundamentally new, this is at least a relevant change. for example, what is a not crappy way to go about writing code, say, for a GPU?... maybe there are better answers than, say, well, pretend you are running loops over big arrays (CUDA) and well, just run C on the thing (OpenCL). IMO, I sort of like mailboxes and asynchronous and trans-thread function/method calls, but these are relative novelties (vs the ever present lock a mutex or enter a critical section or similar model). ... or such... On Jul 17, 2011, at 11:31 AM, karl ramberg karlramb...@gmail.comhttp://mc/compose?to=karlramb...@gmail.com wrote: Hi Here is a interesting video about programming languages http://skillsmatter.com/podcast/agile-testing/bobs-last-language Karl ___ fonc mailing list fonc@vpri.org http://mc/compose?to=fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://mc/compose?to=fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -Inline Attachment Follows- ___ fonc mailing list fonc@vpri.org http://mc/compose?to=fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Last programming language
On Tue, Jul 19, 2011 at 1:36 AM, Ken 'classmaker' Ritchie classma...@gmail.com wrote: Break the program free from its representation? How, other than by transforming one representation to another? Actually, certain transformations might yield great benefits, in perception or execution! That's the entire point of our current complier / editor technology stack: - The human interprets a program in the context of their knowledge of the programming language, its libraries, and general culture. - The compiler interprets a program in the context of a specific machine architecture and instruction set. - The computer interprets a program as a sequence of electrical impulses traveling through the system. The limits of each layer in the stack force certain compromises on the realm of possible transformations. Since human computing power is still relatively more plentiful, we shift the majority of the burden to the human layer for understanding. But as computing becomes more ubiquitous in the material world we can start entertaining programs like: to toggle is to turn the led on for 1000 ms and then turn it off ; Now this program is understandable by even my 4 year old. She helps me build circuits for fun and she's loves playing with leds and motors. The hardest thing for her to grasp is ms but she calls that really really fast fast, but she knows what a second is. Now if I add a little color to this program, I actually have one programming environment that can interpret it as is: to toggle is to turn the led on for 1000 ms and then turn it off ; If you notice, I've highlighted the salient terms. And I'm cheating here because this code is taken directly from Chuck Moore's Colorforth Primer http://colorforth.com/primer.htm but with embedded comments making it into a more literate style. The colorforth system can interpret this code because some of the semantic information is tagged on each word to describe its role in the representation. But there is no reason that a sufficiently complex system could not do the following: - perform a statistical analysis to determine the probability that each term in the sentence is significant - compile the most probable variations into object code - ask a human which one does the right thing If you apply a similar rigor to the definition of test code you could engineer reliable software systems for which there is no program in the traditional sense. The specification of the system is informal, subject to vagaries in interpretation, and in effect not a lot different from handing off a spec to a bunch of programmers in another country who don't speak your language :) While it might be helpful to have a formal language and jargon to talk about specific constructs. And it might be better to write everything in a more formal linguistic style to improve the odds of getting the correct interpretation, it would not be a prerequisite for use. While you are transforming one representation to another, a sentence to object code, the gap between the human mental model and the computer is bridged through artificial understanding. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Last programming language
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]paul_ho...@yahoo.ca 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 fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
