Resurrection Time?

Resurrection Time?

Summary: So what's wrong with APL? it fits Sun's CMT like a glove, is easily understood andused by the science community, and allows for simple results publication andverification. For real problems you'd need a petaflop machine, but so what? That'swhat they're building

TOPICS: Hardware
Sun has a large group led by Guy Steele working on a language called "Fortress" -something they describe as "Java for scientists, Java for the programmers of a peta-scale supercomputer."

Java started out as a hardware abstraction layer for set top TV boxes aimed at using the TV to provide internet access and became wildly popular because people thought the same abstraction could be effectively applied to reduce the impact of Microsoft's perpetual client changes. That turned out, eventually, to be sort of true - but only if Java first moved onto the server and that, of course, drove its strategic role at Sun. Great, but since Microsoft doesn't have a presense in super computing, there's no need to build a Java like kludge there.

This isn't to say that there isn't a niche for a new programming language aimed at helping scientists make better use of super computers, there is. Right now that niche is filled mainly by Fortran and C, or C++, at the traditional applications level and Maple and Mathematica at the desktop level.

I've used both Fortran and C fairly extensively, and tried both Maple and Mathematica under Solaris as recently as last year. Of these C seems ridiculously undervalued these days, Fortran was obsolete in the sixties, and both Maple and Mathematica are so absurdly PC centric in everything they do that they're not worth a nickel for work big enough to need a Unix workstation.

I've recently been trying to understand, however, how to build an application that would make truly effective use of the four way threading in Niagara's cores to get from 11Ghz (8 cores x 1.4 Ghz) to 44.8 (32 x 1.4) on chunks of C and C++ code. As part of the digging around that's occassioned, I came across a comment Donald Knuth made about APL in a 1993 interview with Dan Doernberg


DD: I realize your current emphasis is on "literate programming", but were you ever whatsoever attracted to APL as a math-oriented language?

Knuth: That's another story. APL is for people who have problems to solve and don't care too much about efficiency; they want a nice elegant way to state the solution to their problem, but the solution that they come up with is not necessarily anything that a computer has an easy job doing. It's a problem specification language, but not a system programming language... .

That's a wicked response - but it's also quite reasonable in the context of the time.

On the other hand, it's dated - those hardware limitations are long gone. Even in 1993, a 32MB APL workspace was worthy of comment. Today a Sun V890z workstation can deliver nearly 64GB of real workspace and a virtual infinity of memory mapped virtual space for less than two hundred thousand bucks - and tomorrow's Niagara and Rock systems will bring those costs down to the affordable desktop level.

So what's wrong with APL? it fits Sun's CMT like a glove, is easily understood and used by the science community, and allows for simple results publication and verification. For real problems you'd need a petaflop machine, but so what? That's what they're building.

