C# and other OOP languages

[vvanders]

There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.

That said its easy to do wrong but that could be said about 90% of C/C++.

[tggzzz]

There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.

That said its easy to do wrong but that could be said about 90% of C/C++.

Well, comparing a good DSL to typical templates or macros isn't much of a contest - and I'd agree with you. The problem is that most DSLs aren't good.

Usually they "start small" as a means of adding scriptability to a compiled application, and usually the reasons for that are bogus. Then something can't be expressed/done in the existing DSL, so a hack is added on. And then another. And another. And soon the DSL has grown like Topsy so that nobody, including the inventor, can quickly and intuitively grasp the interaction between all the misfeatures. (And I wouldn't dream of comparing that to C++, oh no)

And, of course, there is zero tool support since it isn't needed for a tiny add-on to the real application.

And you can't find anyone external with experience in myScrottyDSL so you have to train people. Except that anyone with an ounce of gumption won't want to tie their career prospects to a non-portable skill.

Contrast that with having a library expressing the same concepts. Tool support comes for free, developers already know the language and toolset so no training, and you can get the best rather than the dullards.

I once made the mistake of creating a scrotty little DSL for a 2 week job. I quickly realised I should just have used Forth (in that case), and vowed never to make a similar mistake again.

I have, however, repeatedly seen projects and companies spending many years going down the blind alley of custom DSLs - one to the extent that it actually killed the company!

[HackedFridgeMagnet]

Examples:
(a) tHisisa_FuntTHAT_IMADE_pm(unsigned char a, unsigned char p).
(b) A function called do_nothing(), which contains a timer loop and a watchdog timer reset routine.
(c) rrunDAIG(), where DAIG is meant to be Diagnostics.
(d) Putting a watchdog reset in a 1ms timer interrupt. Tossers!
(e) About 200 files all up - 100% of which had names which meant nothing or were ambiguous.
(f) Functions put into random files.
(g) Extreme abbreviations like get_prdc_get_tm_sm() where the acronyms have no logical meaning.
(h) 5000 lines reduced to about 700 lines yesterday. Cut 'n paste kiddies.
(i) Up to 6 levels of Gets and Sets all over the place. Bloody Windoze OOP programmers.
(j) #defines without any case consistency. eg a_COnstant, A_constant, acon, Acon, whatever they wanted. You cannot easily depict a constant from a variable.

Wow some impressive stuff there. A worthwhile hijack.
For code like that you really need an IDE to find your way around it.
Does the project actually work?

does d) call b)  ??!! they are both WTF by themselves.

I guess 6 levels of Gets and Sets might be ok if it was an OO language.

I can't remember ever seeing code that crazy in an actual project, and I have been on the receiving end of a few still born projects. A pet hate is badly written MACROs, they make life very hard.

Got any more juicy examples?

[vvanders]

There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.

That said its easy to do wrong but that could be said about 90% of C/C++.

Well, comparing a good DSL to typical templates or macros isn't much of a contest - and I'd agree with you. The problem is that most DSLs aren't good.

Usually they "start small" as a means of adding scriptability to a compiled application, and usually the reasons for that are bogus. Then something can't be expressed/done in the existing DSL, so a hack is added on. And then another. And another. And soon the DSL has grown like Topsy so that nobody, including the inventor, can quickly and intuitively grasp the interaction between all the misfeatures. (And I wouldn't dream of comparing that to C++, oh no)

And, of course, there is zero tool support since it isn't needed for a tiny add-on to the real application.

And you can't find anyone external with experience in myScrottyDSL so you have to train people. Except that anyone with an ounce of gumption won't want to tie their career prospects to a non-portable skill.

Contrast that with having a library expressing the same concepts. Tool support comes for free, developers already know the language and toolset so no training, and you can get the best rather than the dullards.

I once made the mistake of creating a scrotty little DSL for a 2 week job. I quickly realised I should just have used Forth (in that case), and vowed never to make a similar mistake again.

I have, however, repeatedly seen projects and companies spending many years going down the blind alley of custom DSLs - one to the extent that it actually killed the company!

