Colossus Cipher Challenge Winner On Ada
An anonymous reader writes "Colossus Cipher Challenge winner Joachim Schueth talks about why he settled on Ada as his language of choice to unravel a code transmitted from the Heinz Nixdorf Museum in Germany, from a Lorenz SZ42 Cipher machine (used by the German High Command to relay secret messages during the World War II). 'Ada allowed me to concisely express the algorithms I wanted to implement.'"
For the most part the language doesn't matter that much. ADA, C, C++, PASCAL, BASIC, LISP... Almost every languge can get the job done. It is just a matter on how well it handles different details. I like Python for its List Processing and Top Down Design. Some people like Visual Basic for its ease in creating good interfaces. Some people like C and C++ because they can control the system at a lower level.
ADA being a government/military based languge I am not to suprised that it won the competition decifering a goverment/military code. (it is more complex then that)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
What makes you think that Ada does not allow type conversion?
"typename(variable)" is pretty easy in my opinion...
(not much harder than the type cast in other languages: "(typename)variable")
Ada even has a package called Ada.Unchecked_Conversion if you don't care
about ensuring the result is within the bounds of the target type...
In 1997, producing small, fast executables for desktop and database client applications (Delphi's raison d’ètre) mattered a whole lot more than it does today. These days, it's generally far more important to use a tool that lets the programmer be very productive and to produce nice, maintainable code. Both of which Delphi does very well, mind you.
My blog
My blog
The programmer won the competition; not the language. He just happened to write it in Ada. Languages are nothing but syntax: none are "better" than anther at certain operations. Folks here /. apparently never learned that in school.
I can't imagine using the words concise and Ada in the same sentence.
Constricted - maybe. Painful - most certainly.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
As someone whose first programming language was Ada, and who knows of several universities around the same time who chose Ada as a teaching language, I can say with certainty that you are completely wrong.
First off those strict rules help you because you spend miles less time debugging stuff you don't understand, once it compiles it will tend to run and the compiler gives helpful messages about what you are doing wrong (often including suggestions on how to fix it). With Java, and especially C and C++, let alone scripting languages the beginner spends much more time debugging non-operational code than writing the code in the first place. This tends to mean that these people focus on "getting an executable" rather than "getting it running".
Ada is a brilliant language to teach newbies in (again I've personally done this) as you can explain the abstract concepts and then have the compiler make sure they are doing it right rather than have them say "it compiles but it keeps falling over, why?".
Ada's issues are due to the mentality of lots of (IMO) unprofessional engineers who focus on the number of characters over the operational viability of a system.
And for a final point. Take a look at the complex code the guy wrote, if that was in Java, C, C++, Scala, Ruby, Perl, LISP or what ever do you think that you'd have a chance of understanding it?
An Eye for an Eye will make the whole world blind - Gandhi
I only found out about the contest a couple of days before it began, and I was away at the time, so I
couldn't participate in "real time", but I used the
copies of the sent ciphertexts on the Bletchley
website.
I worked away on a lorenz breaker for the SZ42 stuff, written in C. I was able to break
ciphertext roughly an order of magnitude faster
than Joachims code. Joachim worked away on his code
for several weeks in advance of the contest. I had only a couple of days notice.
I think two things matter in a competition like
this:
o The *appropriateness* of the language
o The skills of the coder
Joachim got all the glory on this one, since he
was first to announce the breaks. But there are
probably a number of others who were "close"
when Joachim announced his break.
You only like VB.Net because you don't know C#.
Well libraries. That's a huge part of language choices these days; you really choose frameworks or libraries and live with the language as a consequence. A lot of what we do these days is glue stuff together.
This problem, however is a completely different kind of programming. It's old school stuff: building everything you need yourself to run on really slow hardware. And hardware is always slow relative to crypto problems. Ever try to implement RSA encryption from scratch? I have. There's a reason the public key stuff is only used for key exchange.
I think the usefulness of Ada on this kind of problem is related to the issue of testing being costly. When I started in this business, compiling and linking a two hundred line program took about fifteen minutes. Something like unit testing would have been utterly impractical. So a strictly typed language was for nearly everyone a good idea.
Over the last couple of years, I've been trying my hand at a number of difficult algorithmic problems. This is not the stuff that 99% of the programmers in the world do professionally, including me.
Working on these problems was like programming was in the old days. Not only was it just you and the problem with no frameworks to come between, every output becomes a milestone when it takes a program days to generate. It also means that the style of programming is different. You don't worry so much about language restrictions introducing frictional losses into the code/test/recode cycle. You do worry more about mistakes that make it past the compiler.
Ada's philosophy is that coding should be, if not exactly slower certainly more deliberate. If you are running something for which your hardware is monumentally slow, then this is a good style to work in.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
We should expect software to work correctly, and take our business elsewhere when it doesn't.
No one dies if your kitchen faucet squirts the water out sideways, but we don't just shrug it off and live with it.
Sheesh, evil *and* a jerk. -- Jade