On 9/23/2017 at 6:45 AM, RivieraKid said:

My argument is that he made decisions to push javascript forward because he created it, a position of complete bias.

This isn't true. First of all, JavaScript was created as work-for-hire, with Eich working for Netscape Communications. What he wrote in 10 days was merely a prototype; the beta didn't ship until four months later. It was submitted for standardization by ECMA the following year. None of this was driven by the personal agenda of Mr. Eich; Netscape Communications and Microsoft were the prime movers at this time.

You've allowed your personal objections to Mr. Eich to make you vulnerable to massive historical distortion, and then based an ostensibly technical dissatisfaction on said distortion.

On 9/23/2017 at 6:01 AM, SillyCow said:

I would not consider run time compilation as very different than interpretation. For me, the main advantage of compilation (and static typing) is that it helps find errors in large projects before you run them. C# and Java JIT is not the same, because the languages are precompiled into bytecode, and it's only the bytecode that goes through JIT.

First off, that's not how JavaScript compilation works today:

https://arstechnica.com/information-technology/2014/05/apple-integrates-llvm-compiler-to-boost-webkit-javascript-performance/

https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

Modern JavaScript compilation in WebKit (I believe Google's V8 has something similar) has four stages of compilation, essentially live-profiling invocations of functions and pushing for the next tier of compilation/optimization when certain thresholds are crossed. The fourth stage in WebKit uses the same LLVM compiler back-end that powers the clang C++ compiler, swiftc Swift compiler, rustc Rust compiler and others.

Secondly, as pointed out by @ericrrichards22, typing proceeds along two orthogonal axes which we may label static and strong. Some "statically" typed languages, like C, are nevertheless weakly typed, permitting easy type coercion and often automatically/silently promoting them, with subtle errors—even with more stringent compiler flags enabled. Python and JavaScript are strongly typed languages, with zero coercion, but are dynamically typed in that they allow rebinding objects of different types against variables and elide type constraints on function signatures. A language like Rust shows that static typing is not absolute, as it permits rebinding against the same variable name as long as it can infer static type, but mandates type constraints (and lifetimes!) on function calls.

Quote

The interesting questions are:

Is the language designed to be compiled?

What design advantages do you get from compiling it?

What design advantages do you get from interpreting it?

etc...

None of these are interesting questions. Instead, ask:

1. whether it can efficiently be deployed to the target environment (no point writing a C++ program to run in the browser—yet);
2. whether the program can maintain the invariants required by the specification; and
3. what the median operational complexity and upper-bound cost of execution are.

As a developer, I wish every language offered both interpretation and compilation, so that I could model and explore the problem space and debug my solution interactively, and then compile with full optimizations for production deployment. I believe that is eventually where we'll end up, rendering this "debate" moot once and for all.

8 minutes ago, Oluseyi said:

whether it can efficiently be deployed to the target environment (no point writing a C++ program to run in the browser—yet);

Plenty of reasons to write a C++ program in a browser. That was the whole point of browser plugins. Take Flash videos as an example... It would be very hard to implement high quality video decompression in JavaScript. While people didn't like how dirty it was, writing native (buggy) code was the only way to support videos in a browser. 

From a gaming perspective, you can look at the Unity browser plugin. While they say it is being deprecated, I have not seen webGL support all of the features that the unity player does. 

2 hours ago, SillyCow said:

Plenty of reasons to write a C++ program in a browser. That was the whole point of browser plugins. Take Flash videos as an example... It would be very hard to implement high quality video decompression in JavaScript. While people didn't like how dirty it was, writing native (buggy) code was the only way to support videos in a browser. 

From a gaming perspective, you can look at the Unity browser plugin. While they say it is being deprecated, I have not seen webGL support all of the features that the unity player does. 

Don't be disingenuous. You, as a downstream developer, are not authoring C++ programs to run in a browser today—and arguably never did, WildTangent notwithstanding. The existence of browser plugin architecture didn't lead to a profusion of application developers creating their own custom plugins.

(I'll point out as an aside that, technically, writing a plugin in C++ isn't "writing a C++ program in a browser" anyway, but rather writing a native application that has its I/O bridged to the web page by the proprietary browser interface. It is abundantly clear from my context, and my inclusion of a link to WASM, that I wasn't referring to this sort of tortuous interoperability.)

Even with Flash, as in your video example, web developers bound their Flash objects to the rest of their pages using… JavaScript. For fully Flash games and RIAs (remember those?), they used ActionScript, an ECMAScript variant.

17 hours ago, Oluseyi said:

As a developer, I wish every language offered both interpretation and compilation, so that I could model and explore the problem space and debug my solution interactively, and then compile with full optimizations for production deployment. I believe that is eventually where we'll end up, rendering this "debate" moot once and for all.

This sounds like Smalltalk. Though my understanding of what you're saying is admittedly hazy.

Long ago I also wished for a hybrid interpretation/compilation model. Then I started writing programming languages.

Nowadays I'd much rather see a really stupidly fast compile model that can do subsets of a program (incremental builds) fast enough to implement something like a good REPL, but without the inherent cost of maintaining two complete forks of a language's execution model. Of course, I say this mostly because implementing both interpretation and compilation is a giant headache and maintenance nightmare, not because the fast-compile solution is inherently better :-)

9 hours ago, Alpha_ProgDes said:

As a developer, I wish every language offered both interpretation and compilation, so that I could model and explore the problem space and debug my solution interactively, and then compile with full optimizations for production deployment. I believe that is eventually where we'll end up, rendering this "debate" moot once and for all.

For C/C++, we compile our internal builds with the edit-and-continue flag set, and place a macro that disables optimization at the top of any file that we're  in the process of working on. That gets you quite a long way towards interactive C++ with very little effort (compared to full runtime compilation / hot-swapping DLL's / etc). You can also type actual code into the 'watch' window and have it be evaluated/executed to experiment during a debugging session.