I guess we just have different experiences, I find protobuf, flatbuffers and a few other DSL based code gen frameworks to be a lifesaver. It also depends on how you build your DSL, I find that ANTLR with either the C# or Java runtime to work particularly well.

Now writing your own DSL parser, that's the path of madness. If I'm building a project where I need to do a lot of boiler plate code(interop between C++/C# or other languages) I find DSLs to be a life saver.

[tggzzz]

There's nothing wrong with a DSL to do code gen. I much prefer it to overly complex templates or a mess of macros.

That said its easy to do wrong but that could be said about 90% of C/C++.

Well, comparing a good DSL to typical templates or macros isn't much of a contest - and I'd agree with you. The problem is that most DSLs aren't good.

Usually they "start small" as a means of adding scriptability to a compiled application, and usually the reasons for that are bogus. Then something can't be expressed/done in the existing DSL, so a hack is added on. And then another. And another. And soon the DSL has grown like Topsy so that nobody, including the inventor, can quickly and intuitively grasp the interaction between all the misfeatures. (And I wouldn't dream of comparing that to C++, oh no)

And, of course, there is zero tool support since it isn't needed for a tiny add-on to the real application.

And you can't find anyone external with experience in myScrottyDSL so you have to train people. Except that anyone with an ounce of gumption won't want to tie their career prospects to a non-portable skill.

Contrast that with having a library expressing the same concepts. Tool support comes for free, developers already know the language and toolset so no training, and you can get the best rather than the dullards.

I once made the mistake of creating a scrotty little DSL for a 2 week job. I quickly realised I should just have used Forth (in that case), and vowed never to make a similar mistake again.

I have, however, repeatedly seen projects and companies spending many years going down the blind alley of custom DSLs - one to the extent that it actually killed the company!

I guess we just have different experiences, I find protobuf, flatbuffers and a few other DSL based code gen frameworks to be a lifesaver. It also depends on how you build your DSL, I find that ANTLR with either the C# or Java runtime to work particularly well.

