Steele: Fortress - programming for supercomputers
KT
Video of Steele talking at JAOO and slides.
Frank Buss
The video works only for the first third part, then stops. But why do you
think a Lisp programmer would be interested in a statically typed language?
Fortress sounds a bit like a mix of Haskell and Java, with some nice
additional features, like extending the syntax, but this is possible with
Lisp macros, too. Maybe a good idea is to use a mathematical syntax, but
then operator overloading doesn't work very well with the Lisp philosophy
of dynamic typing and explicit programming (you write what you mean, e.g.
(concatenate 'string foo bar)), vs. implicit programming ((+ foo bar), and
then searching the type of foo and bar, and the meaning of #'+ in other
parts of the source code).
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Pertti Kellomäki
> But why do you
> think a Lisp programmer would be interested in a statically typed language?
Some of us are interested in what the author of "Common Lisp,
the Language" is up to nowadays.
--
Pertti
Pascal Costanza
Fortress is indeed targeted more at Java programmers than at users of
more advanced programming languages, but nevertheless, it has some
interesting ideas. Nothing earth-shattering, but nevertheless, I
wouldn't dismiss it too quickly...
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Frank Buss
> Some of us are interested in what the author of "Common Lisp,
> the Language" is up to nowadays.
Maybe he has learned something from the mistakes of the past and now
develops statically typed languages with type inference, like Haskell :-)
KT
> Fortress is indeed targeted more at Java programmers than at users of
> more advanced programming languages, but nevertheless, it has some
> interesting ideas. Nothing earth-shattering, but nevertheless, I
> wouldn't dismiss it too quickly...
>
> Pascal
Fortran: "To Do for Fortran What Java Did for C" is their motto. It is
targeted exclusively to Fortran programmers and scientific
supercomputing applications. I think the main interest is how Steele
and Co are going to succeed in integrating language features into
coherent whole. But if there is one person who has experience with
this kind of work, it is Steele.
The presentation is IMHO really good. Main themes I piked:
- Growing the language by experts using libraries, core fortress is
really small: objects and traits.
- Modularity. You can take out reals from core library and replace it
with your own implementation. It should still work with the rest of
the core library.
- Efficient abstractions with static and dynamic optimizations, type
inference.
- Parallelism is default (My first impression is that they are aiming
at MapReduce kind of functionality in the language level).
- They are going to experiment with mathematical syntax (emphasis on
experiment).
--
Pascal J. Bourguignon
> Pertti Kellomäki wrote:
>
>> Some of us are interested in what the author of "Common Lisp,
>> the Language" is up to nowadays.
>
> Maybe he has learned something from the mistakes of the past and now
> develops statically typed languages with type inference, like Haskell :-)
Or maybe he just couldn't find a CL job, and is happy to have landed a
job in the statically typed world, like most of us? :-)
--
__Pascal Bourguignon__
Rainer Joswig
He is a language designer. Besides his work on Scheme and Common Lisp,
he is known for a lot of things:
* co-wrote a book on C
* was involved in the ANSI C standard
* worked on High Performance Fortran (HPF)
* worked on Java, co-wrote the Java Spec
* worked on ECMAScript (JavaScript)
and more
For Lisp-interested people particularly interesting is
the Hacker's Dictionary (the Steele version from 1983).
smallpond
> - They are going to experiment with mathematical syntax (emphasis on
> experiment).
>
> --
It looks like I can dust off my APL keyboard.
Frank Buss
> Fortress is indeed targeted more at Java programmers than at users of
> more advanced programming languages, but nevertheless, it has some
> interesting ideas. Nothing earth-shattering, but nevertheless, I
> wouldn't dismiss it too quickly...
I watched the rest of the video (streaming worked after some hours again)
and looks like there are really some interesting ideas. I like the idea of
using a very small compiler and providing as much as possible in libraries,
with an integrated versioning system and allowing the programmer to replace
libraries with ones with higher performance or better memory usage etc. The
libraries even helps how to compile things like the reducers etc. at
runtime.
Sounds a bit complicated how it is interweaved, but I hope they'll release
the source code of anything to take a look at it.
Sohail Somani
Interesting video, thanks for posting it! I imagine he is trying not to
say "just like Common Lisp."
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani
I just noticed that he said "C standard library" when referring to the C+
+ standard library. Maybe he thinks C = C++.
Christopher Browne
Um, the primary Steele book that I keep on my desk that gets leafed
thru more often than pretty well anything else is _C - A Reference
Manual_. Extremely handy when looking for differences between
Unixes...
He is notable in history as a language designer, and has had
considerable involvement with *many* languages of different styles.
--
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://linuxdatabases.info/info/emacs.html
"The problem might possibly be to do with the fact that asm code
written for the x86 environment is, on other platforms, about as much
use as a pork pie at a Jewish wedding."- Andrew Gierth in
comp.unix.programmer
KT
> but I hope they'll release
> the source code of anything to take a look at it.
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
svn checkout http://fortress.sunsource.net/svn/fortress/trunk fortress
--username username
--
Ken Tilton
Rainer Joswig wrote:
> In article <7c8x2ol...@pbourguignon.anevia.com>,
> p...@informatimago.com (Pascal J. Bourguignon) wrote:
>
>
>>Frank Buss <f...@frank-buss.de> writes:
>>
>>
>>>Pertti Kellomäki wrote:
>>>
>>>
>>>>Some of us are interested in what the author of "Common Lisp,
>>>>the Language" is up to nowadays.
>>>
>>>Maybe he has learned something from the mistakes of the past and now
>>>develops statically typed languages with type inference, like Haskell :-)
That would explain the quote about Java having dragged people away from
C++. Towards Lisp. PWUAHAHAHAHHAHAAA!
>>
>>Or maybe he just couldn't find a CL job, and is happy to have landed a
>>job in the statically typed world, like most of us? :-)
Traitors all! To yourselves and to mankind, who needs Lisp! Starbucks is
hiring, programming is to sacred to compromise over.
>
>
> He is a language designer. Besides his work on Scheme and Common Lisp,
> he is known for a lot of things:
>
> * co-wrote a book on C
> * was involved in the ANSI C standard
> * worked on High Performance Fortran (HPF)
> * worked on Java, co-wrote the Java Spec
> * worked on ECMAScript (JavaScript)
And Constraints, a godawful mess as bad as Java.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
jimka
overloading
in C++ failed because there are not enough operators. Fortress allows
operator overloading but encourages using traditional notation using
the seemingly limitless set of unicode characters.
There are 50 years of computer programming notation evolution, but
there are 500
years of mathematical notation evolution.
most of our current notation comes from fortran, and fortran was first
done on keyboards designed for business, not for mathematics. Before
Fortran, Stelle said that the * character was used only once anywhere
in mathematics in one paper he could find. But Fortran convinced
us that * means multiply ... Whereas tradition dictates that
juxtaposing
is the traditional notation for multiplication.
He also distinguishes binding, from updating, from looping.
x := means i cannot change the variable
x = means updating a variable
x <- (actually the Unicode arrow) means streaming from a sequence
but order independent.
I must admit that the code samples he shows in the video are very
intuitive to read.
Tamas
I watched 20 minutes of that video, and now I am afraid I will have
nightmares when I go to bed.
A lot effort is spent on notation, only to come up with a really
baroque system. Version control in the libraries? (if I understood
that right). Seen on a slide at 21:57: "Repeat the success of the
Java Virtual Machine." Indeed.
This seems like another language designed for "somebody else" by a
committee; in this case the audience seems to be engineers who use
Fortran. But that misses the point: very few people use Fortan
because they love it so much, they use it because a lot of (legacy)
code and reasonably good compilers are available, and it is the status
quo anyway in some communities. Yeah, static type checking of
physical units is the thing we have been missing all these years.
About math: mathematical notation is great, but most of it is ad hoc
and context-dependent (compare the role of the superscripts in
\sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x)), that is one reason it is so
useful: you can write it quickly, and the context is usually obvious
for humans who understand the semantics behind the syntax. But for
programming, math notation becomes a nightmare.
Tamas
tim Josling
> About math: mathematical notation is great, but most of it is ad hoc
> and context-dependent (compare the role of the superscripts in
> \sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x)), that is one reason it is so
> useful: you can write it quickly, and the context is usually obvious
> for humans who understand the semantics behind the syntax. But for
> programming, math notation becomes a nightmare.
>
> Tamas
Yes, and I don't want code to be as hard to read as math texts or papers.
One-character variable names, etc...
Tim Josling
Sohail Somani
> Yes, and I don't want code to be as hard to read as math texts or
> papers. One-character variable names, etc...
Fortran code is full of one character variable names. One time I was
reading some code and was convinced it was computer generated as there
was no way a human could follow that. I asked around and sure enough, it
was hand written.
So Fortran programmers would be right at home!
Pascal Costanza
> With all due respect to GLS (and lots due!), I believe his position is
> one of lending credibility to the committees he sits on, based on the
> authority from earlier original work.
I briefly talked to Guy Steele about Fortress at last year's OOPSLA. He
is definitely convinced that it's a good thing, it's not just politics.
(He was also open in the past about his involvement with Java, which
apparently was indeed more just a 'job', and not so much a passion.)
Geoffrey Summerhayes
> On Fri, 18 Jan 2008 03:24:18 +0000, tim Josling wrote:
> > Yes, and I don't want code to be as hard to read as math texts or
> > papers. One-character variable names, etc...
>
> Fortran code is full of one character variable names. One time I was
> reading some code and was convinced it was computer generated as there
> was no way a human could follow that. I asked around and sure enough, it
> was hand written.
You missed an interesting era. We weren't trying to be obscure,
just trying to fit the damn programs onto 80-column punch cards.
Nothing like tripping and playing a game of 52-pickup * 1000.
> So Fortran programmers would be right at home!
:)
--
Geoff
Alex Mizrahi
T> love it so much, they use it because a lot of (legacy) code and
T> reasonably good compilers are available, and it is the status quo anyway
T> in some communities.
you have something wrong with your logic.
yes, people HAVE to use FORTRAN because they cannot find language to replace
it.
but FORTRAN is UGLY.
what should we do? make something that can replace FORTRAN and is less ugly.
seems logical, right?
as for me, i've found Fortress exciting, both syntax and features.
i'm only afraid they won't be able to make a good implementation for it, as
it appears to be quite complex..
Alex Mizrahi
M> those single implementation languages, whose slice of the market pie Sun
M> was so keen to bite into :)
let's take another example of great Language Designer who have made the most
popular language for internets:
----
PHP was written as a set of Common Gateway Interface (CGI) binaries in the C
programming language by the Danish/Greenlandic programmer Rasmus Lerdorf in
1994, to replace a small set of Perl scripts he had been using to maintain
his personal homepage.[3] Lerdorf initially created PHP to display his
résumé and to collect certain data, such as how much traffic his page was
receiving. Personal Home Page Tools was publicly released on 8 June 1995
after Lerdorf combined it with his own Form Interpreter to create PHP/FI
(this release is considered PHP version 2).
Zeev Suraski and Andi Gutmans, two Israeli developers at the Technion IIT,
rewrote the parser in 1997 and formed the base of PHP 3, changing the
language's name to the recursive initialism PHP: Hypertext Preprocessor.
----
this guy knew absolutely nothing about language design. he have just hacked
simpliest interpeter for a perl-like syntax.
semantics were simply shocking weird. 9 years and 4 major version after
(each version introducing incompatible changes, of course), it still looks
like an inconsistent and buggy bullshit.
but many people like it..
author's skills were not in effect here. the key to success of PHP was a
large group of amateur wannabe web programmers who have found a use for a
small and easy programming language that suited well their unsophisticated
needs like forums and guestbooks. it's quite understandable that big
companies and serious people were not addressing needs of this group.
but, you know, mathematicians is quite different group of people. they won't
be satisfied with some amateurish constructs, and languages with one bright
feature won't suit them.
programming language for mathematicians working with high performance
computing should be carefully designed by experienced and sane people.
viper-2
I don't think that FORTRAN is unreadable. It's just that we have
become so inured to Lisp's ability to be self-documenting that we have
lost patience with perceived "lesser" languages. :-)
Here are a couple of simple FORTRAN subroutines (included here not for
the code value but in reference to the readability issue) from my 1983
Engineering Honours thesis "Interactive Computer Package
Demonstrating: Sampling Convolution and the FFT":
SUBROUTINE AFUN(F1,F2,K,AT)
COMMON NB,NP,T,M,P,TL,Y
DIMENSION F(1024), F1(1024), F2(1024), AT(1024)
CHARACTER*24 TP,A
4 IF (K.EQ.1) TP="TIME FUNCTION"
IF (K.EQ.2) TP="TIME FUNCTION1"
2 CALL GETPRM(TP,A,R)
IF(A.EQ."J") CALL SI(NB,Y,T,F,AT,£1)
IF(A.EQ."K") CALL CO(NB,Y,T,F,AT,£1)
IF(A.EQ."L") CALL TRI(NB,NP,T,P,F,AT,M,TL,£1)
IF(A.EQ."M") CALL RECT(NB,NP,T,P,F,AT,M,TL,£1)
IF(A.EQ."N") CALL EXPO(NB,T,F,AT,£1)
IF(A.EQ."O") CALL STEP(0,NB,T,F,AT,£1)
IF(A.EQ."P") CALL RAMP(NB,T,F,AT,£1)
PRINT,"ERROR!!CODE NOT IN EXPECTED RANGE. TRY AGAIN."
IF (K.LE.2) GOTO 4
IF (K.LE.3) GOTO 5
1 CONTINUE
DO 10 I = 1,NB
IF (K.LE.2) F1(I)=F(I)
IF (K.LE.2) PRINT,F1(I)
IF (K.EQ.3) F2(I)=F(I)
IF (K.EQ.3) PRINT,F2(I)
10 CONTINUE
K=K+1
IF (K.EQ.2) GOTO 3
IF (K.EQ.3) GOTO 5
IF (K.EQ.4) GOTO 3
5 TP="TIME FUNCTION2"
GOTO 2
3 DO 6 I = 1,NB
6 CONTINUE
RETURN
END
SUBROUTINE SI(NB,Y,T,F,AT,*)
DIMENSION F(1024), AT(1024)
DO 10 I = 1,NB
J=I-1
F(I)=(SIN(Y*J*T))
AT(I)=J*T
10 CONTINUE
RETURN1
END
There seemed to have been no problem with reading the code. In fact,
it was so well read that the "University "in question excluded my
thesis from my academic record, used it to give someone else a PhD,
and apparently exploited my program for commercial use in Europe's
North Sea oil industry. The doctoral award was rescinded only in 2003
in consequence of my submission of evidence of authorship and repeated
demands since my discovery of the fraud in 1996.
In the package, which comprised a main program and 21 subroutines, I
used the Fast Fourier Transform (FFT) to demonstrate the convolution
of signals, which I generated from library functions (e.g. "sin x" as
above) and by subroutines that I authored to generate periodic
triangular, rectangular, and other signals. I also coded a pair of
subroutines to graph the convolution of signals of finite length,
since the project was intended for use as a teaching aid in
communications theory.
I plan, in the near future, to implement features from computer vision
using Lisp interfaced with C or FORTRAN to do the actual number
crunching because of considerations of speed. Naturally, I've been
wondering what offerings Fortress will bring to the table since I have
the (possibly misguided) impression that with the advent of C, people
use FORTRAN mainly because of the huge code bases of that language
already in existence.
The FORTRAN FAQ:
http://www.faqs.org/faqs/fortran-faq/
suggests that the FORTRAN v C debate is aimless, but is it really -
especially with Fortress in sight?
agt
John Thingstad
<visi...@mail.infochan.com>:
Ugh..
This code looks like it's from the 60's. You know of Fortran77 and beyond?
> Naturally, I've been
> wondering what offerings Fortress will bring to the table since I have
> the (possibly misguided) impression that with the advent of C, people
> use FORTRAN mainly because of the huge code bases of that language
> already in existence.
Not entirely because of the code base. FORTRAN is faster for numerical
computation on most architectures.
C is optimized for integer computing. All float libraries are of type
double. This means that if you only need float precision you have to
convert to double and then back to float. Thus you miss out on the numeric
processors ability to run small floats in parallel. This can give 30% or
so speed increase. In general numeric operations are more optimized in
FORTRAN.
--------------
John Thingstad
David Golden
> yes, people HAVE to use FORTRAN because they cannot find language to
> replace it.
> but FORTRAN is UGLY.
Well. It's not the prettiest ever, but do bear in mind that, somewhat
like Lisp vs. LISP of yore, Fortran itself has moved on a bit from the
days of FORTRAN 77.
viper-2
> På Fri, 18 Jan 2008 19:28:39 +0100, skrev viper-2
>
> Ugh..
> This code looks like it's from the 60's. You know of Fortran77 and beyond?
John, this should have been FORTRAN 77.
> Not entirely because of the code base. FORTRAN is faster for numerical
> computation on most architectures.
> C is optimized for integer computing.
Thanks, I'll be looking into the problem of speed - and deciding on
the best approach.
agt
jimka
> About math: mathematical notation is great, but most of it is ad hoc
> and context-dependent (compare the role of the superscripts in
> \sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x)), that is one reason it is so
> useful: you can write it quickly, and the context is usually obvious
> for humans who understand the semantics behind the syntax. But for
> programming, math notation becomes a nightmare.
>
> Tamas
I don't think that is the claim he is making... infact just the
opposite.
He says using characters like \sin^2(x)+\cos^2(x)=1 and \cos^{-1}(x))
to represent math is something we got from fortran because it was done
on a limited keyboard of 100 keys or so. from fortran we got the idea
that math should be representable in ascii characters, whereas 500
years of mathematics tradition leads us nowhere near that conclusion.
mathematicians and physicists invent new notation all the time because
it
makes their work easier and clearer.
jimka
> Yes, and I don't want code to be as hard to read as math texts or papers.
> One-character variable names, etc...
>
it seems like from the video that the goal is not to let people
who don't know math all of a sudden be mathematicians. But rather
let mathematicians. and physicists write programs without having
to be programmers.
in languages like lisp and fortran, single variable names cause
difficulty
because their only characteristic is their ascii code. It seems like
Steele is saying that single character variable names which are
overloaded
with font, size, position (superscription/subscription) and chosen for
a
very large alphabet can actually be more meaningful.
I saw a video where sussman uses the lambda character in his lectures
because
he thought it was more descriptive than writing out LAMBDA every
time. the symbol
for PI is actually more descriptive that the word "PI" and a italics e
with an
x superscript is more convincing as an exponential then (exp x) or
exp(x)
tim Josling
Apart from the issue with double/single precision that were mentioned,
Fortran has assumptions about aliasing that allow for more aggressive
optimization than C is allowed to do. I think C90 has some declarations
that allow the programmer to declare that certain things are not aliases
of each other, but by default the compiler still has to assume that
different parameters to a subroutine may be aliases, which slows things
down a lot.
Tim Josling
jimka
As I understand, this is in-the-end left up to the library
implementor,
not as part of the language. When you define a new operator or
overload an existing one, you can set the precedence to other
operators. He said this is possible, but won't be the
convention. It is SUGGESTED that you only use precedence rules
which already exists in tradition. (indeed curious whether
programmers will obey that guideline)
But there are two new concepts.
1. Precedence rules ARE NOT transative.
If you overload / * and + with / higher than *
and * higher than +, that does not make / automatically
higher than +.
2. The other concept is that not all precedence rules are defined.
Ones that are not explicitly defined are ambiguous and the
compiler will refuse to compile it until you insert the
correct parentheses.
viper-2
> On Jan 18, 3:06 pm, "John Thingstad" <jpth...@online.no> wrote:
> > Ugh..
> > This code looks like it's from the 60's. You know of Fortran77 and beyond?
>
> John, this should have been FORTRAN 77.
I should have added that while I have a habit of teaching myself
(sometimes from ancient books :-)) the character data type used in the
third line of subroutine AFUN:
CHARACTER*24 TP,A
was introduced by FORTRAN 77.
This was a tip I picked up, right at the beginning, from the
University's GinoGraf expert that was invaluable for building the
program's interactivity. Thanks again Jim Mitchell!!
agt
John Thingstad
<visi...@mail.infochan.com>:
You are probibly right.
Take a look at these coding exaples to see how FORTRAN has evolved to it's
current form
Fortran 2003.
http://en.wikibooks.org/wiki/Fortran/Fortran_examples
--------------
John Thingstad
Andreas Davour
In relation to think it might be worth while to remember one of the most
common objections to lisp; that it's ugly and unreadable because of the
parenthesises. Ugly is in the eye of the beholder.
I personally find Fortran and Lisp both to be clear and understandable,
which I e.g. don't find C and C++ to be (or Java).
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
viper-2
> Take a look at these coding exaples to see how FORTRAN has evolved to it's
> current form
> Fortran 2003.
>
> http://en.wikibooks.org/wiki/Fortran/Fortran_examples
The evolution is indeed striking - almost Darwinian.:-)
But it seems that Fortress may be poised to leave FORTRAN behind in
the cosmic dust. It certainly shows promise in HPC with its
parallelism by default. It might be just what is needed for the kind
of precision required in real time vision applications.
agt
David Golden
> But it seems that Fortress may be poised to leave FORTRAN behind in
> the cosmic dust. It certainly shows promise in HPC with its
> parallelism by default.
Not quite the same thing, but Fortran 2008 will apparently be including
co-arrays as a standard parallelism model, though of course fortran HPC
folk are well used to MPI message-passing and OpenMP too:
ftp://ftp.nag.co.uk/sc22wg5/N1651-N1700/N1669.pdf
(co-arrays might be idly interesting for people looking at parallelism
models for lisp, he said, trying to appear on-topic).
Andreas Davour
> David Golden <david....@oceanfree.net> writes:
>
>> Alex Mizrahi wrote:
>>
>>> yes, people HAVE to use FORTRAN because they cannot find language to
>>> replace it.
>>> but FORTRAN is UGLY.
>>
>> Well. It's not the prettiest ever, but do bear in mind that, somewhat
>> like Lisp vs. LISP of yore, Fortran itself has moved on a bit from the
>> days of FORTRAN 77.
>
> In relation to think it might be worth while to remember one of the most
> common objections to lisp; that it's ugly and unreadable because of the
> parenthesises. Ugly is in the eye of the beholder.
>
> I personally find Fortran and Lisp both to be clear and understandable,
> which I e.g. don't find C and C++ to be (or Java).
What is this? Am I getting dyslectic or is it demetia? That looked
perfectly alright when I posted it.
Again.
It might be worth remembering, that the most common problem people seem
to have with Lisp is that it is ugly. That is, they think it look ugly
with all those parenthesises. Ugly is in the eye of the beholder.
Now, just wait for that to get all messed up when I press C-c C-c and
it's distributed all over the world...
/Andreas
Tamas
> Another interesting concept seems to be the idea of precedence rules.
> As I understand, this is in-the-end left up to the library
> implementor,
> not as part of the language. When you define a new operator or
> overload an existing one, you can set the precedence to other
> operators. He said this is possible, but won't be the
> convention. It is SUGGESTED that you only use precedence rules
> which already exists in tradition. (indeed curious whether
> programmers will obey that guideline)
>
> But there are two new concepts.
> 1. Precedence rules ARE NOT transative.
> If you overload / * and + with / higher than *
> and * higher than +, that does not make / automatically
> higher than +.
Looks like debugging errors resulting from precedence rules will
provide hours of good, clean fun for Fortress users. Unicode makes it
even better, as there are more symbols in it.
Tamas
dr2chase
> On Jan 17, 10:26 pm, Frank Buss <f...@frank-buss.de> wrote:
>
> > but I hope they'll release
> > the source code of anything to take a look at it.
This link is far more current:
svn checkout http://projectfortress.sun.com/svn/Community/trunk PFC
It's a Trac project