Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.misty.com!news.iecc.com!.POSTED!nerds-end From: =?UTF-8?Q?Joshua_Cranmer_=f0=9f=90=a7?= Newsgroups: comp.compilers Subject: Re: Writing A Plain English Compiler Date: Sat, 08 Nov 2014 10:48:09 -0600 Organization: A noiseless patient Spider Lines: 80 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-11-018@comp.compilers> References: <14-11-004@comp.compilers> <14-11-005@comp.compilers> <14-11-012@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: miucha.iecc.com 1415474550 11752 2001:470:1f07:1126:0:676f:7373:6970 (8 Nov 2014 19:22:30 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 8 Nov 2014 19:22:30 +0000 (UTC) Keywords: design, parallel Posted-Date: 08 Nov 2014 14:22:29 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1426 On 11/7/2014 3:23 PM, George Neuner wrote: > On Wed, 05 Nov 2014 00:54:18 -0600, Joshua Cranmer ? > 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