Now writing your own DSL parser, that's the path of madness. If I'm building a project where I need to do a lot of boiler plate code(interop between C++/C# or other languages) I find DSLs to be a life saver.

The differences aren't so great: you have chosen decent DSLs with limited ambitions, and used them only where they shine.

The trouble is that many DSLs, and more importantly DSL advocates, aren't so knowledgable and disciplined.

[VK3DRB]

...Does the project actually work?...

...Got any more juicy examples?...

The project worked reasonably well after I spent 5 months fixing 40 bugs in the inherited code.

Other juicy examples...

Yesterday I found ticks and tocks all over the place as variables and functions names. is a tock?! They meant nothing special, eg: not alternate timer ticks. They were used to refer to timer ticks in some obscure way. I got rid of all the tocks by turning them into ticks and sensibly renaming some functions and variables or deleting others as dead code. Except there is one tock I missed coming across... the complete tock who wrote that code.

Another line of code I found, which appears in a few similar ways in different files....
error_code = the_errorcode;





 
   

[sunnyhighway]

Another line of code I found, which appears in a few similar ways in different files....
error_code = the_errorcode;

Let me guess... error_code has a global scope.

[amyk]

Thank is pretty bad. But what I am dealing with is much much worse. Seriously so.

That sounds like http://thedailywtf.com/

[VK3DRB]

Another line of code I found, which appears in a few similar ways in different files....
error_code = the_errorcode;

Let me guess... error_code has a global scope.

Good guess, but no. the_errorcode was passed on the stack into the function and error_code was locally defined. BOTH were used. Cleaning up the function removed the local one and the passed in one was renamed.

[linux-works]

... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.

Python almost always complies perfectly and that's the problem.

C style commenting has the same problems (and solutions) as Python's indentation ...

Python also got a bit better than it was in the past, they stopped allowing you to mix tabs and spaces in indentation.

My problem is more with the lack of static typing (that is, a compile time constraint on the types of arguments and variables). It is less readable IMO and defers much of the type checking to runtime (assuming the the code is covered). 

Last year I implemented an internal systems and did it in Python to speed up the development.  After a week or so I realized that  as the code becoming more complex the development slows and the code becomes less maintainable, so I rewrote it in Java and continued the development in Java.

Static typing is a very strong language feature.

I used to think so, but not so much anymore.

I just completed 2 weeks of python classes at work, given by a python core dev (raymond H., fairly well known teacher, developer and evangelist).  I was skeptical, being a 25+ yr c programmer.  at the end of the 2 weeks, I was pretty convinced that python is the Next Big Thing(tm)

java?  let it die already.  too complex and never really delivered on 'portability' (look at all the versions and problems they have).  python is much simpler, does have all the fancy language features you'd need and really is portable (ignoring the v2.x and v3.x stuff for now).

I'm also finding that python is being taught to corporate guys (like me) in a very serious way.  I'm at cisco right now and they are sending a lot of their engineers to python training.  we are even going to convert a lot of our test code from tcl over to python (dumping tcl is a good move, of course).  I'm seeing this in the industry all over; python is being accepted very quickly.  its very useful to list it on your resume/cv and so I'm now happy to learn and use it

there are some cultural things that are interesting, though: it seems that people from india are very heavily invested in java, certs for the language and this probably won't change quickly.  otoh, in the US, we are a bit less locked-in to java and I see python 'winning' the war.  if 2 groups in the same company start to work on a new project, the india group will usually pick java and the US group will (more often) pick python.  whoever gets there first gets to continue on (lol).  it may be some time before india stops being java's b*tch and sees the light, but I do think it will happen eventually.

if you get a chance to take some python courses, do so!  go in with an open mind and I bet you will see the benefits of the language and its huge runtime libr. (built in and contrib) richness.

[VK3DRB]

Am at the half way point! Whoo hoo... about 24,000 lines of frogshit has been refactored. Another 6 weeks and it should be finished if I don't become a serial killer of slapdash engineers first.

Today I found a sprintf() for a simple conversion from an integer to a 5 character string in an area where speed was critical. To make matters more silly, there was already a function that would do that exact conversion efficiently sitting two functions away.

Also found a byte XOR calculator where the passed characters into the function were typed as chars and the XOR calculator was typed as an unsigned char. I don't like XOR as a so-called "checksum" as much as summation, because unlike with summation, XOR of two consecutive bytes of the same value produces 0x00.

The original programmers called their XORed bytes CRC's quite often in function names, variable names and in the comments. It is obvious they did not know what a CRC actually is, and they would have done well to have used it.

[zapta]

I was skeptical, being a 25+ yr c programmer.  at the end of the 2 weeks, I was pretty convinced that python is the Next Big Thing(tm)

I can sell you the Bay Bridge   ;-)   

I know of at least one Python project by a core Python developer that was rewritten in Java for maintainability. It's a glamorous scripting language, not the first and not the last.

http://en.wikipedia.org/wiki/Scripting_language

[linux-works]

sure, not the first or last, but its getting traction and being taken very seriously.  quite a lot of companies are investing in it, in training for their people (which I find surprising, given how cheap companies are and how they hate to spend money on training, overall).

if you know java, you will probably want to continue with it, because you were trained in it and it did take a lot of training.

if you don't know java then python is, imho, probably the better thing to write in.  java, to me, seems way too complex for what it should be doing.  (I never quite got what it was supposed to be good at, anyway, but ...)

if java loses popularity, I'd be quite happy to see python pick up the slack.  the language is just plain easier, and the culture is nicer, too.

I'm convinced that you can write big and complex apps in both and if you are good, either will be supportable and debuggable.  but java's learning curve is much higher and there's more stuff you have to deal with and worry about.  python has no build system, it just plain runs (lol).  its funny, but I kind of like that.  big change from 'ant' and all that xml build file crap.

[miguelvp]

Also you can import C++ or C modules in python, so you can get performance as well.

[tggzzz]

I was skeptical, being a 25+ yr c programmer.  at the end of the 2 weeks, I was pretty convinced that python is the Next Big Thing(tm)

I can sell you the Bay Bridge   ;-)   

I know of at least one Python project by a core Python developer that was rewritten in Java for maintainability. It's a glamorous scripting language, not the first and not the last.

http://en.wikipedia.org/wiki/Scripting_language

Yes indeed. Many people have fallen into that trap, and many more will.

