Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #479 > unrolled thread

Have we reached the asymptotic plateau of innovation in programming language design?

Back to article view | Back to comp.compilers

Contents

  Have we reached the asymptotic plateau of innovation in programming language design? Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 13:52 +0000
    Re: Have we reached the asymptotic plateau of innovation in programming language design? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-03-08 00:44 -0600
      Re: Have we reached the asymptotic plateau of innovation in programming language design? torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-14 09:51 +0100
        Re: Have we reached the asymptotic plateau of innovation in programming language design? Gene Wirchenko <genew@ocis.net> - 2012-03-19 08:00 -0700
          Re: Have we reached the asymptotic plateau of innovation in programming language design? torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-21 11:53 +0100
            Re: Have we reached the asymptotic plateau of innovation in programming language design? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-03-22 21:17 +0100
            Re: Have we reached the asymptotic plateau of innovation in programming language design? jgk@panix.com (Joe keane) - 2012-03-23 19:45 +0000
      Re: Have we reached the asymptotic plateau of innovation in programming language design? eijkhout@tacc.utexas.edu (Victor Eijkhout) - 2012-03-19 15:42 -0600
        Re: HPC and parallel programming, was Have we reached the asymptotic Marco van de Voort <marcov@toad.stack.nl> - 2012-03-21 10:28 +0000
    Have we reached the asymptotic plateau of innovation in programming la SLK Systems <slkpg3@gmail.com> - 2012-03-08 10:21 -0500
      Re: Have we reached the asymptotic plateau of innovation in programming la BGB <cr88192@hotmail.com> - 2012-03-09 18:16 -0700
        Re: Have we reached the asymptotic plateau of innovation in programming la glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-12 07:42 +0000
          Re: Have we reached the asymptotic plateau of innovation in programming la BGB <cr88192@hotmail.com> - 2012-03-13 02:27 -0700
            Re: Have we reached the asymptotic plateau of innovation in programming la glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-14 05:19 +0000
              Re: Have we reached the asymptotic plateau of innovation in programming la BGB <cr88192@hotmail.com> - 2012-03-15 00:06 -0700
            Re: Have we reached the asymptotic plateau of innovation in programming la torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-14 09:24 +0100
      Re: Have we reached the asymptotic plateau of innovation in programming languages? "robin" <robin51@dodo.com.au> - 2012-03-11 21:09 +1100
      Re: Have we reached the asymptotic plateau of innovation in programming languages Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> - 2012-06-06 17:38 +0000
        Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-06 22:40 +0000
          Re: Have we reached the asymptotic plateau of innovation in programming languages Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-06-07 08:00 -0400
            Re: Have we reached the asymptotic plateau of innovation in programming languages Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> - 2012-06-07 17:21 +0000
              Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-08 22:31 +0000
              Re: Have we reached the asymptotic plateau of innovation in programming languages Martin Ward <martin@gkc.org.uk> - 2012-06-10 10:42 +0100
              Re: Have we reached the asymptotic plateau of innovation in programming languages Alex McDonald <blog@rivadpm.com> - 2012-06-10 13:36 -0700
                Re: Have we reached the asymptotic plateau of innovation in programming languages "robin" <robin51@dodo.com.au> - 2012-06-11 20:21 +1000
                Re: Have we reached the asymptotic plateau of innovation in programming languages Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-06-11 18:18 +0200
            Re: Have we reached the asymptotic plateau of innovation in programming languages Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2012-06-08 16:16 +0200
        Re: Have we reached the asymptotic plateau of innovation in programming languages "BartC" <bc@freeuk.com> - 2012-06-07 14:20 +0100
          Re: Have we reached the asymptotic plateau of innovation in programming languages Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-06-07 16:06 -0400
            Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-08 22:47 +0000
        Re: Have we reached the asymptotic plateau of innovation in programming languages "robin" <robin51@dodo.com.au> - 2012-06-08 00:03 +1000
          Re: Have we reached the asymptotic plateau of innovation in programming languages Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> - 2012-06-07 18:01 +0000
            Re: Have we reached the asymptotic plateau of innovation in programming languages Lieven Marchand <mal@wyrd.be> - 2012-06-09 17:24 +0200
        Re: Have we reached the asymptotic plateau of innovation in programming languages torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-06-11 13:41 +0200
          Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-11 22:13 +0000
            Re: Have we reached the asymptotic plateau of innovation in programming languages "robin" <robin51@dodo.com.au> - 2012-06-13 01:16 +1000
    Re: Have we reached the asymptotic plateau of innovation in programming language design? "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-03-08 19:54 +0000
    Re: Have we reached the asymptotic plateau of innovation in programming language design? George Neuner <gneuner2@comcast.net> - 2012-03-08 17:41 -0500
    Re: Have we reached the asymptotic plateau of innovation in programming language design? Ian Lance Taylor <ian@airs.com> - 2012-03-08 17:02 -0800
      Re: Have we reached the asymptotic plateau of innovation in programming language design? Cameron McInally <cameron.mcinally@nyu.edu> - 2012-03-08 23:40 -0500
        Re: Have we reached the asymptotic plateau of innovation in programming language design? thomas.mertes@gmx.at - 2012-03-11 07:33 -0700
      Re: Have we reached the asymptotic plateau of innovation in programming language design? Michael Dunlavey <mikedunlavey44@gmail.com> - 2012-03-09 16:07 -0500
      Re: Have we reached the asymptotic plateau of innovation in programming language design? BGB <cr88192@hotmail.com> - 2012-03-09 21:14 -0700
    Re: Have we reached the asymptotic plateau of innovation in programming language design? Rock Brentwood <federation2005@netzero.com> - 2012-03-17 12:31 -0700
      Re: Have we reached the asymptotic plateau of innovation in programming language design? BGB <cr88192@hotmail.com> - 2012-03-18 02:35 -0700
      Re: Have we reached the asymptotic plateau of innovation in programming language design? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-03-18 20:35 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#492

