
More information on Google's new web language, Dash - praxxis
http://markmail.org/message/uro3jtoitlmq6x7t
======
sriramk
As an ex-MSFT person, this doc sounds like a Microsoft doc more than something
you would see from Google.

And I'm amazed at sentences like these - can you imagine MSFT saying this and
getting away with it? "The goal of the Dash effort is ultimately to replace
JavaScript as the lingua franca of web development"

and

"What will Google developers be using? We will strongly encourage Google
developers start off targeting Chrome-only whenever possible as this gives us
the best end user experience."

~~~
deno
And also: ”Developers using Dash tooling will be able to use a cross-compiler
to target Javascript for browsers that do not support Dash natively.”

Not very different to having native support for e.g. CoffeScript in browser X
and supporting other browsers via JS.

Of course the main issue is that this is _yet another language_. Since all
browsers are essentially becoming poor man’s virtual machines, why not drop
the pretense and adapt some kind of bytecode instead. There’s
JVM/CLR/LLVM/NaCL — just pick one already! Alas, politics
(Oracle/Microsoft/Apple/Google).

Well anyway, Dash is a very positive news nevertheless. The biggest issue with
current cross-compilers (GWT, Pyjamas, Haxe etc.) is that they lack good tools
to develop and debug. Having support for those natively, there’s hardly any
reason to target JS directly anymore. And once Chromium has the infrastructure
to support more than one language, it’s possible that the abstractions will be
general enough to add support for other languages as well.

“Our approach is to make an absolutely fantastic VM/Language and development
environment and build great apps that fully leverage it in order to help other
browsers see the wisdom in following. Once Dash has had a chance to prove its
stability and feasibility, we are committed to making Dash an open standard
with involvement from the broader web community.”

~~~
jdonaldson
I'm not sure what you mean by Haxe debugging. That happens with whatever run
time debugger you have for js, php, etc. As far as development goes, there's
flashdevelop, an eclipse plugin, a few textmate bundles, a vim package, etc.
<http://haxe.org/com/ide>

If you don't mind me asking, what part of debugging/development in haxe turned
you off?

~~~
deno
I’m not familiar with haXe all that well, just enough to include it in the
list. However, in the end haXe is too, statically translated into Javascript.
GWT has an excellent debugger as well, but there’s only so much you can do on
that level of indirection.

------
antimatter15
In the FAQ section, they mention a "Cloud IDE" named Brightly, which frankly
seems more interesting than the language itself:

"How does this affect our cloud IDE (Brightly)? Brightly will enable building
any web application in V1 using today’s Javascript plus the additions in
Harmony. As soon as it is ready, Brightly will support Dash as well. We expect
that the more prescriptive development aspects of Brightly that will come on
line in the future will be more Dash focused."

~~~
feronull
Google is working on a web-based IDE named Brightly for building JavaScript
and Dart apps.

source: <http://geddesign.com/post/10097230191/google-dart>

------
cousin_it
Whenever I look at all these old and new curly-brace languages, I imagine a
world where they are different runtime libraries for the same language
instead, and no one has to learn the subtle syntactic differences introduced
by the latest group of well-meaning overlords.

I mean, there's only one widely accepted way to write a "for" loop in a curly-
brace language, right? Only one possible syntax for the ternary operator. One
obviously right way to organize classes and imports. A couple competing ways
to declare types (Foo foo or foo:Foo), but perhaps we as a community could
make a bold choice just this once? One obvious syntax for generics, and so on.

The lowest common denominator I have in mind looks almost exactly like early
versions of Java, except with optional typing ("var"), some rudimentary
generics and without checked exceptions.

There seems to be no good reason for new languages like Dash to embrace a
different style. And there's one big reason why you'd want source-level
compatibility: polyglot libraries! For example, there's a rather huge open
source library for dealing with geographical coordinate systems, basically a
huge bunch of complicated math with almost no platform dependencies. How
awesome would it be to have it compilable for the JVM, the CLR and the Flash
player from the same source code?

I'd imagine many shops would jump at the chance to future-proof big parts of
their code in this way. And the syntaxes are already so tantalizingly close to
each other! Juuuust different enough to enable platform lock-in...

~~~
josephg
It sounds like you're not looking for a bold choice; you're looking for
language innovation to stop.

The only widely accepted for loop syntax is the C-style for loop, which was
invented 40 years ago and is vastly inferior to for..in loops, ruby's .each /
.each_index and python's list comprehensions. That says nothing of
generics[1].

