Re: Writing A Plain English Compiler

On 11/7/2014 3:23 PM, George Neuner wrote:
> On Wed, 05 Nov 2014 00:54:18 -0600, Joshua Cranmer ?
> <Pidgeot18@verizon.net> wrote:
>> 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 its place, but it isn't any kind of universal solution. There
> is a large class of problems that are not a good fit.


I apparently didn't state this very well in my original post, but my
personal opinion is that there is no "one true paradigm" but rather a
set of paradigms best suited to different tasks. IMHO, programming
languages ultimately need to have a collection of paradigms that it
supports well, and for languages targeting large applications, OO is
one (but not the only one) of the ones that absolutely needs to
supported.


> 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.


I won't deny that parallelism is a problem for which a good solution
does not yet exist. But we've reached an age where it's a problem that
can't be solved by sticking your head in the sand--and a solution that
allows you to solve some problems well is better than one that allows
you to solve nothing.


I think it's clear that the mutable shared model and
mutex/condvar/etc.-based building blocks as the only level of support is
a, well, disaster, as you put it. Immutable data I think has also been
shown to be a complete non-starter. Sometimes when your parallelism is
completely centered on very large mutable, shared data structures, and a
solution that completely prevents that from being used is untenable. At
the same time, shared mutable memory is a definite lightning rod for
disaster--maybe having "unsafe" blocks isn't such a bad idea. :-)


I think actor models (which is basically CSP?) appear to be winning out,
but, as you say, they're not completely sufficient. If I had to make a
bet, it would be on an actor-based model with some support for
cross-thread shared data collections. But I would be hesitant to wager
very much even on that.


You've failed to mentioned transactional memory. There are also things
like Concurrent Collections which I'm hard-pressed to place, particular
since I'm vague on the details (maybe dataflow?).


> 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.


There's an issue not strictly related to ambiguity that I realized
when reading Gerry's examples. English (and presumably other natural
languages, but I'm not enough of a linguist to say with any
confidence) allows you to reliably refer to one, sometimes two, things
without naming them. At the same time, it makes it cumbersome to name
a temporary object.


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


I prefer Brainfuck as the go-to "unprogrammable" language. :-)


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

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