Life In 19x19

schilds wrote:Just as in go where a strong player might be able to play flexibly without planning out his whole game because he's built up the unconscious mental machinery to evaluate board positions quickly and identify what moves may reasonably lead to workable strategies.

In go terms, imagine if you could undo an arbitrary number of moves when it became clear that a line of play doesn't work, and then continue play from there. That's like iterative development.

A certain level of expertise is still needed to be successful, of course, but that's true regardless of the techniques you employ. If you can't design the system iteratively, you certainly can't design it all up-front either since you don't have the experience. At least prototyping gives you a way to get the experience

Actually that would be an interesting experiment: pair a new go player with a score counter and infinite undos and see how strong they could end up playing (probably against a computer since human players wouldn't have the patience).

In go you can simply start over every 30 minutes (or so), and as you get better you have your thoughts checked by stronger players naturally through just playing them.

At least prototyping gives you a way to get the experience .

Well, if you're asking a novice programmer to just jump in and start prototyping as a way to get experience, I would suggest that they're going to spend a heck of a lot of time reinventing every wheel up til the current day that's ever been invented in computer science ... I think I'd suggest they read a few books first :p. However, I don't think that's what you're actually suggesting, again, I think the unspoken assumption is that they already have some ideas for how to approach the problem.

I agree that they're going to spend a lot of time getting things wrong and rewriting code. It's just a question of how far to take the design part before you start writing code. The more experienced you are, the more goes unconscious thought will go into the design part. Novices will only be able to read a couple of moves ahead before getting confused.

Note: I can't figure out if I'm disagreeing or agreeing with you. Or what I'm trying to say, even ... eh, well don't mind me :p. Just take this as my iterative method of getting thoughts out . Maybe in a few more posts I will have something reasonably coherent!

Maybe we can draw a comparison between tsumego and designing everything explicitly. They both force you to develop machinery to work everything out in your head instead of having to play actual moves. Ok, maybe that doesn't really work as a comparison.

[edit]
Ok, here's something that's hopefully more coherent:

Mike Novack wrote:If you instead start with the langauge and what data structures and algrotihms come built in then you are very likely to make data structure and algorithm decisions based on that and can almost guarantee bad choices.

Fwiffo wrote:IMO, prototyping in a high level language is the design phase.

I agree with both of these statements. I think the disagreement between you both is what constitutes a high enough level language. Of course Mike expresses and works out his designs in a high level language, he simply considers existing programming languages to not be high level enough. If we could execute his language, then Fwiffo would argue that he's doing rapid prototyping. On the other hand, if Fwiffo would pick a language that didn't force unnecessary assumptions or models of thinking on Mike, then Mike would consider such a language an effective tool for use during the design process .

"If we could execute his language, then Fwiffo would argue that he's doing rapid prototyping. On the other hand, if Fwiffo would pick a language that didn't force unnecessary assumptions or models of thinking on Mike, then Mike would consider such a language an effective tool for use during the design process"

Sort of the right idea, but .............

a) I am assuming that I will have a "machine" to execute (or evaluate -- we have "functional" programmers reading this) this imaginary language. In other words, as soon as I have the problem solved in terms of the data sturctures and operations on them of this imaginary language all that remains is to emulate those using some real language. That is going to be easy (and easily testable in pieces)no matter what the real language used.

In effect I have broken the problem into two parts, a high level solution testable on paper (correctness proofs) and a low level solution to implement that high level "machine" (each part of which is small and testable in isolation).

b) Except that for any real language you name it doesn't matter what finite set of goodies it comes with built in. I could always find an example problem which called for abstract constructions it did not already contain.

c) The sorts of things by which I decide a language convenient may be different (example: are variables and functions (names) local or global? -- I detest having to deal with "data dictionaries"). Choices here differ. The reason why C and Unix shells appear lower level than they are is that they devised by engineers in the Bell lab who preferred memorizing bizarrely shortened names/spellings to entering more keystrokes.

From my point of view it doesn't make much difference what language is used to implement the inaginary machine that solves the problem. The bits and peices are small enough the advantages of one language over another is comparatively small.

For somebody who doesn't have experience programming, the choice of language should probably one that facilitates learning, not worrying about performance or anything else like that. But the better question is "how do I learn how to write software."

Writing the fanciest go game database in the world is probably not a good starting point because that's a pretty advanced task.

A good first program is one that just prints "Hello, world!"

A good second program might be one that takes a decimal dollar value as input (e.g. 24.32) and then prints out the necessary bills and coins to produce that value.

A good third program might sort a list of numbers.

A good fourth program might do the same, but efficiently.

etc.

I disagree somewhat.

