22 minutes ago, RivieraKid said:

An important difference to note is that JavaScript is forced onto the largest subset of user-facing developers. If google/ms/apple could get their fingers out and agree on a common vm JavaScript would die off practically overnight. Unfortunately MS already have a perfectly capable sln that they are prevented from using because of political. Google / Apple don't want to go down that road - they would end up delivering something very similar to .net and they know it.

Server side JavaScript only exists because JavaScript is a must on front end. People want to share their code base and that is the only practical way to do that. No sane developer would have independently developed JavaScript for server side if it didn't already exist.

I chuckle a little bit whenever I see that the next big thing in the front-end world is something that existed 10, 15, 20, 30 years ago...  We keep reinventing Java applets, Flash, UI paradigms that are old enough to order a beer, and even makefiles.  But in Javascript!

I never claimed to be any authority, it's just my opinion that javascript as assembly is a poor analogy- the only reason I include the fact that I've made games this way was an attempt to preempt the "how would you know, I bet you've never used javascript before" argument, despite the fact that I use it quite regularly.  Am I not allowed to have my own opinion? 

2 hours ago, ericrrichards22 said:

I chuckle a little bit whenever I see that the next big thing in the front-end world is something that existed 10, 15, 20, 30 years ago...  We keep reinventing Java applets, Flash, UI paradigms that are old enough to order a beer, and even makefiles.  But in Javascript!

[rant]

I personally blame this guy https://brendaneich.com/ 

