FP tutorial for OO programmers?
Brandon J. Van Every
Standard ML. I'm looking for a no-nonsense, practical, concise, results
oriented tutorial that explains:
1) how to do things in FP that people typically do, or think they need to
do, in OO.
2) how to design FP programs that use underlying OO libraries.
I am not looking for airy fairy theoretical articles about the supposed
advantages of FP. The real world is not usually clean slate architecture:
one ends up running into OO libraries and OO programmers. For instance read
"Why no one uses functional languages."
http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal
There's clearly a problem of paradigm shift here. So, what are the
pragmatic solutions?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
Gour
> I am not looking for airy fairy theoretical articles about the supposed
> advantages of FP. The real world is not usually clean slate architecture:
> one ends up running into OO libraries and OO programmers. For instance
> read "Why no one uses functional languages."
> http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal
Is it possible to download this article for free somewhere?
Sincerely,
Gour
--
Gour | go...@mail.inet.hr
Registered Linux User | #278493
GPG Public Key | 8C44EDCD
I R T
>> advantages of FP. The real world is not usually clean slate architecture:
>> one ends up running into OO libraries and OO programmers. For instance
>> read "Why no one uses functional languages."
>> http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal
>
> Is it possible to download this article for free somewhere?
Google is your friend...
www2-data.informatik.unibw-muenchen.de/ Lectures/FP/sigplan-why.pdf
Gour
Thanks. I've found this version googling, but thought it's some shorted
version since the one on portal.acm.org says it's around 500K, but maybe
it's just complete journal issue.
Patrick Philippot
> example, Standard ML. I'm looking for a no-nonsense, practical,
> concise, results oriented tutorial that explains:
Hi Brandon,
I'm currently facing the same problem. I'm in charge of a rather
complicated, real-world, SML project (actually an SML .Net project) and
I have tried to find articles and books that could help me understand
the language and understand the source code I have to maintain. I didn't
find anything really helpful. Everything that has been written about SML
has been written by scientists for scientists, or rather by
mathematicians for mathematicians. SML *is* a language for researchers
and scientists, and as such it certainly does the job. But it's
certainly not a production tool for mainstream applications (this is
just my opinion and I'm not saying that SML is a "bad" language, though)
I found only one book : ML for the working programmer, Paulson,
Cambridge University Press
Although it's certainly a good book, I couldn't use it to solve the
practical problems I had (still have) understanding the project's code.
I also found a limited number of web sites:
http://www.dcs.napier.ac.uk/course-notes/sml/manual.html
http://www.dcs.ed.ac.uk/home/stg/NOTES/
http://www.lfcs.inf.ed.ac.uk/software/ML/
http://sml.sourceforge.net/Basis/
http://www.smlnj.org//index.html
http://burks.bton.ac.uk/burks/language/ml/
But this didn't solve my problems either.
I'd like to add the following comments too:
- SML is *extremely* difficult to debug and retro-document. Even though
SML .Net is better than the standard tools because Visual Studio .Net
provides some support for debugging, it's almost impossible to
understand and analyze existing code by stepping through it. The
recursive nature of SML makes this very difficult.
- I tried to find some support on Usenet. I found 2 newsgroups:
comp.lang.functional and comp.lang.ml. The level of activity in these
groups makes me wonder how much developers are using the language. You
can't produce without support and obviously, support for SML is scarce.
- Beside the compiler and the standard libraries, it's hard to find
tools that could help program and maintain SML code in a productive way.
For example, I needed a source code beautifier to reformat the SML
source code that I received from my customer. Such a tool just doesn't
exist (Emacs has an SML mode but this is clearly not enough - and after
all, we are now in the 21th century and don't see any good reason for
using Emacs - well, ok, I'm a Windows developer :-)) ). The only advice
that I got about this issue was: "It's easy to find an MSL parser and to
add code behind it to produce reformatted source code". I agree
(actually, I had the same idea), but my concern is productivity. This
answer is technically correct but typical from a researcher. I have
deadlines to meet, however. So I spent two days reformatting the code
manually.
- I'm still trying to understand what can be done in SML (or with any
functional programming language) that I couldn't do with an OOP language
that has introspection capabilities. Although I read a lot of documents,
I didn't find any feature in SML that has no equivalent in the OOP
world.
- About 20 years ago, when I was still working at IBM, I had to write
code using the APL language. A very powerful language with a big
drawback: when you go back to your code 10 days after you've written it,
you have difficulties understanding what you wanted to do at that time.
I have the exact same feeling with SML. So imagine when you've *not*
written the code yourself.
- Someone told me that the OCaml language was better supported (OCaml is
the OO version of Caml). This is not my feeling (not much books, only
one newsgroup).
For these reasons, an although I'm trying hard to analyze this SML code,
I'm considering switching to an OOP language and rewriting the code from
the specs using C#.
Greetings from Paris.
PS: I have spent a week in Seattle 2 months ago. Nice city.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Brandon J. Van Every
>
> I also found a limited number of web sites:
Thanks for the links, and I feel your pain.
> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language. You
> can't produce without support and obviously, support for SML is
> scarce.
I think mailing list archives are a fairer test.
SML/NJ's archive is puny.
https://sourceforge.net/mailarchive/forum.php?forum_id=10073
MLton's archive is a little better, but still quiet.
http://www.mlton.org/pipermail/mlton-user/
OCaml's is robust.
http://caml.inria.fr/caml-list-eng.html
I had forgotten about the "community viability" problem because OCaml has a
viable community. Hrm. Well, the reality is right now *I* have to write my
code, not a community. What I really want is OCaml with 32-bit ints, 32-bit
floats, and a straightforward C FFI. But I fear the amount of work I'd have
to do to implement that (quite possibly beyond my skills), and also that the
changes wouldn't ever make it into the official OCaml.
> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP
> language that has introspection capabilities. Although I read a lot
> of documents, I didn't find any feature in SML that has no equivalent
> in the OOP world.
My problem is actually the other way around. I want to understand how to do
FP, dispensing with anything I thought I needed OOP for.
> Greetings from Paris.
> PS: I have spent a week in Seattle 2 months ago. Nice city.
Yes, especially right now in the summer! I did a 14 week stretch in Paris
one summer, great city.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Joachim Durchholz
>
> - SML is *extremely* difficult to debug and retro-document. Even
> though SML .Net is better than the standard tools because Visual
> Studio .Net provides some support for debugging, it's almost
> impossible to understand and analyze existing code by stepping
> through it. The recursive nature of SML makes this very difficult.
>
> code using the APL language. A very powerful language with a big
> drawback: when you go back to your code 10 days after you've written
> it, you have difficulties understanding what you wanted to do at that
> time. I have the exact same feeling with SML. So imagine when you've
> *not* written the code yourself.
This is a question of being used to the standard idioms.
I had the same difficulties initially. After a while, I found myself
documenting less and less, and "seeing through" the idioms more and more.
> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language.
> You can't produce without support and obviously, support for SML is
> scarce.
Agreed.
There's currently no "large developer base".
> - Beside the compiler and the standard libraries, it's hard to find
> tools that could help program and maintain SML code in a productive
> way. For example, I needed a source code beautifier to reformat the
> SML source code that I received from my customer. Such a tool just
> doesn't exist (Emacs has an SML mode but this is clearly not enough -
> and after all, we are now in the 21th century and don't see any good
> reason for using Emacs - well, ok, I'm a Windows developer :-)) ).
> The only advice that I got about this issue was: "It's easy to find
> an MSL parser and to add code behind it to produce reformatted source
> code". I agree (actually, I had the same idea), but my concern is
> productivity. This answer is technically correct but typical from a
> researcher. I have deadlines to meet, however. So I spent two days
> reformatting the code manually.
Writing a beautifier shouldn't have taken more than 2 days either :-)
... with the understanding that it takes a full day to find an SML
parser and understand how to use the hooks that need to be used for
producing formatted output, so there's a full day left to write the
actual beautifier.
(Heck, I've done this kind of work as a kid, and it didn't take me more
than a day using an imperative language. I didn't have to do a full
parse though, so I added the day - as such estimates go, your mileage
will certainly vary considerably.)
Of course, it would have been better to have a formatter readily available.
> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP
> language that has introspection capabilities. Although I read a lot
> of documents, I didn't find any feature in SML that has no equivalent
> in the OOP world.
Closures.
I.e. the ability to take two functions submitted as parameters, place
the call to one of them in the parameter position of another one (if the
functions had N and M parameters, this gives me a new function of N+M-1
parameters), fill in a few other parameter positions with values, and
then return the whole thing so that other parts of the program execute
it if and when they need it.
Oh, and the ability to write down an expression that uses locals, and
return the entire thing - those locals are transferred into the closure
so that it will still work long after the function that houses the
expressions has finished running.
Java's inner classes can be used to mimick closures, though in an
extremely cumbersome way. (Closures were proposed as an alternative, and
were rejected on the basis that inner classes are "more OO".
Technically, they were right, but closures would still have been far,
far easier to use for event handlers and such.)
Of course, you can also construct a closure using a class. You "just"
need to write about 50 lines to handle class syntax, constructor, and an
"execute" function that houses the expression proper. Oh, and find a
good name for the class, write the JavaDoc stuff, make a unit test -
what's a single line of code not even worthy a second thought in a
functional language takes two full days in an OO language.
There's a more indirect advantage.
The more restricted a piece of code is, the easier it is to read - you
have less assumptions to check when it comes to understand why it does
what it does.
FPLs don't overwrite data (usually), so if you're chasing a bug, you
don't have to check your assumptions whether some data stays the same,
sparing you a lot of thought and and code-sifting effort.
Just my 2c.
Regards,
Jo
Matthias Blume
> SML/NJ's archive is puny.
> https://sourceforge.net/mailarchive/forum.php?forum_id=10073
That's because we are not using it. We have a separate development
mailing list. It's address is posted on www.smlnj.org.
Matthias
Thant Tessman
> Patrick Philippot wrote:
[...]
>> - I'm still trying to understand what can be done in SML (or with any
>> functional programming language) that I couldn't do with an OOP
>> language that has introspection capabilities. Although I read a lot of
>> documents, I didn't find any feature in SML that has no equivalent
>> in the OOP world.
>
>
> Closures. [...]
When I was learning Scheme, the first thing I did was build two or three
object systems to prove to myself I could live with the language. I
eventually came to realize that the tools I used to build these object
systems (higher-order functions by way of closures) were by far the more
powerful concept.
Also, I will add that what SML gives me that neither Scheme nor C++ has
given me is a type system so well-designed that if a program compiles,
it very likely just works. This may be contradicted by the experiences
of Patrick Philippot, but the whole concept of SML .net hurts my brain.
-thant
Brandon J. Van Every
Ok, here's the problem. Your web page says you have a new mailing list
hosted by SourceForge. Those of us experienced with SourceForge, assumes
that means the mailing list is accessible and archived from its SourceForge
project page. 2 mailing lists are given: smlnj-commits and smlnj-list. I
would point out that the list given by scanned image on the website is not
listed on the SourceForge page, and that I didn't notice this in the course
of events. Maybe that's by deliberate design to defeat spammers, but you've
also created obscurity for people trying to determine the viability of
SML/NJ. It's not like the homepage is extensive or looks like a big user
community, so maybe X% of people stop looking when they 'accidentally'
peruse a (seemingly empty) mailing list archive.
I think if you boldly highlighted all relevant info about hunting and
pecking the mailing list, in its own clearly defined header section rather
than a line interspersed in a list of other stuff, it would alleviate the
problem.
You might also put something about how to find the 'secret' mailing list on
the SourceForge project page.
Also, do you archive the 'secret' mailing list? Not being able to
immediately view an archive reduces the radar profile of a shopped-for
language. I can't, for instance, quickly determine the health of the SML/NJ
community. Maybe you will have obscure mailserv commands I can use, if I
have knowledge of such arcane technologies and am willing to futz with them
(i.e. more barriers). Maybe you won't.
At least you are here though, so that's a partial antidote.
Brandon J. Van Every
>
> pecking the mailing list, in its own clearly defined header section
> rather than a line interspersed in a list of other stuff, it would
> alleviate the problem.
Incidentally, you also have no instructions about how to subscribe to the
list. Those of us who know about these technologies will try things like
"subscribe" in the header and the body of the message, seeing as how you
could be using either schema. I just sent one of those, but I have not
gotten any kind of an immediate reply message. This could mean either your
mail server is slow, you hand moderate all replies, your mail server is
broken, or there's some double secret SourceForge subscribing mechanism I
wouldn't initially think about. It seems I won't know until 'later',
whenever that turns out to be. More futz factors to keep people, not just
spammers, away from SML/NJ.
It is also not a good sign that apparently these problems have been allowed
to persist for some time. I don't know how much time, whether you moved
over to a new mailing list a week ago or a year ago. www.smlnj.org shows
Copyright 2003 on its various webpages, right by where it says the 'secret'
mailing list address. Maybe you in fact just changed over last week, but in
a higher volume community, I believe these problems would have been noticed
and addressed right away.
Dirk Thierbach
> - SML is *extremely* difficult to debug and retro-document. Even though
> SML .Net is better than the standard tools because Visual Studio .Net
> provides some support for debugging, it's almost impossible to
> understand and analyze existing code by stepping through it. The
> recursive nature of SML makes this very difficult.
Like everything, it's a matter of getting used to a certain style.
An advantage of functional programs is that they don't have side
effects; so you can test each of the old functions in isolation.
Also, just looking at the type some the function often gives a lot
of information about what it is supposed to to.
> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language.
Try asking here or in clm, and see if the answers help you. There are
also mailing lists (not sure about SML, but certainly for the other FP
languages).
> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP language
> that has introspection capabilities.
All languages are Turing complete, so every language can do everything
else another language can. But some things work better in FP than in
OO, and lots of programs are a lot shorter in FP.
> For these reasons, an although I'm trying hard to analyze this SML code,
> I'm considering switching to an OOP language and rewriting the code from
> the specs using C#.
As with everything, there is a learning curve, for OOP and for FP.
Somebody who hasn't been trained in OOP will have as much trouble
with your code as you have with the FP code.
Still, a rewrite might be the better alternative, if you are having
a hard time switching to FP thinking, and if it's a one-time job.
But if you do have the specs, the SML code shouldn't be so hard to figure
out...
- Dirk
Simon Helsen
>> - I'm still trying to understand what can be done in SML (or with any
>> functional programming language) that I couldn't do with an OOP
>> language that has introspection capabilities. Although I read a lot of
>> documents, I didn't find any feature in SML that has no equivalent
>> in the OOP world.
>
>
> Closures.
While I am sympathetic for Phillipe's problems (SML or Ocaml are simply
not up to widespread industrial usage - the few exceptions are in fact
companies founded by former language designers and researchers), I have
to reject what Joachim is saying. Closures are readily available in
Smalltalk under the name of blocks and behave virtually identical. They
are in no way unique to FP and are not contradictory to OO, so arguably
this is not a feature that augments SML.
What is really different between OO and FP is that the formers focuses
on an extensible datatype model, whereas the latter focuses on
side-effect free expressions. That is no "theoretical" notion, but has
tremendous practical consequences in program development and debugging
(for good and for bad if you throw in lazyness). Now, mind you, to date,
this has not been quantified properly and the statement is based on
personal experiences in the two paradigms. Also, in a purely functional
style, having first-class functions (aka closures) is pretty much a
must-have!
What is likely the more distinguishing feature of Standard ML is its
functors. There is no OO-language to date that has a similar powerful
module concept, except for mixin-based languages. They are, however,
even rarer than SML.
As for a practical point of view, I would not even think of starting a
real-world project ("real world" simply means 1) hard deadlines and 2)
real money down the line) in SML or Ocaml unless I can do it in
isolation (just me and maybe a few other FP-savy programmers), do not
have to rely on the product a few years down the line (you never know if
your compiler will still be around, and less so, if there are
programmers who can follow-up what you did), and do not require too much
interdependencies with other software written in other environments and
languages (interoperability is often restricted, unreliable, or
experimental). Of course, it is hard to imagine a real-world project
that satifies these constraints.
> Java's inner classes can be used to mimick closures, though in an
> extremely cumbersome way. (Closures were proposed as an alternative, and
> were rejected on the basis that inner classes are "more OO".
> Technically, they were right, but closures would still have been far,
> far easier to use for event handlers and such.)
While I agree, you have to be careful. The ability to override methods
in inner-classes extends their ability in comparison with a normal
closure and this idiom is very common in Java. I am not sure if I
actually like it because it makes the spagethi even worse...
> Of course, you can also construct a closure using a class. You "just"
> need to write about 50 lines to handle class syntax, constructor, and an
> "execute" function that houses the expression proper. Oh, and find a
> good name for the class, write the JavaDoc stuff, make a unit test -
> what's a single line of code not even worthy a second thought in a
> functional language takes two full days in an OO language.
>
>
> There's a more indirect advantage.
> The more restricted a piece of code is, the easier it is to read - you
> have less assumptions to check when it comes to understand why it does
> what it does.
> FPLs don't overwrite data (usually), so if you're chasing a bug, you
> don't have to check your assumptions whether some data stays the same,
> sparing you a lot of thought and and code-sifting effort.
That is of course the other side of the coin. The single-most
problematic thing I am currently experiencing while writing OO is that I
never know what has been overridden where and I am almost permanently
lost in bizarrly interacting class-hierarchies. This may well be my lack
of experience but I seriously doubt that this increases error-shy
programming. In fact, I darely need an IDE like Eclipse to help me find
my way in just about any OO program. With good old SML, (X)emacs will do
the job.
Regards,
Simon
Andreas Rossberg
>
>> Java's inner classes can be used to mimick closures, though in an
>> extremely cumbersome way. (Closures were proposed as an alternative, and
>> were rejected on the basis that inner classes are "more OO".
>> Technically, they were right, but closures would still have been far,
>> far easier to use for event handlers and such.)
>
> While I agree, you have to be careful. The ability to override methods
> in inner-classes extends their ability in comparison with a normal
> closure and this idiom is very common in Java. I am not sure if I
> actually like it because it makes the spagethi even worse...
On the other hand, Java's inner classes are not closures. They cannot
capture variables from surrounding scope. That makes them almost useless.
Last time I looked something along these lines was proposed for C#, but
required pretty ad-hoc rules for variable life-time, because variables
are not first-class as they are in ML or other impure FPLs.
- Andreas
--
Andreas Rossberg, ross...@ps.uni-sb.de
Let's get rid of those possible thingies! -- TB
Brandon J. Van Every
>
> As for a practical point of view, I would not even think of starting a
> real-world project ("real world" simply means 1) hard deadlines and 2)
> real money down the line) in SML or Ocaml unless I can do it in
> isolation (just me and maybe a few other FP-savy programmers), do not
> have to rely on the product a few years down the line (you never know
> if your compiler will still be around, and less so, if there are
> programmers who can follow-up what you did), and do not require too
> much interdependencies with other software written in other
> environments and languages (interoperability is often restricted,
> unreliable, or experimental). Of course, it is hard to imagine a
> real-world project that satifies these constraints.
An indie game project with a small, sharp team fits the bill. :-)
> That is of course the other side of the coin. The single-most
> problematic thing I am currently experiencing while writing OO is
> that I never know what has been overridden where and I am almost
> permanently lost in bizarrly interacting class-hierarchies. This may
> well be my lack of experience but I seriously doubt that this
> increases error-shy programming. In fact, I darely need an IDE like
> Eclipse to help me find my way in just about any OO program. With
> good old SML, (X)emacs will do the job.
In my own designs, which were for rendering planetary geometry, I found
myself spending too much time creating OO abstractions at too fine a grain.
I was thinking in terms of all my objects being reusable components, so that
I could build up more complicated geometric operations. But, ultimately
this severe degree of 'bottom up' coding was not justifiable. It would tend
to be confusing and somewhat error prone to spread functionality across a 3-
or 4-deep object hierarchy. It would usually not be quite the right design.
Relationships of ownership and invocation were often problematic, i.e. ISA
vs. USES. I conclude, oddly enough, that inheritance at too fine a grain
actually violates encapsulation. I would have been better off making my
objects much more coarse, not trying to reuse them, and simply rewriting
them wholesale when/if they proved to be inadequate in their design.
Because of my negative practical experiences with OO, I'm more open to other
paradigms, such as FP. I really don't believe all the FPers bullshit about
how great it's supposed to make life, however. It's all theoretical
handwaving, I see no evidence of proven utility. FP's failure to capture
industry mindshare is clear enough. Rather, I take a modest view that FP is
probably useful for something, and probably not any more harmful than OO.
In particular, FP may be a better fit to some of my 3D graphics and AI
problems, if not all of them.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every
>
> Incidentally, you also have no instructions about how to subscribe to
> the list.
After 48 hours of receiving no reply, I correctly guessed that a *-request
suffix was needed to get anything to happen. My 1st post is going to be
about how invisible the list is to people.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Simon Helsen
> Simon Helsen wrote:
>
>>
>>> Java's inner classes can be used to mimick closures, though in an
>>> extremely cumbersome way. (Closures were proposed as an alternative, and
>>> were rejected on the basis that inner classes are "more OO".
>>> Technically, they were right, but closures would still have been far,
>>> far easier to use for event handlers and such.)
>>
>>
>> While I agree, you have to be careful. The ability to override methods
>> in inner-classes extends their ability in comparison with a normal
>> closure and this idiom is very common in Java. I am not sure if I
>> actually like it because it makes the spagethi even worse...
>
>
> On the other hand, Java's inner classes are not closures. They cannot
> capture variables from surrounding scope. That makes them almost useless.
I think you have relativate this a little-bit.
1) There is entirely normal lexical scoping for "fields" of
encapsulating classes for both inner and local classes.
2) For local variables (and parameters, etc), yes, they have to be final
(i.e. normal bindings) for them to be available in the inner class. This
is because javac makes a copy of the used local variable. A trick to get
around that is to create an array with the rhs as its element and of
course, each reference to it in the local block has to access the local
variable via the array element. While ackward, it behaves like a
closure. In fact, this is not so different from what happens in SML.
Only in Java, there is no such thing as a ref constructor, so you have
to use an array for that instead.
I do not see what you mean by "that makes them useless".
If you would try (bad idea) to program entirely functional in Java, you
do not want destructive updates, so you just as well may define your
local bindings as final. If you want to be imperative in SML you have to
use ref, so use array in Java (with bloated syntax, I agree). Finally,
if you program in an OO fashion in Java (quite likely!) you do not face
these problems in the first place. Local variable updates in the local
class are not likely and enclosing field updates, being most common, are
allowed.
> because variables are not first-class as they are in ML or other impure FPLs.
What do you mean by variables are (or are not) first-class? Could you
explain exactly what the difference is here? The only difference I see
is that SML (like all impure FPLs) makes a distinction between bindings
(by default) and assignments (requiring extra syntax). In Java, that
happens "the other way around" by having assignments by default and
bindings by annotation.
Simon
Thant Tessman
[...]
> What is likely the more distinguishing feature of Standard ML is its
> functors. There is no OO-language to date that has a similar powerful
> module concept, except for mixin-based languages. They are, however,
> even rarer than SML.
There is much in this post I disagree with, but the only claim I want to
respond to is this one. I've become convinced that there is a similarity
between SML's functors and C++'s templates that is not captured by a
traditional taxonomy of programming language features. In fact, I think
C++'s templates are superior to SML's functors (not counting syntax). I
still think SML is by far the superior language on the whole, and
functors are one of the reasons why. But they're not *the* reason why.
-thant
Matthias Blume
> Brandon J. Van Every wrote:
> >
> > Incidentally, you also have no instructions about how to subscribe to
> > the list.
>
> After 48 hours of receiving no reply, I correctly guessed that a *-request
> suffix was needed to get anything to happen. My 1st post is going to be
> about how invisible the list is to people.
The list is not supposed to be public. It is for developers, and if
you want to become one, you could have asked to be put on the list
nicely (if you can't figure out how to do it yourself).
So don't bother telling us about it. It is going to be a waste of
everybody's time.
(In case you didn't notice: Yes, I am a bit ticked off right now at
the tone of your previous 3 or 4 articles regarding the SML/NJ
development process.)
Matthias
Simon Helsen
> There is much in this post I disagree with, but the only claim I want to
> respond to is this one. I've become convinced that there is a similarity
> between SML's functors and C++'s templates that is not captured by a
> traditional taxonomy of programming language features. In fact, I think
> C++'s templates are superior to SML's functors (not counting syntax). I
> still think SML is by far the superior language on the whole, and
> functors are one of the reasons why. But they're not *the* reason why.
I agree that there are some similarities between SML functors and C++
templates. In fact, indirectly, these have been documented (there are
papers describing dependently typed problems with functors and many use
templates for meta-programming. Needless to say, dependent type systems
and meta-programming are very akin).
If you disagree so much, could you please qualify yourself? Also, SML
may well be superior as a programming language (in fact, I am strongly
on your side there), it is simply not practical enough for the reasons
mentioned in my earlier post (And there are others -> someone already
referred to Phil Wadler's column).
Simon
Stefan Axelsson
> handwaving, I see no evidence of proven utility. FP's failure to capture
> industry mindshare is clear enough.
I guess this is where we wave the Erlang flag again?
(http://www.erlang.org). I'd say there's quite some evidence of proven
utility there. Within Ericsson alone we have two *major* products both
very successfull in their fields (market leaders). And those aren't the
only ones.
While we also like to think that this is because of how nice and
competent people we are :-) We also like to plug Erlang itself as a
contributory factor.
Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Joachim Durchholz
>
> creating OO abstractions at too fine a grain. I was thinking in terms
> of all my objects being reusable components, so that I could build up
> more complicated geometric operations. But, ultimately this severe
> degree of 'bottom up' coding was not justifiable. It would tend to
> be confusing and somewhat error prone to spread functionality across
> a 3- or 4-deep object hierarchy. It would usually not be quite the
> right design. Relationships of ownership and invocation were often
> problematic, i.e. ISA vs. USES.
This is the standard staple of design problems in OO.
Welcome to the club ;-)
> I conclude, oddly enough, that inheritance at too fine a grain
> actually violates encapsulation.
Actually inheritance violates encapsulation regardless of how you use
it: after all, the inheriting class has access to all the internal
machinery of all of its ancestors. (Unless that machinery is
"protected", but that comes with its own set of problems and limitations.)
> I would have been better off making my objects much more coarse, not
> trying to reuse them, and simply rewriting them wholesale when/if
> they proved to be inadequate in their design.
Reusable code requires throwing away at least two perfectly working (but
not-so-reusable) designs. I think that's one of the promises that OO
failed to deliver on.
> Because of my negative practical experiences with OO, I'm more open
> to other paradigms, such as FP. I really don't believe all the FPers
> bullshit about how great it's supposed to make life, however. It's
> all theoretical handwaving, I see no evidence of proven utility.
Hey, try it or leave it. Ranting is going to neither improve the
state of affairs, nor make anybody more willing to help you out.
You're in a very real danger of building a self-fulfilling prophecy here.
Not that I don't share your opinion that most FPLs still lack the
support you can get for other languages. It's just that academia gets
funding for researching new stuff, not for grunt work - and providing
all that support is indeed grunt work with little place left for research.
If you think that programming languages should be advanced into a state
of usability, write to your parliamentary representative and propose
funding for that...
Regards,
Jo
Joachim Durchholz
> Brandon J. Van Every wrote:
>
>> It's all theoretical handwaving, I see no evidence of proven
>> utility. FP's failure to capture industry mindshare is clear
>> enough.
>
> I guess this is where we wave the Erlang flag again?
> (http://www.erlang.org). I'd say there's quite some evidence of
> proven utility there. Within Ericsson alone we have two *major*
> products both very successfull in their fields (market leaders). And
> those aren't the only ones.
>
> While we also like to think that this is because of how nice and
> competent people we are :-) We also like to plug Erlang itself as a
> contributory factor.
I have to put an ounce of salt into that.
While Erlang is all nice and dandy for the kind of environments it was
written for, it doesn't work very well if some of the basic assumptions
are wrong.
For example, my idea was to use it in a client-server setting. In that
setting, the special advantages of Erlang (network-transparent message
passing between Erlang processes) vanished: there was no way to identify
and authenticate Erlang processes, functions in a closure sent as a
message are identified by name (creating all sorts of havoc if versions
come into play), and (the final straw) there's an easy way to overflow
an internal table of the server with a DoS attack.
For the record: I like Erlang quite a bit. There's a lot of good support
available for it. It should work very well in any environment where a
known set of CPUs must interoperate for a relatively well-defined
overall task.
Regards,
Jo
Matthias Blume
[...]
> I found only one book : ML for the working programmer, Paulson,
^^^^^^^^^^^^^^^^^^^^^
[...]
> http://www.smlnj.org//index.html
^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
> But this didn't solve my problems either.
You didn't read past the front page of these web site(s), did you?
On the SML/NJ front page you find a section on "Documentation and
Literature". The links lead to information on no less than 9
tutorials and 19 books. Admittedly, quite a few of them aren't what
you are currently looking for, but to say that you weren't able to
locate more than one book is a joke.
> I'd like to add the following comments too:
>
> - SML is *extremely* difficult to debug and retro-document.
How much experience do you have with the language? If you are still
hunting for books that explain it to you, I guess not that much. If
that is indeed so, and given that programming in SML feels quite
different than programming in any of the languages that you do know
(meaning that you can't just guess your way through), I am not
surprised at all that you find it difficult to debug and document SML
code written by others. But that has nothing to do with the language
itself.
> Even though SML .Net is better than the standard tools because
> Visual Studio .Net provides some support for debugging, it's almost
> impossible to understand and analyze existing code by stepping
> through it. The recursive nature of SML makes this very difficult.
I find the idea of trying to understand a program by "stepping through
it" mind-bogglingly ill-conceived (in *any* language).
> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language. You
> can't produce without support and obviously, support for SML is scarce.
Instead of ranting here about the lack of support, why did you not try
asking a specific question? Some people here do try to answer such
questions! Pissing them off right from the start doesn't sound like a
great strategy. (Not to mention the fact that a low level of quality
traffic is much preferable to the kind of thing that goes on in some
of those "more active" groups...)
> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP language
> that has introspection capabilities. Although I read a lot of documents,
> I didn't find any feature in SML that has no equivalent in the OOP
> world.
Of course, that is not the point. As others have pointed out,
programming languages tend to be equally expressive if you gloss over
the amount of work that is required to emulate one style of
programming with another. There is (much) more to good language
design than just a pile of features. The question should not be
whether one *can* do it, but rather how easy it is, how natural it is,
how scalable the approach is, how maintainable the results are, etc.
Unfortunately, even reading one or two books won't help you. In the
end it takes considerable practical experience to appreciate the
benefits (if there are any) of "switching" from one language to
another.
(In language design, less is often more. The fact that you mention
"introspection facilities" when comparing FP to OO speaks volumes.)
> - About 20 years ago, when I was still working at IBM, I had to write
> code using the APL language. A very powerful language with a big
> drawback: when you go back to your code 10 days after you've written it,
> you have difficulties understanding what you wanted to do at that time.
> I have the exact same feeling with SML. So imagine when you've *not*
> written the code yourself.
I don't have this feeling about SML code at all. (You may have
guessed that already. :-) I have written several tens of thousands of
lines of SML code which I can still maintain (after years of not
looking at certain portions). I have also worked on code several
magnitudes larger -- and written by others. The community of people
who wrote this code was and is fairly loosely knit, so it is not
nearly as well organized as you might expect from a successful program
of that size. I give huge credit to the language for the (amazing)
fact that one can succesfully work on such code at all.
> - Someone told me that the OCaml language was better supported (OCaml is
> the OO version of Caml). This is not my feeling (not much books, only
> one newsgroup).
Support is not the same as books and newsgroups.
> For these reasons, an although I'm trying hard to analyze this SML code,
> I'm considering switching to an OOP language and rewriting the code from
> the specs using C#.
Good luck! (My suggestion -- and I am not kidding -- would be to
consider rewriting the code from the spec using _SML_. This way you
get a chance to learn more of the language, you can concertrate on the
problem and don't have to learn both a language and someone else's
solution to a problem at the same time. And when you get stuck, you
even have a piece of "reference" code, the value of which -- over time
-- you will perhaps begin to appreciate as well.)
Matthias
Matthias Blume
> Your web page says you have a new mailing list
> hosted by SourceForge. Those of us experienced with SourceForge, assumes
> that means the mailing list is accessible and archived from its SourceForge
> project page.
I don't understand how you come to such an assumption. (Granted, our
SourceForge presence -- if we decide to stick with it -- could use
some work. But SML/NJ is much older than SF, and we use SF mainly to
host the CVS repository now.)
> 2 mailing lists are given: smlnj-commits and smlnj-list. I
> would point out that the list given by scanned image on the website is not
> listed on the SourceForge page, and that I didn't notice this in the course
> of events. Maybe that's by deliberate design to defeat spammers,
No "maybe". Our web page says so quite clearly.
> but you've also created obscurity for people trying to determine the
> viability of SML/NJ.
No, we have not "created" obscurity. Our main presence on the web is
not the SF page. Just because we did not post the list name there
does not mean we are more "obscure" than before. (Plus, our home page
-- including the address in question -- is only one click away from
the SF project page.)
Matthias
Ketil Malde
> As for a practical point of view, I would not even think of starting a
> real-world project ("real world" simply means 1) hard deadlines
I agree, but only for the reason of being able to say 'look at all
these other projects using <imperative langauge>, they are late too'
instead of taking the blame for using weird tools. I don't think
there's any evidence of FP programs being delivered in a less timely
fashion, and I'd expect the opposite.
> Of course, it is hard to imagine a real-world project that satifies
> these constraints.
I probably don't live in what you consider the real world anyway.
> That is of course the other side of the coin. The single-most
> problematic thing I am currently experiencing while writing OO is that
> I never know what has been overridden where and I am almost
> permanently lost in bizarrly interacting class-hierarchies. This may
> well be my lack of experience
The it's my lack of experience also - you accurately describe my main
gripe against OO. It's not so hard to see why; FP is just a more
elegant form of structured programming, it focuses on the breakdown of
programs by control flow. OO focuses on breakdown by data structure,
and consequently, control flow becomes more difficult to track.
OO was invented to solve problems that were control flow breakdown was
difficult to do (simulation), but it has gone from there to domination
in all areas, also where the fit is less good.
IMHO.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Stefan Axelsson
> I have to put an ounce of salt into that.
As always YMMV.
> For example, my idea was to use it in a client-server setting. In that
> setting, the special advantages of Erlang (network-transparent message
> passing between Erlang processes) vanished: there was no way to identify
> and authenticate Erlang processes, functions in a closure sent as a
> message are identified by name (creating all sorts of havoc if versions
> come into play), and (the final straw) there's an easy way to overflow
> an internal table of the server with a DoS attack.
Yes as my area of research is computer security you don't have to tell
me. However, as you say it's really outside the design parameters.
Erlang IMHO would still make a useful tool for that setting when one
recognises that it's really designed to build tightly (well on the lose
end but still) systems. If you used Erlang for the server using the
intrinsic network transparency to implement redundancy etc. and used or
implemented standard protocols for authentication etc it would still be
a win. (And IMHO this is where one wants to follow someone else. It's
all too easy to get a security protocol wrong.)
Within Ericsson itself we don't (typically) use Erlang over the wire as
the protocols over which we need to communicate are standardised, and
there are a lot of them to boot. As a result of being developed for that
environment I'd still say that Erlang is (perhaps) more useful than most
other languages as it's easy to implement a protocol stack for almost
any protocol in Erlang given the library support etc. As a for instance:
the SNMP bug that bit almost all of our competitors (really the rest of
the world) a few years back didn't have any effect on us. The reason was
that the rest of the world had just incorporated the Berkley SNMP
parsing code into their products (one would assume since
reimplementation was considered prohibitive). Not so with the Erlang
stack, which contains its own very much short and sweet SNMP stack.
Being implemented in Erlang it didn't suffer from the typical buffer
overruns that plagued the other implementations (implementation?).
So I'd say that Erlang is well suited to the client server application,
but not applied in the naive (perhaps: straightforward?) fashion.
> For the record: I like Erlang quite a bit. There's a lot of good support
> available for it. It should work very well in any environment where a
> known set of CPUs must interoperate for a relatively well-defined
> overall task.
Incidentally. I'm in the static typing camp myself, so I'm a bit guarded
in my praise. Still it's better than the alternatives. :-)
Brandon J. Van Every
because of it.
Matthias Blume wrote:
> (In case you didn't notice: Yes, I am a bit ticked off right now at
> the tone of your previous 3 or 4 articles regarding the SML/NJ
> development process.)
I know nothing about your SML/NJ development process. Could be the best in
the world, but frankly, how would I know? My comments are about your
mailing list interface and your lack of a Googleable public archive. I
definitely infer some things about the size of the SML/NJ community from
that though.
Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> writes:
>
>> Your web page says you have a new mailing list
>> hosted by SourceForge. Those of us experienced with SourceForge,
>> assumes that means the mailing list is accessible and archived from
>> its SourceForge project page.
>
> I don't understand how you come to such an assumption.
"We have switched over to a new mailing list hosted by SourceForge. The name
of the new list is [image of -dev- mailing list name]."
Why do you bother to advertize your 'new' mailing list as "hosted by
SourceForge" if you do not expect people to access it by standard
SourceForge interfaces? In the quote above, you don't even link to your
specific SourceForge project. You link to SourceForge in general. People
may very well infer that they can get to the SML/NJ mailing list from the
SourceForge top level. They would be wrong. They might not notice the
error at all, as the contextual transition from SML/NJ homepage to
SourceForge homepage to SML/NJ SourceForge project page is at least 3 steps
if not more.
Meta question: do you understand the open source culture of Source Forge?
All the project activity metrics? If you have some project with an
apparently dead mailing list, people assume your project doesn't have any
life to it. In your quest to be rid of spam, you are negatively advertizing
SML/NJ.
How about this redraft:
"Our current mailing list is [image of new sourceforge mailing list]. The
old mailing list, smlnj...@lists.sourceforge.net, is no longer being used.
Please be advised that to prevent spam, the current mailing list is not
listed on our SourceForge project page. To subscribe, please send an e-mail
to [image of new sourceforge mailing list *-request address] with the word
"subscribe" in the body of the message."
And a hint on the SourceForge project page, like "Warning! This is a
spamtrap. See www.smlnj.org for details."
>> but you've also created obscurity for people trying to determine the
>> viability of SML/NJ.
>
> No, we have not "created" obscurity. Our main presence on the web is
> not the SF page. Just because we did not post the list name there
> does not mean we are more "obscure" than before.
Before *what* ?
> (Plus, our home page
> -- including the address in question -- is only one click away from
> the SF project page.)
Bottom line:
- no subscription instructions
- no public archive
You are obscure. The fixes are trivial.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Brandon J. Van Every
> Brandon J. Van Every wrote:
>> It's all theoretical
>> handwaving, I see no evidence of proven utility. FP's failure to
>> capture industry mindshare is clear enough.
>
> I guess this is where we wave the Erlang flag again?
> (http://www.erlang.org).
L'excepcion qui preuve la regle!
I'd be interested in Erlang if I was writing a Massively Multiplayer Online
Game (MMOG), but I'm not. Also I'm not sure if Erlang is proving something
about Functional languages or *Concurrent* languages.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
I spy
"Ketil Malde" <ke...@ii.uib.no> wrote in message
news:egacywq...@havengel.ii.uib.no...
> The it's my lack of experience also - you accurately describe my main
> gripe against OO. It's not so hard to see why; FP is just a more
> elegant form of structured programming, it focuses on the breakdown of
> programs by control flow. OO focuses on breakdown by data structure,
> and consequently, control flow becomes more difficult to track.
structure. Whoever taught that was probably from a dataflow or DB
background. True there is a superficial similarity between tables and
classes but the similarity ends there. OO is about *non hierarchical*
breakdown of control. In traditional stepwise refinement you take a problem
to be solved and define a function/procedure for it whichi is is then
refined into subprocedures. In OO you identify classes and allocate
responsibilities for part of the task to each of the classes (Of course the
classes should have meaningful coherent responsibilities - one reason why OO
doesn't make much sense in solving small problems or algorithmic problems).
Then the classes cooperate to get the task done. They might even use
implicit invocation (events) to acheive it.
Of course despite what some people might be saying in this thread, there is
no real reason why functional programming and OO design cannot be used
together to mutual benefit.
cheers
-sri
Brandon J. Van Every
> Brandon J. Van Every wrote:
>>
>> I conclude, oddly enough, that inheritance at too fine a grain
>> actually violates encapsulation.
>
> Actually inheritance violates encapsulation regardless of how you use
> it: after all, the inheriting class has access to all the internal
> machinery of all of its ancestors. (Unless that machinery is
> "protected", but that comes with its own set of problems and
> limitations.)
False. Try implementing 'Private' machinery.
> Reusable code requires throwing away at least two perfectly working
> (but not-so-reusable) designs. I think that's one of the promises
> that OO failed to deliver on.
Well, I can't get a design right until I've done it 6 times. It starts
becoming somewhat like it should be after 3 passes, so I suppose our
experiences agree.
>> Because of my negative practical experiences with OO, I'm more open
>> to other paradigms, such as FP. I really don't believe all the FPers
>> bullshit about how great it's supposed to make life, however. It's
>> all theoretical handwaving, I see no evidence of proven utility.
>
> Hey, try it or leave it. Ranting is going to neither improve the
> state of affairs, nor make anybody more willing to help you out.
The comments generated from my previous queries, or such a barb, are already
as much 'help' as I need. I'm not here to please anybody, become someone's
language adherant, or pump sunshine up anyone's skirt about technology. In
terms of industrial mindshare, FP sucks. There are probably good tangible
reasons for that somewhere, and it's best that people look at them and
address them. I've seen too many fora, read too many archives, of too many
FPers going on and on and on about how FP is the promised land. But I see
no promise to industry in general. I see people waving hands about how good
things are *supposed to* be. *If only* everyone used my paradigm of choice,
etc.
And, we've had decades to look at this mote in our eye.
> If you think that programming languages should be advanced
> into a state of usability, write to your parliamentary representative
> and propose funding for that...
What nonsense. If I cared *that* much, I'd write the language. As it
stands, I care enough to survey other people's language writing efforts. I
have no interest in NIH if someone's actually inventing what I want.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Brandon J. Van Every
> "Patrick Philippot" <patrick....@mainsoft.xx> writes:
>
> [...]
>> I found only one book : ML for the working programmer, Paulson,
> ^^^^^^^^^^^^^^^^^^^^^
>
> Literature". The links lead to information on no less than 9
> tutorials and 19 books. Admittedly, quite a few of them aren't what
> you are currently looking for, but to say that you weren't able to
> locate more than one book is a joke.
His preceding paragraph provided context. I took his comment to mean, "I
only found one book that was oriented towards the practical matters I was
concerned with."
>> - SML is *extremely* difficult to debug and retro-document.
>
> How much experience do you have with the language? If you are still
> hunting for books that explain it to you, I guess not that much. If
> that is indeed so, and given that programming in SML feels quite
> different than programming in any of the languages that you do know
> (meaning that you can't just guess your way through), I am not
> surprised at all that you find it difficult to debug and document SML
> code written by others.
Fair comments.
> But that has nothing to do with the language itself.
Not quite accurate. Python, for instance, is reputed to be easy for
beginners to learn. I would never presume to bill C++ as a 'quick study'
for anyone. So perhaps his learning curve does indeed have something to do
with SML itself. For any language, it's fair to ask "What payoff justifies
its learning curve?" Python doesn't have to justify much: its learning
curve is low. C++, as far as I'm concerned, doesn't have any justification
anymore. It's an evolutionary dead end.
> I find the idea of trying to understand a program by "stepping through
> it" mind-bogglingly ill-conceived (in *any* language).
Actually, it was the most successful strategy when I was writing 3D device
drivers. But, that's a cut-and-dried problem domain. We know how 3D
pipelines work.
I hate debugging and avoid it as much as possible. I control errors by
micro-incremental development, rigorous testing, and fascist source control.
I also hate understanding industrial APIs, especially Microsoft APIs. I
hate *ever* trying to understand other people's code. It is mentally far
less taxing to write my own code. Unfortunately, I'm not some kind of
prolific coding genius, so writing my own code is somewhat pricey. I'm
hoping someday I find a langauge and a development environment that works
with my brain instead of against it. It certainly isn't C++.
Nor is it any of the low performance languages. I have always been gifted
at ASM, as it is the simplest, most elegant expression of an actual
computer. Not that all actual computers are elegant! Alpha was; Intel
wasn't and isn't. Worse is better. :-( Anyways, my ideal language would
scale to any / all levels of abstraction or concreteness I'd choose to work
with. This is why SML/NJ and NLFFI are of interest to me. A lot of Higher
Level Language guys aren't interested in low level performance, and that
bugs the crap out of me.
> Instead of ranting here about the lack of support, why did you not try
> asking a specific question? Some people here do try to answer such
> questions! Pissing them off right from the start doesn't sound like a
> great strategy.
Do you piss off easily, instead of just taking lumps in stride that might be
partially deserved?
Has your language community evolved to the point where some camp actually
takes marketing and evangelism seriously?
Actually, I am impressed you are here though. That's unusual for a language
author. It is good advertizement.
I've been round and round with Guido and the Python Software Foundation on
marketing issues. They are not worth the time. They have pissed off a lot
of people who wanted to put proper marketing campaigns behind the language,
to fight Java and C# and so forth. Serious efforts probably aren't going to
happen again for another 2 years. By then, hopefully the community and the
mentality will have shifted. Right now they are run by techies who cannot
market their way out of a paper bag. Microsoft and Sun will continue to
crush them, using inferior technology.
> The question should not be
> whether one *can* do it, but rather how easy it is, how natural it is,
> how scalable the approach is, how maintainable the results are, etc.
> Unfortunately, even reading one or two books won't help you. In the
> end it takes considerable practical experience to appreciate the
> benefits (if there are any) of "switching" from one language to
> another.
Grandpa, taught Dad, who taught me, there are 3 kinds of experience:
- primary: I did it
- secondary: you did it?
- tertiary: someone did it...
Not sure if those were Grandpa's terms. But, he was a newspaperman.
Hearing all the handwaving about FP, and seeing no clear answers from any
corner, I conclude I'll probably have to read every gory detail of some FP
language to understand what it is / isn't worth. Proving from 1st
principles like back in grade school. Pretty much what I did with C++ 12
years ago.
Brandon J. Van Every
> Simon Helsen <where-X=@-in-shelsenXcomputer.org> writes:
>
>> As for a practical point of view, I would not even think of starting
>> a real-world project ("real world" simply means 1) hard deadlines
>
> I agree, but only for the reason of being able to say 'look at all
> these other projects using <imperative langauge>, they are late too'
> instead of taking the blame for using weird tools. I don't think
> there's any evidence of FP programs being delivered in a less timely
> fashion, and I'd expect the opposite.
Running a Seattle OCaml SIG the other week, one fellow's opinion is that
it's the people, not the language, that will make or break a project. It is
possible for talented soloists to write incredible pieces of code. But, it
doesn't scale up. Once you get past a small team of very sharp people,
corporate communication and the law of averages start to affect you.
> The it's my lack of experience also - you accurately describe my main
> gripe against OO. It's not so hard to see why; FP is just a more
> elegant form of structured programming, it focuses on the breakdown of
> programs by control flow. OO focuses on breakdown by data structure,
> and consequently, control flow becomes more difficult to track.
So to take the inverse, in FP we'd expect the flow of data to become more
difficult to track. Six of one, half dozen of the other?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Brandon J. Van Every
>
> Of course despite what some people might be saying in this thread,
> there is no real reason why functional programming and OO design
> cannot be used together to mutual benefit.
Sure they can, as in OCaml. But my original motivation in asking my
question, is that OCaml has a bad interface to low level code (only 31-bit
ints, no 32-bit floats, funky 2-step C calling conventions) and SML/NJ
doesn't. The price for what I want is giving up OO. So, I want to know how
FP languages 'do things' without OO support.
Joachim Durchholz
> Joachim Durchholz wrote:
>
>> I have to put an ounce of salt into that.
>
> (well on the lose end but still) systems. If you used Erlang for the
> server using the intrinsic network transparency to implement
> redundancy etc. and used or implemented standard protocols for
> authentication etc it would still be a win.
Fully agreed.
On re-reading my last post, I see I omitted an important detail: I
wanted something where clients and server interoperate in a
network-transparent fashion.
It was tantalizing to see that Erlang came so close, but failed on two
relatively minor but essential points: security if you cannot trust all
Erlang processes, and marshalling closures. Both can be worked around,
but unfortunately in both cases the workarounds create impedance mismatches.
Since I have a limited budget, this ruled Erlang out - though I'd
readily subscribe to Erlang being a fine tool overall.
> (And IMHO this is where one wants to follow someone else. It's all
> too easy to get a security protocol wrong.)
Not sure what you meant with that.
> [Erlang SNMP stack] Being implemented in Erlang it didn't suffer from
> the typical buffer overruns that plagued the other implementations
> (implementation?).
Yup, one of the major things that plague the Unix world.
I don't think that Erlang is particularly good with that though - any
language with a garbage-collected heap would avoid this kind of problem,
even Basic ;-)
Erlang's specific strengths lie elsewhere, and the main highlight is its
commercial-use, commercial-mind support. Ericsson isn't going to simply
leave things unhandled if the Erlang project started to fall apart,
that's a quite strong promise about Erlang's future and quality.
> So I'd say that Erlang is well suited to the client server
> application, but not applied in the naive (perhaps: straightforward?)
> fashion.
Agreed :-)
>> For the record: I like Erlang quite a bit. There's a lot of good
>> support available for it. It should work very well in any
>> environment where a known set of CPUs must interoperate for a
>> relatively well-defined overall task.
>
> Incidentally. I'm in the static typing camp myself, so I'm a bit
> guarded in my praise. Still it's better than the alternatives. :-)
Ditto :-)
Regards,
Jo
Matthias Blume
> > But that has nothing to do with the language itself.
>
> Not quite accurate. Python, for instance, is reputed to be easy for
> beginners to learn. I would never presume to bill C++ as a 'quick study'
> for anyone. So perhaps his learning curve does indeed have something to do
> with SML itself.
Certainly, the slope of the curve is a function of the language (and,
to some degree, the background of the learner). But with a shallow
curve, you never get to any significant elevation either (unless you
spend a lot of time on that curve). :-)
> C++, as far as I'm concerned, doesn't have any justification
> anymore. It's an evolutionary dead end.
One thing we 100% agree on.
> > I find the idea of trying to understand a program by "stepping through
> > it" mind-bogglingly ill-conceived (in *any* language).
>
> Actually, it was the most successful strategy when I was writing 3D device
> drivers. But, that's a cut-and-dried problem domain. We know how 3D
> pipelines work.
Yes, I should have qualified this statement a bit. For limited
domains (and code that is not too big) this might work. In the
general case, though, it is a fairly bad idea.
> I hate debugging and avoid it as much as possible. I control errors by
> micro-incremental development, rigorous testing, and fascist source control.
> I also hate understanding industrial APIs, especially Microsoft APIs. I
> hate *ever* trying to understand other people's code. It is mentally far
> less taxing to write my own code. Unfortunately, I'm not some kind of
> prolific coding genius, so writing my own code is somewhat pricey. I'm
> hoping someday I find a langauge and a development environment that works
> with my brain instead of against it. It certainly isn't C++.
Wow. A whole paragraph we nearly 100% agree on. Maybe SML is for you
after all...
> > Instead of ranting here about the lack of support, why did you not try
> > asking a specific question? Some people here do try to answer such
> > questions! Pissing them off right from the start doesn't sound like a
> > great strategy.
>
> Do you piss off easily, instead of just taking lumps in stride that
> might be partially deserved?
Not that easily. Otherwise I wouldn't be answering at all.
> I've been round and round with Guido and the Python Software Foundation on
> marketing issues. They are not worth the time. They have pissed off a lot
> of people who wanted to put proper marketing campaigns behind the language,
> to fight Java and C# and so forth. Serious efforts probably aren't going to
> happen again for another 2 years. By then, hopefully the community and the
> mentality will have shifted. Right now they are run by techies who cannot
> market their way out of a paper bag. Microsoft and Sun will continue to
> crush them, using inferior technology.
One thing is: In the end we are academics. We are not judged by our
peers based on whether our language has become successful (although
this might be a tie-breaker in some cases), but rather on the number
and quality of publications in reputable conferences an journals.
When you want to publish, it helps somewhat to write about a
successful product, but in the end it is the ideas that count, not the
performance in the popularity contest. (After all, as you noted,
popularity and inherent value are often uncorrelated at best and
sometimes even seem inversely proportional.)
So it comes down to a question of time and effort. We try to do some
of the necessary marketing, but it can only be done in our spare time.
> Grandpa, taught Dad, who taught me, there are 3 kinds of experience:
> - primary: I did it
> - secondary: you did it?
> - tertiary: someone did it...
>
> Not sure if those were Grandpa's terms. But, he was a newspaperman.
Personally, I'm definitely a "primary" kind of guy when it comes to
PL. Before I have written a substantial piece of code in a language,
I can't claim to know/understand/appreciate it.
Matthias
Joachim Durchholz
> Also I'm not sure if Erlang is proving something about Functional
> languages or *Concurrent* languages.
Both.
Erlang is functional when programming-in-the-small and concurrent when
programming-in-the-large.
One interesting information that's been repeated several times is that
some internal Ericsson statistics said that a line of Erlang is roughly
equivalent to five lines of C. (Try googling for "productivity
site:erlang.org" (without the quotes).)
There's also a quote about the software in the Ericsson AXP line of
telephony switches. I may have gotten the numbers mixed up so please
check before you quote me, but it was something around the lines of
"100,000 lines of Erlang, 100,000 lines of C, 80% of the functionality
is done in the Erlang parts".
Of course, all of these numbers have a fat "YMMV" tag on them, but even
then the numbers are impressive. Even sub-average programmers seem to
multiply their productivity when they switch to Erlang (at least that's
what I read between the lines).
Personally, I think a large part of these effects is due to Erlang's
support for automatic garbage collection, together with a system that
"just works out of the box".
The functional stuff is still great for factoring out commonalities -
far less syntactic excess than with OO methodology in fact. I attribute
that to the fact that you need tons of syntax to factor out a single
line of code into a superclass, while a single-line function declaration
may be fully sufficient (both technically and documentation-wise) in an FPL.
Of course, this kind of advantage really matters only when you have
started to use the approach on a larger scale, and at that point most
people are already committed and couldn't reverse the decision even if
they wanted to. That's why the FP arguments sound like every other
hype... even if it's true. (I'm pretty sure that FP isn't the end-all of
design-in-the-large, but it's the best technology that I know about.
(Well, famous last words... *gg*))
Regards,
Jo
Ketil Malde
> I'm afraid this is a misunderstanding of OO. OO does not break down
> by data structure.
Okay. But IMO, the main idea behind OO is the grouping of data and
functions.
> OO is about *non hierarchical* breakdown of control.
This used to be called "spaghetti code", and used to be regarded as a
bad ting. OO is a way to bring some structure into this, to make it
managable.
> In traditional stepwise refinement
You can also build things bottom up, constructing the basic building
blocks for the process. This is IMHO often advocated in FP.
> In OO you identify classes and allocate responsibilities
> for part of the task to each of the classes
> [...] Then the classes cooperate to get the task done.
I still maintain that OO usually has the focus on the data structures
and their interfaces, rather than on the process you want to perform.
IME, objects are almost always the processees, not the process. I
think that to some extent, processes are instead captured by design
patterns.
> Of course despite what some people might be saying in this thread,
> there is no real reason why functional programming and OO design
> cannot be used together to mutual benefit.
Perhaps not, there certainly are multi-paradigm languages out there.
Matthias Blume
> Why do you bother to advertize your 'new' mailing list as "hosted by
> SourceForge" if you do not expect people to access it by standard
> SourceForge interfaces?
To give credit where credit is due.
> In the quote above, you don't even link to your specific SourceForge
> project. You link to SourceForge in general. People may very well
> infer that they can get to the SML/NJ mailing list from the
> SourceForge top level.
The mailing list (which was formerly hosted by Bell Labs and, thus,
totally off limits as far as self-subscribing and googling is
concerned) is a means of getting in touch with us in case of problems,
bugs, and suggestions. It being now hosted by SF is merely a
consequence of our departure from BL, the fact that SF is a convenient
host to which most people have easy access, and the prospect that it
will continue to exist.
> > No, we have not "created" obscurity. Our main presence on the web is
> > not the SF page. Just because we did not post the list name there
> > does not mean we are more "obscure" than before.
>
> Before *what* ?
Before SF even existed. SML/NJ has been an open source project long
before "Open Source" became a household term.
Matthias
Joachim Durchholz
> Joachim Durchholz wrote:
>
>> Brandon J. Van Every wrote:
>>
>>> I conclude, oddly enough, that inheritance at too fine a grain
>>> actually violates encapsulation.
>>
>> Actually inheritance violates encapsulation regardless of how you
>> use it: after all, the inheriting class has access to all the
>> internal machinery of all of its ancestors. (Unless that machinery
>> is "protected", but that comes with its own set of problems and
>> limitations.)
>
> False. Try implementing 'Private' machinery.
Sorry, it was too late in the evening; I meant to write "private"
wherever the above says "protected".
> In terms of industrial mindshare, FP sucks.
Well, I'm in the process of setting up a repository for SML code so that
there's easy access to SML libraries. Since I don't get paid for that,
it's been rather slow progress, isn't ready for the public, and won't be
for another three months or so (I'm going to move end of July, and
everything is in a state of disarray and neglect right now).
As this example shows, you can expect industrial-strength support if
there's industrial support. In industry, there would be a team
responsible for that (even if they were doing it part-time along with
other duties), so if one of them were unavailable the rest could keep
the thing working.
Since I'm doing it privately, there's no way it's going to be
industrial-strength.
If you're out for something that's got industrial-strength support,
don't rant about those languages that are still in academia. Or get
yourself an industry that gives you the needed support. Or select a
language that's already in industry, such as Erlang... and live with the
trade-offs that that entails (I'm pretty sure you know it's not all
roses there either, TANSTAAFL).
But don't rant. You'd get more intelligent responses if you didn't.
>> If you think that programming languages should be advanced into a
>> state of usability, write to your parliamentary representative and
>> propose funding for that...
>
> What nonsense. If I cared *that* much, I'd write the language.
Which would result in yet another sub-industrical-strength language.
If I'm writing nonsense, I'm definitely not alone in this exchange.
*plonk*
Jo
Ketil Malde
> So to take the inverse, in FP we'd expect the flow of data to become more
> difficult to track. Six of one, half dozen of the other?
Yes, that wouldn't surprise me. I'm sure that if you take a problem
that maps well to OO, it could be hard to model it elegantly using
FP.
So you would have to look at what the problem is focused on; does it
make sense to structure your program with a focus on process (e.g. as
a pipeline of filters), or on data (objects), before you decide the
technology you want to use.
Brandon J. Van Every
>
> The mailing list (which was formerly hosted by Bell Labs and, thus,
> totally off limits as far as self-subscribing and googling is
> concerned) is a means of getting in touch with us in case of problems,
> bugs, and suggestions. It being now hosted by SF is merely a
> consequence of our departure from BL, the fact that SF is a convenient
> host to which most people have easy access, and the prospect that it
> will continue to exist.
Do you want more visibility for SML/NJ?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Adrian Hey
> FP is just a more elegant form of structured programming, it focuses on
> the breakdown of programs by control flow.
Eeek..I'm shocked (really:-), this seems remarkably similar to the IMHO
ill-informed FUD regularly parroted by a certain citizen of comp.object
(I won't name names, but anybody who can recall what was probably the
longest flame war in the history of comp.lang.functional will know who
I'm talking about:-)
Taken at face value this statement would appear support the allegations
of functional programs suffering from maintainability problems typical of
"legendary spaghetti code" with "hierarchical dependency".
But seeing as I know that you are not ill-informed about FP, I guess you
have good reason for saying this (though I have to say I disagree).
[
I was considering writing a long explanation of why I don't think FP is
in any way comparable to traditional state dependent and state mutating
structured programming. But I guess I'd be preaching to the converted,
so I'll spare myself and everybody else from all that :-)
]
Regards
--
Adrian Hey
Philippa Cowderoy
> So to take the inverse, in FP we'd expect the flow of data to become more
> difficult to track. Six of one, half dozen of the other?
>
Depends. In pure FP it's all there explicitly - same goes for references,
for that matter.
Brandon J. Van Every
> Brandon J. Van Every wrote:
>>
>> In terms of industrial mindshare, FP sucks.
>
> Well, I'm in the process of setting up a repository for SML code so
> Since I'm doing it privately, there's no way it's going to be
> industrial-strength.
>
> If you're out for something that's got industrial-strength support,
> don't rant about those languages that are still in academia.
You changed the subject. My comment has nothing to do with whether your
personal project is industrial strength or not. I can point you at
*legions* of open source C++ or Java or Python projects that are in exactly
the same boat you're in.
FP - any language, any form - has had decades to achieve industrial
mindshare of some kind or another. It hasn't. That's the bottom line. We
must ask why, if we are to be honest about what our languages achieve and
what they don't. Not hide behind covers like "it's an academia thing, you
just wouldn't understand."
We do see some exceptions in some cases. Erlang has been mentioned. I've
seen CAD companies use Lisp. A few game studios try things other than C++.
> But don't rant. You'd get more intelligent responses if you didn't.
I think the only slight diminishment of intelligence going on here, is your
willingness to label what I say a 'rant'. "FP sucks at industrial
mindshare" isn't a rant, it's a fact. Maybe you meant: the fact makes you
mad, so you don't respond as intelligently to what you don't like to hear?
>>> If you think that programming languages should be advanced into a
>>> state of usability, write to your parliamentary representative and
>>> propose funding for that...
>>
>> What nonsense. If I cared *that* much, I'd write the language.
>
> Which would result in yet another sub-industrical-strength language.
Not necessarily. I might have better focus for such a problem than the next
guy. Emphasis on *might*. I have no interest in finding out right now, I
already said I avoid NIH as a matter of policy. If someone has invented
what I want, then I don't need to.
Anyways, why do you think gov. funding would result in something other than
the language landscape we see today?
> If I'm writing nonsense, I'm definitely not alone in this exchange.
> *plonk*
You seem to be the sensitive type. Whatever dude, enjoy your plonking.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Ketil Malde
>> FP is just a more elegant form of structured programming, it focuses on
>> the breakdown of programs by control flow.
> Eeek..I'm shocked
Okay. It could be that I am indeed ill-informed, I only *use* a bit
of FP, I never really *learned* it, you know. I find that I often
break down my code in a manner resembling how I wrote my Pascal
progams all these years ago - structuring the process, not the data.
I'm not at all trying to say that they are the same, or that I'd ever
want to go back. While SP was rigid, FP is very flexible. FP
supports reuse and bottom-up much better.
> Taken at face value this statement would appear support the allegations
> of functional programs suffering from maintainability problems typical of
> "legendary spaghetti code" with "hierarchical dependency".
I'm sorry, but IMHO spaghetti is the opposite of structured -
spaghetti is when the control flow jumps arbitrarily around in code.
SP was trying to fix this by not letting you do that (GOTO considered
harmful etc).
But if your code is going to end up as spaghetti anyway, I think OO
may be a good way to structure it[*]. (One thing to look for may be
multiple "use cases"-diagrams involving the same classes?)
> (though I have to say I disagree).
Please elaborate!
-kzm
[*] Paul Graham says something along these lines in his "Advanced"
book, chapter on CLOS, but I don't have the book here to provide the
quote.
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> writes:
>
>>> But that has nothing to do with the language itself.
>>
>> Not quite accurate. Python, for instance, is reputed to be easy for
>> beginners to learn. I would never presume to bill C++ as a 'quick
>> study' for anyone. So perhaps his learning curve does indeed have
>> something to do with SML itself.
>
> Certainly, the slope of the curve is a function of the language (and,
> to some degree, the background of the learner). But with a shallow
> curve, you never get to any significant elevation either (unless you
> spend a lot of time on that curve). :-)
Well, that's baloney in the case of C++. For your deeper curve, all you get
is wasted time. Python people claim they get tons for their shallow
curve... but they also haven't done much of anything for 3D graphics or AI
problems, so what would I conclude for my needs? I can point to their
successes at process control, but not at large scale applications
development. I think, "what is the curve, how steep should it really have
to be?" is problem domain specific.
>> C++, as far as I'm concerned, doesn't have any justification
>> anymore. It's an evolutionary dead end.
>
> One thing we 100% agree on.
Heh, ain't that a hoot.
>> I hate debugging and avoid it as much as possible. I control errors
>> by micro-incremental development, rigorous testing, and fascist
>> source control. I also hate understanding industrial APIs,
>> especially Microsoft APIs. I hate *ever* trying to understand other
>> people's code. It is mentally far less taxing to write my own code.
>> Unfortunately, I'm not some kind of prolific coding genius, so
>> writing my own code is somewhat pricey. I'm hoping someday I find a
>> langauge and a development environment that works with my brain
>> instead of against it. It certainly isn't C++.
>
> Wow. A whole paragraph we nearly 100% agree on. Maybe SML is for you
> after all...
We will see. I'm on the language trajectory I'm on for a reason, and I've
been digging awfully hard at the 'better language problem' for about a year
now.
>> Do you piss off easily, instead of just taking lumps in stride that
>> might be partially deserved?
>
> Not that easily. Otherwise I wouldn't be answering at all.
True.
> One thing is: In the end we are academics. We are not judged by our
> peers based on whether our language has become successful (although
> this might be a tie-breaker in some cases), but rather on the number
> and quality of publications in reputable conferences an journals.
> When you want to publish, it helps somewhat to write about a
> successful product, but in the end it is the ideas that count, not the
> performance in the popularity contest. (After all, as you noted,
> popularity and inherent value are often uncorrelated at best and
> sometimes even seem inversely proportional.)
And then at another extreme, you have the Corporates. The ideal Corporate
language is something like Java or C#. Mundane, somewhat labor saving over
a previous paradigm (C++), but wholly unremarkable. A blunt tool for
grunting out code with legions of average programmers. There's money in the
model, for the Corporate owners. There's no competitive advantage for the
line worker. She is a cog, her intelligence will not be leveraged. She
will drown in repetitive processes that maintain lines of authority. She
will ultimately be Indian, Russian, or Chinese.
I am not either of you. I am an independent game developer. I am mostly
self-taught in all areas of computerdom that I know. I have been
self-funded the vast majority of the time. I have neither academic peers,
nor corporate peers. I have crossed a little into both worlds. I share
some of each's concerns. But my main goal is to GET THINGS DONE as a ONE
MAN BAND. It is a crazy ambition, and there are few of us. If only because
the 'low hanging fruit' was taken by such people in previous decades (Apple,
Microsoft, guys who wrote games like Sneakers). I believe I / we are like
them and will fundamentally prevail. We simply have to scale up to the
level of complexity that computerdom has become.
We cannot use the primitive technologies of the Corporates, nor put up with
academia when it chooses irrelevance. So we have to take what's available
and fix it, until it works for us.
Matthias Blume
> Matthias Blume wrote:
> >
> > The mailing list (which was formerly hosted by Bell Labs and, thus,
> > totally off limits as far as self-subscribing and googling is
> > concerned) is a means of getting in touch with us in case of problems,
> > bugs, and suggestions. It being now hosted by SF is merely a
> > consequence of our departure from BL, the fact that SF is a convenient
> > host to which most people have easy access, and the prospect that it
> > will continue to exist.
>
> Do you want more visibility for SML/NJ?
Sure. But I can't be the marketeer any more than I already am. (In
other words: When I have to decide between improving the product and
improving its web page, I will always lean towards the former.
Moreover, neither of these two can be my top priority in life.)
Matthias
Isaac Gouy
-snip-
> > The it's my lack of experience also - you accurately describe my main
> > gripe against OO. It's not so hard to see why; FP is just a more
> > elegant form of structured programming, it focuses on the breakdown of
> > programs by control flow. OO focuses on breakdown by data structure,
> > and consequently, control flow becomes more difficult to track.
>
> So to take the inverse, in FP we'd expect the flow of data to become more
> difficult to track. Six of one, half dozen of the other?
Use an OO / functional hybrid, then control flow and data flow are
equally difficult to track ;-)
Joachim Durchholz
>> If I'm writing nonsense, I'm definitely not alone in this exchange.
>> *plonk*
>
> You seem to be the sensitive type. Whatever dude, enjoy your
> plonking.
... I've taken this to private mail.
Regards,
Jo
Stefan Axelsson
> It was tantalizing to see that Erlang came so close, but failed on two
> relatively minor but essential points: security if you cannot trust all
> Erlang processes, and marshalling closures. Both can be worked around,
> but unfortunately in both cases the workarounds create impedance
> mismatches.
Well, yes, I feel your pain. Indeed it *looks* like Erlang would be a
tight fit, but as it wasn't really built for the 'Internet' but rather a
network of computers that you could still see (both the AXD and the
GSNs are single rack configurations) 'expensive' stuff like security
(authentication etc) done right was left out. (That and the fact that
telecoms people are used to non hostile environments, phreaking
notwithstanding).
These issues could be fixed now, from a functionality standpoint, but
then that has the posibility of making the average usage slower/more
resource intensive, and since the non-functional requirements are
important in a highly standardised field such as telecoms, I'm not sure
it would be an overall win.
Stefan Axelsson
> Both.
> Erlang is functional when programming-in-the-small and concurrent when
> programming-in-the-large.
Seconded.
> There's also a quote about the software in the Ericsson AXP line of
> telephony switches. I may have gotten the numbers mixed up so please
> check before you quote me, but it was something around the lines of
> "100,000 lines of Erlang, 100,000 lines of C, 80% of the functionality
> is done in the Erlang parts".
Close. The AXD line of ATM switches has ca 1 million lines of Erlang
(the logic, failover etc, the 'difficult' stuff), ca 500k lines of C
(device drivers mostly) and ca 13k lines of Java (management interface
mostly). If you want the exact line counts as of today you have to ask
Ulf. :-)
Simon Helsen
> I'm sorry, but IMHO spaghetti is the opposite of structured -
> spaghetti is when the control flow jumps arbitrarily around in code.
> SP was trying to fix this by not letting you do that (GOTO considered
> harmful etc).
unless you start using call/cc and first-class continuations: obscurity
by elegance (and considered harmful) ;-)
Simon
Simon Helsen
> unless you start using call/cc and first-class continuations: obscurity
> by elegance (and considered harmful) ;-)
I meant *not* harmful (call/cc is not harmful, at least, IMO)
Simon
Bijan Parsia
> Joachim Durchholz wrote:
> > Brandon J. Van Every wrote:
> >>
> >> In terms of industrial mindshare, FP sucks.
> >
> > Well, I'm in the process of setting up a repository for SML code so
> > that there's easy access to SML libraries. [...]
> > Since I'm doing it privately, there's no way it's going to be
> > industrial-strength.
> >
> > If you're out for something that's got industrial-strength support,
> > don't rant about those languages that are still in academia.
>
> You changed the subject. My comment has nothing to do with whether your
> personal project is industrial strength or not. I can point you at
> *legions* of open source C++ or Java or Python projects that are in exactly
> the same boat you're in.
>
> FP - any language, any form - has had decades to achieve industrial
> mindshare of some kind or another. It hasn't. That's the bottom line.
[snip]
XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
*enormous* mindshare, and it's growing.
That XSLT doesn't *kill* people's taste for FP is a miracle in and of
itself :)
Of course, exactly what is being shared by these minds is a little hard to
say. However, I think ruthlessly securing a bandwagon (by whatever means)
is a fairly standard route to mindshare. (See Java.)
FP and tree transformation/manipulation do seem to be a good fit.
Certainly, research in type systems has been influential in the XML world
otherwise (see Relax-NG). It's not like there lacks for, e.g., OO
approaches (see DOM), or even wackier ones (see SAX).
Cheers,
Bijan Parsia.
Thant Tessman
[...]
> If you disagree so much, could you please qualify yourself?
The distinguishing characteristic of functional programming languages is
the ability to compose functions from other functions in the manner of
the lambda calculus. (Some people also consider referential transparency
(no destructive updates) and lazy evaluation to be defining criteria,
but curiously no one seems eager to offer alternative terminology for
languages that conform to the first, but not the second and third (like
Scheme and SML).)
Support for higher-order functions (as defined above) implies closures,
but that's just an implementation detail. Too often the people who seem
eager to trivialize the difference between languages with genuine
support for higher-order functions and languages that kinda sorta have
closures also seem to be people that haven't had a lot of experience
with the former.
As for OO, it could be considered a matter orthogonal to FP were it not
for the fact that it is much easier to do OO with FP than it is to do FP
with OO. (See any one of many object system libraries for Scheme or
Common Lisp.) What's interesting is trying to jibe OO with type systems,
and in that context OO has a lot harder time standing on its own as a
pervasive methodology.
As for deciding whether to use or not use SML, it depends on whether one
is looking for reasons or excuses.
-thant
Andreas Rossberg
>>
>> On the other hand, Java's inner classes are not closures. They cannot
>> capture variables from surrounding scope. That makes them almost useless.
>
> I think you have relativate this a little-bit.
>
> 1) There is entirely normal lexical scoping for "fields" of
> encapsulating classes for both inner and local classes.
Of course, but that is not a sufficient criterion for closure. Even C++
has lexical scoping.
> 2) For local variables (and parameters, etc), yes, they have to be final
> (i.e. normal bindings) for them to be available in the inner class. This
> is because javac makes a copy of the used local variable. A trick to get
> around that is to create an array with the rhs as its element and of
> course, each reference to it in the local block has to access the local
> variable via the array element. While ackward, it behaves like a
> closure. In fact, this is not so different from what happens in SML.
> Only in Java, there is no such thing as a ref constructor, so you have
> to use an array for that instead.
>
> I do not see what you mean by "that makes them useless".
You can always build closures by hand (and in a language with garbage
collection, even use them), but do you really want to? What you suggest
sounds very unnatural and tedious to me.
> if you program in an OO fashion in Java (quite likely!) you do not face
> these problems in the first place. Local variable updates in the local
> class are not likely and enclosing field updates, being most common, are
> allowed.
Why do you think it is "OO fashion" not to use closures over local
variables? Besides this somewhat sidestepping the point, I'd say that
e.g. in Smalltalk you'd use them quite frequently, for example for
iterating over collections. In a non-functional setting, the need for
local updates arises quite naturally then, if you ever want to return
something interesting as a result.
Mind you that Java libs and programs avoid that idiom, partly due to its
restricted closure mechanism, and partly due to its inflexible type system.
> What do you mean by variables are (or are not) first-class? Could you
> explain exactly what the difference is here? The only difference I see
> is that SML (like all impure FPLs) makes a distinction between bindings
> (by default) and assignments (requiring extra syntax). In Java, that
> happens "the other way around" by having assignments by default and
> bindings by annotation.
In ML, a "variable" in the imperative sense is called a reference, which
is first-class and hence can be passed around independently from any
context. In typical imperative languages, variables can only be copied
out of context.
Cheers,
- Andreas
--
Andreas Rossberg, ross...@ps.uni-sb.de
Let's get rid of those possible thingies! -- TB
Simon Helsen
> Simon Helsen wrote:
>
>>>
>>> On the other hand, Java's inner classes are not closures. They cannot
>>> capture variables from surrounding scope. That makes them almost
>>> useless.
>>
>>
>> I think you have relativate this a little-bit.
>>
>> 1) There is entirely normal lexical scoping for "fields" of
>> encapsulating classes for both inner and local classes.
>
>
> Of course, but that is not a sufficient criterion for closure. Even C++
> has lexical scoping.
that is of course not what I meant (and you know it). Lexical scoping is
lexical scoping and it becomes interesting once you have the ability to
talk about code in a first-class manner, e.g. with inner classes or
blocks. If you do not implement them as closures, then you automatically
get dynamic scoping instead of lexical scoping. The issue simply does
not arise in C++ and in fact, I reiterate that lexical scoping *is* the
sufficient criterion to make first-class *code* into closures.
> You can always build closures by hand (and in a language with garbage
> collection, even use them), but do you really want to? What you suggest
> sounds very unnatural and tedious to me.
It is tedious, but you do not entirely program them by hand. Java
literally copies the local variable inside the inner class, essentially
constructing a closure. However, because
1) Java combines binding and assignments in one construct, and
2) puts local variables on the stack
they have decided to enforce the "final" requirement. The latter makes
you variable assignment behave like a binding and the array behaves like
a reference. I never said this is a natural style. I am just pointing
out that the differences are not all that big because Java *does* copy
the local variables inside the inner class, just like you expect from a
closure.
> Why do you think it is "OO fashion" not to use closures over local
> variables? Besides this somewhat sidestepping the point, I'd say that
> e.g. in Smalltalk you'd use them quite frequently, for example for
> iterating over collections. In a non-functional setting, the need for
> local updates arises quite naturally then, if you ever want to return
> something interesting as a result.
>
> Mind you that Java libs and programs avoid that idiom, partly due to its
> restricted closure mechanism, and partly due to its inflexible type system.
You are right. I was too quick there. I agree that in Smalltalk, you
want to do updates on your local variables from a block. But that is
mostly because Smalltalk uses blocks in a lot of places where you have
specific Java mechanisms to cope with it.
I only wanted to rebut your assertion that anonymous classes are
essentially useless. Look at any significant body of (properly written)
Java code and you will see that anonymous classes are used all over the
place.
> In ML, a "variable" in the imperative sense is called a reference, which
> is first-class and hence can be passed around independently from any
> context. In typical imperative languages, variables can only be copied
> out of context.
I understand this, but I find it bizar to call a variable first-class.
You only break appart the notions of binding and assignment. In ML, you
have binding unless you use a "ref", in Java you have assignment unless
you use "final".
Again, the actual implementation of inner classes is not different from
that of functional closures. It just happens that because Java puts the
assigned value on the stack, and not on the heap, they enforce the user
to use a binding instead.
Simon
Simon Helsen
> The distinguishing characteristic of functional programming languages is
> the ability to compose functions from other functions in the manner of
> the lambda calculus. (Some people also consider referential transparency
> (no destructive updates) and lazy evaluation to be defining criteria,
> but curiously no one seems eager to offer alternative terminology for
> languages that conform to the first, but not the second and third (like
> Scheme and SML).)
That is *your* definition. I would like to put it differently. FP is a
paradigm that by default supports binding and may or may not support
assignment. This does not contradict the lamba calculus which
effectively does everything by binding instead of destructive assignment
(in contrast with Turing or Minsky machines). Now, for this to be
practical, you usually want first-class functions. However, fc functions
are not exclusive to FPs. In Smalltalk, you can compose functions as
easily as in any functional language, yet, that is not the way to go
about. The main reason is that Smalltalk is an OO system which is based
on implicit state and thus requires destructive assignment by default.
Functional binding (explicit state) as in FPs, would be problematic for
Smalltalk's OO system.
So, SML, Scheme, Haskell, etc. all fall into the category of functional
languages because they have "binding" by default. Yes, they also have
first-class functions, but if that was the criterion, then I have to put
Smalltalk in my list and do not want to do that. Btw, javascript also
has first-class functions. Do you really want to call that an FP?
> Support for higher-order functions (as defined above) implies closures,
> but that's just an implementation detail.
I agree.
> Too often the people who seem
> eager to trivialize the difference between languages with genuine
> support for higher-order functions and languages that kinda sorta have
> closures also seem to be people that haven't had a lot of experience
> with the former.
If you are implying that I do not have a lot of experience with
functional languages, you better watch your words. I have by *far* more
experience in what I call functional languages, but I simply disagree
that first-class functions are their distinguishing feature as explained
above. In fact, from my long experience with FP, I noticed that
functional state is the single-most reason why the FP paradigm is so
good. HOFs are only a necessary thing to make this become practical.
I think the best "negative" example that HOFs are not that essential for
FP is Erlang. Erlang long did not have explicit HOFs. Erlang is
functional except for its concurrency model (Erlang also provides
standard I/O). However, Erlang *did* have the distinction between
binding and assignment. Modern versions of Erlang also have HOFs but I
still get conflicting views on their necessity. Even though Erlang is
mostly designed as a concurrent language, most people agree that it is
also functional.
> As for OO, it could be considered a matter orthogonal to FP were it not
> for the fact that it is much easier to do OO with FP than it is to do FP
> with OO. (See any one of many object system libraries for Scheme or
> Common Lisp.) What's interesting is trying to jibe OO with type systems,
> and in that context OO has a lot harder time standing on its own as a
> pervasive methodology.
It is true that static (say ML-like) typing does not go well with OO. If
you try to program your typical OO program in Ocaml, you'll notice some
of the problems. A modern interpretation of OO, however, implies
implicit state and that does contract FP's inherent drive to separate
binding from assignment. Without assignment, there is no way to
manipulate your state. I know there things like functional objects, but
I do not know if you can really call this an OO paradigm.
> As for deciding whether to use or not use SML, it depends on whether one
> is looking for reasons or excuses.
What a naive remark. I am not looking for excuses to not use SML. I am
in fact looking for excuses to *use* it. To date, in the vast majority
of "real-world" situations, it would be irresponsible (and just plain
dumb) to use SML. That is called pragmatism, a characteristic that a lot
of the FP community lacks. I do not want to insult anybody because I
know from my experience that academics get paid for papers, not working
systems. Also, I admire the intelligence of many of the regular posters
here. But that is not good enough to get it out there, working in a real
environment, with real customers, real deadlines, and real money. For
that to happen, you need pragmatism (they way the Erlang developers had
it).
Anyways, feel free to live on in your bulp...
Simon
Brandon J. Van Every
Do you have any people in the SML/NJ community with minimal web design
skills?
Thant Tessman
> Thant Tessman wrote:
>
>> The distinguishing characteristic of functional programming languages
>> is the ability to compose functions from other functions in the manner
>> of the lambda calculus. (Some people also consider referential
>> transparency (no destructive updates) and lazy evaluation to be
>> defining criteria, but curiously no one seems eager to offer
>> alternative terminology for languages that conform to the first, but
>> not the second and third (like Scheme and SML).)
>
>
It's not a definition. It's an observation. I'm bored with arguments of
terminology. Call it whatever you want.
> What a naive remark. I am not looking for excuses to not use SML. I am
> in fact looking for excuses to *use* it. To date, in the vast majority
> of "real-world" situations, it would be irresponsible (and just plain
> dumb) to use SML. That is called pragmatism, a characteristic that a lot
> of the FP community lacks. [...]
Last time I looked into the issue, memory violations were the single
biggest category of software bugs and security vulnerabilities. Who's
the ones being irresponsible?
-thant
Matthias Blume
> Do you have any people in the SML/NJ community with minimal web design
> skills?
Define "minimal skills".
Simon Helsen
> Last time I looked into the issue, memory violations were the single
> biggest category of software bugs and security vulnerabilities. Who's
> the ones being irresponsible?
what has *that* to do with the reasons for using or not using SML? Your
response shows that you are not interested in a differentiated view. I
am sorry I wasted my time.
Simon
Brandon J. Van Every
> Thant Tessman wrote:
>
>> one is looking for reasons or excuses.
>
> What a naive remark. I am not looking for excuses to not use SML. I am
> in fact looking for excuses to *use* it.
I don't see how you can deduce enough information from Thant's comment above
to know what he actually meant. Seems to me he could be agreeing with you,
or you could be talking past each other.
> To date, in the vast majority
> of "real-world" situations, it would be irresponsible (and just plain
> dumb) to use SML. That is called pragmatism, a characteristic that a
> lot of the FP community lacks.
I don't know... I'm currently interested in SML/NJ because NLFFI looks far
more pragmatic *for my problems* (high performance 3D graphics and AI
algorithms) than OCaml does. And, I wouldn't accuse the OCaml crowd of
being unpragmatic. For instance they don't force a choice between
functional or imperative coding, and they are attempting to do OO with a
functional language.
I think it is fair to say, however, that any academic project is not as
pragmatic as a commercial one.
> I do not want to insult anybody because I
> know from my experience that academics get paid for papers, not
> working systems. Also, I admire the intelligence of many of the
> regular posters here. But that is not good enough to get it out
> there, working in a real environment, with real customers, real
> deadlines, and real money. For that to happen, you need pragmatism
> (they way the Erlang developers had it).
Well, Erlang was pushed by a company. Academics definitely aren't into
'push', the only marketing they care about is papers. To me the question is
whether academics allow / facilitate a bunch of non-academics, so that other
people can actually get the gruntwork done. Issues like a standard OCaml
library get bandied about on caml-list, for instance. It seems that the
OCaml community has evolved to the point that a lot of people are asking the
hard questions about industrialization. It doesn't look like they've made
progress yet on the kind of community organization needed, i.e. nothing
remotely resembling the Python community. And, as much progress as Python
has made on practical sharing of technologies, they still can't market their
way out of a paper bag. Not for lack of trying either; rather, the PSF has
imposed barriers to progress.
The issue of who-cares-about-what and who's-in-charge definitely becomes
problematic. In some sense languages have to free themselves of their
progenitors, because the progenitors often don't have the skills necessary
for industrialization and don't care. So, popular language evolution is a
series of fits and starts until certain predictable milestones are overcome.
You can, for instance, look at the webpages for SML/NJ, OCaml, Python, Perl,
and Java and see exactly how far each language has evolved in terms of user
community and industrialization.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Matthias Blume
> You can, for instance, look at the webpages for SML/NJ, OCaml, Python, Perl,
> and Java and see exactly how far each language has evolved [ ... ]
I would like to remind everyone that that SML/NJ is not a language but
merely one particular implementation of a language that has several
implementations of reasonable quality.
Also, extensive web representation is not identical to popularity or
utility. (Where is the web page of the C programming language?)
Matthias
Thant Tessman
I hope I'm not putting the words in the mouths of SML's creators, but if
anything differentiates the design of SML--particularly from languages
that purport to be object-oriented, it's in its attempt to guarantee the
soundness of your program in a statically-verifiable way while giving up
as little expressiveness, performance, and practicality as possible.
That is, the *main* thing that recommends SML is that it makes it easier
to write bug-free programs, especially as the complexity of your
application goes up.
-thant
Daniel C. Wang
{stuff deleted}
> Sure. But I can't be the marketeer any more than I already am. (In
> other words: When I have to decide between improving the product and
> improving its web page, I will always lean towards the former.
> Moreover, neither of these two can be my top priority in life.)
By improving the webpage you can get others to improve the product. Spending
timing on developing a viable community of developers is more important than
"improving" SML/NJ.
The SML/NJ development philosophy suffers from a "cathedral" attitude that
is counter productive. This pervades the SML community in general. The
whole SML Basis book fiasco being one of the more obvious recent stupidities.
Personal apologies to all the personalties involved. I do not mean to
offend, but I want to vocally complain about this. They are all damn smart
and hard working people, but I'm just sometimes amazed what actually ends up
happening.
I think the SML/NJ developers are sticking to a very effective development
philosophy that worked very well for at least a decade or so. It is
unfortunate that this development philosophy is completely out of sync with
the "real" world as it is today.
Wake up! Don't cop an attitude.
P.S. I've always been convinced that SML will become the Algol of my
generation. You should read that as both high-praise and damnation. So, far
nothing I've seen has changed by mind about that.
P.P.S. Ohhh that felt so good to get out of my system.. :P
I R T
They also need a better web site.
The current one looks like it is run by dairy farmers interested in cows from
New Jersey :-)
I R T
> The list is not supposed to be public. It is for developers, and if
> you want to become one, you could have asked to be put on the list
> nicely (if you can't figure out how to do it yourself).
Most languages have a developers list and at least a few
general mailing lists.
Are we to assume that the SML/NJ general mailing lists are dead due
to lack of interest ?
I R T
> Our main presence on the web is
> not the SF page.
Is it the Ocaml page ?
I R T
> I've always been convinced that SML will become the Algol of my
> generation. You should read that as both high-praise and
> damnation. So, far nothing I've seen has changed by mind about that.
Ocaml are doing an excellent job of keeping ML alive and visible.
Brandon J. Van Every
Capable of performing the trivial edits I suggested for clarity of accessing
the mailing list, and having the time and wherewithal to do so?
I R T
> One thing is: In the end we are academics. We are not judged by our
> peers based on whether our language has become successful (although
> this might be a tie-breaker in some cases), but rather on the number
> and quality of publications in reputable conferences an journals.
Haskell seems to have a greater presence despite it's academic roots.
I R T
> Brandon J. Van Every wrote:
>> It's all theoretical
>> handwaving, I see no evidence of proven utility. FP's failure to capture
>> industry mindshare is clear enough.
>
> I guess this is where we wave the Erlang flag again?
> (http://www.erlang.org). I'd say there's quite some evidence of proven
> utility there. Within Ericsson alone we have two *major* products both
> very successfull in their fields (market leaders). And those aren't
> the only ones.
Erlang had the benefit of being designed by and promoted by people active in
industry instead of in academia.
Brandon J. Van Every
Yes, if I were picking languges solely on the basis of community viability,
there would be no contest. OCaml beats SML/NJ hands down. I think it is
possible for OCaml to reach the "Python stage" of industrialization, but of
course many problems have to be dealt with to make it happen. Meanwhile,
SML/NJ has not reached the OCaml stage of industrialization.
I am hoping that by establishing a Seattle ML SIG, I can pull these language
communities along. My ultimate goal is "better game technology." It would
be sweet to someday do lectures at the GDC about why I'm making tons of
money and other people are not. :-) The candidate for my uber-game
technology is currently the ML language family. Hope it works.
Brandon J. Van Every
In terms of aesthetics, trying to talk to techies about "better websites" is
a lost cause. Look at the eyesore that is www.python.org. Look at that POS
logo. I worked with groups of people who offered things like this instead:
http://www.pollenation.net/assets/public/python-main-oct05.png (bear in mind
it's an image of a webpage, not a webpage). But the PSF is incompetent.
Guido went so far as to publically trash the web designer who did the logo
and the mockup as not really knowing anything about graphic design. As far
as I'm concerned, in matters of visual aesthetics, Guido is an idiot. The
kind of guy who should be CTO, never CEO, and certainly not an Art Director.
I've told him so, same way he told that web guy.
Meanwhile Sun rolls on with www.java.com. Even though the volunteers of the
Python community are talented enough to compete with their slick web
designs. It's nothing short of infuriating. Fortunately for me personally,
I had enough problems with Python itself to walk away from it. It really
isn't the right technology for what I want to do. It may be in 3 to 5 years
though, when they've sped it up.
So, I've gone up some of the learning curve of making language communities
commercially viable. Don't have any feather in my cap from it yet though.
The next part of the Master Plan is local conquest. I think beer is a
powerful determinant of human action.
Brandon J. Van Every
> Simon Helsen wrote:
>>
>> To date, in the vast
>> majority of "real-world" situations, it would be irresponsible (and
>> just plain dumb) to use SML. That is called pragmatism, a
>> characteristic that a lot of the FP community lacks. [...]
>
> Last time I looked into the issue, memory violations were the single
> biggest category of software bugs and security vulnerabilities. Who's
> the ones being irresponsible?
"Garbage collection for the masses" is yesterday's headline. Java did it,
C# aped it.
There's no way I could consult SML/NJ with the kind of web presence it
currently has. Any manager would take one look at those webpages and flee
in terror. Even OCaml would be quite a stretch. Currently my only option
is to write my own software with either, sell it, and make a lot of money.
Hopefully if I succeed at such production problems, "I've made money with
this" will become a powerful consulting tool. But there's a faceplate
that's gonna have to happen as part of the exercise.
Matthias Blume
> By improving the webpage you can get others to improve the
> product. Spending timing on developing a viable community of
> developers is more important than "improving" SML/NJ.
Why don't you do it then, Dan? If you feel so passionate about it...
(The opportunity was -- and still is -- there.)
> The SML/NJ development philosophy suffers from a "cathedral" attitude
> that is counter productive. This pervades the SML community in
> general. The whole SML Basis book fiasco being one of the more
> obvious recent stupidities.
You are being extremely unfair, and you know it. What "fiasco"? What
"stupidities"? Be glad John and (I believe) Emden are not reading
netnews, otherwise a big, serious apology would be in order. And by
this I don't mean:
> Personal apologies to all the personalties involved. I do not mean to
> offend, [...]
This is bullshit! You can't go around insulting people left and right
and then step away with a simple "oops, sorry, no offense" or such!
> but I want to vocally complain about this. They are all damn
> smart and hard working people, but I'm just sometimes amazed what
> actually ends up happening.
Maybe you could elaborate? Yes, they are all smart and hard-working.
Which is why things are slow -- because being hard-working means they
can't spend all their time on these web pages. [On second thought:
No, don't elaborate. When I am done with this article I think I am
done with this thread, too.]
And by the way: I take the "cathedral" thing as a compliment. I never
bought into this ESR nonsense anyway. I *hate* bazaars in general,
and the software variety in particular. Just go and have a look at
all those projects at SF: 90% utter crap, ill-conceived, half-baked,
full of bugs! And even the ones that aren't crap (including the
high-profile ones) are almost never original in any way. They are not
advancing our horizons! There are things that cannot be done well
bazaar-style. Designing a language or a library API are good examples
for that.
In short, I don't care if SML or Haskell or even OCaml or Clean or ...
will die -- as long as some of the better ideas that went into their
design make it into future languages and as long as the worst ideas
survive as warnings for future designers. In this sense the Algol
analogy is probably true -- and no reason for being ashamed.
In the meantime, SML is by no means dead -- and neither is SML/NJ. And
since many of us continue to find the language and the implementation
to be excellent tools for what we do, we will continue to try and help
improve them.
> I think the SML/NJ developers are sticking to a very effective
> development philosophy that worked very well for at least a decade or
> so.
Ok.
> It is unfortunate that this development philosophy is completely
> out of sync with the "real" world as it is today.
It seems to me that being effective would be better than being "in
sync" with the so-called "real" world. You know, that "real" world
isn't all that great to begin with...
> P.S. I've always been convinced that SML will become the Algol of my
> generation. You should read that as both high-praise and
> damnation. So, far nothing I've seen has changed by mind about that.
See above.
> P.P.S. Ohhh that felt so good to get out of my system.. :P
Good for you. I, otoh, feel like I have just been back-stabbed.
Matthias
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> writes:
>
>> You can, for instance, look at the webpages for SML/NJ, OCaml,
>> Python, Perl, and Java and see exactly how far each language has
>> evolved [ ... ]
>
> I would like to remind everyone that that SML/NJ is not a language but
> merely one particular implementation of a language that has several
> implementations of reasonable quality.
So, where is SML '97's web presence? All of the SML implementations are at
the same level of web presence: better than nothing, but not by much.
> Also, extensive web representation is not identical to popularity
False. Try Google hits as one of your metrics.
> or utility. (Where is the web page of the C programming language?)
C and C++ have tremendous historical weight behind them. Therefore, they
are no longer centralized. You might dream of SML being at such a stage of
utility.
Java, C#, and all their major competitors have centralized web presences.
And books in every Barnes & Noble. This is how the industrial game is
played. In Seattle, most programmers understand this game exceedingly well,
because the master of the game is in our backyard.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
Ketil Malde
> Why don't you do it then, Dan? If you feel so passionate about it...
Or Brandon. Or I R T. Document your experiences. Set up a Wiki.
Mailing lists. Get involved!
> And by the way: I take the "cathedral" thing as a compliment. I never
> bought into this ESR nonsense anyway
I think that to a large extent, successful software projects require
leadership. Often as a single person doing most of the development
initially, to a handful of 'core' developers later on, as people dig
into the code to solve their particular problems.
The problem with this is that until there is a sufficiently large
team, the project risks dying at the whim of the core developer(s).
The multiple implementations of SML may be sufficiently compatible and
independent that this isn't a major blocker for its 'real world' use
-- I don't know.
But where the 'bazaar' is most helpful, is as a user community:
documentation, bug reports, web infrastructure. And it seems to me
that is where most of the complaints about SML are directed -- and
Matthias has made it pretty clear that this is not where is interests
lie. So, if you want SML to be industrially successful, you have to
contribute the advertising yourself. I'm sure that for instance
www.standardml.org would be happy for any contributions.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Philippa Cowderoy
> "Garbage collection for the masses" is yesterday's headline. Java did it,
> C# aped it.
>
Agreed, though check out MLKit's region inference system - no GC required.
I spy
"Ketil Malde" <ke...@ii.uib.no> wrote in message
news:eg7jtzq...@havengel.ii.uib.no...
> "I spy" <s_ned...@yahoo.com> writes:
>
>
> > In OO you identify classes and allocate responsibilities
> > for part of the task to each of the classes
> > [...] Then the classes cooperate to get the task done.
>
> I still maintain that OO usually has the focus on the data structures
> and their interfaces, rather than on the process you want to perform.
> IME, objects are almost always the processees, not the process. I
> think that to some extent, processes are instead captured by design
> patterns.
I have been architecting and designing OO software for 10 years and I have
no idea what you're talking about here. Any OO book that says that OO
focusses on data structures is imparting misinformation. Some of the earlier
OO books used to suggest "start brainstorming classes, writing down the
names of all the 'things' you can think of", so perhaps that's where you got
the idea. But the things being identified have little to do with data -
instead they are about responsibilities (e.g. to take a simple HR example,
what responsibilities does Employee have, what does a Company have, what
does a Project have, etc. Once you've identified the responsibilites, and
only then, does it make sense to sit down and figure out what data and data
structures a class needs in order to get its job done). Which is why many
design sessions today start with CRC (Class Responsibility Collaboration)
cards to get peoples mindsets away from the notion that its about data
structures. The idea that class = data structure is probably the most
damaging idea that ever took hold in OO, and might explain all that Fortran
code out there masquerading as OO.
As for design patterns, where did you get the idea they are about capturing
processes?
cheers
-sri
I spy
Haskell or Scala?
(http://scala.epfl.ch/).
"Brandon J. Van Every" <try_vanevery_a...@yahoo.com> wrote in
message news:2jqh6tF...@uni-berlin.de...
> I spy wrote:
> >
> > Of course despite what some people might be saying in this thread,
> > there is no real reason why functional programming and OO design
> > cannot be used together to mutual benefit.
>
> Sure they can, as in OCaml. But my original motivation in asking my
> question, is that OCaml has a bad interface to low level code (only 31-bit
> ints, no 32-bit floats, funky 2-step C calling conventions) and SML/NJ
> doesn't. The price for what I want is giving up OO. So, I want to know
how
> FP languages 'do things' without OO support.
>
> --
> Cheers, www.indiegamedesign.com
> Brandon Van Every Seattle, WA
>
I spy
"Bijan Parsia" <bpa...@email.unc.edu> wrote in message
news:Pine.A41.4.44+UNC.0406...@login0.isis.unc.edu...
> On Tue, 22 Jun 2004, Brandon J. Van Every wrote:
>
> > > Brandon J. Van Every wrote:
> > >>
> > >
> > > Well, I'm in the process of setting up a repository for SML code so
> > > that there's easy access to SML libraries. [...]
> > > Since I'm doing it privately, there's no way it's going to be
> > > industrial-strength.
> > >
> > > If you're out for something that's got industrial-strength support,
> > > don't rant about those languages that are still in academia.
> >
> > You changed the subject. My comment has nothing to do with whether your
> > personal project is industrial strength or not. I can point you at
> > *legions* of open source C++ or Java or Python projects that are in
exactly
> > the same boat you're in.
> >
> > FP - any language, any form - has had decades to achieve industrial
> > mindshare of some kind or another. It hasn't. That's the bottom line.
> [snip]
>
> XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
> *enormous* mindshare, and it's growing.
>
> That XSLT doesn't *kill* people's taste for FP is a miracle in and of
> itself :)
Huh? I've written good sized XSLT scripts and seen the contortions you have
to go through to get the job done. Give me a good term rewrite engine any
day. Besides, its somewhat apples and oranges to compare XSLT and FP.
Different tools for different jobs
cheers
-sri
Patrick Philippot
> You didn't read past the front page of these web site(s), did you?
> On the SML/NJ front page you find a section on "Documentation and
> Literature". The links lead to information on no less than 9
> tutorials and 19 books. Admittedly, quite a few of them aren't what
> you are currently looking for, but to say that you weren't able to
> locate more than one book is a joke.
:-))) I guess most of them are already on your bookshelf. But just try
to order them or to find them in a computer bookshop. Most are old
things or are out of print.
>> - SML is *extremely* difficult to debug and retro-document.
>
> How much experience do you have with the language?
Not much. But overall, I have a very good experience of programming in
general and I usually adapt very quickly. I may not be SML-wired but
compared to the other tools I have used since years, I insist, it's more
difficult to debug SML. However, it's true that the code that I have to
maintain is not particularly well-commented.
> I find the idea of trying to understand a program by "stepping through
> it" mind-bogglingly ill-conceived (in *any* language).
Your opinion, not mine. In many cases you have no other choice. I would
even say that it's the fastest way to understand a code that is not
correctly documented.
>> - I tried to find some support on Usenet. I found 2 newsgroups:
>> comp.lang.functional and comp.lang.ml. The level of activity in these
>> groups makes me wonder how much developers are using the language.
>> You can't produce without support and obviously, support for SML is
>> scarce.
>
> Instead of ranting here about the lack of support, why did you not try
> asking a specific question? Some people here do try to answer such
> questions! Pissing them off right from the start doesn't sound like a
> great strategy.
Answer irrelevant. I'm not saying that questions are not answered. I
just looked at the activity on comp.lang.ml and was wondering how much
developers where using this language. When I say "no support", this
means:
- no recent books (see above)
- no rich set of companion tools (I was looking for a SML code
beautifier, for example - no such thing)
- no tool vendors
SML is not a language supported by the industry. It is a tool mostly
used by researchers and scientists. Not a criticism. Just a fact. Again,
I'm trying to use this language in the commercial world. I have
deadlines to meet. I'm talking about production.
If I understand well, you're pretty involved in the development of SML.
While this certainly gives you an authoritative opinion on the language
benefits and capabilities, on the other hand, this doesn't qualify you
as the right person for evaluating the difficulties of using SML in the
industry. That's the point. I'm not bashing the language. I'm convinced
it has been pretty well designed in order to solve very difficult
problems. I'm just trying to evaluate whether it can really be used for
the project that I have to maintain given the constraints of my
customer.
I'm not interested in philosophical discussions about what language is
the best. I have used many languages in my programmer's life (APL,
BASIC, Pascal, C, C++, assembly, VB, VB .Net, C#, just to name a few).
None is the best, some are better suited for certain projects than
others. I just want to determine what *solution* is the best for my
customer. And currently, I see many drawbacks in the current SML
approach originally taken in this project given the lack of productivity
tools. The problems that I mentioned are real and are inhibitors for my
current project. They may not be of any importance under different
circumstances.
Cheers.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Bijan Parsia
> "Bijan Parsia" <bpa...@email.unc.edu> wrote in message
> news:Pine.A41.4.44+UNC.0406...@login0.isis.unc.edu...
[snip]
> > > FP - any language, any form - has had decades to achieve industrial
> > > mindshare of some kind or another. It hasn't. That's the bottom line.
> > [snip]
> >
> > XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
> > *enormous* mindshare, and it's growing.
> >
> > That XSLT doesn't *kill* people's taste for FP is a miracle in and of
> > itself :)
> Huh? I've written good sized XSLT scripts and seen the contortions you have
> to go through to get the job done.
Hence my wonder.
> Give me a good term rewrite engine any
> day. Besides, its somewhat apples and oranges to compare XSLT and FP.
Hardly. XSLT is a functional programming language. It's basically syntatic
uglification of DSSSL-O which is a fairly pure functional subset of
Scheme. It's pattern matching oriented, has single assignment, etc. etc.
XQuery has a nicer syntax and an interesting type system etc. etc.
> Different tools for different jobs
Well, except XSLT is perhaps the most widely used FP langauge. So, to some
degree, they are the same tool (though saying "FP" covers so much, it's a
bit odd to compare).
Cheers,
Bijan Parsia.
I spy
> On Wed, 23 Jun 2004, I spy wrote:
>
> > "Bijan Parsia" <bpa...@email.unc.edu> wrote in message
> > news:Pine.A41.4.44+UNC.0406...@login0.isis.unc.edu...
> [snip]
> > > > FP - any language, any form - has had decades to achieve industrial
> > > > mindshare of some kind or another. It hasn't. That's the bottom
line.
> > > [snip]
> > >
> > > XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
> > > *enormous* mindshare, and it's growing.
> > >
> > > That XSLT doesn't *kill* people's taste for FP is a miracle in and of
> > > itself :)
> > Huh? I've written good sized XSLT scripts and seen the contortions you
have
> > to go through to get the job done.
>
> Hence my wonder.
>
> > Give me a good term rewrite engine any
> > day. Besides, its somewhat apples and oranges to compare XSLT and FP.
>
> Hardly. XSLT is a functional programming language. It's basically syntatic
> uglification of DSSSL-O which is a fairly pure functional subset of
> Scheme. It's pattern matching oriented, has single assignment, etc. etc.
Where's the higher order functions? Where's the recursive functions? Where's
the type classes? Where's the type inferencing? All these either
characterize or are pretty much standard with modern day functional
languages. XSLT is just a verbose term rewrite engine, nothing more. And not
a particularly clever one at that.
> XQuery has a nicer syntax and an interesting type system etc. etc.
>
> > Different tools for different jobs
>
> Well, except XSLT is perhaps the most widely used FP langauge. So, to some
> degree, they are the same tool (though saying "FP" covers so much, it's a
> bit odd to compare).
well I disagree with your characterization of XSLT as a functional language
so I can't really comment on the rest of your statement
cheers
-sri
> Cheers,
> Bijan Parsia.
>
Ketil Malde
> I have been architecting and designing OO software for 10 years and
> I have no idea what you're talking about here.
Okay - perhaps I don't really grok OO.
> The idea that class = data structure is probably the most damaging
> idea that ever took hold in OO, and might explain all that Fortran
> code out there masquerading as OO.
So what is a class, then? I happily admit to the belief that it is a
data structure enriched with operations. IME most, if not all, data
an OO program uses is encapsulated in objects. Classes tend to be
nouns, nouns tend to be data. (Especially in contrast to FP where
things tend to be structured around functions, i.e. the verbs. (Also
IME; so I'm probably going to be flamed from the other side as well :-))
(Does Fortran even have data structures other than arrays? :-)
> As for design patterns, where did you get the idea they are about
> capturing processes?
Because from what I've seen, they describe how objects interact in
order to achieve some (somewhat abstracted) process. As you say,
the class structure are defined by identifying 'concepts' and their
responsibilities. They don't tell you how the classes interact,
that's why you have 'use cases' and, I think, at least to some extent,
design patterns.
Perhaps I don't know them well enough; I've only done a little OO, and
that was a while ago.
Brandon J. Van Every
>
> And by the way: I take the "cathedral" thing as a compliment. I never
> bought into this ESR nonsense anyway. I *hate* bazaars in general,
> and the software variety in particular. Just go and have a look at
> all those projects at SF: 90% utter crap, ill-conceived, half-baked,
> full of bugs! And even the ones that aren't crap (including the
> high-profile ones) are almost never original in any way. They are not
> advancing our horizons!
When you refuse to be industrially relevant, whatever originality you may
come up with doesn't make it to 99.9999% of people. You can't advance the
computer industry's horizons that way. You can only advance the horizons of
an exceedingly narrow group of your academic peers.
> There are things that cannot be done well
> bazaar-style. Designing a language or a library API are good examples
> for that.
Growing language communities is a bazaar problem, not a cathederal problem.
In an ideal world, the people who insist on spending most of their time in
the cathederal would at least acknowledge the concerns of those in the
marketplace outside, and take minimal steps to facilitate their
organization. Bazaar people can organize bazaars, but you have to let them,
and minimally coordinate with them.
For instance, if someone complains that they can't find your mailing list,
where does that complaint go? Circular file? Or do you authorize /
deputize someone to edit your webpages?
> In short, I don't care if SML or Haskell or even OCaml or Clean or ...
> will die -- as long as some of the better ideas that went into their
> design make it into future languages and as long as the worst ideas
> survive as warnings for future designers. In this sense the Algol
> analogy is probably true -- and no reason for being ashamed.
So, you write for language designers. Not working programmers. A pity.
With such an attitude, you are unlikely to improve the programming lives of
terribly many people.
Brandon J. Van Every
> Matthias Blume <fi...@my.address.elsewhere> writes:
>
>> Why don't you do it then, Dan? If you feel so passionate about it...
>
> Or Brandon. Or I R T. Document your experiences. Set up a Wiki.
> Mailing lists. Get involved!
I am currently organizing a Seattle ML SIG, as per a post I recently made to
comp.lang.ml. I attempted to produce marketing materials for the Python
community. I have learned from experience, however, that there are certain
things I can't do if the gatekeepers withhold the keys to the kingdom. Like
edit web pages I don't have authorization for.
There are certain things the Powers That Be have to do, in order to build
credible language communities. If the official website of a given language
is not in good order, it's very unlikely that a third party contender can
reverse the negative marketing that generates. You'd have to get to the
size of the Python community before it would be possible to have a 'palace
revolt' and get the traffic to go to your website instead of the broken
official website. And unfortuantely, the people in the Python world who
could have pulled that off, folded up their tent and went home.
> So, if you want SML to be industrially successful, you have to
> contribute the advertising yourself. I'm sure that for instance
> www.standardml.org would be happy for any contributions.
This bodes ill. Both of their listed mailing lists are dead and contain
spam. One is the very same dead list that triggered this subthread! A
viable language community is not happening here.
So which is the easier problem? Getting SML guys to form a viable language
community, or getting the OCaml implementors to fix their broken integer
representation, add 32-bit float support, and clean up the C FFI? Talk
about a rock and a hard place! I think I'm just going to get drunk with
whomever's in Seattle until the answer reveals itself.
Brandon J. Van Every
>
>> I find the idea of trying to understand a program by "stepping
>> through it" mind-bogglingly ill-conceived (in *any* language).
>
> Your opinion, not mine. In many cases you have no other choice. I
> would even say that it's the fastest way to understand a code that is
> not correctly documented.
Or sparsely documented. I've certainly used this approach to understand
other people's open source game projects. Such projects are not too big,
and their flow control is not too crazy. I would say that cranking up the
debugger is appropriate for understanding any project with a "modest main
trunk." A 3D device driver, for instance, may contain huge amounts of code
but probably has a fairly modest main trunk.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
Miguel Oliveira e Silva
> "I spy" <s_ned...@yahoo.com> writes:
>
> (...)
>
> > The idea that class = data structure is probably the most damaging
> > idea that ever took hold in OO, and might explain all that Fortran
> > code out there masquerading as OO.
>
> So what is a class, then?
Quoting from Meyer's Object-Oriented Software Construction
(2ed, pg. 142):
"A class is an Abstract Data Type equipped with a possibly partial
implementation."
> I happily admit to the belief that it is a
> data structure enriched with operations. IME most, if not all, data
> an OO program uses is encapsulated in objects. Classes tend to be
> nouns, nouns tend to be data. (Especially in contrast to FP where
> things tend to be structured around functions, i.e. the verbs. (Also
> IME; so I'm probably going to be flamed from the other side as well :-))
OO is built around abstract data (not data). Interacting with an object
is done through its (class) public interface, and it must obey its contract
(methods/features preconditions). In return the object "ensures" that
the class's invariants and method/feature postconditions are also obeyed.
The implementation of an object data structures and its methods/features
are irrelevant internal issues (from the client's point of view).
All this being said, it is true that when searching for "appropriate"
classes (ADT's), the data (information) eventually used in the problem
space is a much better approach than to look at than the "functions"
of the problem. They are less vulnerable to changes (specially if one
captures "correctly" their abstract properties, and clearly delegates
the responsibilities [contracts] between the class and its clients).
> (...)
>
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants
-miguel
--
Miguel Oliveira e Silva email: m...@det.ua.pt
Dep. de Electrónica e Telecomunicações / IEETA
Universidade de Aveiro - PORTUGAL
phone: +351 234 370375 fax: +351 234 370545
www: http://www.ieeta.pt/~mos
Brandon J. Van Every
> I don't know much about them, but have you looked at languages like O
> Haskell
I have not read that Haskell is high performance, so I wouldn't expect it of
O'Haskell. The main reason I investigated OCaml rather than Haskell is
performance. Also, OCaml seemed more willing to be industrially relevant
than Haskell. Haskell seems oriented towards "very computer sciency
paradigms." I am not sure if those paradigms are valuable or not. I do
know that I need good interfaces down to the ASM level, and grunging with
low level optimization problems seems to bore an awful lot of academics.
> or Scala? (http://scala.epfl.ch/).
Just looked at it now. It lays out webs, networks, and .NET interoperation
as basic motivators - all things I hate and am utterly uninterested in. I
want a language that generates fast native code for low level 3D graphics
and AI problems, but is also a HLL.
Stefan Axelsson
> I had enough problems with Python itself to walk away from it. It really
> isn't the right technology for what I want to do. It may be in 3 to 5 years
> though, when they've sped it up.
Have you tried Psyco? (http://psyco.sourceforge.net/) It made Python
fast enough for my interactive visualisations (that admittedly aren't
game related).
Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Andreas Rossberg
>
> Lexical scoping is
> lexical scoping and it becomes interesting once you have the ability to
> talk about code in a first-class manner, e.g. with inner classes or
> blocks. If you do not implement them as closures, then you automatically
> get dynamic scoping instead of lexical scoping. The issue simply does
> not arise in C++ and in fact, I reiterate that lexical scoping *is* the
> sufficient criterion to make first-class *code* into closures.
There is a difference between lexical scoping and lexical closure. All
remotely modern languages have the former, but only high-level languages
tend to have the latter.
Imposal of restrictions on lexical closure does not turn lexical scoping
into dynamic scoping. Still it means that you do not have proper (full)
closure. I agree that Java is not far away. I just consider the missing
bit very important.
Btw, the issue *does* arise in C++, that's why it has even more
arbitrary restrictions than Java (local functions may only access static
variables of outer scope etc.).
> Java
> literally copies the local variable inside the inner class, essentially
> constructing a closure. However, because
>
> 1) Java combines binding and assignments in one construct, and
> 2) puts local variables on the stack
>
> they have decided to enforce the "final" requirement. The latter makes
> you variable assignment behave like a binding and the array behaves like
> a reference. I never said this is a natural style. I am just pointing
> out that the differences are not all that big because Java *does* copy
> the local variables inside the inner class, just like you expect from a
> closure.
Agreed, but this minor technical difference has major practical impact,
IMHO.
> I agree that in Smalltalk, you
> want to do updates on your local variables from a block. But that is
> mostly because Smalltalk uses blocks in a lot of places where you have
> specific Java mechanisms to cope with it.
That is precisely my point. Why do you need these specific ad-hoc
mechanisms instead of a more generic approach? Because Java's support
for closures is not powerful enough! It can only be used for rather
trivial things.
>> In ML, a "variable" in the imperative sense is called a reference,
>> which is first-class and hence can be passed around independently from
>> any context. In typical imperative languages, variables can only be
>> copied out of context.
>
> I understand this, but I find it bizar to call a variable first-class.
Why?
> You only break appart the notions of binding and assignment.
Breaking apart, or rather decoupling, concepts is exactly what makes
them first class.
> In ML, you
> have binding unless you use a "ref", in Java you have assignment unless
> you use "final".
Some rather philosphical comment: you suggest that both approaches are
somehow dual, but they aren't. In ML, when you need a certain capability
(eg. mutability) you create a value of a type that provides it. In Java,
that capability is always there by default, built into some other,
conceptionally unrelated mechanisms (functions, objects), and you need
sort of a "negative capability" (final) to revoke it. Maybe it's just
me, but I find this backwards, unnatural, and the need for negation
suspicious. The only reason I can see is historical accident.
- Andreas
--
Andreas Rossberg, ross...@ps.uni-sb.de
Let's get rid of those possible thingies! -- TB
Thant Tessman
>
>>Simon Helsen wrote:
>>
>>>To date, in the vast
>>>majority of "real-world" situations, it would be irresponsible (and
>>>just plain dumb) to use SML. That is called pragmatism, a
>>>characteristic that a lot of the FP community lacks. [...]
>>
>>Last time I looked into the issue, memory violations were the single
>>biggest category of software bugs and security vulnerabilities. Who's
>>the ones being irresponsible?
>
>
> "Garbage collection for the masses" is yesterday's headline. Java did it,
> C# aped it.
Yes the fact that Java supports automatic memory management allows it to
avoid the single biggest category of software bugs. But it's hard to
consider this much of an accomplishment given other (better) programming
languages have been doing this for decades.
The popularity of Java in particular is proof that the biggest obstacles
to the advancement of the craft of computer programming are cultural,
not technical. Java is C++ with garbage collection and without all that
complicated template stuff. Although I hear they're adding back some of
that complicated template stuff because it was in C++ for a reason.
> There's no way I could consult SML/NJ with the kind of web presence it
> currently has. Any manager would take one look at those webpages and flee
> in terror. [...]
What kind of manager decides on a programming language based on a web page?
There are reasons I have to use C++ most of the time (and there are
people I work with who would rather I use C instead--I tell them no),
but those reasons aren't ubiquitously preponderate, and I have used SML
for Real Work (TM) in the past, and plan to use it again in the future.
-thant
Lauri Alanko
Thant Tessman <th...@acm.org> wrote:
> not technical. Java is C++ with garbage collection and without all that
> complicated template stuff. Although I hear they're adding back some of
> that complicated template stuff because it was in C++ for a reason.
Except that now it's much less complicated and less bloaty, and in
general Done Right.
(Well, all right, I would have preferred NextGen instead of GJ as the
basis of JSR-14, but you can't have everything...)
Lauri Alanko
l...@iki.fi
Bijan Parsia
> "Bijan Parsia" <bpa...@email.unc.edu> wrote in message
> news:Pine.A41.4.44+UNC.0406...@login2.isis.unc.edu...
> > On Wed, 23 Jun 2004, I spy wrote:
[snip]
> > Hardly. XSLT is a functional programming language. It's basically syntatic
> > uglification of DSSSL-O which is a fairly pure functional subset of
> > Scheme. It's pattern matching oriented, has single assignment, etc. etc.
> I'm having a hard time seeing how you can call XSLT a functional language.
This is getting silly:
http://www.topxml.com/xsl/articles/fp/Default.asp?printerversion=true
> Where's the higher order functions? Where's the recursive functions?
These are sorta there with pain. XSLT is crippled, no doubt. But anyway.
> Where's
> the type classes? Where's the type inferencing? All these either
> characterize or are pretty much standard with modern day functional
> languages.
[snip]
Well, if we rule out Scheme, ok, fine. Some versions of Erlang would fail
hard too. I'll stick with XQuery for my point. My point was that
functional and functional like programming languages and FP inspired
things have quite a bit of mindshare and it's growing fast. (XQuery is
quite the buzz at the moment.)
I notice that the person I was responding to (who made the claim that FP
had no industrial mindshare) hasn't commented (either to riposte or
concede). In any case, drop out XSLT and he's still refuted (IMHO). Put it
in, and he's refuted all the more :)
Cheers,
Bijan Parsia.
P.S., I'm not convinced by the article I pointed to above. The tact seems
a bit wrong. Anyway.
William Lovas
> Patrick Philippot wrote:
>>
>>> I find the idea of trying to understand a program by "stepping
>>> through it" mind-bogglingly ill-conceived (in *any* language).
>>
>> Your opinion, not mine. In many cases you have no other choice. I
>> would even say that it's the fastest way to understand a code that is
>> not correctly documented.
>
> Or sparsely documented. I've certainly used this approach to understand
> other people's open source game projects. Such projects are not too big,
> and their flow control is not too crazy. I would say that cranking up the
> debugger is appropriate for understanding any project with a "modest main
> trunk." A 3D device driver, for instance, may contain huge amounts of code
> but probably has a fairly modest main trunk.
I would say that debugging by stepping is chiefly used with imperative
code. The more expression-oriented your code becomes, the less meaningful
"stepping" becomes. c.f. John Backus's Turing Award Lecture on the von
Neumann bottleneck.
cheers,
William
beli...@aol.com
> (Does Fortran even have data structures other than arrays? :-)
Fortran has had data structures (called "derived types" (DT)) since
the 1990 standard. You can use DT's as procedure arguments and
function results, create arrays of DT's, and overload operators such
as '+'. Members of DT's can be declared public or private.
Fortran 2003 adds further support for object-oriented programming. I
believe it has single but not multiple inheritance.