On Friday, March 9, 2012 5:40:18 AM UTC+1, Cameron McInally wrote:
> On Thu, Mar 8, 2012 at 8:02 PM, Ian Lance Taylor <ian@airs.com> wrote:
> > Rui Maciel <rui.maciel@gmail.com> writes:
> >
> >> - And here's the first itchy point: there appears to be no correlation
> >> between the success of a programming language and its emergence in the
> form
> >> of someone's doctoral or post-doctoral work. This bothers me a lot, as an
> >> academic. It appears that deep thoughts, consistency, rigor and all other
> >> things we value as scientists aren't that important for mass adoption of
> >> programming languages.
> >
> > As a non-academic, I agree.  None of those things matter very much to me
> > when it comes to actually getting stuff done.  They are not bad things
> > to have, but they are not the things that matter.

When somebody writes about my project I can easily tell, if he/she is
from the academic or not-academic area. People who obviously only read
the FAQ and tell me that I do not understand the stuff, which is
already implemented, often turn out to be from the academic area.
Nitpicking from the FAQ, comparing egos and knowledge seems to be
easier than downloading and trying. Don't get me wrong, I have a lot
of respect for the academic area, since I studied myself and got a
Ph.D in computer science. People from the non-academic area often
already tried my project and ask for specific functionality like
unlimited precision integers, select for sockets, font support or how
to write a web application. Funny: People from the non-academic area
seem to explore new stuff, while academic people criticize me, because
I do not jump on an existing computer science fashion.

> This summarizes my empirical experiences well. Programming languages
> appear to grow organically, as if they were species. There are many
> dialects, from many tribes. Sometimes, a new language feature is
> created out of utility. If that feature is very useful, it spreads to
> different dialects. Later, theorists study the phenomena and define it
> formally. Sometimes, out of utility, a language feature is created by
> a tribe. Other tribes may not find this feature particularly useful.
> It becomes a regional colloquialism or dies off.

Totally agree. This is also my view. I see extensible programming
languages as part of the picture. Language evolution is supported by
extensible programming languages, because it is not necessary to
improve a compiler, just to get a feature from another language.  The
problem is: Extensibility is not a feature which can be added
afterwards. A language must be designed from ground up to be
extensible.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#487

