Yeah, Martin is always quite good at explaining these things... I found most of his works quite confirming.
The trouble seems to be (and this is an issue I have with computers) as Alan points to... (but perhaps broader than he intended)... Optimisation should be separated from Intent Expression. Higher level languages are, by definition, to aid humans in understanding - and yet they are themselves not able to be decoded / de-composited. For CRAP's sake, we use the word "code" to talk about programming... but that's not what it should be... imagine a world of layered information processing systems... all dealing with a tiny slice... all smalltalk-like compiled down to optimised systems behind the scenes...(ie on the fly compilation and optimisation)... At its most useful, each "system" should be a machine that uses its own language, defined for inspection in the system itself... and explains its requirements... each tiny bit of code should be expressed in no more than a paragraph. This would then engender two things: - infinite pedagogic inspection, down to the "bare metal" - infinite accessibility, because things would be separated into their proper detail scope One of the troubles seems to be that people don't seem to feel that you can engineer this into a "language" or process (for want of a better term). So we end up with extremely fragile system such as SmallTalk (when I first tried it, I broke my windows... I didn't know what to click, and I had to "STOP" everything, and not save changes to the world because I ended up in some context I had no idea about). As system designers, I think we could learn a fair bit from game designers... Blizzard / Diablo III for example: http://www.youtube.com/watch?v=IzhoGX_7uFY&feature=youtube_gdata_player In particular, the comment "At Blizzard, we don't like standalone tutorials very much... we don't like people showing up and giving you a wall of text... we want you to learn to play the game... by playing it" The equivalent of a wall of text to read would be learning a programming language... ideally programming is fun... the fun part is when you get the computer to do what you want it to do. Programming languages stand in the way of doing this. Ideally programming a computer should be MORE fun than playing a video game (more fun because it should be as fun as playing a game with the added advantage of being useful in the "real world", too). Thinking about ToyLog... as an extremely tiny toy version of a programming language, or TileScript as a first step towards having a proper non-text-based programming language. Seriously guys, it's 2012... why is it even possible that I can make syntax errors any more? What Blizzard and many other game shops have been doing for a long time is building the learning into the game itself... "Hardcore Games For Everyone Is What Blizzard Does"... they were talking about how they bring EVERYONE up to the level of hardcore gamer (that's to say someone who's keenly interested in gaming)... they do this through a slow ramp up process (actually it's as fast as you want to go)... and this is what language designers need to do. Anyway enough of me ranting. I gotta go do some stuff so that I can build these systems I keep ranting about. Julian On 09/05/2012, at 5:11 PM, Jarek Rzeszótko wrote: > Yes, your description of the "thought clearing process" is very accurate, the > main point being two interesting issues this process raises: > > A. Considering that the pseudo-code could have contributed more to my > understanding of the problem that the final code, how much is lost by not > having such "intermediate" artefacts somehow be part of the final code? What > would be the best way to incorporate them? There is a partial analogy in > mathematics where the mathematicians job is pretty much generating proofs but > there is much less information about how those were discovered. > > B. Can programming languages be "brought" closer to the way we think yet > still stay executable by the computer... ? (So that A is not relevant anymore) > > B1. ... via a particular programming style? > > B2. ... by an appropriate design? > > Such division helps to systematise some of the approaches you already > mentioned. > > For example, with literate programming which implements a solution to A) I > could keep the pseudo-code as part of the program in an interesting way, but > with the amount of cross-referencing than goes on, I wonder how easy it is to > remember where each part of a large program is located. Also, I have a hard > time imaging working with multiple persons concurrently on a large literate > program... But I don't have much experience here. > > For B1), I learned lots of little ways of writing "readable" code from Martin > Fowlers "Refactoring", tricks like this: > > http://martinfowler.com/refactoring/catalog/introduceExplainingVariable.html > http://martinfowler.com/refactoring/catalog/decomposeConditional.html > > But this can only go so far - it works in business programming but with > really complicated things it isn't enough to make an "ordinary" programming > language a good "tool for thought". > > B2) is more serious, with the before-mentioned Lisp macros, POLs etc. I again > (unfortunately) do not have experience programming in this style. > > I will be very vague here, but maybe you could somehow invert B) and instead > of finding a way to program that's similar to the way we currently think, > find a programming language that would be convenient to reason in. I have > things like program derivation in mind here, an interesting modern example is > this paper: > > http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/sudoku.pdf > > Maybe a good idea for an advanced programming course would be to take two > weeks off from ordinary work, pick a couple of non-trivial algorithmic > problems and, say, try to solve two of them via literate programming, two of > them via constructing a language bottom-up in Lisp or Smalltalk, two of them > via derivation etc. On the other hand, it seems quite reasonable to ask > whether this matters at all during problem solving, maybe the same mostly > unconscious mental facilities do the work anyway and then this would matter > only for communicating the solution to other people. Anyway, maybe that's > what I will try to do during my vacation this year :) > > Cheers, > Jarek > > 2012/5/8 Julian Leviston <jul...@leviston.net> > Isn't this simply a description of your "thought clearing process"? > > You think in English... not Ruby. > > I'd actually hazard a guess and say that really, you think in a semi-verbal > semi-phyiscal pattern language, and not very well formed one, either. This is > the case for most people. This is why you have to write hard problems down... > you have to bake them into physical form so you can process them again and > again, slowly developing what you mean into a shape. > > Julian > > On 09/05/2012, at 2:20 AM, Jarek Rzeszótko wrote: > >> Example: I have been programming in Ruby for 7 years now, for 5 years >> professionally, and yet when I face a really difficult problem the best way >> still turns out to be to write out a basic outline of the overall algorithm >> in pseudo-code. It might be a personal thing, but for me there are just too >> many irrelevant details to keep in mind when trying to solve a complex >> problem using a programming language right from the start. I cannot think of >> classes, method names, arguments etc. until I get a basic idea of how the >> given computation should work like on a very high level (and with the >> low-level details staying "fuzzy"). I know there are people who feel the >> same way, there was an interesting essay from Paul Graham followed by a very >> interesting comment on MetaFilter about this: > > > _______________________________________________ > fonc mailing list > 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
