back to article Turing Award winner Barbara Liskov on CLU and why programming is still cool

It has been 12 years since Barbara Liskov won a Turing Award for her contributions to practical and theoretical foundations of programming language and system design, and these days the creator of the CLU programming language continues to work on some interesting problems. We spoke about innovation, abstraction and …

  1. Robert Carnegie Silver badge

    A Turing Award apparently resembles a science Nobel Prize in the time that you wait to get it. Reasons including that it may take a while for the world to realise that you've done something brilliant, and then, there's a queue. (Have they given a Turing Award for queues yet?)

  2. Tom 7 Silver badge

    Damn - missed her work when I was bootstrapping my programming!

    Might have saved me a lot of fuss - though I think I was using C on the shared vax780 so getting CLU might have been tricky. Remember writhing #include files with meaningful names for various lengths of asterixes in my OOP experiments in C. Now to spend the afternoon checking out her byzantine fault tolerance!

  3. Paul Hovnanian Silver badge

    Error handling

    Or you could just let the user fix them.

    1. ecofeco Silver badge

      Re: Error handling

      LOL. Right?

  4. vektorweg

    mumbo jumbo

    I used to code in C++ . In hindsight, its a bunch of mumbo jumbo.

    Attaching a method to a class is a feelgood exercise - humans just love grouping things. But what you gonna do if you have an operation on several types that are hierarchically unrelated to each other? Who's gonna get the method then? Your god object? Hard encapsulation is overrated. Look at functional programming: putting loosely related functions and data definitions into the same module file is just good enough for encapsulation's sake. With a proper type system in place, there's nothing that could break from that approach.

    Error handling is definitely a concern. Especially when the entire stack from software to hardware works on exceptions, which may leave undefined state left and right. However, you can still try to abstract away from these shortcomings in your applications. Like doing computation and exception handling in a monad stack - that's a FP thing too.

    1. Warm Braw

      Re: mumbo jumbo

      what you gonna do if you have an operation on several types that are hierarchically unrelated to each other

      That's why C++ has multiple inheritance - and languages like java and C# have interfaces.

      Most decent programmers were largely implementing the principles of object-oriented programming before it was a thing - the language features are just supposed to facilitate it. Unfortunately, it seems to have become radically theologised - though, as you imply, a number of its former adherents are now proselytes to FP: and there's no-one as devout as a convert...

      1. gnasher729 Silver badge

        Re: mumbo jumbo

        Does anyone use multiple inheritance? I know about classes implementing multiple interfaces, and I’ve seen multiple inheritance used 20 years ago, but today?

        1. doublelayer Silver badge

          Re: mumbo jumbo

          Since implementing multiple interfaces is the same concept that works in exactly the same way with a different name, yes they do. You've probably seen it because you primarily see code in a language using interfaces instead of inheritance for it, but those using C++ will still use multiple inheritance if that's the most convenient way of setting up the architecture.

          1. Warm Braw

            Re: mumbo jumbo

            With default methods having now shown up in both Java and C# interfaces, the distinction is becoming increasingly difficult to discern.

            I'm old enough for my early career to significantly pre-date C++, but I'm struck by the extent to which people who've been through college long after the advent of OOP can struggle with the basic concepts. I worry that programming has become "cool" in the same way as modern jazz: while many people acknowledge its intellectual rigour, few people actually understand it or want to listen to its practitioners.

    2. Anonymous Coward

      Re: mumbo jumbo

      C++ is a cargo-cult programming language: just because idea x is shit in C++ does not mean it is shit, because everything C++ touches turns into shit. Encapsulation does not solve all problems. But it does solve some, and i 1973 those problems needed solving, very badly.

    3. doublelayer Silver badge

      Re: mumbo jumbo

      "Error handling is definitely a concern. Especially when the entire stack from software to hardware works on exceptions, which may leave undefined state left and right."

      So you would prefer what, precisely? Exceptions are a lot less undefined than hoping the user remembers to check the return value every time for something indicating a deviation from the golden path. A function that calls a utility, checks that it returned correctly, and runs it with a different parameter if it receives a certain error is no different than one that catches an exception for the same result. It also means that, should my code be badly written and fail to catch the exception, it will either signal you in a way you can recover from anyway or at least you'll see what the problem is rather than dealing with my flawed attempt at recovery.

    4. Richard 12 Silver badge

      Re: mumbo jumbo

      Especially when the entire stack from software to hardware works on exceptions, which may leave undefined state left and right

      No, it may not. Any function/method that leaves undefined state around after a recoverable error is simply broken. All error signalling systems require this cleanup to be done, and exceptions make cleanup far easier because the language guarantees certain things will happen in a specific order when an exception is thrown.

      So you've actually got somewhere to put that cleanup - such as a destructor or "finally".

      You can write terrible code in any language.

      Irrecoverable errors are different of course, and again exceptions help there as it gives you a single global place to catch all irrecoverable errors and package up some kind of fault report so maybe you can make it recoverable in future, or avoid the irrecoverable state entirely.

    5. swm

      Re: mumbo jumbo

      When I was writing operating systems I realized that there were no errors. If a file can't be opened, read etc. the operating system just has to deal with it just as it has to deal with a successful file read.

      At Xerox, the copy machine software for a large copier was about 80% dealing with error conditions (jammed paper, out of paper etc.). A language that assumes the "main line" is important and has a special exception mechanism for errors, in my opinion, is broken. Error recovery is hard and the language should support it well over making the "main line" easy to code.

      Extensive testing of error conditions is hard but absolutely necessary.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like