Thanks so much for the comments everyone, once I have done more significant work (fun) I will report back!

I did a really cursory mission statement, paper prototype and pseudocode for the program, though it is definitely too incomplete - I know that I am going to ad lib some as I go along.

Structs are just value-type, cut-down classes (in C#) right? So I think I might already be being a little object oriented. I may have a look online and through my textbook and start using classes proper.


(Now to begin thinking about escape characters in comments...!)

_________________
Revisiting Go - Study Journal
My Programming Blog - About the evolution of my go bot.

OK, just a warning. I may be using language about programming a little differently than many of you. Some examples .....

I wouldn't think of "object oriented" and "procedural" as opposed. To me, the opposite of "procedural" is "functional" (do you define a process or define a function; does you code do something or evaluate something). In any case, many of our "object oriented" languages aren't (objects do not exist at run time).

And when I say abstract I mean much more abstract. Thus here we have a parsing problem. OK, what is the FSM (finite state machine) that solves the problem. This is as much a matter of finding the right place to divide a problem up, to be sure of correctness both in design and that you have tested the coding of that design. In the final program it might no longer be obvious "this is a finite state machine", especially if there are just a couple states and you don't use obvious names. Or let it remain obvious (an example for the junior programmers).

Language is pretty much irrelevant and in the real world you will be restricted to the couple used in your shop. It is very rare that the slightly greater ease using one language over another for a particular problem is worth the trouble (when they call the standby programmer in the middle of the night because program X hung, how many languages does this person need to know?).

But if you want to see extreme examples of "more suited" don't think about language features so much as "what are the native variables". In other words,is fundamental to this language numbers, lists, or strings. If you want an example of this try the following problem in a number of languages:

The program is to accept input of a string, determine whether a palindrome according to the usual rules for TEXT (not mathematical) palindromes, report the result and be willing to accept another string. Notice the problem did not define things like "strings of length less that M".

Try that with any of your favorite languages and then try it using just the bash shell and standard 'nix library. We don't have any languages devoted to string processing (like SNOBOL) around anymore but bash + the library will do very well as a string processing language.

You might end up with fewer characters in that script than lines of code in most other languages. Been a while (and I lost it in a house fire) but I think my solution was maybe a five line script of somewhat over 100 characters.

The point here is that a language like C++ will come provided with objects to support abstract structures like lists (or queues, o ...) but if you were using a language like LISP you don't need anything special for lists (the fundamental data type of the language).

I think this is quite a bit different than what a majority of software engineers think.

I think it's a matter of tastes. I don't think there are opposites. Lisp has an object system, you can certainly extend Forth to do so, and you can write almost object-like code in plain C using structs and function pointers. There is nothing special about object oriented programming. Of course there is a clear distinction between functional and non-functional languages, just like stack based are different from variable based, or between Prolog and everything else. Each one has its strong points and its weak points, and deep inside all are equivalent. Choose the best, but don't settle on a hammer thinking all to cabinetmaking is driving nails. You also need planes, screws and rasps. Learn as much as possible, as different fields as possible.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

It is not clear what a char is in this context. Many East Asiatic character sets have multibyte characters that properly contain \ or ].
For example, "Honinbo" written in Big5 contains a ']'.

SGF has the CA tag, which specifies the character set, and which therefore theoretically should make this clear. But the SGF standard specifies that the charset used should be in RFC 1345, which is over 20 years old and does not mention UTF-8, UTF-16, UTF-32, Big 5 and many other character sets.

And of course, since the CA tag is inside the SGF, you don't know the encoding until after you've started reading the SGF, so to do it correctly, you should switch to the specified encoding specifically when you start reading the content of a text property, you can't just read the whole file with a specific encoding.

Text parsing and processing outside simple ASCII is a pain in the ass.

Mike posted about writing a palindrome checker in five lines of code, but I bet that assumed simple ASCII input

@Loons: Just assume it is safe to read the file via the standard library file reading methods, there are far more interesting things to write code for than weird edge cases in character encodings

Writing short code for the sake of it is... well, I won't say stupid, because it is not, but usually it's just a fun thing you should do on the side, when bored. After all, if terseness is the only thing you want, learn to program in J or APL. The J function to check if a (lower-cased or upp-ercased) string is a palyndrome is this beauty of 5 characters:



I don't know enough J to say much about this aside from knowing J is very hard and here we probably have a fork and an adverb in place.

And that's like:

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

If you are a computer science major (as opposed to "data processing") you will unboubtably prove this (or at least learn to follow the proof).

A "Turing Machine" (procedural) and a "Wang Machine" (stack) are equivalent.

For a naive "it's obvious", picture how a Turing machine is defined with its state machine moving back and forth on an infinite "tape" and a state machine placed between two stacks (a "Wang"). If one can compute anything that is computable so can the other.

IMHO the greatest usefulness of "object oriented" is to shortcut learning time. But there are arguments both ways. For example, if you learned C from the original Ritchie text then you would know how to construct your own version of all the standard 'nix library things (because exercises of the text). If we had had been using an objct oreinted language in the shop where I worked all that meant would be that one or two of us "top hands" would be deifning the objects to be used by the programmers.

It shouldn't take very long before an experienced programmer (having started from scratch) had in a personal library all those useful bits and pieces or at least knew from which preciously written program they could be grabbed as necessary. When I say I wrote about 300,000 lines of code in my day I don't mean 300,000 lines of new code. After the first ten years probably 80% of the average new program written would be from old programs, slighttly modified.

And you really can write anything in anything. To replace a great deal of hard coding in many programs (check if this policy is an exception case) I wrote fast search routine (that when first called read in data from a file users could add exception cases to) that was a "hash table of lists" and this was a COBOL* shop! << specially written with instructions in the comments so that the programmers could do any necessary future maintenance without understanding what a hash table was, what lists were, etc. >>

* OK, assembler was allowed too, but there were even fewer of us around who maintained those. We tried really hard to avoid adding any new assembler programs.

I'm no computer science major (I'm a mathematician,) this is just a fact I know. If I'd need to show a line of proof from stuff I know, I know S-expressions as defined by McCarthy in his seminal Lisp paper are Turing complete, hence any language where his eval/apply (and the 6-7 basic primitives) can be programmed is also Turing complete. Since writing this in Forth (stack-based language) is relatively straightforward and Forth is almost as bare a high level stack based language gets (save Brainf*ck,) stack languages are also Turing complete.

What is a "data processing"?

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Perhaps. There are two interpretations of the FF4 standard, and both occur in real life. One uses char=byte. That makes life easy for a parser, and the CA property is not needed to parse the game, only to display the text fields. After inserting escapes, the resulting SGF file need no longer be a text file, and ordinary text editors may not be able to handle it. The other uses char=(possibly multibyte) character. Now the SGF file remains a plain text file, easy to handle, but the CA property is needed to be able to parse the game. A parser must know about all possible text encodings.
Since both interpretations occur, FF4 is not a well-defined format.