Techniques that work well with small programs often don't scale. In particular they run into difficulties when

• proof is required that certain methodologies have been followed
• multiple people simultaneously creating a large application
• integrating new components (i.e. not battle-proven libriaries) written in haste by other people/companies
• maintenance of codebases written 10 years ago by people/companies that have gone away

[VK3DRB]

The language does not matter!

You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.

The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.

[tggzzz]

The language does not matter!

You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.

The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.

The language is not absolutely good/bad, but the language definitely does matter since it increases/decreases the probability of a good result.

A good language (including library where appropriate) allows

• easy expression of the algorithm used to implement the program's objectives and requirements
• simple easily-understandable correspondance between the requirements and the code
• avoids unexpected behaviour
• avoid behaviour that can only be understood upon close inspection by users with exceptional experience
• prevents common errors from resulting in code that executes without visible errors

A bad language (including library where appropriate) allows

• requires contorted tricks to implement the algorithm used to implement the prograb's objectives and requirements
• has unexpected behaviour
• has behaviour that can only be understood upon close inspection language and implementation experts
• allows common errors to execute without visible errors

As a humourous example of language mattering, can you imaging whispering sweet nothings to a lady such as "you have beautiful bust-warts"? (Brustwarze is German for nipple, and guess what the literal translation is). Or try pronouncing the German for "butterfly" (Schmetterling) and seeing if it invokes a feeling of something delicate and beautiful!

[VK3DRB]

The language does not matter!

You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.

The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.

The language is not absolutely good/bad, but the language definitely does matter since it increases/decreases the probability of a good result....

Agreed, the language matters to some extent, but is a poor second to the three A's. At the moment I am working with refactoring coding mostly in C where 4 of the 5 predecessors had at least 1 of the 3A's missing and a maybe a few screws loose as well. However, one predecessor was very good and wrote crisp clean efficient C code, easy to follow and beautifully commented.

That programmer included some AVR assembly language files, three which I came across today when I noticed that my Windows 7 sees a .asm file, it calls the file "Assembler source file". There is no such language as assembler and there never has been. The correct term is assembly language. Notepad++ used to call assembly language "assembler" until I got the authors to change it around version 4. I am not sure whether it is Visual Studio, AVR Studio, some other compiler or Windows Explorer incorrectly identifying the .asm file.

[tggzzz]

The language does not matter!

You can make poetry or garbage from any language, whether it be C, assembly, C++, C#, Python, JAVA or any other language.

The triple A attributes to writing good code is Attitude, Aptitude and Ability. If any of those are lacking, rubbish will be the result; you get high levels of all three from an engineer or programmer and you have a winner.

The language is not absolutely good/bad, but the language definitely does matter since it increases/decreases the probability of a good result....

Agreed, the language matters to some extent, but is a poor second to the three A's. At the moment I am working with refactoring coding mostly in C where 4 of the 5 predecessors had at least 1 of the 3A's missing and a maybe a few screws loose as well. However, one predecessor was very good and wrote crisp clean efficient C code, easy to follow and beautifully commented.

Where refactoring is concerned, C offers pretty dismal and error prone facilities - Java is much much better. Yes, I appreciate Java doesn't solve all the world's ailments, but in this respect it is orders of magnitude better.

Why is C so bad?

Well, let's start with trying to determine all the places a function is called. Potentially very error-prone, given the ability of the macroprocessor to completely change the source code before it gets to the "real" compiler. Yes, I have seen some truly horrible things done with macros.

Next let's move onto trying to determine which bits of code can alter a specified variable. Consider (void *) - enough said. It is impossible to solve accurately - it is the aliasing problem that plagues attempts to have globally optimising C compilers and linkers. The obvious manifestation is the plethora of mutually-incompatible compiler/linker flags that attempt to allow the programmer to allow the compiler to optimise.

And time's run out, so I won't mention some of the others!

So good luck with refactoring C - in Java the "refactoring browsers" in IDEs are a very significant advantage. Refactoring is the norm and is routinely done on a day-by-day basis.

And that's an excellent example of where languages can help/hinder.