The reality is, we can make much better languages today than Java or C#.

[1]
[http://weblogs.java.net/blog/arnold/archive/2005/06/generics...](http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid.html)

~~~
cousin_it
As a consumer of programming languages, I'd like the evolution of languages in
the mainstream to be less incremental and more punctuated.

If you make a new language that's exactly like the old language but has a
slightly tweaked syntax for one or two little things (e.g. changing the
capitalization of the name of the string class), you're forcing lots of
programmers everywhere to rewrite their code in the new flavor. You're forcing
companies everywhere to spend more resources on hiring, retooling, etc. And
you actively contribute to bitrot by weakening the incentives to keep old code
running as-is on newer runtimes, because "no-one writes such code nowadays
anyway". It's basically a lot of waste that could be avoided.

The jump from C++ to Java was big enough: it introduced garbage collection,
proper modules, proper strings and other nice things into the mainstream. The
jump from Java to Python, if it happens, might be marginally big enough to
merit rewrites (we gain many nice small-scale constructs like dicts,
generators and list comprehensions, but lose the IDE tooling and guaranteed-
correct refactorings enabled by static types). The jump from JavaScript to
Dash doesn't seem big enough to justify all the busywork. Please come back in
five years with more shiny things.

...A man can dream, can't he. Obviously the big guys will keep introducing new
languages where a new library or a new runtime could've done the job. They
have incentives to do so. But it's not so pleasant to the rest of us.

You'll note that I have avoided using the word "innovation" so far. That is
because genuine language innovation generally happens outside of the
mainstream and takes decades to percolate. For example, the idea of list
comprehensions is older than I am (NPL '77). For that matter, so is the idea
of lazy pure functional programming (SASL '76), and the idea of parameterized
types (ML '76), and any number of other ideas that people mislabel as
"innovative" to justify creating new languages today. Adding 30-year old
features into curly brace languages, bit by little bit, and forcing us to
rewrite all our code at every step doesn't sound to me like the noble practice
of innovation. It's more like a big coordination trainwreck.

~~~
ehsanu1
_As a consumer of programming languages, I'd like the evolution of languages
in the mainstream to be less incremental and more punctuated._

While there is such a thing as punctuated equilibrium, I believe you'll find
that evolution is largely incremental in nature. Seems like evolution simply
has to happen this way, whether we're talking about biology or technology,
including programming languages.

------
mumrah
Maybe rather than a new language, we should work towards browser "assembly"
code. Lots of modern JavaScript development is in the direction of: write in
language X, compile to JS. Would be nice if there was a lower-level target
than JS

~~~
jules
They are doing that with NativeClient. It runs x86 assembly and LLVM IL in the
browser. Supposedly they'll even make it work in other browsers than Chrome.

~~~
stephenhalter
NaCl does not allow direct manipulation of the DOM or provide other JavaScript
APIs like canvas. NaCl provides alternative ways of getting things done like
pp::Graphics2D, but it is not meant for DHTML. Dash, on the other hand,
provides access to JavaScript APIs.

I think that browser "assembly" code, like Dash, would have to support this,
particularly if it is meant to be an alternative to compiling to JavaScript.

~~~
Detrus
Pepper is the link between NaCl and browser APIs.

------
equark
I have a feeling that Dart may be some version of Bracha's Newspeak. If you
read his blog post on Javascript's failings, you'll see him talk about how
they are already trying hard to have Newspeak fill the gap:

[http://gbracha.blogspot.com/2011/03/truthiness-is-out-
there....](http://gbracha.blogspot.com/2011/03/truthiness-is-out-there.html)

There is also an uncanny link between the features Dart highlights --
security, optional typing, modularity -- and Newspeak. The timing of Newspeak
development and Google's Dart also coincide perfectly. The blog post talks
about a Javascript compiler, pluggable type system, IDE (Brightly?) all being
in the works.

Newspeak's pluggable type system sounds similar to what is known about Dart.
For instance,

<http://bracha.org/newspeak.pdf>

> We also intend to extend Newspeak with an optional type system and a
> framework for pluggable types , enabling the language to enjoy most benefits
> of static type systems without incurring their limitations.

It also seems like a smart engineering choice to base whatever Dart is heavily
on some proven language, even if there is a new VM. Given that Newspeak is
Bracha's most recent attempt and it's goals are so well aligned, it's hard to
imagine he'd start from scratch.

~~~
nickik
Newspeak has a very cool IDE (that is written in Newspeak). Maybe this
"Brightly" is just that with HTML/CSS as a presentation layer. I belive he
said that its written in a way that could make it possible to replace the
presentation layer.

~~~
jink
Maybe Dart does not require HTML/CSS.

------
peterhunt
I really wish that we would see a concerted effort to get Python in the
browser (or anything reasonable, really) rather than creating yet another new
dynamic language that needs half a decade to grow a decent ecosystem.
JavaScript has been around for years and only in the past few years have we
seen a legitimate developer ecosystem emerge around it.

~~~
zmmmmm
I think that going from a language with real genuine closures to one with the
half measure that Python has (lambdas) would actually be a backwards step.

Plus I agree with the other (downvoted) commenter that whitespace would be a
huge annoyance. A language for the web has to be something robust to copying
and pasting to / from web pages.

~~~
andybak
Closures and lambda (anonymous functions) are orthogonal features. Python has
closures (and one last limitation related to scope and rebinding was fixed in
Python 3)

Furthermore although I agree Python's limited lambda's make it slightly uglier
to do some constructs, it's merely syntactic sugar.

First-order functions are the critical feature. Whether you are compelled to
give them a name or not isn't critical.

------
jameskilton
This is from a year ago, but this is also the first time I've heard of it. Do
we know the progress of this movement today? Googling for "Dash Language" and
variants doesn't give me anything of note.

~~~
patrickaljord
There you go
[https://plus.google.com/112643613234453381402/posts/XTDu92t9...](https://plus.google.com/112643613234453381402/posts/XTDu92t9N1c)

Edit: this one says Dart, not Dash

~~~
goodside
Calling it 'Dart' is rather confusing, given that there's already an existing
Google product called DART:
<http://www.google.com/doubleclick/publishers/dart.html>

~~~
Dobbs
And Dash is confusing because there is already a shell/language called dash:
[https://secure.wikimedia.org/wikipedia/en/wiki/Debian_Almqui...](https://secure.wikimedia.org/wikipedia/en/wiki/Debian_Almquist_shell)

~~~
malbs
So is it Dash or Dart? It was referred to as Dart earlier in the week when
someon linked the conf that Lars Bak / Gilad Bracha (spelling) would be
revealing all at. I'm confused now.

~~~
tonfa
It is Dart.

------
Groxx
> _Developers using Dash tooling will be able to use a cross-compiler to
> target Javascript for browsers that do not support Dash natively._

So it'll have all the inherent downsides of Javascript, because you can't
cross-compile without restricting the abilities. I wonder how they feel about
CoffeeScript?

At least Mozilla is trying something _completely_ different with Rust. Maybe
they could support that effort instead?

~~~
antimatter15
Later in the document they say that only a subset of Dash code can be cross-
compiled into ordinary JS.

~~~
Groxx
Ah, thanks :) I didn't wade through the whole thing. There didn't seem to be a
whole lot about the language itself.

------
allertonm
Hidden away in there is the news that Google plans to obsolete GWT.

Sorry, I mean "support teams for a long time on the current generation".

------
CurtHagenlocher
There seem to be quite a few ex-Microsoft people involved.

------
mythz
I Like the ethos behind Dash but language design is also an art, and judging
by Go - Google is not very good at it.

~~~
enneff
Wow, way harsh.

Those of us that actually use Go are pretty enamored with it.

~~~
mythz
Let me explain, Rather than trying to make a language as aesthetically
pleasing to the programmer as possible, the Go team tried to get by its
limitations with design kludges and workarounds that are visually less
appealing and intuitive then the many well-designed solutions that preceded
it, e.g:

    
    
      - Error codes are a poor substitutions for Exceptions
    
      - Have to code around lack of generics, e.g. by abusing their typed map if possible 
    
      - Defer less desirable and intuitive than C# using
    
      - array bracket notation prefixing the variable
    
      - No proper classes?
    

I mean, take their example on a File type
(<http://golang.org/doc/go_tutorial.html>):

type File struct { fd int name string }

func (file _File) Read(b []byte) (ret int, err os.Error) {}

func (file _File) Write(b []byte) (ret int, err os.Error) {}

file := &File{fd, "file.txt"}

The same signatures in CoffeeScript can be achieved by:

class File

    
    
      constructor: (@name) ->
    
      read: (cb) ->  
    
      write: (contents) ->
    

file = new File "file.txt"

Which I'm sure a majority of people would find a lot more readable.

Just for kicks I decided to rewrite Go's Cat example to StdOut in CoffeeScript
for a side-by-side comparison. The examples are fairly close but not exact,
i.e. cat.Go implements via streaming while CoffeeScript's is non-blocking.

<https://gist.github.com/1207994>

The CoffeeScript version ways in at 12 LOC, while Go's example is over 110 LOC
and a lot more unfriendlier on the eye.

~~~
enneff
I didn't want to get into a slinging match, but I take issue with all of your
points.

"Error codes are a poor substitutions for Exceptions" This is debatable.

"Have to code around lack of generics" Some people complain about this, but in
practice their absence hasn't been a big problem. It's still an open issue,
though.

"Defer less desirable and intuitive than C# using" Again, debatable.

"array bracket notation prefixing the variable"
<http://blog.golang.org/2010/07/gos-declaration-syntax.html>

"No proper classes?" This is a bizarre complaint. Go doesn't have classes. It
has types and methods. Why would you need classes? What is a "proper" class?

The tone of your complaints implies that we didn't consider any of these
things, or that these decisions were made through sheer incompetence. This
couldn't be further from the truth. Language design is just as much about what
you exclude as what you include. One of Go's major strengths is its
simplicity. It's a very small language; so small, you can read the spec in one
sitting! <http://golang.org/doc/go_spec.html>

As has been pointed out already, your comparison between Go and CoffeeScript
is not illustrative of much. Go is typed, CoffeeScript is not. The "cat"
comparison is very strange. Your (very unidiomatic, and in some places plain
wrong) Go program re-implements everything from a syscall level, while the
CoffeeScript example uses library calls. Why?

Here's how one might write a similar "cat" in Go:

    
    
        package main
    
        import (
            "io"
            "log"
            "os"
        )
    
        func cat(name string) os.Error {
            f, err := os.Open(name)
            if err != nil {
                return err
            }
            defer f.Close()
            if _, err = io.Copy(os.Stdout, f); err != nil {
                return err
            }
            return nil
        }
    
        func main() {
            for _, arg := range os.Args[1:] {
                if err := cat(arg); err != nil {
                    log.Print(err)
                }   
            }
        }
    

This handles multiple files specified on the command line, and handles errors.
(The CoffeeScript one just throws them, right?) Not bad for 24 lines of code.

~~~
mythz
If you considered them it's even worse - by keeping the language simple you've
made it more unintuitive and less readable for the programmer. IMHO the
primary beneficiaries of Go are the compiler writers, not the programmers
having to read and write source code.

Your example is not the same, this is just a C-style single method. The whole
point of my example was using Go's own sample source code to showcase the
hacks needed around structs to get around the deficiencies in not having
classes. The resulting struct method signatures are ugly, verbose and
unintuitive - it's not nearly as readable and wrist friendly as grouping them
in a single class definition.

In following this pattern the __defer __keyword is a magic method that doesn't
visually demonstrate its behaviour - compare that with C#'s using statement
which does.

~~~
enneff
If that's what you were trying to demonstrate then you were pretty far off the
mark. The two programs are far from equivalent, and your Go code is just
bizarre.

I think this statement of yours is quite revealing: "Your example is not the
same, this is just a C-style single method." It's not a "single method," it's
a function. Not everything is or should be about object orientism. It's not
always the right choice, and people who obsess over making everything an
object (those who think functions are a special type of method) are doomed to
overcomplicate their design. (For example, there is no reason you should need
to construct new objects to write cat.)

I'm confused as to why someone who clearly doesn't know Go would try so hard
to discredit it. What's your motivation?

~~~
mythz
The Go code is bizarre? That's the introductory Go tutorial showing off Types
in Go (<http://golang.org/doc/go_tutorial.html>) Not a single line of the Go
code is mine (I just copy and pasted the entire tutorial in a single file). If
you want to blame someone for making Go look bad - blame the author of the
tutorial - or better yet the inventors of the Go Language.

If you think OOP is not important for building and encapsulating large
software code bases, then we operate in different worlds and Go wasn't
designed for my purposes in mind. Feel free to keep using Go as a better C and
I'll stick to mainstream languages without these deficiencies (aka trade
offs).

------
moonboots
First Go now Dash, Google should really google for these names before choosing
them

~~~
woadwarrior01
That's probably the least of your concerns, especially when you have a near
monopoly in the search business.

I think by choosing a not so unique name, they're ensuring that people
remember to prefix these names with Google (Google Go, Google Dash etc). This
should has a significant effect on Google's branding.

~~~
redthrowaway
How is "Dash" any less unique than "Python", "Ruby", "Lisp", "Java", "Basic",
etc? We only associate those names with languages because those languages are
established; I doubt googling "Ruby" in 2000 would have resulted in anything
but minerals on the front page.

~~~
Corrado
Dash[1] (Debian Almquist SHell) has been around since the early 2000's and is
the first thing that I thought about when reading the title of this post.

1 - <http://en.wikipedia.org/wiki/Debian_Almquist_shell>

------
craigmccaskill
This looks like (from my admittedly limited perspective) an attempt by Google
to build their own language ecosystem to reduce the reliance on Java and limit
any potential future liability from patents held by sun/oracle.

~~~
voyou
Why do you say that? The post doesn't mention Java, and is talking about an
area (in-browser scripting) in which Java is largely irrelevant.

~~~
zmmmmm
I think Java prominent by its omission. So much so that it underlines the GP's
point exactly. When you read all the stated goals of the project you can
basically put a tick next to Java on every one:

    
    
        - runs in all browsers
        - works client side and server side
        - scales from large projects to small projects
        - contrary to your point, supports in browser scripting (admittedly, crudely).   
        - highly performant (with some specific issues)
    

They could easily inherit nearly all of these qualities by starting with the
Java VM and going from there. The reasons not to basically boil down to NIH,
politics and the encumbrances (not sure if there is a way to tightly embed a
GPL engine inside a non-GPL product, but at this point it would rightly scare
the hell out of anyone making a browser to even attempt it).

I see this as very much Google saying "We need a new Java, one that we control
this time".

~~~
kragen
Java doesn't scale to small projects and isn't "highly performant" when the
metric you're trying to optimize is page _load_ time, although it could
conceivably be made to "support in-browser scripting".

Also, I think an implicit item on the list would be "doesn't suck", which is
the whole point of the effort, not merely a constraint on feasible solutions
like the "goals" you listed. They want something that sucks _less_ than
JavaScript, not something that sucks _more_ , such as Java.

So I don't think "the reasons not to basically boil down to NIH, politics and
the encumbrances"; they boil down to Java being a shitty non-solution to their
problem.

~~~
zmmmmm
I understand that you don't seem to like Java, but it is really immaterial to
my point. They stated all the goals of Java in their feature list and then
didn't mention Java. If they thought Java sucked or didn't meet their
requirements even though it has the same stated goals then they might have
said so. But they didn't say anything at all - it's kind of an odd omission to
make by accident.

------
Detrus
For a while it seemed like Google had a strategy with Go, NaCl and Pepper. But
they have other "evolutionary vectors" and the reasoning is not obvious. Is it
technical or political?

------
swah
Since they are the ones (IIRC) that started writing Java and converting it to
Javascript (GWT), they wouldn't be pushing for a language without some static
typing, right?

~~~
wahnfrieden
Google's Closure compiler also has some kind of ability to add stati typing
annotations to JavaScript.

------
fuzzythinker
In Chrome by mid 2011, I guess it's a bit behind schedule..

~~~
richdougherty
It might be written already, but waiting for a certain keynote before being
released...

[http://gotocon.com/aarhus-2011/presentation/Opening%20Keynot...](http://gotocon.com/aarhus-2011/presentation/Opening%20Keynote:%20Dart,%20a%20new%20programming%20language%20for%20structured%20web%20programming)

(Assuming Dart is just Dash renamed.)

------
chc
What they're talking about here seems a bit vague, but with all the talk of
somehow being related to Harmony, this sounds more like Traceur (get a jump on
that slow-moving JavaScript) than whatever Dart is going to be. But I could be
totally off and maybe Dash is Dart.

------
tluyben2
This sounds bad to me. I was hoping they had something real, but this is
disappointing. It won't work as JS is too big (I would love to see them try),
but it doesn't seem to 'fix' anything; it's just more of the same.

------
peterbraden
Interesting that they blame the rise of apps on easier to use platforms like
iOs rather than the bigger issue of closed ecosystems with better hooks to
devices and vendors crippling browsers.

------
reddit_clone
> isolation, leaves the web in a hobbled state and unable to compete against
> the encroachment of other, less open platforms.

This seems more about fighting Apple Appstore than fixing Javascript issues.

------
tree_of_item
Brightly sounds almost as interesting as Dash. A web based IDE from Google!

------
wavephorm
This sounds like a pretty good strategy to me. I'd like to see some syntax
examples. And I hope they have a JavaScript-to-Dash converter so I can move
over as much as my existing codebase as possible.

~~~
arctangent
The article says:

"The Dash Cross Compiler should be capable of taking typed Closure code (with
some restrictions) and converting to Dash. Although the migration process
won’t be fully automatic, it should make moving over to a Dash codebase
somewhat easier."

I agree that a JS->Dash/Dart compiler is necessary to improve take-up of the
new language.

------
ThaddeusQuay2
You kids and your new languages! While you endlessly debate over features and
runtimes and whatnot, I still happily use PL/I under OS/360 on Hercules, and I
don't think that I'm missing out on anything worthwhile. All of the below were
built by real engineers, and have stood the test of time. It's an unfortunate
waste of manpower that the industry keeps trying to reinvent things which
remain perfectly usable. May the 60's never re-IPL!

<http://en.wikipedia.org/wiki/OS/360>

<http://en.wikipedia.org/wiki/Hercules_(emulator)>

<http://en.wikipedia.org/wiki/PL/I_programming_language>

~~~
nickik
Thats the same thing some generals said when the wanted to replace the Cavalry
with tanks and cars. There are always people like you but luckly there are
always more people that want to push ahead.

If you trully belive that the last 50 years of PL/Compiler/VM research did do
nothing, I pity you.

Luckly for you that these old PL/1 and Cobol-System will be almost imposible
to replace since they are a monilitic blocks of messy code. I know of banks
that teach the unimployed programming so that they can update there cobol
code.

~~~
ThaddeusQuay2
Do you deliberately misspell words?

If you truly believe what you say, then you should tell IBM to stop providing
PL/I certification (<http://www-03.ibm.com/certify/certs/pl_index.shtml>), and
stop updating their PL/I compilers
(<http://www-01.ibm.com/software/awdtools/pli>).

Apparently, the last 50 years of PL/Compiler/VM research did do something: It
turned you into a sourpuss. I pity you.

"The geeks shall inherit the properties and methods of object Earth."

~~~
nickik
Not everybody is a nativ english speaker.

Why should I tell them that, I never sad its not ok to make money of people
that still use this stuff! Why should IBM not do it if there are still lots of
people with old code that they can make money off? All I said is that there
are languages way better then PL/I.

~~~
ThaddeusQuay2
I am also a non-native speaker. It's funny how you prefer modern software, yet
you don't make use of a spellchecker, something which, to my knowledge, was
not available on OS/360, but which is easily available today. Spellcheckers
are the non-native speaker's best friend. I know that they may not catch
certain things, like the difference between "their" and "there", but they
would prevent most of your simple mistakes. You can make use of today's
software to appear more professional, instead of just talking about how much
better it is than the 1960's technologies that I prefer.

You should tell IBM, what I said, because their compiler upgrades and
certification programs are not just for people with old code. PL/I is being
used for new code, mostly by companies who are not persuaded by the shininess
of the latest fads. PL/S, a proprietary dialect of PL/I, was used internally,
by IBM, to create much of z/OS. XPL, another dialect of PL/I, was used to
create the compiler for HAL/S, the language in which the programs that
controlled the Space Shuttle were written. Incidentally, I note that HAL/S
supported GOTO, which is amazing, considering that mission-critical aerospace
applications could use GOTO, when written in a good language, whereas
Javascript and its modern, GOTO-less brethren, regardless of speed, are not,
as far as I know, worthy of such important applications.

I submit that there are no languages intrinsically "better" than PL/I, or, at
least, that there isn't much else, that's been created since 1970, which is
better than the latest PL/I (which is likely to be IBM's Enterprise PL/I for
z/OS). Pretty much anything important, that you can code, in one of today's
hip languages, I can also code, in my ancient PL/I "F" compiler, on OS/360,
and those things which I can't do there, I probably could, by upgrading to
MVS, under S/370, again on Hercules, where I can use the PL/I "Optimizing"
compiler, but even that additional capability still puts me in the 1970's.

My original, fundamental point, which is correct, and which you cannot
successfully argue against, is: Since the end of the OS/360 era, there has
been a definite trend towards a tremendous waste of resources in rediscovering
old programming truths, with some of the worst waste being in permanently
forgetting about some very cool advances which we thus have to do without,
today. A great deal of expensive, expert domain knowledge has been lost in
old, abandoned codebases, and usually for no more reason than merely a glimmer
of hope that some new way of doing things will be "better". One small example
is Multics, an amazing operating system, written mostly in EPL, yet another
dialect of PL/I.

<http://en.wikipedia.org/wiki/Multics>