He wrote the 1st version of javascript in a mad dash in 10 days (and donated to anti-same sex marriage campaigns, unrelated but gives an idea of the kind of ideological bs that goes on in his head, he's a zealot).

Knowing that the core of javascript (at the time) was a sloppy joke he still went on to champion it through Firefox and Mozilla. To this day he still riding that broken train. Web assembly is next which I think would be a great improvement but tbh I think it will be another 5 years before we see it making a difference. Its HIS baby, he's biased and has led millions of uninformed developers for decades with bugger all progress.

Look at the advancements in gaming compared to web. Its laughable. Web developers get excited when CSS supports rounded corners or they can draw lines on a canvas. Even today rendering a 100 column * 100 row table in html/js will grind any browser to a halt.

Oh and if you want the best experience you have to target JS, Java, C#, Swift (maybe C too!), a different UI model for each and physically test on hundreds of handsets. Have I mentioned that modern websites do little more than present rectangular images and text?

There is no competition between web technology vendors, no incentive to make things better.

[/rant]

On topic: Who cares if C++, in gaming, is dominant or not, you can still choose to use something else if you desire.

Each language has different goals in mind. Use the right language for the right job.

• C 
  • Close to assembly code. Easy to expect what your code will be compiled into
  • Good for embedded devices
  • Good for high performance bursts
  • Good C can be practically as fast as assembler (If you are willing to read the map files and optimise your code)
• C++ 
  • First and foremost: A way to extend C to support some OOP syntax
    • C was popular, and C++ allows you to write OOP only where you want it
    • You can easily use C code and libraries
  • The fastest implementation of OOP principles
    • Fast because you can allocate objects on the stack
      • Memory management  (GC) in other languages can be the costliest thing in the program
    • Fast because you can allocate packed arrays of objects
• Java
  • Designed to be stable and maintainable
  • Very easy to control and analyse large projects written by large teams
  • If you want to write a stable buisness application, that will never crash, write it in Java
• Javascript
  • Designed to run everywhere (achieved this goal way better than java)
  • Designed to be forgiving:
    • The event based nature of HTML bindings means that if something fails, the program will keep running
      • There is no main function to be thrown out of...
    • Asynchronous I/O in combination with the limit to a single thread means you get easy paralilism without alot of complexity
• C#
  • Microsoft saying: We can do better than Java
  • Much more advanced and agile than Java
  • If you want to write *MS only* code that does not need low level memory management, look no furhter
    • Yes, I know about mono. But every time I wanted to use it for non trivial projects, I hit some brick wall with a missing library or feature.
• Scheme/Lisp/Prolog:
  • Languages designed for exploring programming language syntax.
  • Very good for academic work
  • Very good for solving small problems in creative ways. (as opposed to writing an OS or a large Webapp)
  • Very good for solving mathematical problems

Before looking at their syntax, you can see that each of these languages are designed and optimised for different goals.

You would be insane to write a complex business webapp in C. (It will crash every time a new dev alters something)

You would be ludicrous to write an embedded (16k) kernel in Javascript

You would be a laughingstock use java to calculate large amounts of particle physics.

If you write *large* enterprise apps in python (untyped, interperted, and whitespace based) then you will have a bad time. No amount of linting can compare to the forced expressiveness of Java/C# .

If you write small programs in Java using a notepad (instead of a syntax parsing IDE), then you should really look into Python.

etc...

On 9/21/2017 at 4:31 AM, matt77hias said:

(there is even no compile-time because JavaScript is generally a purely interpreted language)

JavaScript is routinely compiled these days, with various levels of optimization triggered by access frequency and invocation history. This has been a big part of the performance improvements of Google's V8 and Apple's Nitro, especially on mobile.

13 hours ago, RivieraKid said:

(and donated to anti-same sex marriage campaigns, unrelated but gives an idea of the kind of ideological bs that goes on in his head, he's a zealot).

Your argument is poor, and takes a single socio-political position as justification to demean and dismiss the entirety of someone's technological contribution. Don't do that; that's zealotry, too.

6 hours ago, Oluseyi said:

JavaScript is routinely compiled these days, with various levels of optimization triggered by access frequency and invocation history. This has been a big part of the performance improvements of Google's V8 and Apple's Nitro, especially on mobile.

 

Your argument is poor, and takes a single socio-political position as justification to demean and dismiss the entirety of someone's technological contribution. Don't do that; that's zealotry, too.

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.

With Javascript, Python, etc... You have a much murkier idea of the state of your code before you run it. From a maintainability perspective: There is little difference between just-in-time compilation and interpretation. The main question is not: "Can a language be compiled?". That's because every language can be compiled... If I gave you instructions in Spoken English, you could probably interpret them and compile them into assembler. There is also nothing preventing you  from interpreting C at runtime. 

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...

23 minutes ago, SillyCow said:

Javascript, Python, etc... You have a much murkier idea of the state of your code before you run it. From a maintainability perspective: There is little difference between just-in-time compilation and interpretation. The main question is not: "Can a language be compiled?". That's because every language can be compiled... If I gave you instructions in Spoken English, you could probably interpret them and compile them into assembler. There is also nothing preventing you  from interpreting C at runtime. 

The interesting questions are:

Is the language designed to be compiled?

Beyond compiled vs interpreted, this is really veering into the territory of dynamic vs static typing, and also the strength and expressiveness of the type system. Javacript and Python aren't a PITA for large systems because they are interpreted - although things like exec and self-modifying code and monkey-patching don't help - it's mostly because they've got dynamic type systems that are pretty weak. Static typing isn't necessarily a silver bullet; C is statically typed, but weakly, and you can do all sorts of evil stuff casting and poking at memory.

Haskell might be getting too far into the chains-and-whips masochist end of the spectrum, but it increasingly seems like evidence is piling up in favor of more strongly, statically typed languages. At least for anything that has to be supported and maintained and isn't quick-and-dirty throwaway code.

7 hours ago, Oluseyi said:

your argument is poor, and takes a single socio-political position as justification to demean and dismiss the entirety of someone's technological contribution. Don't do that; that's zealotry, too.

I said it was not relevant to technology. It is not a single argument though.

My argument is that he made decisions to push javascript forward because he created it, a position of complete bias. He has acted from this view point inspite of sound technological reasons to do the opposite. If he is willing to hand over money to enforce his religious beliefs then I think it says something about his character, that is the only relevance it has.

14 hours ago, SillyCow said:

• Javascript
  • 1)Designed to run everywhere (achieved this goal way better than java)
  • 2)Designed to be forgiving:
    • The event based nature of HTML bindings means that if something fails, the program will keep running
      • There is no main function to be thrown out of...
    • 3) Asynchronous I/O in combination with the limit to a single thread means you get easy paralilism without alot of complexity

 

1) JavaScript runs everywhere because A LOT of people worked very hard to make it run everywhere. It was designed to run in netscape, end of story. In fact it currently doesn't run to an acceptable level in the majority of real life cases (e.g. IE8) (all users must constantly upgrade to the latest edition or face poor performance), i actually stopped using firefox because for a long time it had aggressive hard barriers to upgrade every week. There are still differences between implementations.

2) Maybe in the past but these days if something in JavaScript fails you are pretty screwed.

3) Most languages have an asynchronous method for I/O. For a long time you couldn't do any significant processing in the front end because it would freeze the browser. You could ONLY response to events. It is still very painful to deal with a large volume of visual elements.

