Re: Writing A Plain English Compiler

On Wed, 05 Nov 2014 00:54:18 -0600, Joshua Cranmer ?
<Pidgeot18@verizon.net> wrote:


>On 11/4/2014 3:50 PM, Gerry Rzeppa wrote:
>> Having worked with a wide variety of traditional languages, and having
>> written a number of compilers together, we knew that a practical procedural
>> programming language could be concocted with just five types of statements:
>>
>> 1. Type definitions;
>> 2. Global Variable definitions;
>> 3. Routine Headers;
>> 4. Conditional Commands; and
>> 5. Unconditional Commands.
>
>Honestly (and I mean no disrespect), this doesn't feel like "practical
>procedural programming language" but "C or maybe Java." Personally,
>I've never felt that distinguishing between procedural, imperative,
>object-oriented, functional, etc. is terribly useful because the major
>modern languages end up being a complex mismatch of everything. I mean
>C++ and Java both now have lambdas, and C++ is even talking about
>coroutines the other day.


Lambdas in C++ and Java are merely ad-hoc objects. It's true that
objects and closures are isomorphic, but the manner in which they are
provided creates differences in idiomatic use and utility.




>Essentially, I find your categorization troubling because you're
>assuming a particular, very specific way of looking at
>programming--and a model that's not necessarily reflective of most
>large-scale programs (where object-oriented code rules the day).


OO has it's place, but it isn't any kind of universal solution. There
is a large class of problems that are not a good fit.


I frequently am amazed at the contortions Java programmers go through
to solve problems within the restrictive OO model. IMO, "Design
Patterns" was an admission that too many programmers couldn't use Java
to solve routine programming problems.
[That's as much an indictment of the lack of CS education among
programmers. Java - somewhat successfully - tried to pander to less
educated programmers by making simple things simpler, but in doing so
it made solving many real problems more complicated.]


IMO, the utility of a language is measured by how easily it bends to
fit the problem. I try to avoid using languages that unnecessarily
force the problem to bend.




>A good example of where things really break down is in the
>introduction of parallelism. Many (all?) languages these days have put
>some emphasis on trying to decide good parallelism and concurrency
>models at increasingly fundamental positions in the language.


Most of which are ineffective.


CSP (ala Hoare) works well for well structured problems: i.e. chained
"bucket brigade" solutions and solutions that can be cast as
map/reduce. However, more general, less well structured problems that
require frequent and/or complex coordination patterns among tasks
still are difficult to code.


Shared data structures general are a disaster - it's well known that
the majority of programmers are unable to write a correct solution
that involves shared data. However, programmers are enamored with
shared memory threads and so languages/libraries "help" by including
synchronization "primitives". Unfortunately, those "primitives" tend
to be anything but - often they are extremely slow due to their
generality. Where light weight special purpose primitives are
available, they often are eschewed because programmers don't
understand where, when and how to use them correctly.


Functional languages operating on immutable data are inherently
parallel at various granularities. But effective use of fine grain
parallelism has proved difficult because available hardware is not
optimized for it. Moreover immutable data structures often are far
more costly to manipulate than are their mutable versions.




>I believe there's a widespread consensus that shared multithreading
>isn't good enough, but while there are models of more structured
>constructs (e.g., OpenMP, which does explict task parallelism), I
>can't speak to how often those get used in practice in major systems.


OpenMP is an example of the CSP model. It is used extensively in big
science coding (with well structured problems). Erlang is another
example that sees a lot of use in telecommunications where the tasks
are numerous but are largely independent.
[Scala is a language based largely on Erlang that targets the JVM.]




Dataflow languages (Lucid, Oz, etc.), constraint logic (Prolog, etc.),
and explicit coordination languages (Linda, Occam, etc.) solve the
coordination issues of unstructured problems, but they are not
popular. [Note that some of the examples above fall under multiple
categories.]


The dataflow and logic languages tend to be limited to shared memory
systems, declarative and functional (which puts off many people), and
rely on unfamiliar computation models and/or extra-logical constructs
(which further puts off people).


Coordination languages tend to be more familiar looking ... but some
like Occam are too closely associated with hardware that no longer
exists, and others like Linda rely on associative memory that (even
distributed) can become a bottleneck for a large system.




>Certainly, I think the academic community heavily desires the use of
>"structured" parallelism instead of "unstructured" (much as we prefer
>structured control flow over the goto statement), but industry best
>practices can lag a bit or a lot.


CSP handles structured problems quite well. The real issue is that
there are too many problems that are not well structured. The
academic community recognizes this, but has produced few viable
solutions and none that scale well.




>What [Gerry Rzeppa et all] have done is not used English as a
>programming language. What you did was start with a semantic
>definition of your language and work out a syntax for it that
>happens to be a subset of the English language.


+1




>In other words, now you have an example of event-driven programming!


There are languages specifically designed for event programming. They
also tend to be niche and unpopular.




>The reason I bring this all up, though, is that you make a conceit in
>your Indiegogo page that the importance of what you're doing is that
>you want "scientists, engineers, programmers and many others [ ... ]
>to simply write down what they're thinking, in the way that's most
>natural." And the way that's most natural is not necessarily
>procedural programming--sometimes you can express stuff most naturally
>in an event-driven model, perhaps a functional model, or maybe an
>actor model. And that's why the major programming languages of today
>are all multi-paradigm languages (and even continually expanding their
>paradigms)--because, in the end, sometimes it's better to structure
>portions of a program in different paradigms.


What's important is problem solving logic - the language used to
express the logic of the solution may either help or hinder the
implementation.


Most natural languages are a hindrance to logic because they are
inherently ambiguous. There is some anecdotal evidence that Sumerian
might have been sufficiently unambiguous to program with, but the
issue is moot because no one today speaks it.




>Now, to some degree, a Turing-complete language can emulate any other
>Turing-complete language, even if the two are completely different,
>incompatible paradigms. That doesn't mean it's a wise idea though, and
>you can lose a lot of expressiveness and simplicity in such a
>conversion.


Any Turing-complete language *can* emulate any other (and also any
sub-Turing language). Expressiveness of the language is important to
programmer productivity but does not affect capability.


E.g., anything you can write in Lisp you also can write in assembler
... assuming you have unlimited time on your hands.


George

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