Topic: Hardware

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Time for some new approaches certainly

    I will say right away I am in no position to comment on scientific programming.

    However, I am growing more and more convinced that the dominance of functional-procedural languages needs to be overthrown. They really haven't met the promises they have made and have severely hampered the development of more generic approaches to programming. When a C, C++ or Java programmer sees a problem their immediate response is to throw a problem specific function or method at it, we have thus ended up with impenetrable forests of classes, methods and functions as exemplified in the various foundation classes for Java and C++ and of course in the Windows API.

    It would I think be a much more interesting and useful project for Sun to implement an imperative, declarative language as a complementary alternative to Java. Chris Date and Hugh Darwen's Tutorial D springs to mind as the most obvious candidate. There is no Unix implementation available as yet.

    The field of logic programming has been very sadly neglected and D offers data definition and manipulation, rule definition and event handling all in one language. It is certainly an example of a language where you can concentrate very clearly on the problem you have to solve and not on the technical intricacies of the computer.

    Furthermore D has a very strong mathematical basis in predicate logic. You might say that the methods it uses have been under test for longer than computers have existed, so I think this is a tool we can trust.

    People against the proliferation of programming languages agree with you that using and existing language like APL is MUCH preferable to developing a new one. PAPPL members are fed up with the never-ending stream of new specialty-languages. (supposed) Ease of use has trumpeted ease of education, as new languages and accompanying learning curves are introduced - because existing languages are not - quite - perfect, at the - specific - task - that is being targeted. Whatever happened to "if it ain't broke . . ."?
    Roger Ramjet
    • Yes, general purpose languages are required

      We might bear in mind however that in order to use C++, Java or C# programmers now need to learn literally thousands of classes and methods and the situation is getting worse all the time.

      The learning curve is now as steep as learning the vocabulary of a foreign natural language.

      I think there is a great deal of room for work on more generic programming methods than those offered by the functional approach embodied in C and its descendents.

      And wasn't Ned Ludd a fully paid up member of PAPPL ;-)?
    • Normally, I would agree

      But Date and Darwen's D is definitely different enough from what we have a present to warrant being introduced as a new programming language.

      Interestingly their definition of D is a logical definition of the language, you can implement it syntactically however you wish.
  • Edsger Dijkstra

    was almost as damning about APL as he was about COBOL. This certainly dampens my enthusiasm somewhat.
    • Wasn't he

      the guy that killed the GOTO statement (except for VB!)? Didn't he also propose that all programs can be written with just 3 data structures - sets, stacks and queues?
      Roger Ramjet
      • Structured programming

        Edsger Dijkstra invented it. As a physicist by academic background he also staged a lifelong struggle to bring more scientific and mathematical rigour into computer science (if only he had been more successful).

        Regarding goto, it exists in C and (whisper it) in Java too (though its use is somewhat restricted by the language).

        It is also possible to write programs in COBOL completely without using goto. I have written several dozen myself.

        But I think the next step after getting rid of goto is to get rid of loops and you need a different kind of programming language to do that.
  • Resurection???

    Not familiar with the term.
    • Me neither

      Ooops, spell check? what's that? sometimes I forget - sorry.
  • Why D would be right for Sun

    1. A great many of Sun's customers are running SQL DBMSs.

    D has been specifically designed as a truly relational replacement for SQL. However Date and Darwen are wise enough to know that SQL will be around for a while to come and the language has been made as far as possible compatible with the SQL legacy (though for obvious reasons tables without primary keys cannot be supported in D).

    As Java has proved an extremely clumsy fit to SQL DBMSs D would have a big advantage here.

    2. D is designed not only to replace SQL but also to replace host languages for accessing DBMSs. Therefore there would be no need for Java and SQL or COBOL and SQL, D alone would do the job. Also, as a declarative language D can do most things with considerably less code than is possible in Java.

    3. Date and Darwen have defined the only coherent fusion of object-orienated and relational approaches that I have yet read.

    4. D has been designed by one of the foremost theoreticians in the RDBMS world and one of IBM's leading language designers, so its pedigree is excellent.

    5. Sun are not yet in the DBMS market. Though a first implementation of D might well be as middleware on top of existing SQL DBMSs there would be nothing to stop Sun developing a native D DBMS. The additional functionality and reliability provided by a true implementation of the relation model (as opposed to the severely compromised implementation in SQL) would be enough to give Oracle, IBM and Microsoft serious pause for thought. The existing players in the DBMS market are too heavily invested in their existing platforms and in SQL to make this kind of revolutionary step.

    6. In a very loose way D is a natural extension of the Unix way of thinking. In Unix everything is stream of bytes. Unix utilities take a stream of bytes as input and deliver a stream of bytes as output.

    You could say (again very loosely) that D takes this idea to a higher level of abstraction by doing the same thing with data rather than merely at the physical level of bytes.

    In D, you might say, everything is a relation. The product of any relational operator is another relation. Therefore any D expression can contain any number of levels of nesting of expressions. This effectively eliminates the need for the kind of clumsy iterative methods like stored procedures required in SQL.

    7. There is at present no Unix implemenation of D.

    Chris Date was interviewed recently on the O'Reilly web site
    • Sounds sensible

      I don't know enough about "D" to have a strong feeling either way on it's appropriateness, but I certainly agree that an RDBMS fits the CMT model, that SQL is terrible, and that SUn could benefit enormously by creating or leading a high end RDBMS development effort aimed at its own hardware first and everyone else's second.
      • The full potential of RDBMS

        is far from being fully realised.

        Given the feebleness of current implementations it is easy to forget that a DBMS that truly implemented the relational model would be far more than just a means of storing data. The RDBMS, properly implemented, is a logical inferencing engine and its use can remove a great deal of complexity (and coding).