- entry 2015/11/17

The source code is messy. When are you going to fix it?

In a word: I'm not.

Well, okay, in two words. Maybe three depending on how you count the contraction.

David pointed out that his stuff was written in Twin. I have never had the "pleasure" of using Twin, but I'd imagine it would be something not unlike ARMBE, and I found ARMBE to be somewhat painful. And, as I pointed out, display devices generally sucked back then, and all this fancy-whizzy clever IDE stuff didn't exist. Ever used the DOS versions of TurboC or TurboPascal? That was cutting edge stuff.

Yes, there are some things that probably need changing in Ovation. Many variables are not "initialised", definitions of things can appear in odd places in the source, and there are even some old style C function definitions.
But you know what I plan to change?

Nothing.

Not unless there is a feature to add or a bug to fix.

Why? It's simple. Ovation works.

All too often, a company (or individual) gets the idea that when taking on an existing project, the best thing to do is rewrite it. That is, of course, the absolute dumbest thing. You see, you may feel that Ovation's code is "messy", but David has given us three things:

1. The source code itself. If you really don't like it, then take his or take mine and rewrite it all. I won't hold my breath.
   
   
2. The software. With a few things fixed, Ovation works. It works on my Pi just like it did on my A3000. What is the logic of doing a huge overhaul of the code, or even maybe rewriting it all, just to end up with what we have at the moment? I've heard some damn fine grandiose plans on the ROOL forums, and about the only one that has arrived is a more modern Javascript web browser in the guise of a rather non-RISC OS-like port of Webkit (which lays claim to insane amounts of memory and runs like treacle). The rest? Still waiting...
   But in this specific point, Ovation, you'd take the time to revamp the application to arrive at what already exists? Why? What's the point?
   Or maybe you can suffer feature creep and add lots of extra functionality to your rewrite. Well, we have that too. It's called OvationPro.
   
   
3. Experience. This, this is the part you cannot provide. I don't mean experience as a coder, I mean experience with the software. Think about it - when you see something in Ovation that might look weird, you can either figure David was pulling an all-nighter and had run out of teabags (they didn't have 24h Tesco back then), or you can figure more logically that the weirdness is to work around specific issues. Specific issues in specific operating systems, or maybe even on specific machines? Things had to be tried and tested, a lot. We live in an easy age where I can push out software versions to you. If I screw up, no biggie, I'll patch it and put a fix on my site. The major operating systems have patching built in, or some sort of updating mechanism. We're lazy. Crap gets pushed out the door that shouldn't have passed basic Q&A (any guessing on whether the next major iOS release will have an easy-to-bypass lockscreen?). Back then, back in those days, software was sold on a floppy disc. Getting upgrades was... rare. Beebug never notified me, a legitimate purchaser, of any updates. I had to ask them when their added-on-top installer stuff failed on RISC OS 3. They, of course, provided a replacement that worked. I posted them my original floppy disc, they sent it back with the updated software on it. By mail. In an envelope. With a stamp on it.
   As such, things needed to be tested that much better than happens today. But things can still slip through, and the accumulation of the fixes and specific code is what I refer to as "experience". In essence, Ovation has been tried and tested since 1990. I went looking for bugs to fix (asides from the zero page issues) and I posted a request for people to tell me about their pet bugs. I have found only a few small niggles, and nobody has reported anything.
   Point is - the "messy" code you have in front of you builds a working application that has, in varying incarnations, been in the wild as a released product of Beebug, Risc Developments (aka Beebug), and APDL; carrying price tags anything from freebie to a hundred quid. This code. Not some other code. David isn't Rickrolling us, he isn't going to say "ha ha, fooled ya!" and unveil the BASIC source that builds Ovation. No, it's this. All that development, all that time, all those questions asked and hurdles jumped over. They're all there in the 50 C files and 59 header files that are the megabyte and a third of code that creates the third-of-a-megabyte of executable that is Ovation.

I understand the "Not invented here" syndrome. It affects us all at some stage, and has trashed projects and killed some companies and kicked others. It makes sense to begin a project afresh when it is going to be something else. OvationPro is not Ovation, and while I might see some duplicated code in it, I can imagine a lot of the design is different. In this respect, it makes sense to begin again. What doesn't make sense is to make big changes to the Ovation source code simply for the sake of making them. The result? Will be Ovation. Maybe your compiler will give you a lovely good karma feeling, but those feels will evaporate quickly when you realise that big changes can change things in subtle ways. In other words, I'm going to be here farting around with some of my own code or watching Noragami . . . and you? Would you prefer DDT or DADebug? ☺

tl;dr: "The source code is messy. When are you going to fix it?". I'm not. Don't fix what ain't broken.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

David Pilling, 18th November 2015, 18:27

A curse... some of the source code is messy because I didn't understand what I was doing, sometimes I eventually understood. Some of it is messy because that way of doing things works. There is stuff in there which you would not write that way - as I did, set off with the simple sane way of writing the code, find it won't work on RISC OS, then do it another way. Make changes... do you understand the side effects, at one level all that messy code, what might you break. But at a worse level, how might you change the behaviour of the program. Desktop publishers expect things to work in a particular way.    I've never written pretty code, I have encountered people who can write code as nice as poetry. Is pretty code more likely to be correct.    I really liked the twin editor. A bit of an oddity beca

David Pilling, 18th November 2015, 18:36

As I was saying, I really liked the twin editor. A bit of an oddity because it came out at the start of the Archimedes, but was not desktop based - the desktop did not multi-task at the time, so there was not much point.    I was going to do a 32 bit version, but never got around to it.    In 1988 it was the best editor by far, quite possibly the only editor - I can't think of any other.    I have loads of sins. Since 32 bit came out I've used Edit, because I couldn't be bothered sorting out why Zap didn't work (I now have it working). By mid 1988 I'd ported EMACS, and not long after other UNIX style editors vi etc. Learning any of those would have served me a lot better than being a twin expert.    I'm sure I continued using twin long after everyone, including Sophie Wilson had packed it in.    I recall a live chat on Prestel Micronet where the author promoted "their new editor".

David Pilling, 19th November 2015, 13:49

The last posting but one is a bit gloomy. I say go for it. The problems would be there with all but the best documented software.    I know nothing about the history of twin - maybe it was used to write the original Archimedes OS. Maybe for OS 1.2 or RISC OS 2.

Rick, 19th November 2015, 19:46

I wouldn't say gloomy. I don't think "modern" people really appreciate what it is like programming when you don't have multiple windows, oddles of online references, syntax highlighting, variable name completion, versioning repositories, and all of the other stuff that is just "expected" these days.  Can you tell me more about Twin? Do you have any screenshots of it in action?

Rick, 20th November 2015, 08:35

Forget the lock screen, try charge=freeze! http://www.theregister.co.uk/2015/11/19/apple_frozen_ipad_confir mation/

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 50974 backwards.
		Your comment