Yes, the first thing with some new language is to see how one obtains the output "hello world" (and then perhaps some of the others, but not "devise an efficient* sort algorithm". By some simple exercises which you have done before (in other languages you can quickly see how this language does things differently.

But that isn't about learning "programming" (the design of correct programs)

Just "try it and see" is why most programs contain bugs that surface later (a randomly selected test set is almost certain not to be testing all possible conditions).



* Sorry, but if you have the competence even to determine "this sorting algorithms will execute in n*lg(n) time" then you are far from a beginner in programming. Especially when you throw in the special case consideratons like "already almost in order" (that changes things)

I wouldn't expect a beginner to design a shellsort, mergesort or the something, or even know what big-O means, but implementing one (after being shown how they work) is a good exercise for a beginning programmer to introduce the concepts. Obviously, if possible, in a "real" program you should use some existing efficient sort already provided, unless you have very specific requirements.

About programming languages I just discovered an interesting one julia ( http://julialang.org/ ) IT happen to be just started so evolution might happen but it is interesting that it is quite high level (maybe not as much as python) but rut quite fast (maybe not as much as C) so I decided to use it for writting a go engine.

I also saw Julia a few days ago (HackerNews). Although it looks promising (code is very clean), if you are in for the raw speed nothing beats C (except assembler), unless the algorithm or design are very screwed up. I wonder if the name is a reference to Gaston Julia (would bet for a "yes", but...).

RBerenguel wrote:if you are in for the raw speed nothing beats C (except assembler), unless the algorithm or design are very screwed up.

Actually the assembler vs. C run-time speed comparison is not necessarily true anymore. Nowadays C compilers do very advanced optimizations. Even the easy to understand ideas are cumbersome to do while manually coding in assembly (like changing the order of unrelated computation to reduce memory access). Furthermore, modern CPU's execution got very complicated with advanced features (out-of-order execution, speculative branching, more stuff I don't know about). In short, not only you would go mad writing assembly code, but also a decent C compiler would beat you in execution time (as you say, assuming C implementation is not a total screw up).

Btw. I love Python. A language named after Monty Python, how cool is that (spam spam spam spam spam spam)

kivi wrote:

RBerenguel wrote:if you are in for the raw speed nothing beats C (except assembler), unless the algorithm or design are very screwed up.

Actually the assembler vs. C run-time speed comparison is not necessarily true anymore. Nowadays C compilers do very advanced optimizations. Even the easy to understand ideas are cumbersome to do while manually coding in assembly (like changing the order of unrelated computation to reduce memory access). Furthermore, modern CPU's execution got very complicated with advanced features (out-of-order execution, speculative branching, more stuff I don't know about). In short, not only you would go mad writing assembly code, but also a decent C compiler would beat you in execution time (as you say, assuming C implementation is not a total screw up).

Btw. I love Python. A language named after Monty Python, how cool is that (spam spam spam spam spam spam)

Even pipelining (Pentium I) already made optimizing C compilers almost as good as the best "human assemblers". The only point of writing assembly is optimizing very very small computations repeated over and over, in case of need. I have never needed anyway, C is fast enough. And when it is not, it means you need to improve the algorithm. And I also love Python as a language, when I need to do something "quick and dirty" I use either Lisp or Python, depending on what's more suitable.

Mike Novack wrote:* Sorry, but if you have the competence even to determine "this sorting algorithms will execute in n*lg(n) time" then you are far from a beginner in programming. Especially when you throw in the special case consideratons like "already almost in order" (that changes things)

Mostly true, but I think I learned the O(n) characteristics of several sorting algorithms before I could do "hello world" in any language.

I did a lot of math and logic in college and grad school, but before age 23, all I'd ever done with code was a short and disastrous encounter with Maple in high school.

I will concede that that's unusual.

Philip Traum wrote:While we're arguing; is there anyone who takes the standpoint that they don't have to document their code?
I have met people stating: "My code is so clear that comments only waste space, and when it is maintained the code will be updated but not the comments, so I never write any comments".

Absolutely not!

Code that is not clearly commented is an abomination.

Ideally the "comments" go in before the code is written. When I used to do this I would design the program "in words" formatted according to the rules for "comments" in the target language and only later when the design has been analyzed as correct insert the actual code that implemented those words.

Maintainers not maintaining comments? That's a shop discipline issue.

Mind, in some cases I was sometimes writing things that most of the programmers in the shop did not understand. In other words, had to be written so that they would be able to maintain the code after I was gone even though they didn't understand the fundamental concepts behind how the program worked (example a fast "exception" look up routine using a hash table of lists in a shop where most programmers don't know what a hash table is, what a list is, etc.) Bomb proof design with comments like "if this program needs more space (to handle a larger number of exceptions) increase this constant and recompile".

Mike Novack wrote:Bomb proof design with comments like "if this program needs more space (to handle a larger number of exceptions) increase this constant and recompile".

Now the little devil in me wants to know why it was a constant and not a parameter (I mean something that could be e.g. read from a configuration file or similar)?

My bet: Because increasing the number of exceptions per se implied changing the code, so moving the constant to a configuration file doesn't make much sense.

uPWarrior wrote:My bet: Because increasing the number of exceptions per se implied changing the code, so moving the constant to a configuration file doesn't make much sense.

May well be, but then the comment itself was quite misleading