JavaScript was designed to do async data fetches and chuck that into the UI (and yet it didn't come with any concept of data binding), under the hood it stored hashTable<obj> where obj could be another hashTable, a primitive type or a function (maybe some other junk too). Types were evaluated based on the operation on that line at the time of interpretation. A class was just functions and values in a hashTable. Any graduate can write this without any fore knowledge of this field. I have done so.

I'm sure someone could pick out 3 paradigms/tools that when used correctly make JavaScript a "Dream" but that is really beside the point - clearly there is something wrong if you need some dev guru with 5 years experience to direct you to some random corner of the internet for some 3rd party tools that patch up all of its short comings. 

Anything good about JS is too little too late imo, it makes me not want to be a developer anymore.

37 minutes ago, RivieraKid said:

3) Most languages have an asynchronous method for I/O. For a long time you couldn't do any significant processing in the front end because it would freeze the browser. You could ONLY response to events. It is still very painful to deal with a large volume of visual elements.

 

I challenge you to find an asynchronous I/O C++ 11 API  (or Java) that's as friendly as JavaScript's implementations. And while javascript uses multi-threading to do the actual I/O under the hood, the fact that all the processing happens on a single blocking thread makes it much easier to program (and slightly slower). With C++ and Java you would have to worry about synchronisation and deadlocks when doing multi-threaded asynchronous I/O. True, you could implement a single threaded message loop or a selector, but that's much more complicated to write and maintain. However, in Javascript, if you ever wanted to have mutlithreaded message*processing* you would have to work much harder than with C or Java.

That's why javascript is more beginner friendly. It takes the most common case ( that only the actual I/O takes time, and that processing is negligible), and gives you that out of the box. Requiring you to allocate new processing buffers for each request on the heap in the process.

That's why C is for more advanced use cases: You'd work 50 times as hard writing the code, but you can process requests in place on multiple threads.

And that's why Java is interesting: Because even though you'd still work 40 times as hard, you're huge code would be more maintainable if was part of a big project. (and it would run 50% as fast as C)

So if you're writing a small server side app with short bindings for javascript GUI code, use Node.js.

If you're writing a huge banking app, use Java.

If you need the extra performance because you are writing an HTTPS gateway (like NGINX) use C. 

If you try to write the banking app in C or Javascript, you are probably doing it wrong.

IF you write the massively loaded HTTPS gateway in javascript you are probably also doing it wrong...

I'm using the webapps as an example. Because with games, your choice of language usually just stems from the toolset you want to use: ( Unity = C# , Unreal = C++ , Browser=Javascript, Android = Java + C (NDK) , iPhone = ObjC, etc...)

1 hour ago, RivieraKid said:

(e.g. IE8) (all users must constantly upgrade to the latest edition or face poor performance), i actually stopped using firefox because for a long time it had aggressive hard barriers to upgrade every week. There are still differences between implementations.

I have rarely encountered a case where the  poor performance of a web page had anything to do with javascript performance. Most of the time it had to do with slow browser APIS, and slow implementations of Canvas and Vector art and Memory management, which are all implemented in C/C++.

As an early mobile HTML developer android allways had the fastest java-script engine, while apps allways ran faster on apple devices. This is because apple optimized their native browser code which was doing all the heavy lifting (decompressing jpegs, rendering canvasses, parsing CSS, etc...), while Android optimized javascript which usually does very little work on a webpage. Javascript usually just handled C-Parsed json coming from ajax calls, and fires DOM events like .show() which are then implemented in C (nobody draws an html button in javascript). So the whole "compiled javascript is so much faster" allways seemed irrelevant to me.

The same is true for game logic coding. The heavy lifting (physics, Spatial partitioning, rendering, and pathfinding)  are all implemented in C++ or shader code. What language you choose to call model.render() or player.pathfind() from is largely irrelevant from a performance point of view. In fact, if you choose to it in C you are probably working too hard.

To a large extent, it is even irrelevant what you call opengl.renderVBO from... I remember a long debate advocating the use of NDK over java in android to make openGLES calls. I decided to benchmark a switch to NDK over Java. The NDK calls were 17% faster than the java calls. Considering that opengl calls were only 40% of my execution time, that's a 7% increase in performance for a much more complicated code base in C. Hardly worth it...

Another point: Shader languages are one of the first cases of DSLs I can think of where the DSL was targeted directly at performance. They actually created a "weaker" language that was easier to parallelise, thus actually increasing performance by making things more abstract. This is the first wide spread example of a weaker language actually being faster than a powerful low level one.