That may be true. “Big game studios” have to make all kinds of miserable sacrifices and compromises that I am sympathetic for but not very interested in.
On this forum, I’m expecting to chat about programming technology with others are excited about that.
Believe me, I’d rather not talk about C++ at all, but people always want to bring it up. It actually hurts me to defend it in any manner. BUT I think it very useful for us to be at least partially sane when having technical discussion.
@Cas: why javascript? We could come up with all kinds of technical reasons, but they’d all be BS. The real reason has got to be because Netscape made a successful browser. Follow the bellwether.
Small game studios have to make miserable sacrifices too, mind.
@Roquen - I know why javascript, historically… I’m just wondering why competing clientside tech failed to flourish. VBScript died on the vine, Google are attempting only now to do something called Dart but of course it won’t work anywhere outside of Chrome. Browsers would probably have been far better off if they used some sort of bytecode that any language could have been compiled down to instead of the current status quo. Maybe LLVM is the best bet for a rosy and inclusive future.
Cas 
Dart is compiled into JavaScript which runs on all major browsers. No one is deploying raw Dart source. The native Chrome support is a development feature so you can dev/debug in native Dart and compile/deploy with compiled JavaScript.
JavaScript is being used as a byte code. People have been compiling CoffeeScript, ClojureScript, Dart, Java, C#, and now Microsoft TypeScript to JavaScript.
You seem to be implying that JavaScript established it’s dominance through the idiosyncracies of the evolution of the web and browsers and computing devices and not because it won some pure intellectual best language competition… This is beyond obvious. Most technical standards are like that. It’s hard to rally all the competing players together to push new replacement standards. Look at x86; many have pointed out flaws and many have designed much better ISAs, but still people have found ways to make new chips with cutting edge designs that satisfy legacy x86 compatability baggage. Everyone can point out flaws with JavaScript, but many are finding ways to provide cutting edge dev tools and runtimes around the legacy compatability issues.
@Cas: LLVM bytecodes wouldn’t be a desirable solution as it’s too low level IHMO. For instance type information is already baked in at that point. All bytecode definitions suffer from problems like this. This limits the types of languages and features which can be supported. I favor an abstract syntax tree representation. Smaller in size and a higher-level abstraction model. Once the VM is done with any verification and high-level transforms, it’s simple to flatten into something like LLVM, which then handles all the hard-core low level optimizations and spews out native.
I don’t see what the problem of typed bytecodes is in terms of supporting higher level languages. If you have no types in the bytecodes, then what you really have is a single type. If the bytecode supports an “object” type and other types, then you can easily emulate a unityped VM within that typed one. At runtime, type information is an optimization you needn’t concern yourself over.
An AST is higher-level, but it has no semantics of its own. Let’s say my language supports delimited continuations, and I spit out an AST for it. Let’s say the underlying execution engine I hand this AST to doesn’t have any notion of them. Now how do I implement them efficiently? An AST would certainly make a more sensible compiler target than a crazy hall of funhouse mirrors like javascript source, but it doesn’t give you any extra semantics for free (except maybe macros).
I’m certainly not above miss-equating personal performance with technical superiority, but I’d say that macros alone is a pretty big deal. (For others, by macros we’re not talking about C/C++ pre-processor style macros but expanding a code base over various configurations…like hygienic macros, or c++ templates…that don’t suck)
All macros suck, they render your code unreadable and make it impossible for others to modify without major headaches.
If your only experience with macros is of the C variety, then I suppose that’s a pretty natural conclusion. Otherwise, you might want to educate yourself a little on the sort of things that structural transformation of code can actually do before rendering sweeping judgements on readability and maintainability.
Heck, even cpp macros … do you find code using NULL harder to read than code with ((void *)0) instead?
I wouldn’t say that there are no syntax-tricks. What about the enhanced for-loop, or the shorthand-if?
Compared to Python, Java’s “syntax sugar” is laughable.
Python has a lot of useful things like list comprehension, “with” statement, multi-line strings, operators for joining/multiplying lists and objects (and ways to override these), a crapload of common methods like str.splitlines() or CSV parsing/loading, keywords for method paramaters, etc. Once you’re familiar with Python or any other functional language, going back to write in Java feels extremely “old school” and verbose. You find yourself writing double or triple the amount of code, and none of it can be written ‘functionally’.
I’d say Python is imperative. I don’t get this new fad of calling all dynamically typed languages functional.
It’s because these languages support basic functional concepts like, say, first-class functions. It’s hardly the “dynamic” aspect, which actually diminishes it as functional with respect to modern FP techniques that involve sophisticated type systems such as those found in Haskell and Scala. You don’t need such a type system to be a functional language – Scheme and Erlang get by without it – so at best the type system is orthogonal.
Python also imported list comprehensions from Erlang, and those are very much a functional construct. Haskell uncovered the building blocks behind list comprehensions (spoiler: it’s monads), and C# and Scala followed suit, so now you can write your own “whatever-comprehensions” by just implementing a couple simple functions. Python unfortunately doesn’t base its listcomps on the functional principles, but it doesn’t mean that the hardwired listcomps/genexps it has are any less functional themselves.
Python’s definitely not a functional language by any stretch, but it does at least support it.
… I think we all know that the internet was not supposed to be used as an interface for multi-media in the first place. It was only made for text-based systems, and people decided that they wanted to use it for more powerful media. Obviously when the Internet was first made, it wasn’t devised for movies, mass media, or gaming.
HTML and JavaScript are just plain outdated. That is the fact. What all companies, especially Google, is trying to do is keep JavaScript and HTML relevant so all the loads of old web pages would still be readable. JavaScript is definitely not suited for dealing with the amount of media we are trying to achieve nowadays.
If it weren’t for Google pushing to great lengths to keep JavaScript relevant, the Internet would have probably collapsed under the device overload. The applications are getting more and more powerful every day. Something is going to break, and I think JavaScript is running a thin wire.
If you ask me, the Internet needs a language overhaul. Right now, due to the inclusion of tablets and phones, the programming world has become very messy and unfocused. Even Java’s whole notion of “write once, run everywhere” is essentially ruined. It is like companies don’t know what technology to go behind. Ha, I don’t have any clue what technology to go behind. Too bad time is money… … . …
What makes you think the Internet is the Web, or that even the Web strictly pertains to HTML? So it wasn’t “designed” for movies. The phone system wasn’t designed to carry data either, nor was the cable TV system. Well-designed systems adapt and evolve without needing to be destroyed first.
Have you read some of the first RFCs? I think you’ll find that graphical apps were being considered right from the start.
As Tim Berners-Lee famously said: “The Web will always be a little bit broken, because we are too.”
Try c, c++, and ASM, of course others but none of them used macros. ASM from the 1980s to about 1995. I find syntax for most languages to be blech, but you can set a constant NULL instead of a macro, global constants are possible, and programatically sane, in cpp.
In true OOP macros are not only bothersome, they are unnecessary.
The “internet” gets a “language” overhaul about once a year. The latest trend is HTML5, replacing Flash, thankfully. Tablets and iPads need an overhaul, if anything, and all other touch devices, so they can interface with other events instead of just “click here.”
Okay then, I’m not talking about anything like those. Try Scheme, Lisp, Dylan, and Scala macros, or Python’s EasyExtend, and that’s much more like what I’m referring to when I say macros. The C Preprocessor gave macros a bad name.
Macros are still obsolete. It’s actually one of the reasons I prefer Java, the other being that everything except primitives is a pointer, and the garbage collection system.
http://www.faqs.org/rfcs/rfc178.html
Are you referring to this? It took a bit of time before graphic interactions became part of the RFC’s.
I agree with your point. Let me clarify my points a bit.
The Internet is not the Web, but the Web does make up a chunk of the Internet. Tablet and phone devices are more-or-less structured to handle the Web better than any other feature of the Internet. HTML5+JS is pretty much de-facto for all Web interactions (if you want it to work everywhere.) Personally, I find JavaScript very clunky to work with.
The fact that we have to convert everything to HTML5+JS to make programs and web pages work everywhere seems like a step backwards. Isn’t the ability to program in many different languages the key to better programs? Unless you are arguing that these systems (HTML and JS) are well- designed, I can’t see the point you are getting at.