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.'"

Comments

Re:Let the raging tardfight commence

[morgan_greywolf]

He should have used a real programming language like Java or VB.Net.

Pffft. Real men write programs like this:

$ cat >/bin/myprogram

Re:Let the raging tardfight commence

[jellomizer]

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)

I like the choice.

[DrWho520]

Use a masochistic language to break a German code...groovy.

ADA Resurgence?

[Arakageeta]

Has anyone else started to notice an ADA resurgence? I feel like several years ago the general feeling was "ADA is a backwards language used only on old military projects." Now I read a positive story about ADA every few weeks! Was ADA 2005 that good of a language revision?

Re:ADA Resurgence?

[Skeptical1]

Ada is not a backward language. Ada is a palindrome.

Re:ADA Resurgence?

[Barromind]

Ada 2005 is comparatively minor (although some changes, like interfaces, are not that minor). The real improvement was Ada 95. The 95 revision managed to standardize many things that C++/java are now settling.

Ada is not trendy, but it has had built-in portable concurrency and many other killer features for more than a decade. Proper specifications are one of my favs.

Of course there are other factors, like the lack of good and free compilers. Fortunately now the gcc toolchain has put this to rest. Also there are few libraries. Really few. Binding to C is easy, but still a deterrent for the hobbyist.

It's emphasis in making maintenance easy over quick programming really pays in the end, not even in the middle/long term but shortly after getting familiar with the language. I find myself much more productive. When something compiles, I'm sure that the only bugs remaining are logical, not some funny pointer or unexpected type conversion or overflow. Nowadays I rarely fire the debugger more than once a month. My C/C++ has improved because Ada forbids the things that are considered bad practices in C/C++, but you still end doing because "you know better".

I think that Ada is getting now more exposure because, albeit a niche language, Adacore is pushing hard behind it. Also, its SPARK derivative by Praxis has made some headlines with large and difficult projects getting flying marks. SPARK has made static analysis a reality for large projects.

I'd say that anyone capable of discipline will enjoy the benefits of Ada. It's not the thing for quick hacking, but it is perfect for anything not trivial. Software engineers should love it. I have heard somewhere that it is a safe C++, and I concur: feature-wise is more or less on par, it catches bugs sooner and prevents many typical ones.

Have I already said that concurrency is built-in and portable :P? And that inter-thread communication is really well done?

Compiler price..

[renoX]

I think that the main reason why Ada has 'lost' to C++ is that some time ago, C++ compiler were either cheap or free whereas Ada compiler were expensive.

Too bad since Ada is 'by default' a language which is more secure than C++..

other factors often dominate language choice

[_|()|\|]

Like the author of the article, I have a tendency to dabble with a variety of programming languages. I haven't used Ada seriously, but I am intrigued by it, especially in contrast to the looser languages that are currently popular. A lot of bytes have been spilled on the topic of static and dynamic typing, bondage & discipline vs. unit testing, etc. While these discussions often devolve to religious wars, I do think that language matters. Never mind Sapir-Whorf or Turing, some languages are simply more or less pleasurable or powerful for certain tasks.

That said, often the language itself is not the dominant factor in choosing the language. As nice as (Ada | Erlang | Haskell | Lisp | Ruby) is, it's not going to be my first choice if another language has a readily available library that will make it easier to write the program. I can write web applications in Lisp, but I probably won't. There is probably a parser generator for Ada, but I'd rather use Flex and Bison, or maybe ANTLR. And when it comes to my first choice, independent of problem domain, I'll usually pick Python, in part because of its extensive library.

Re:other factors often dominate language choice

[hey!]

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.

You couldn't BE more wrong

[MosesJones]

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?

Re:Concise??!!

[hey!]

I can't imagine using the words concise and Ada in the same sentence.

Perhaps you should read what you just wrote.

Re:Programmer not langauge.

[jellomizer]

Well it is more complex then that. Different language syntax can help or hinder someones performance for a particular job. For example old C didn't have much to say in terms of string handling if you wanted to use a string you needed to do a Char *VarName then when working with that languge you need to insure memory managment and that you don't create buffer overflows..... A big pain if you didn't make youself some good String functions you spend a lot of your programming just making sure your program doesn't blow up. vs. Newer Languges And the String class in C++ where you can concatinate get sub strings parse.... it makes doing such job much easier and a lot less anoying. Most well programed languges will not prevent you from getting anything done. However there is the Human element of the equasion if the syntax is to difficult for a particular job then the person will tire out and make more mistakes. The winner of this competition felt that ADA syntax offered him the ability to solve the problem better, thus helped him to win.

I have written Web Apps in FORTRAN 77 just to prove that you can. However I wouldn't say it would be OK to consult a client to do the same, as it really isn't the right tool for the job.

Horses for courses

[Viol8]

Its not really surprising that he found ADA nicer to use than C for this sort of project because its not the sort of thing C was created for. People seem to think that C was designed as an all purpose programming language - it wasn't. It was specifically designed as a systems programming language that could substitute for assembler 99% of the time. Its abilities lie in low level manupulation of memory and I/O , not in high level mathematics algorithms (though obviously it can do this too).

Then of course C++ came along which wanted to have its cake and eat it and the end result was a nasty mishmash of low and high level constructs which is difficult to learn , unintuitive and generally messy to use.