That programmer included some AVR assembly language files, three which I came across today when I noticed that my Windows 7 sees a .asm file, it calls the file "Assembler source file". There is no such language as assembler and there never has been. The correct term is assembly language. Notepad++ used to call assembly language "assembler" until I got the authors to change it around version 4. I am not sure whether it is Visual Studio, AVR Studio, some other compiler or Windows Explorer incorrectly identifying the .asm file.

You can't polish a turd, whatever language it is written in. But some languages at least put the turds in plastic bags.

[linux-works]

a lot of what you just said is all based on TOOLS issues, not so much language issues.

with a good ide, all languages are refactorable and you can find refs to functions, vars, externs, etc.

a lot of what java fans think is good about java is quite often about the ide they learned on!

don't get me started about makefiles (their equiv) on java.  what a horrible mess!  makefiles in c have been around so long, its a proven technology and not hard to master.  ant and other build systems for java are horribly complex and take a long time to learn to do them well.

I love that python has no build system and no need for it.  no compilers, and yet it runs very fast if you do things in the proper pythonic way

c++ always annoyed the hell out of me.  I love C since its been around forever, its used to write os's, networking stacks and most of the unix cmds you use every day.  for scripting, though, I am migrating from bash to python.   java was an interesting experiment, but I consider it like pascal: great to learn stuff on, but I hate having to support other peoples' code when they use java.  and its mostly the new generation that insists on java; us oldtimers still mostly reject it (personal experience working in the bay area, fwiw).

[tggzzz]

a lot of what you just said is all based on TOOLS issues, not so much language issues.

No. The macroprocessor and aliasing issues are solely in the language, and in general tools cannot get around the issues. The tools can help in special cases where disciplined developers only used a restricted subset of the language's capabilities - but in that case it probably won't be necessary to do refactoring in the first place.

The aliasing issue is very real and is a very significant problem, and significantly restricts the ability of compilers to do optimisations that are trivial in other languages. The workarounds (use of myriads of compiler flags) are error prone. If you or your libraries' user accidentally uses the valid-but-inappropriate-combination of flags,  a presumption is violated and their program will produce subtle errors. Perhaps the user will notice the error, probably not.

with a good ide, all languages are refactorable and you can find refs to functions, vars, externs, etc.

a lot of what java fans think is good about java is quite often about the ide they learned on!

I learned computing using Algol-60 on 5-channel paper tape. (Consider how you can represent digits, letters and symbols in 5 bits.)

I used C in the 80s, eventually moving to Objective-C, and avoiding C++.

I've used Java professionally since 1997.

So I've got wide knowledge and a solid history of making good choices about what technology really does advance the art of the possible.

don't get me started about makefiles (their equiv) on java.  what a horrible mess!  makefiles in c have been around so long, its a proven technology and not hard to master.  ant and other build systems for java are horribly complex and take a long time to learn to do them well.

Famous problem with makefiles was that invisible differences in the makefile caused different behaviour: tabs had different meanings to spaces! Stunning.

I love that python has no build system and no need for it.  no compilers, and yet it runs very fast if you do things in the proper pythonic way

And the indentation-is-significant produces all sorts of run-time errors that is avoided by "{...}" or "begin....end".

Welcome to shellshock-class bugs in every program!

c++ always annoyed the hell out of me.  I love C since its been around forever, its used to write os's, networking stacks and most of the unix cmds you use every day.  for scripting, though, I am migrating from bash to python.   java was an interesting experiment, but I consider it like pascal: great to learn stuff on, but I hate having to support other peoples' code when they use java.  and its mostly the new generation that insists on java; us oldtimers still mostly reject it (personal experience working in the bay area, fwiw).

If C++ is the answer, then (a) I want to know th equestion and (b) we should change the question.

[SirNick]

I find it about as absurd to compare Python, Java, and C as it would be to compare a can opener, scissors, and chainsaw.

Giving up Bash scripting for Python is a good move.  Giving up C for Python is not.  Python is a scripting language, like Perl, and is really good for quick-n-dirty tasks, or minor applications.  For whatever reason it's the darling of developers right now, but you wouldn't write a device driver in Python, or a kernel, or an embedded application.  Wrong tool.

