I worked a lot in several assembler implementations in the 80/90s and creating self-rewriting code was still common.
I remember creating a program crawling in memory on an IBM 370 compatible computer by copying itself before jumping in its new instance, I wrote this one as an amusement :) I never considered data and code to different things. This was imposed on me when working with other "high-level" languages except Lisp for with which I always felt more affinities. When you look at code and data as being the same, things are much more simple to understand and easier to deal with. Divide to conquer they say... I think this division created faked walls that slowed down improvements in software in general. Luc P. On Wed, 20 Jul 2011 10:22:13 -0400 daly <d...@axiom-developer.org> wrote: > On Tue, 2011-07-19 at 22:16 -0700, Sean Corfield wrote: > > On Tue, Jul 19, 2011 at 5:14 PM, Adam Richardson > > <simples...@gmail.com> wrote: > > > the value placed on the last language being > > > homoiconic (without much justification) > > > > Yeah, that was definitely a weak point of his talk. I thought there > > was a lot of interesting stuff in there tho' and it was entertaining > > (which was mostly why I enjoyed it - so many talks, even keynotes, > > can be pretty dull even if the information is good :) > > A justification of homoiconicisty is that programs == data. > > A clever soul named Von Neumann made the observation that machines > were controlled by external commands (i.e. programs) to operate on > things (i.e. data). His insight was to unify the problem and treat > programs as data resulting in the invention of the stored program > computer. > > If you completely separate something like a loader (program) from > its data (the binary program) then there is no way to treat the > program-you-load as the-program-to-run. > > Today we teach students to write "programs to manipulate data" so we > have returned to the pre- Von Neumann mindset. It is considered the > height of bad form to execute data. In fact, some bright spot > added SELinux with the default policy that you could not > execute code from the heap! > > Robert gave an example of self-modifying behavior with the IBM > move instruction where he talked about modifying the length field > dynamically. In fact, the IBM 370 included an EX instruction that > executes another instruction with modifications. Both of these are > easy to do since the program and the data have the same binary > representation. > > In your best language (e.g. C++, Python, Ruby, etc) can you write > a program that modifies itself in the source language (e.g. C++) > while continuing to execute? Would this be considered a bug during > code review? (Fortran used to allow me to write over the FORMAT > output string which allowed me to change the output format based > on the data.) If you do write a self-modifying program, did you > have to write a C++ parser first? In lisp, all you have to do is > walk the program as a list, rplaca the target sublist, and continue. > > Fortunately someone at Sun was able to cross this barrier when they > decided to write the hotspot JVM. Hotspot self-modifies as it runs > to improve performance, similar to the Rubics cube program I > mentioned previously. I wish they had been mindful enough to make > Hotspot a fundamental part of Java itself. We would be able to write > Java programs that self-optimize in ways that Hotspot cannot know > by accessing and rewriting our own byte codes. If someone reifies > the byte codes in lisp syntax it would be easy to write programs > directly on the JVM that look like lisp, compiles to byte codes, > and could be self modified. > > Homoiconicity is Von Neumann's insightful idea that > programs == data > > > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View -- http://corfield.org/ > > World Singles, LLC. -- http://worldsingles.com/ > > Railo Technologies, Inc. -- http://www.getrailo.com/ > > > > "Perfection is the enemy of the good." > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- Luc P. ================ The rabid Muppet -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
