Re: Current work in compiler/language design.

>I am a programming languages 'person' and after covering
>the field, OO beats all other existing methodologies in almost every
>respect, and if it doesn't, I can just add it as a new OO feature.


Apart from being incorrect, this rings alarm bells everywhere. You *can't*
get every feature you want just by adding it to the OO paradigm, and you
should realise that adding features left right and centre isn't a good way
of approaching any problem.


>Do you see a
>special logic or functional programming journal addition to sigplan


I thought an SML one was on the cards, but I don't know the details. There
are numerous functional programming journals anyway (including, erm, the
"Journal of Functional Programming" :-))


Isn't there a FORTRAN journal in SIGPLAN? Does that make it good? Having a
journal might reflect the popularity of a language or system, but this
isn't necessarily a measure of technical merit, especially when "fashion"
is involved (and, with OOP, I believe it is - see below).


>Functional programming solves mathematical problems in a clean way. Is
>this general purpose? No, it leaves out simple statement sequences and
>and only allows single (constant) assignments, this has yet to be shown
>that it can solve even simple problems (i.e. violates every software
>engineering principle I can think of except provable code), let alone
>complex ones (just ask a functional programmer if they would like to
>bootstrap their compiler, they'll tell you they wrote it in C and it will
>stay that way (unless they upgrade to C++)).


Not to sound too harsh here, but I consider your views here to be wrong in
every major respect.


Firstly, you give no reasons why you consider statement sequencing and
updateable assignment to be necessary. (I consider the main weakness of OO
systems to be the implicit state in the objects themselves, leading to
bugs as growing applications come to rely on the undocumented sequenced
behaviour of the components.) (The other main weakness in the systems I've
used is the lack of secure storage management, but this is not a weakness
of OOP itself, and languages like Eiffel do this properly.)


Secondly, functional programs do solve problems, be they simple or be they
several tens of thousands of lines of code. I can cite examples, including
commercial products. Thirdly, give me one software principle that
functional programming violates. Fourthly, explain why functional
languages are bad for complex tasks (assuming you have a polymorphic type
discipline and a reasonable modules system). Fifthly, I know a number of
functional language compilers written in functional languages (often
themselves): SML/NJ is written in SML, Poly/ML is in Poly, CAML/ZINC is
written in itself, Emacs Lisp is self-compiling, and so on.


Yes, functional language compilers often use C for runtime support.
Conventional compilers use assembly language. So what? Compilers rely on
such runtime support to provide parts of the abstract machine interface
they're compiling to. This makes C and/or assembler good tools for this
purpose, due to allowing low-level access to the machine and/or a simple
model of memory access. That's all.


OO is nice in a lot of ways, and I've used it extensively. However, it is
not suited for a lot of things, and other paradigms are a lot better in
other respects (provability being an important one, in fact).


An important point about OOP has already been made. It's fashionable, and
this is because it comes along with merits which are *not new* to OOP, but
are coming into a world which hasn't seen them yet. Read Meyer's Eiffel
book closely. He gives the benefits of OOP at great length and in great
detail. From Chapter 1 up until about Chapter 10, *EVERY* benefit he cites
of OOP is true of Standard ML, which is not remotely OO. Only then (with
inheritance and subtyping) does he get into OO-specific areas.


>How about LISP based systems (boy do I expect it here): Are they general
>purpose? Not really, they are interpreted and run several hundred times
>slower than compiled code (although this could change). They usually
>don't have static typing, so you have no choice, dynamic typing or naught.
>They have an unnatural syntax, big violation here. Recently, they claim
>to have 'Multi-Methods' and claim they are more powerful than method
>passing in traditional OO. But, these are just function calls at
>run-time, and their system works at run-time, so what are they really? you
>guessed it, function calls! If you add dynamic typing to C++ guess what
>you get when you invoke a function dynamically??? This is not better than
>object-oriented message passing, in fact, this is a joke. As far as other
>nice features of Lisp based (OO) languages, functional, logic, etc., just
>identify them, if they're useful we can add them to almost any programming
>language. Want logic-style pattern matching, type inferencing, user
>defined control-structures, meta-level access, just ask or provide, don't
>go to something really weird(unusable).


I don't think you have a valid technical point to make here. You're mixing
up features, implementation techniques, performance issues with no
consideration of the levels of abstraction inherent in any language system
or its implementation. You're trying to argue merits of a language by
arguing about implementation techniques for the most part, and this is
just invalid. What's more, you don't seem to be at all familiar with the
state of the art when it comes to functional language implementation
styles and techniques. I suggest you at least track down the SML/NJ papers
from Princeton and/or Bell Labs to see (some of) what you've been missing.


                Nick.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.