C is really the sweet spot between ASM and Java / Objective C / whatever, and despite a LOT of en-vogue languages coming and going through the years, it's still ubiquitous.  Yeah, void* can be a pain in the butt, however the times you use void* should be relatively few and far between.  And in such cases, there should be no obviously preferable way to handle it.  It's a very sharp knife, so don't be careless with it.  Hopefully you're not using it for a tight loop's index, so optimization of a raw pointer shouldn't be so critical anyway.  Most of the time, you're dealing with char, int, structs, and pointers to the same.  In those cases, the code you compile probably can't get any more optimized.  (Just ask the guys in the 1 Minute thread.)

Anyway, Java is pretty big, and if it's going to be unseated, it won't be by Python.  For e.g., the US government relies on Java pretty heavily for web services and such.  No one's going to be tossing out all that enterprisey app server stuff for a scripting language.  C'mon...

[Howardlong]

I learned computing using Algol-60 on 5-channel paper tape. (Consider how you can represent digits, letters and symbols in 5 bits.)

Me too! On an Elliott 803. 8k words of 39 bits each. Hardware floating point. Ahhhhh....

I do Java and C# if I have to, but C is my real home.

[tggzzz]

I find it about as absurd to compare Python, Java, and C as it would be to compare a can opener, scissors, and chainsaw.

You are missing the point.

It is valid to compare those objects(languages), and particularly to compare aspects of those objects(languages), to understand the domain in which each object(language)is most appropriate.

Where somebody misunderstands objects(languages) features and characteristics, it can lead to misuse and choice of the wrong tool for the job at hand.

Giving up Bash scripting for Python is a good move.  Giving up C for Python is not.  Python is a scripting language, like Perl, and is really good for quick-n-dirty tasks, or minor applications.  For whatever reason it's the darling of developers right now, but you wouldn't write a device driver in Python, or a kernel, or an embedded application.  Wrong tool.

C is really the sweet spot between ASM and Java / Objective C / whatever, and despite a LOT of en-vogue languages coming and going through the years, it's still ubiquitous. 

In the past C really was a good choice for a very wide range of projects, but recently that range has been significantly reduced by more modern tools.

Unfortunately there is still a lot of crap legacy stuff written in C,  still some dinosaurs that think C is the best tool for most problems, and other dinosaurs that don't understand the liberating power of newer tools.

Yeah, void* can be a pain in the butt, however the times you use void* should be relatively few and far between.  And in such cases, there should be no obviously preferable way to handle it. It's a very sharp knife, so don't be careless with it.  Hopefully you're not using it for a tight loop's index, so optimization of a raw pointer shouldn't be so critical anyway.  Most of the time, you're dealing with char, int, structs, and pointers to the same.  In those cases, the code you compile probably can't get any more optimized.  (Just ask the guys in the 1 Minute thread.)

Often they are wrong about high optimisation: see the HP Dynamo project for why emulated C can be faster than -O2 and -O4 C running on the same processor. The techniques necessary to achieve that are applied automatically and invisibly to every program running in a standard HotSpot JVM. Key point: the C compiler has to be unnecessarily pessimistic because it can't prove there isn't any aliasing.

It is frequently necessary to ensure that the very sharp naked knives (which are often unwittingly left behind in projects) are covered by suitable guards/handles/covers/screens etc.

Anyway, Java is pretty big, and if it's going to be unseated, it won't be by Python.  For e.g., the US government relies on Java pretty heavily for web services and such.  No one's going to be tossing out all that enterprisey app server stuff for a scripting language.  C'mon...

Yup. Choose the right tool for the job at hand. But do understand the competitions strengths.

[tggzzz]

I learned computing using Algol-60 on 5-channel paper tape. (Consider how you can represent digits, letters and symbols in 5 bits.)

Me too! On an Elliott 803. 8k words of 39 bits each. Hardware floating point. Ahhhhh....

I do Java and C# if I have to, but C is my real home.

Snap! Minimum instruction time: 0.576ms i.e. ~2kIPS

I still have the opcode handbook and some audio tapes of it clucking like a broody hen when "fetching Algol", and playing tunes (very flat high notes!).

Must go to Bletchley sometime.