User talk:Chris Burrows
Thanks for helping to clean up the Modula-2 article. I am a bit concerned about not having any kind of metric at all in the infobox under "major implementations" because over time people will just add entries there. Who is to say that an implementation is or isn't "major" enough to deserve to go into that box. I felt that even a flawed metric such as the first five compilers that show up on a google search for "Modula-2" would be better than not having any metric at all. With such a metric it should raise the bar for anybody who thinks he must add another entry there. And if the ranking changes and a compiler drops out of those top-5 somebody might just change the list then without getting challenged on that change. If there is a better metric that can be easily verified, that would be fine as well. I just couldn't think of anything else.
Or if there is another way to discourage people from overpopulating the infobox, that would be worthwhile trying too. But the way it is now, I think we are soon going to see folks adding more entries there which is probably not a good thing. Of course we can watch the page and remove any excesses but if somebody is unhappy about having their addition removed, then we probably should have some kind of metric (even if it is not perfect) to justify what goes there and what doesn't. I don't have a perfect solution to offer but the concern remains.
- It is not a problem. No more than 2 have been added in the last 3 years. Start by removing Objective Modula-2 (yours by any chance?). It is (a) only a partial implementation of Modula-2 (b) is not yet 'major'.Chris Burrows (talk) 23:21, 27 February 2010 (UTC)
Fair enough, let's watch the situation. As for removing any entries, the question comes back to what does "major" mean? For example, if the google search index is not agreeable as a metric, then I disagree that Ulm Modula-2 is a major implementation because (a) it is no longer maintained and (b) it is restricted to legacy platforms that are now outdated (SunOS4/MC68K and Solaris2/Sparc). One might also argue about p1 Modula-2 because it too is limited to legacy platforms and APIs (non-Intel Macs/Carbon API). Whatever the metric, what was once a major implementation doesn't necessarily count as major today.
The metric should be simple so it can be verified easily. Using the google search method has that advantage (even if it is not mentioned on the page itself) so I think that in the absence of any other metric, this is what should be used for the time being. If a different metric was used, then that metric should reflect that software falls into two general camps: open source and commercial. There should then be two compilers from the open source pool and two commercial ones. All compilers should be actively maintained/developed/supported and they should support at least one platform that is in use for new product development. For example the 8051 micro-controller is a very old platform but it is being used for new products. Using this metric, the Ulm compiler would not be in that box and the p1 compiler would probably be replaced by Mod51. Wirth's compiler should of course remain there for historic reasons.
- There aren't any current implementations that I would call major i.e. widely used and you can't hope to get a reliable metric from any source. The democratic nature of Wikipedia will eventually eliminate unsuitable entries if anybody is interested. Historically, ETH (not just MacMETH), Logitech, JPI and possibly StonyBrook would have been the most widely used. However, it's not just up to the two of us to decide. I recommend that you relocate this entire discussion from here to the Modula-2 talk page.Chris Burrows (talk) 11:46, 28 February 2010 (UTC)
Oberon-1 / Oberon-2 / Oberon / disambiguation / ...
Please see my comment at talk:Oberon-1 (at least it was Oberon-1 when I left it moments ago). We're sliding into the soup here... ww 03:32, 4 November 2006 (UTC)
SAGE Computer Technology
Do you know if the SAGE Computer Technology Sage IV used VME bus for those boards?, and how did those graphical terminals connect to the computer physically? (RS232 or CPU Bus)
Your recent edits to Comparison of Pascal and C are undone
Hi, Chris Burrows
I'd like to inform you that I have undid your recent edits to Comparison of Pascal and C as they were destructive rather than constructive. Your edits consisted of removing tags that identified very obvious article problems. Now, hiding the issues of an article wouldn't solve anything: The article remains problematic. In the future, please try to solve the actual problem instead of hiding it.
Of course, if you don't understand were the problem is, well, you can always ask. But please refrain from using edit summaries that are inconsistent with truth. (For instance, "Fixed reference to strings"). I assure you, no one in Wikipedia, Administrator or otherwise, loves this.
Turbo Pascal IDE etc
Hi Chris – not sure if you are the Pascal to Oberon man or a Redmond C# evangelist (or both). Like you, I've been trying to clean up the Turbo Pascal article which seems to be a fog of unsourced claims. If you plan to continue working on it, let me know if we can collaborate: I've never used TP myself but I have other sources about that period. - Pointillist (talk) 00:40, 17 May 2010 (UTC)
- I can tell you one thing for sure: I am not the Elvis impersonator ;-)
- I did do the work on the Pascal to Oberon translator and am currently responsible for Astrobe, the ARM Oberon-07 development system. I only used TP a few times as by the time it was released I had more or less finished using Pascal and was heavily involved in Modula-2 development. I believe a thorough cleanup would need the cooperation of more than two people. I'll just limit myself to trying to correct anything that is blatantly incorrect. Chris Burrows (talk) 07:15, 17 May 2010 (UTC)
Hi Chris! Thanks for taking the trouble to pass the Oberon-2 sample code through a compiler. I've been trying to get around to doing that myself, but not had time. The original code did pass through a POW Oberon-2 compiler, and executed (I'm using it in a graphics application). However, you seem to have made a few debatable changes to my example.
- The semicolons before the keyword END (and other closing keywords) are not /required/, but they are /recommended/ by Wirth,
and have been since Pascal. They are also good coding practice, because it's easy to miss adding a semicolon if you need to insert a new line of code before the END.
- Method names are conventionally not capitalised. Only Classes (Modules) and Types have capital initial letters.
- Oberon-2 (as a pose to Oberon) permits the VAR keyword on a Method receiver - see the syntax. In this example, the list structure is simplified so as not to use a base anchor, so it is necessary to modify the receiver object from inside the methods. That isn't possible without VAR, so the code may well compile, but it crashes at runtime.
- If you do not have the time to test your code do not attempt to write it - incorrect code in an article is worse than no code at all.
- Extraneous null statements are rarely seen in code published in authorised texts. When present they risk giving the impression that the author doesn't understand his subject and does not understand their proper use. I have seen no such recommendation by Wirth. Study examples of his code in any of his books and you will see that he certainly doesn't follow that practice. His 'Project Oberon' book is a good place to start.
- Which 'convention' are you referring to? The only style guide I am aware of is that produced by Oberon microsystems and supplied with Blackbox Component Builder. Do you have a reference to a different style guide? In the example I corrected you used a mixture of upper and lower case for the same identifier in one procedure! If you had been consistent I would not have had to change it.
- Oberon doesn't have Method receivers so I'm not sure why you mentioned Oberon in this context. Mere syntax checking is not sufficient to validate an Oberon program. In Oberon-2 the VAR keyword is not permitted on a Method receiver when it is a pointer. It should be either a VAR or a pointer type but not both. Refer to MÖSSENBÖCK's "Object Oriented Programming in Oberon-2" book for more information.