On Sat, Jul 27, 2013 at 10:29 AM, Jonathan S. Shapiro <[email protected]>wrote:
> > 1. Is a *great* general-purpose language that > > This is a perilous way to start a great topic. For certain we all want a great language, but we would be agreeing with our own definitions of a great language, not each-other! :) My definition of a systems programming language is one which enables/allows: 1. ... compilation and distribution of modular binary components, which are independently developed and updated in a backward-compatible way. This is necessary to achieve a systems-level-ecosystem, rather than merely a program ecosystem. Without this capability, we have a whole-program embedded system development kit. 2. ... raw access to CPU features, hardware IO, explicit in-memory data-layouts, and explicit memory addresses. (not only for kernel-drivers, but also for direct access to syscall interfaces, shared memory, MMU tables, and some types of hardware interfaces which allow user-land preparation of commands bound for hardware) 3. ... the capability to author software which can reach the full potential of the hardware, without "dropping into another language". This includes no achilles heels, such as loss of memory-layout-control, introduction of stop-the-world-pauses, or other impediments to controlling the final behavior and expression of the program. My definition of a *good* programming language is task-dependent, and is one which: a. ... allows us to express a specific program we wish to express b. ... enabling a chosen tradeoff between flexibility and safety c. ... enabling a chosen tradeoff between coding-efficiency and readability d. ... and which achieves our goals WRT SLA/latency and third-party interfacing For me, it is (3/d) which have thus-far made garbage collection unsuitable for systems programming. Typical garbage-collection compromises are fantastic for *certain* applications, but I do not consider them systems programming languages, because when (3/d) rears it's ugly-head our only choice is to jettison the entire runtime and switch to something which meets my definition of a systems programming language. Azul C4 may solve (d) but does not solve (3). ---------- I've been hearing that argument for 35 years now. During those 35 years, > I've heard only two or three design pattern scenarios in which (assuming a > properly implemented GC) the programmer had any business caring about this. I do not understand this diminutive characterization. Is one of your "two or three design patterns" nearly all user-facing GUI software? *Today* *all* end-user facing GUI software is either not garbage-collected, or relies on significant components which are not garbage collected -- because the GC pauses are unacceptable to meet desired user-interaction latencies, and we have no widespread technology to remove them. AFAIK, there has never been a fully, or even substantially garbage collected GUI system which meets desired user latencies. AFAIK, the only popular user-facing GUI systems which include GC at all are: (a) browsers, which are substantially C/C++ with small non-global GC heaps in JS, (b) Android, which I argue does not meet desired user latencies in most Dalvik/GCed applications, instead relying on native code; (c) general scripting extensions to large C++ codebases, which are substantially like "a". On the other hand, we can count numerous user-facing systems which have tried to more fully use GC and all had undesirable pauses which have not been fixed to this day. The interactive LISP, Smalltalk, SELF environments had notorious garbage collection pauses. The original HotJava browser had notorious garbage collection pauses. The Apple Newton was notoriously pausy. J2ME was notoriously pausy. .NET client apps are notably pausy (so it's generally only used for raid-development enterprise apps). Android and Dalvik are notoriously pausy, and offer native APIs to get around it. Apple experimented with full GC then openly rejected it for iOS/MacOS. MSFT rejected .NET as the basis for windows-7 (we can only speculate why, but I say GC pauses). So if your "two-or-three design patterns problematic for GC" includes nearly all GUI software, then I agree. If not, well, I don't know where that 35 years of facts came from! :) I've been really excited since Azul C4 appeared to see a GUI system turn this all on it's head. Sadly AFAIK it's not possible to implement C4-techniques on windows, Android, or iOS... and the C4/JVM is unsuitable for systems programming for other reasons.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