14 hours ago, Alpha_ProgDes said:

This sounds like Smalltalk. Though my understanding of what you're saying is admittedly hazy.

Yes, Smalltalk offered something kind of like that, albeit by having an elaborate runtime that allowed you to suspend the running state of a program execution environment, editor and debugger, shut down the computer, and later restore it in full. I want that level of robustness during development, but then aggressive optimization that can strip out all debug hooks for when the code is ready to deploy.

8 hours ago, ApochPiQ said:

Long ago I also wished for a hybrid interpretation/compilation model. Then I started writing programming languages.

Nowadays I'd much rather see a really stupidly fast compile model that can do subsets of a program (incremental builds) fast enough to implement something like a good REPL, but without the inherent cost of maintaining two complete forks of a language's execution model. Of course, I say this mostly because implementing both interpretation and compilation is a giant headache and maintenance nightmare, not because the fast-compile solution is inherently better :-)

I don't disagree. In any case, I see interpretation and compilation as points along a continuum of program execution models. I, also, would love blazing fast compilers, but would not be as concerned if I could lazily compile (and recompile) objects as necessary to bootstrap my program in an interactive, editable mode.

We'll get there, eventually.

4 hours ago, Hodgman said:

For C/C++, we compile our internal builds with the edit-and-continue flag set, and place a macro that disables optimization at the top of any file that we're  in the process of working on. That gets you quite a long way towards interactive C++ with very little effort (compared to full runtime compilation / hot-swapping DLL's / etc). You can also type actual code into the 'watch' window and have it be evaluated/executed to experiment during a debugging session.

I haven't used Visual C++ in years, and I do miss edit-and-continue. My current build tools (clang, g++, swiftc, rustc) don't offer it, AFAICT.

11 hours ago, ApochPiQ said:

Long ago I also wished for a hybrid interpretation/compilation model. Then I started writing programming languages.

Nowadays I'd much rather see a really stupidly fast compile model that can do subsets of a program (incremental builds) fast enough to implement something like a good REPL, but without the inherent cost of maintaining two complete forks of a language's execution model. Of course, I say this mostly because implementing both interpretation and compilation is a giant headache and maintenance nightmare, not because the fast-compile solution is inherently better :-)

JAI has these sort of features, you have which john calls run-time-compilation, which is basically like run part of your code before the actual compiling happens in an immediate way and then everything gets compiled. This makes meta programming a full blast and fun: i would love that feature in modern languages. Producing code from code without any external tools built-in is great.

Also the compiler is pretty fast, even using LLVM backend. But unfortunatly the language is not out yet :-(

But i assume in this community nobody except me will use that - because all are so fixed and happy with c++, which i am totally not.

2 hours ago, Finalspace said:

 

But i assume in this community nobody except me will use that - because all are so fixed and happy with c++, which i am totally not.

JAI has some really cool ideas and it looks interesting.  I'd love to play around with it.  But, it's problematic in many ways as far as adopting it as your main game development language... even if it was out and full featured, robust, fast, and all that.  Every SDK you're going to be interfacing with will be C/C++, and good luck finding programmers for your team who know the language.  Every new person you bring on board will be a brand new time sink of getting them up to speed on the language alone, much less the engine, game code, tools, and everything else.  One of the nice things about JAI is that it's designed to reduce development "friction", but adopting a new untested language is going to be a lot of friction, even if the coding itself is eventually faster and better.