Responding to postings by Rui Marcel and Ian Lance Taylor:

Is there a plateau? In C.S. grad school my fellow students and I were
proud that we were limited only by our imaginations. I've since come
to realize, at least in my case, that's a pretty severe limit.
Industry is a font of interesting, challenging, real-world problems
that could have served us well, but to which we had no exposure.

Later I taught at the college level for 4 years, but after that spent
the rest of my career in industry. I think C.S. academia is seriously
out of touch with reality. There needs to be a much stronger two-way
flow of information between industry and teaching than there is now in
C.S. My experience as an engineering student in Mechanical Engineering
and Civil Engineering was far different, in which partnership with
real practitioners brought a flood of realistic problems to solve into
the academic world, enriching it immeasurably.

I felt strongly enough about this that I wrote a book: "Building
Better Applications" which did not sell very well, but at least got my
ideas out there, which revolved around the application of information
theory as an underlying "physics" of computation. This affects two
areas in particular - performance tuning and
domain-specific-languages. These are not just "academic" matters, they
are very important in real software engineering.

Performance tuning is important because, while students are taught all
about big-O and algorithms, they write monstrously complicated systems
in industry that are orders of magnitude slower than need be, in
constant factors. They do not know how to tune for performance. They
have been told profilers are pretty good for that, starting with
gprof. It is hard to be charitable about this, but even the original
authors of gprof did not claim it was good for much. The only way I
can explain this is that the people teaching about profilers have
never had to significantly optimize a real piece of industrial
software.

Domain specific languages are important because, when properly done
(which they often are not) they allow programmers to achieve results
with one or two orders of magnitude less code and bugs, with far
better maintainability. What happens in academia instead is people are
following the latest butterfly - functional programming, logic
programming, whatever buzzword they think they can latch on to and
join friends to write papers surveying so they can puff their
publication count so they can get tenure. Just once they should go
participate in a real programming team and see what the real problems
are and see if they can do anything to help.

Grrr... ;-)

Michael R. Dunlavey, Ph.D.

[toc] | [prev] | [next] | [standalone]

#490

On 3/8/2012 6:02 PM, Ian Lance Taylor wrote:
> Rui Maciel<rui.maciel@gmail.com>  writes:
>
>> - And here's the first itchy point: there appears to be no correlation
>> between the success of a programming language and its emergence in the form
>> of someone's doctoral or post-doctoral work. This bothers me a lot, as an
>> academic. It appears that deep thoughts, consistency, rigor and all other
>> things we value as scientists aren't that important for mass adoption of
>> programming languages.
>
> As a non-academic, I agree.  None of those things matter very much to me
> when it comes to actually getting stuff done.  They are not bad things
> to have, but they are not the things that matter.

much agreed.

I have also have also had some arguments revolving around "originality"
and "minimalism", both of which being goals I didn't find particularly
important, but some people take these fairly seriously.

like, what really is the problem if the language has a
conventional-looking syntax, and a potentially "not as simple or elegant
as it could be" implementation? most developers probably don't care too
much, otherwise C++ and C# probably wouldn't be nearly as heavily used
as they are currently, and one can infer that both are probably at least
doing *something* right.


much like things like "user defined syntax" and similar:
how is the typical programmer (or nearly anyone, for that matter) going
to value by having PEG integrated into the language syntax/parser?
I actually tend to think this idea is a misfeature.

