On 8/23/2011 7:54 AM, Kevin Driedger wrote:
Here's another citation:
http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingProgramming.pdf
<http://www.wisdom.weizmann.ac.il/%7Eharel/papers/LiberatingProgramming.pdf>
yep, because I think CiteSeer often won't let one read the articles
(well them and ACM and similar...).
now, as for the article:
partly started reading it...
but, I don't generally agree with the author (most of these ideas sound,
lame...).
I also don't think current methodologies are all that bad, and ideally
one can make a current set of methodologies more scalable to larger systems:
fiddle with things; test; repeat...
and ideally find some way to get rid of "formalizing" and "specifying"
things (like, where we no longer have to write documentation or
high-level descriptions, because the tools have auto-documentation and
inference systems that are less "teh suck").
"teaching" things doesn't sound like a desirable strategy IMO, as it
would potentially ruin the "fiddle and test" aspects, potentially
replacing them with something far more annoying.
IMO, building software "could" be more like, say, assembling a computer
from parts (selecting, buying, and assembling various parts), or doing
automotive customization (adding on different tires, fancy-looking
hubcaps, a spoiler, under-lights, swapping out for a more powerful
engine with dual-turbo or similar, or NOS, ...), just without the
heavy/lifting aspects (yanking engine with an engine jack, ...) because
manual lifting is lame (the analogue of the manual lifting in software
is the large piles of code one often has to write to complete "trivial"
tasks, and how abstract/distant/unrelated the code tends to be vs the
task at hand).
or, it could also be sort of like, say, going and buying various
home-entertainment-system components (stereo, speakers, TV, DVD player,
...) and hooking them all together (because mostly one just hooks up the
wires and they work). the analogy would be with current programming it
is more like having to fabricate and solder all the chips to the boards
and similar (and one may more want to have "teh pumping beats" than have
to sit around for a long time with a soldering iron).
or like, say, if more aspects of programming could be more like the
"Armored Core" games, where it is assemble, test, fiddle and repeat
until done, and go...
like, the system can be "object oriented" at a much larger granularity,
rather than just at the level of individual classes, and degenerating
into a tangled spaghetti-code like mess at the higher architectural
levels (where many people who write code in OOP languages have failed to
learn what needs to be done to make projects manageable in languages
like C or similar, they just rely on the fact that the project can get a
little bigger before these things really come and bite them...).
otherwise, recently I came across the idea of split stacks, say here:
http://gcc.gnu.org/wiki/SplitStacks
and, then was idly considering their merits vs things like CPS and
heap-allocated stack frames (which have more interesting possibilities,
but a higher performance and other costs...).
it is a mystery if, eventually, the traditional machine-stack (as a
largish linear memory region) may need to go away (the other possibility
is that the move to 64 bits essentially renders this moot, since then
again the address space is much larger and thus the conceptual
per-thread address-space cost is much lower).
or such...
On Tue, Aug 23, 2011 at 9:39 AM, Dale Schumacher
<dale.schumac...@gmail.com <mailto:dale.schumac...@gmail.com>> wrote:
You might also find David Harel's article "Can Programming Be
Liberated, Period?"
(http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.3837)
interesting. He takes quite a different approach to "specification"
of system behavior, as well as programming in general.
_______________________________________________
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
