Ideas About A Web Programming Language
Frank Gerlach
first let me thank you for challenging the "let's standardize all on JavaScript" conventional wisdom. JS' deficiencies are indeed limiting what can be done inside a browser application.
I do think though, that more "old" ideas could be used to create a high-efficiency web programming language.
First some observations:
A) ALGOL-style languages such as Pascal, Fortran, Ada, C or C++ still have the best efficiency in terms of memory and runtime.
B) For the Pascal language, there exist extremely fast compilers, which output machine code.
C) Manual memory management is still vastly superior in terms of efficiency to garbage collection.
D) The fine-grained and rich memory system of C++ (e.g. stack allocation, object aggregation, object arrays) facilitates memory and runtime efficiency.
Of course, one cannot just take a Pascal compiler/libs and stick that into a browser. It must be assured that no memory errors (e.g. bounds overruns, bad pointers) can occur. After all, browsers execute untrusted code and must safely contain that code in a sandbox. By proper compile-time and runtime checks, this can be assured for code running directly on the microprocessor. There is no need for a virtual machine to safely execute untrusted code.
So my suggestion is to create a Web Programming Language based on a Safe Pascal Variant. Alternatively, Ada could propbably also made memory-safe in the same manner. Downloaded Safe Pascal Code would be compiled in (say) 2 seconds and then execution started. Compiled code could be cached for re-use, of course.
The great benefit from that approach would be runtime and memory efficiency levels comparable to C++.
Kind regards
Frank Gerlach
Gäufelden, Germany
___________________________________________________________
Ihr WEB.DE Postfach immer dabei: die kostenlose WEB.DE Mail App für iPhone und Android.
https://produkte.web.de/freemail_mobile_startseite/
Bob Nystrom
Hello all,
first let me thank you for challenging the "let's standardize all on JavaScript" conventional wisdom. JS' deficiencies are indeed limiting what can be done inside a browser application.
I do think though, that more "old" ideas could be used to create a high-efficiency web programming language.
First some observations:
A) ALGOL-style languages such as Pascal, Fortran, Ada, C or C++ still have the best efficiency in terms of memory and runtime.
B) For the Pascal language, there exist extremely fast compilers, which output machine code.
C) Manual memory management is still vastly superior in terms of efficiency to garbage collection.
D) The fine-grained and rich memory system of C++ (e.g. stack allocation, object aggregation, object arrays) facilitates memory and runtime efficiency.
Of course, one cannot just take a Pascal compiler/libs and stick that into a browser. It must be assured that no memory errors (e.g. bounds overruns, bad pointers) can occur. After all, browsers execute untrusted code and must safely contain that code in a sandbox.
By proper compile-time and runtime checks, this can be assured for code running directly on the microprocessor.
There is no need for a virtual machine to safely execute untrusted code.
So my suggestion is to create a Web Programming Language based on a Safe Pascal Variant. Alternatively, Ada could propbably also made memory-safe in the same manner.
The great benefit from that approach would be runtime and memory efficiency levels comparable to C++.
Frank Gerlach
Statically typed, compiled to machine code, no VM, no GC (or at least the option for no-gc objects)
>> B) For the Pascal language, there exist extremely fast compilers, which output machine code.
>>Yup, but pretty much every language under the sun has fast compilers these days. Pascal is a bit easier because of its >>rammar, but I don't think that makes a big enough difference to matter.
Please point me to an Ada and to a C++ compiler which can compete with Lazarus and Delphi for a real-world project. The buttf*ck of the C/C++ module system prevents anything fast, IMO.
>> C) Manual memory management is still vastly superior in terms of efficiency to garbage collection.
>>I wouldn't say "vastly superior" any more. GC languages having been closing that gap for a long time. These days, mature >>GC languages are within around a factor of two in terms of performance compared to C/C++, I think.
According to
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=gpp
That is only true for runtime, but not for memory consumption.
>> D) The fine-grained and rich memory system of C++ (e.g. stack allocation, object aggregation, object arrays) >>facilitates memory and runtime efficiency.
>>It also facilitates security bugs and really hard-to-use programming languages. :-/
I was referring to things like Stack Allocation (of all data types), Object Value Arrays, Object Aggregation. All of that is impossible in languages like Java, but not for security reasons.
The only reason why this is impossible is that the Java inventors wanted a "uniform" memory model. That's like saying everything should be done with nails, because screws are too complicated.
>> Of course, one cannot just take a Pascal compiler/libs and stick that into a browser. It must be assured that no memory errors (e.g. bounds overruns, bad pointers) can occur. After all, browsers execute untrusted code and must safely contain that code in a sandbox.
>>Yes, memory-safe (i.e. no raw pointers, no pointer arithmetic, no unguarded arrays) languages make that much easier.
That is how it would be done.
>> By proper compile-time and runtime checks, this can be assured for code running directly on the microprocessor.
>>You're a bit hand-wavey about "proper" here. :)
I did not elaborate on type systems which can support separation of multi- and singlethreaded memory. There is some more stuff such as disallowing the use of the this pointer as a right value in the destructor.
But that is all quite straight-forward and you have already pointed out most of it above.
>> There is no need for a virtual machine to safely execute untrusted code.
>>You'll still need some kind of VM to ensure that untrusted code can't exhaust all possible memory or saturate your CPUs.
Memory exhaustion is easy to check - C++ already does return a NULL pointer if memory is exhausted. By encapsulating memory allocation into a trusted library, memory consumption can be controlled. No need for a VM.
Regarding CPU load saturation, I think an optimizing VM (with a machine-code emitting JIT) will be hard-pressed to do that on its own. You need some help from the OS for that. But having a VM does not change any of that.
When you have an event-based system, an OS timing event can put an upper bound on processing time. No need for a VM to do that.
Also, most VMs don't do CPU load monitoring at the moment.
>> So my suggestion is to create a Web Programming Language based on a Safe Pascal Variant. Alternatively, Ada could propbably also made memory-safe in the same manner.
>>Why? Neither language is particularly popular these days.
C++, Pascal and Ada are still widely used. For good reasons - see memory consumption. Also, VM-based languages inevtiably suffer from unpredictable GUI response times (when GC kicks in), which can easily destroy the user experience of games, for example.
>> The great benefit from that approach would be runtime and memory efficiency levels comparable to C++.
>>Right, but also likely the productivity and developer-friendliness of C++. :( We want Dart to be faster than JS, but we don't want to throw out all of the usability you get from dynamic typing and garbage-collection. These days, GC is the norm and non-GC languages are becoming increasingly special-purpose niche languages. Likewise, dynamic-typing is (for better or worse) on the rise and a huge part of the web ecosystem.
Why can't there be a plurality of Web Programming languages ? Why can't I run the most sophisticated 3D-Game in the browser ? Why does Chrome Native Client exist ?
>>Looking at it another way, if you like Pascal, why not compile it to JS so you can use it on the web? You won't get full native code speed, but you'll probably get a lot closer than you think.
According to the Language Shootout, JS is still more than one order of magnitude away from Pascal:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=fpascal
Finally, my proposal is not just an idea; I have already created a Safe Programming Language which has most of the systematic benefits of C++, but fails very similar to Java (i.e. simple-to-understand NULL pointer exceptions, simple-to-understand memory exhaustion, simple-to-understand bounds overflow exceptions) when there are programming errors.
That is very much different to the hard-to-debug memory cancers one can get with C++. I have not done thorough benchmarking, but my anecdotal experience shows that memory and runtime are comparable to C++. Startup times are in the order of a few milliseconds on Linux. All the unsafe stuff of C++ actually adds very little in terms of efficiency.
Frank Gerlach
Scot McSweeney-Roberts
>>>I'm not sure exactly what you mean by ALGOL-style here. Just "statically-typed"?
>
> Statically typed, compiled to machine code, no VM, no GC (or at least the option for no-gc objects)
>
Where does (well, did) UCSD Pascal fit in?. That used a VM.
>>> C) Manual memory management is still vastly superior in terms of efficiency to garbage collection.
>
>>>I wouldn't say "vastly superior" any more. GC languages having been closing that gap for a long time. These days, mature >>GC languages are within around a factor of two in terms of performance compared to C/C++, I think.
>
...
> That is only true for runtime, but not for memory consumption.
It's 2012. What are you doing that makes memory consumption much of an issue?
>>> Of course, one cannot just take a Pascal compiler/libs and stick that into a browser. It must be assured that no memory errors (e.g. bounds overruns, bad pointers) can occur. After all, browsers execute untrusted code and must safely contain that code in a sandbox.
>
If you really, really want to write Pascal code for a web browser, why
not use just NaCL? Failing that, why not write a Pascal equivalent of
GWT?
> C++, Pascal and Ada are still widely used. For good reasons - see memory consumption. Also, VM-based languages inevtiably suffer from unpredictable GUI response times (when GC kicks in), which can easily destroy the user experience of games, for example.
Again, what are you planning on doing so that memory consumption
becomes a concern? As for GC and games - GC hasn't stopped many a
popular browser based game from being written in Flash. I guess if
you're writing the next great Quake it might be an issue, but then
that's what NaCL is for.
>
> Finally, my proposal is not just an idea; I have already created a Safe Programming Language which has most of the systematic benefits of C++, but fails very similar to Java (i.e. simple-to-understand NULL pointer exceptions, simple-to-understand memory exhaustion, simple-to-understand bounds overflow exceptions) when there are programming errors.
Maybe I've spent too much time playing with functional programming
languages, but I'd rather language support for Option types than
simple to understand null pointer exceptions.
Dirk Detering
Am 01.03.2012 13:40 schrieb "Scot McSweeney-Roberts" <maethor...@gmail.com>:
> Maybe I've spent too much time playing with functional programming
> languages, but I'd rather language support for Option types than
> simple to understand null pointer exceptions.
+1!
Ladislav Thon
> Maybe I've spent too much time playing with functional programming
> languages, but I'd rather language support for Option types than
> simple to understand null pointer exceptions.+1!
Isaac Gouy
On Mar 1, 2:09 am, "Frank Gerlach" <frankgerlac...@web.de> wrote:
-snip-
> According to
> http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=jav...
"Don't confuse differences in default memory allocation with
differences in Memory-used when the task requires programs to allocate
more than the default memory. ... Notice that some of the programs are
written for multicore and allocate additional buffers to accumulate
results from multiple processes."
http://shootout.alioth.debian.org/help.php#comparememoryused
-snip-
> According to the Language Shootout, JS is still more than one order of magnitude away from Pascal:
According to that page on the benchmarks game website, some JavaScript
V8 program run times are -
similar, similar, 2x slower, 2x slower, 3x slower, 6x slower, 8x
slower
- with an outlier for arbitrary precision arithmetic (the Pascal
program uses GMP, while the JavaScript program uses something written
in JavaScript) and another outlier for regex but this time JavaScript
would be much faster than the Pascal program.
Lorenzo Pastrana
On 03/01/2012 01:39 PM, Scot McSweeney-Roberts wrote:
>
> It's 2012. What are you doing that makes memory consumption much of
an issue?
Not intended to start a troll here but ... As far as i can tell memory
consumption is _always_ an issue. There is only one thing as certain as
moore's law, it's the ability of programmers to absorb moore's law
benefits by just saying things like "It's 2012".
There is a huge responsibility in building community culture (see PHP's
bad practices promotion) for a project like Dart that hopefully will
have a serious impact on the future shape of the web ...
> If you really, really want to write Pascal code for a web browser, why
> not use just NaCL? Failing that, why not write a Pascal equivalent of
> GWT?
Sure, proposing Pascal semantics here is not what I would call best
diplomacy but I believe Frank's concerns about language 'frugality' and
performance / robustness are somewhat legit and keeping them in mind
while building Dart could be a good idea.
See [misc] Isolates implementation (stacks, count) thread.
IMHO one of Dart's most outstanding value would be to allow same
language on SEVRER and CLIENT. With Dart serving lots of (thousands)
client requests for a complex web application language frugality is
taking a very special meaning.
> Again, what are you planning on doing so that memory consumption
> becomes a concern? As for GC and games - GC hasn't stopped many a
> popular browser based game from being written in Flash. I guess if
> you're writing the next great Quake it might be an issue, but then
> that's what NaCL is for.
I'm not trying to write the next Quake but a simple drawing app (JS
actually for now) that is very sensitive to the near real-time
responsiveness of the brush. I experienced GC issues disrupting UX just
yesterday night.
Not sure this was due to my app specifically (need to profile this) or
simply the main memory being almost depleted (see : memory consumption
IS an issue) so that GC had to run more frequently and widely, but in
the case of a drawing app the impact was _very_ annoying...
Also GCs have the bad habit of being tricked by circular references
causing memory leaks, I'm no GC expert but I know some implementations
can detect the case .. ES5 is proposing weak references to solve for
some GC discrepancies ... Not sure this ain't just a patch on symptoms.
Can someone tell us a little more on Dart's GC specificities ?
Thanks.
Lorenzo
Scot McSweeney-Roberts
<pastrana...@gmail.com> wrote:
>
> Not intended to start a troll here but ... As far as i can tell memory
> consumption is _always_ an issue. There is only one thing as certain as
I'm not saying that it's not an issue, I'm saying that it's not the
prominent issue it once was (when not only was memory far more
limited, so were the compilers, VMs and GCs, assuming you were even
using a garbage collected VM). On modern hardware with modern tools,
for most problems worrying about memory usage from the start is a
premature optimization that will lead to more problems than it solves.
While garbage collectors are not a panacea for all memory problems and
a reckless programmer can certainly get themselves into trouble with a
GC, garbage collectors (now) work well enough.
I would rather see manual memory management as the exceptional case,
not the default.
> moore's law, it's the ability of programmers to absorb moore's law benefits
> by just saying things like "It's 2012".
But we have to take into account that the world has moved on great
deal - I don't mean to be offensive, but Frank's proposal seemed to
have time warped out the late 80s. I'm far more interested in features
like higher order functions, pattern matching or "DSL-ability"(*) than
I am about things like memory allocation, speed of compilation or even
the size of the compilers output (which are in my mind all tooling
issues, not language issues).
> Sure, proposing Pascal semantics here is not what I would call best
> diplomacy but I believe Frank's concerns about language 'frugality' and
> performance / robustness are somewhat legit and keeping them in mind while
> building Dart could be a good idea.
I would say they should be kept in mind while building the compiler,
the VM and their optimizers - ideally as a user it should "just work".
> IMHO one of Dart's most outstanding value would be to allow same language on
> SEVRER and CLIENT. With Dart serving lots of (thousands) client requests for
> a complex web application language frugality is taking a very special
> meaning.
I see some value, but I don't see outstanding value. After all, you
can already use the same language on both client and server with both
Javascript and Java and personally, I prefer a right tool for the job
approach over a desire for a single language.
As for serving thousands of client requests, Java and especially
Erlang handle thousands of requests without issue and both are garbage
collected (and I doubt anyone would call Java "frugal"). Looking at
Erlang in particular, language support for Actors and a very strong
emphasis on immutability appear to be the key to handling a large
number of clients, not memory management.
> Also GCs have the bad habit of being tricked by circular references causing
> memory leaks, I'm no GC expert but I know some implementations can detect
> the case .. ES5 is proposing weak references to solve for some GC
> discrepancies ... Not sure this ain't just a patch on symptoms.
A lot depends on your GC - for example, circular references don't
necessarily cause memory leaks with Java
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html#997442
Scot
(*) You could argue that those features have also time warped out of
the late 80s or even earlier, but they seem more relevant now :-)
Lorenzo Pastrana
On 03/04/2012 06:00 PM, Scot McSweeney-Roberts wrote:
> On Sun, Mar 4, 2012 at 09:58, Lorenzo Pastrana
> <pastrana...@gmail.com> wrote:
>>
>> Not intended to start a troll here but ... As far as i can tell memory
>> consumption is _always_ an issue. There is only one thing as certain as
>
> I'm not saying that it's not an issue, I'm saying that it's not the
> prominent issue it once was (when not only was memory far more
> limited, so were the compilers, VMs and GCs, assuming you were even
> using a garbage collected VM). On modern hardware with modern tools,
> for most problems worrying about memory usage from the start is a
> premature optimization that will lead to more problems than it solves.
Ok, seminal frugality vs premature optimization : tie ...
> I would rather see manual memory management as the exceptional case,
> not the default.
+1 I'm not advocating against GC .. rather _for_ 'sustainable' (read :
responsible, careful) language primitives AND culture ... I still
believe that (in addition to intrinsic features) what will make Dart a
special place to live as a developer is the sharp mindset evolution that
it carries.
Drat is a structured programming language for structured programmers
(tm) See what is a structured programmer's first reaction to webdev
practices :
https://plus.google.com/109047477151984864676/posts/CVGJKLMMehs
I'm glad a fresh eyed guy could phrase this, I'm used to it for too long
now to express it that clearly.
> But we have to take into account that the world has moved on great
> deal - I don't mean to be offensive, but Frank's proposal seemed to
> have time warped out the late 80s.
... the Pascal word :P ... Anyway, robustness, frugality and performance
are not that outdated concepts IMHO (as long as we're talking about a
programming language implementation).
> I am about things like memory allocation, speed of compilation or even
> the size of the compilers output (which are in my mind all tooling
> issues, not language issues).
This is why we discuss those issues here, where the tools builders can
hear ...
> I would say they should be kept in mind while building the compiler,
> the VM and their optimizers - ideally as a user it should "just work".
You're saying this right : it should "just work" is a user concern, and
a side effect of much underground effort and care ...
>> IMHO one of Dart's most outstanding value would be to allow same language on
>> SEVRER and CLIENT. With Dart serving lots of (thousands) client requests for
>> a complex web application language frugality is taking a very special
>> meaning.
>
> I see some value, but I don't see outstanding value. After all, you
> can already use the same language on both client and server with both
> Javascript and Java and personally, I prefer a right tool for the job
> approach over a desire for a single language.
Ok, let me rephrase this : IMHO one of Dart's most outstanding value
would be to allow the use of _Dart_ on SEVRER and CLIENT.
I must admit I didn't give Erlang 'due diligence' but sounded so exotic
a first glance... I'm primarily a server-side developer and reading the
specs in that lighting, I welcome Dart as THE missing link between
Java's ressource-hogism and library bloat and JavaScript's 'looseness'
and lack of generics, I use JS server-side since a while now but I'm
still missing ... something (Not speaking about PHP' spaghettis & meat
balls that can't handle utf8 natively).
> A lot depends on your GC - for example, circular references don't
> necessarily cause memory leaks with Java
> http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html#997442
I'm aware of that, this is why I asked about Dart's GC specificities ?
Lo.
Ladislav Thon
I'm aware of that, this is why I asked about Dart's GC specificities ?A lot depends on your GC - for example, circular references don't
necessarily cause memory leaks with Java
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html#997442