a better idea IMO (for allowing DSL's, ...) is to allow an independent
parser with an independent (albeit presumably fixed) syntax. this could
mean a PEG-based parser or whatever which is deliberately invoked to
parse/evaluate the new syntax.

the above could be aided via the use of block-string syntax:
myParserEval("""
lots of code and stuff...
""");
or:
myParserEval(<[[
lots of code and stuff...
]]>);

I also don't feel this is a particularly severe limitation.


>> - So one pertinent question is: given that not much seems to have emerged
>> since 1979 (that's 30+ years!), is there still anything to innovate in
>> programming languages? Or have we reached the asymptotic plateau of
>> innovation in this area?
>
> As others have mentioned, there may be some good ideas to come in the
> area of safer and more efficient parallel programming.  I like the CSP
> model, but perhaps there is something better.  I personally think the
> model of threads, mutexes and condition variables has so far proven too
> difficult to use correctly for most programmers.  That goes double for
> the atomic operations and barrier model.  And functional and dataflow
> programming languages do not appear to have gotten much adoption in
> practice.


in my case, I am actually using a mix of threading and message passing.

the main way this differs from CSP is mostly that message
sending/receiving is typically asynchronous and non-blocking (and
accomplished via explicit message-channel objects).

mutexes are also available, in addition to the "synchronized(obj) { ...
}" syntax used by Java.

however, as-is, this area hasn't gotten as much use or development in my
case, as my use-cases tend to be better served by the use of an
event-driven programming style than by the use of explicit concurrency
features.


> I also think there is more room for thought about programming in the
> large.  Many software shops these days are huge, producing programs that
> are far too large for anybody to keep in their heads.  As a side-effect,
> many programmers spent a lot of time performing maintenance of various
> sorts.  What can languages do to help?  Refactoring is just the most
> obvious example in this space, and even there it is clear that some
> languages support refactoring far better than others.  Other areas
> related to language are speed of development, dependency management,
> ease of debugging, modularity, ease of performance analysis, no doubt
> many more.

potentially.

in my case, I haven't really been designing things in terms of
particular objectives, but more in terms of what things seem interesting
to myself, or are being an annoyance, or could be helpful with the task
at hand.

so, I made what is mostly a scripting language, and ended up bolting on
features intended mostly for scale / writing "industrial strength" code,
much of which has ended up amounting mostly to syntax sugar (and/or some
amount of micro-optimizing).


for a while, I have been stuck in an "inter-JIT period" as my old JITs
basically fell into being non-functional (and I was stuck mostly with an
interpreter, albeit I did migrate from the use of a "big-switch" based
interpreter to the use of threaded code a while ago). most of this was
due to "bit rot" and a lot of this stuff not really being a huge
priority (my VM internals have changed significantly since the time the
last JIT still worked, and my prior JITs were very hackish and
inflexible, one getting hopelessly out of date, and the other being
seemingly nearly impossible to debug).


recently (as in, mostly last weekend) I got around to mostly
implementing a new JIT, but it is still a bit far from being usable or
complete (large chunks of the ISA are stubs, many cases are not
implemented, ...).

but, performance hasn't been a huge killer, and in many cases native
code was still being generated (even if the bulk of the execution/ISA is
still being handled by the interpreter).

(ironically, the natively generated code tends to use a larger slice of
the total execution time than the interpreter proper, at least according
to the profiler...).


however, it doesn't sound all that impressive to be like "yeah, the
language runs in an interpreter and is around 100x slower than native C
code..." (along with "yeah, most of my 3D engine is also written in
plain C, with the scripting language mostly used for misc stuff, like
scripting and eval and similar...").

but, much more impressive-sounding would be like "it has all of these
nifty dynamic features and operates nearly as fast as C", even if, at
this point, this claim would be a bit unrealistic.


side note:
the new JIT uses "function at a time" compilation, using a modified ABI
(similar to cdecl on x86 and the Win64 ABI on x86-64, but using EBX and
RBX for passing the VM context, with things like "this" and non-local
scope being accessed indirectly via this context), as well as some
amount of link-time code generation. technically, a given function only
holds its own locals and arguments, and depends on the VM context for
nearly everything else (the currently generated code is also a bit
naive, but I am resisting the urge to try to micro-optimize it at least
until the thing is fully implemented and working).


but, "scripting" and "interfacing with C" remain as its driving
use-cases, and "looking sort of like C" as a secondary use-case.

[toc] | [prev] | [next] | [standalone]

#508

On Mar 7, 5:52 am, Rui Maciel <rui.mac...@gmail.com> wrote:
> Quotes:
> - But the truth of the matter is that ever since I finished my Ph.D. in the
> late 90s, and especially since I joined the ranks of Academia, I have been
> having a hard time convincing myself that research in PLs is a worthy
> endeavor.
> So, what are your views on this subject?
>
> Rui Maciel
> [Personally, I'd say there's been precious little new in programming
> languages since Simula gave us OOP in the late 1960s.  In your responses,
> please remember this is comp.compilers, not comp.semicolon-placement.flame.
> -John]

The answer is simple: whenever and wherever you hear such a question
posed, no matter what the context or situation, no matter what the
issue, it is *always* a clear-cut red flag that you are on the cusp of
a major paradigm shift and that the older paradigm (and the older
generation along with it) has simply run its course. Equally clearly
is that during such times, when you start to see things as having been
exhausted, you're also dating yourself and are identifying yourself in
terms of which side of the paradigm boundary you reside on.

The best way to get a glimpse or proper understanding on just what the
key issues underlying and driving the paradigm shift are to look
specifically for all the issues that have been put under the rug
(frequently through a layer of defense-mechanisms that bury the issue
under "established" conventions, divert the issue on hand, or try to
pooh-pooh it as somehow "insiginificant") or issues that have been
left up in the attic as things that are too awkward to bring down into
the living room as furniture that nobody's really been able to get to
ft well.

In the present case, one issue is easy to see and it has driven some
recent changes in the latest standards for programming language (even
C) -- the near complete absence of a consensus academically-derived
well-established formalism (along the same lines as the Algol
standard) for language-level concurrency. Notwithstanding APL,
language-level concurrency is a facility that is nearly absent in the
core of "modern" languages -- only being provided (for instance) as a
layer of bureaucracy up top of a language lacking it at its core (thus
compounding the problem) in a language like C++.

There are two major paradigms in programming. One may be likened to
the composer who writes a score for a song or melody, or a camera
operator who records a video. It is present and dominant at the
desktop or application level (regardless of the type of OS hosting it
be it multitasking or not). This is what all Algol-derived languages
are built around. The differentiation between Procedural, Object-Based
(to use Lippman's term) and Object-Oriented does not change any of
this and is little more than a surface or cosmetic difference within
the two paradigms.

Which gets to the second paradigm: programming that may be likened to
digital cinematography or the full orchestration of a film background
score or symphony. This is the one dominant in embedded applications
-- but only when they are done right, as opposed to how they are
frequently done as the "giant control loop everything else decimated
into bits and pieces governed by explicit finite state machine" style
when the songwriter type tries to take on the task of being an
orchestral composer.

They are easy to do in machine-level languages and in explicitly
parallel languages like VHDL, but are inaccessible from the so-called
"high level languages" except via the extra layer of above-mentioned
bureaucracy of a "threads library" or some such deal. That latter
approach is also how POSIX 4 (now POSIX 1a) approached the matter,
making the whole paradigm into an API, as if it were somehow an
afterthought or addendum.

A concrete example of where this distinction proves critical: take a
look at the Windows API. Never mind the fact that it has over a couple
thousand system calls, the real issue here is that the OS is
explicitly message-passing. What you REALLY want is a program that
runs like this:
Item 1:
  function f() {
      ... do stuff ... wait for A ...
      while (B) {
        do stuff ... wait for B ... do stuff
      }
   }
   main routine:
      ... do stuff... f() ... do stuff ...

where the waits are places where the program is awaiting events or
messages. There is no support for this at the *language level* in the
core of any common language. Nor is it just something you can put in
as an add-on because of the subtle issues involving variable scopes
and lifetimes. That's why, for instance, instead of merely setting up
some kind of "threads" library, C now also has a "thread local" type
of variable and a new keyword to reflect this.

What Windows does is effectively force you to gut this structure turn
it inside-out, so that the boundaries of the routine at the
application level are: (exit) ... wait for A ... ((re-)enter). The re-
entry is then kicked in by a "callback function" (the Windows'
equivalent of what in embedded systems is referred to as an interrupt
handler or other event handler). The paradigm puts handlers out in
front, thereby effectively forcing you in the "single songwriter
trying to thread an orchestra into a giant control loop" mode.

Windows supports threads. But only as an afterthought (the threads
part of the API). It's written in C++ which does not have concurrency
in its core.

That means routine f() above would have an entry point for each wait
-- including the one INSIDE the control flow structure. That means, in
turn, the control flow structure is decimated and you see an explicit
finite state machine crop up.

I've seriously considered just throwing out all the old paradigm and
redoing a language from scratch that has native-level concurrency
built into its very core -- just to have a better and simpler way to
harness the full power of a system like Windows' API.

This is not just Windows. To give you another example: I was briefly
involved early on with a multi-user chat system that used the socket-
level API. The client source distributed to me and others for this was
2000 lines. It was programmed in the above-mentioned single-songwiter
paradigm. I created a server for it, using the same paradigm (before I
became acquainted and experienced with doing programming as an
orchestrator), and the server was about 2000 lines.

A few years later, I literally decimated the client and turned it into
a 99 line program, by redoing it as a concurrent program. With UNIX
the only good way to do that is to fork() the concurrent processes,
and use a combination of signal() and pipe() to get *both* the wait
and message passing, *without* having to tear up the control flow
structures and turn everything into a giant control loop. So, the
program was just 2 small routines working in parallel: one for
handling the user, the other for handling the server.

I shouldn't have to have been jumping through hoops just to compensate
for the lack of native-level concurrency. With Windows API, both the
programming *and* the understanding and explanation (as well as the
concept) of significant portions of the API will undergo a similar
level of decimation when rendered in the frame of mind of an
orchestrator, rather than in the frame of mind of a single score
songwriter. The latter is the frame of mind that the MSDN library
itself is written in and for (and obviously by).
[I've been saying we've run out of language ideas for 20 years.
Pretty slow cusp, if you ask me.  And if there's a paradigm
shift, to what? - John]

[toc] | [prev] | [next] | [standalone]

#509

On 3/17/2012 12:31 PM, Rock Brentwood wrote:
> On Mar 7, 5:52 am, Rui Maciel<rui.mac...@gmail.com>  wrote:
>> Quotes:
>> - But the truth of the matter is that ever since I finished my Ph.D. in the
>> late 90s, and especially since I joined the ranks of Academia, I have been
>> having a hard time convincing myself that research in PLs is a worthy
>> endeavor.
>> So, what are your views on this subject?
>>
>> Rui Maciel
>> [Personally, I'd say there's been precious little new in programming
>> languages since Simula gave us OOP in the late 1960s.  In your responses,
>> please remember this is comp.compilers, not comp.semicolon-placement.flame.
>> -John]
>
> The answer is simple: whenever and wherever you hear such a question
> posed, no matter what the context or situation, no matter what the
> issue, it is *always* a clear-cut red flag that you are on the cusp of
> a major paradigm shift and that the older paradigm (and the older
> generation along with it) has simply run its course. Equally clearly
> is that during such times, when you start to see things as having been
> exhausted, you're also dating yourself and are identifying yourself in
> terms of which side of the paradigm boundary you reside on.

<snip, lots of hand-waving...>


> [I've been saying we've run out of language ideas for 20 years.
> Pretty slow cusp, if you ask me.  And if there's a paradigm
> shift, to what? - John]

I agree.

The problem isn't that there aren't "ideas" (as-in, alternative
possibilities for how things could be), but that there are relatively
few "good ideas" (as-in, would offer a notable advantage over existing
practice), and even fewer are "new" (most major ideas have been floating
around for decades or longer).

Many ideas people often go on endlessly about being the "next big thing"
("Pure Functional Programming" being a big offender here), are hardly
new ideas, and I suspect that there are some notable reasons for their
relatively limited mainstream adoption (and "different" need not be
"better", and can very often be "notably worse").

granted, for example, elements of "impure FP" could be better supported
or utilized in mainstream languages (say, via closures, tail-call
optimization, and syntax for implicit return). this is already happening
some, but I don't expect state or variable assignment to be going away
anytime soon.


concurrency could be a little better, but it is a similar issue. but,
again, the process will likely be more one of gradual incremental
improvements, rather than people "jumping ship" to some entirely new
"paradigm".

an example:
in my language I have "sync" and "async" keywords;
"sync" allows forcing things to be done synchronously (if previously
using async);
"async" allows certain things to be done asynchronously (potentially in
parallel, but if/when something is done is undefined).

both, in my case, are built partly on the VM using "green threads", and
internally by the VM using a CPS based structure.

likewise, "continuations" exist in the implementation, sort of, but are
not available in the language, and have some annoying technical
limitations (they are exit-only and don't work across calls through C land).

however, the default case (and the main way I actually use the
language), is to use good old procedural control flow. even then, these
new features are used in addition to, rather than in place of, other
more traditional mechanisms (as well as them requiring explicit
declaration).

(taken further, a language could have keywords to allow for constraints
and lazy evaluation...).


one could argue, "well, people did 'jump ship' to OOP".

however, it can be noted:
earlier on, OO was hacked on top of C (inspired by Simula, etc...),
forming C++;
Java came some time later, and borrowed a fair amount from C++;
C# came along later, and borrowed mostly from C++ and Java;
all this took place over nearly 20 years (C++ to C#, or 34 years if one
counts Simula);
much "OOP" is not really "OOP", more just procedural code with classes.


so, as I see it, little is new, but there is still a lot of old stuff
that has yet to really be put to use.

maybe new ideas will trickle in, eventually, and "new" languages may in
a number of years start to look dated.

will things look drastically different? probably not.
change is continual, but typically gradual.

[toc] | [prev] | [next] | [standalone]

#510

On Sat, 17 Mar 2012 12:31:13 -0700 (PDT), Rock Brentwood wrote:

> A concrete example of where this distinction proves critical: take a
> look at the Windows API. Never mind the fact that it has over a couple
> thousand system calls, the real issue here is that the OS is
> explicitly message-passing. What you REALLY want is a program that
> runs like this:
> Item 1:
>   function f() {
>       ... do stuff ... wait for A ...
>       while (B) {
>         do stuff ... wait for B ... do stuff
>       }
>    }
>    main routine:
>       ... do stuff... f() ... do stuff ...
>
> where the waits are places where the program is awaiting events or
> messages. There is no support for this at the *language level* in the
> core of any common language.

This looks exactly like an entry call in Ada 83 [BTW, 83 = 1983]. E.g.
timed entry call:

   select
      A; -- call the entry A
   or delay 1.0;
      ... -- Do something useful of A does not respond in 1s
   end select;

> What Windows does is effectively force you to gut this structure turn
> it inside-out, so that the boundaries of the routine at the
> application level are: (exit) ... wait for A ... ((re-)enter). The re-
> entry is then kicked in by a "callback function" (the Windows'
> equivalent of what in embedded systems is referred to as an interrupt
> handler or other event handler). The paradigm puts handlers out in
> front, thereby effectively forcing you in the "single songwriter
> trying to thread an orchestra into a giant control loop" mode.

There are at least two ends in each communication. The "event controlled
paradigm" tries to simplify the problem by making it looking as if there
were only one place you would program it. This has issues and many problems
do not map onto it. But for half-duplex, multicast topologies it works
well.

> That means routine f() above would have an entry point for each wait
> -- including the one INSIDE the control flow structure. That means, in
> turn, the control flow structure is decimated and you see an explicit
> finite state machine crop up.

Which is a procedural view on the issue: the monitor, co-routine etc. There
is an object-oriented counterpart: a protected object, which can be safely
used by concurrent threads while maintaining its internal state. Sometimes
decomposition based on protected objects works better, sometimes it works
poor.

Anyway, both threads (tasks) and protected objects are present at the
language level.

The problem is not in having these primitives. The problem is in
integration them into the types system. And a larger problem is
composability. Either tasks or objects become unsafe when put together.
They are much safer than low-level stuff like raw messaging, events,
semaphores, but still not safe enough for software design.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.compilers

csiph-web