Announcement

Collapse
No announcement yet.

SIMD JavaScript Support Added To Firefox, Under Review For Chrome

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Luke_Wolf
    replied
    Originally posted by caligula View Post
    There are many reasons to use dynamic languages.

    First, it can be tested even if it would not compile.
    Two words for you: Static Analyser.
    Two more words for you: REPL loop.
    The first is nearly if not impossible with a dynamic language, and you don't need a dynamic language for the second (mono, and Microsoft Roslyn being perfect examples)

    Originally posted by caligula View Post
    TDD is the solution to problems, not limited static type checking. The green lights in test report are more useful than cryptic compiler errors or warning (why do they even need to show warnings).
    Not really, while TDD helps gloss over some of the issues of dynamic languages, static type checking helps to ensure deterministic behavior. Further using a compiler validates that the code you've written is well formed and thus standards compliant even if the code itself is broken which means that you have an assurance you're not relying upon undefined behavior (assuming you're not using compiler extensions) which helps cut down on the number of bugs you have to deal with as a direct result.

    In short TDD ensures you get the correct output for a certain input
    Static Type Checking ensures determinism
    Compiliation ensures that the code itself is well formed.
    Static Analysis can help with everything from style guidelines to pointing out errors in the IDE
    Intellisense lessens error prone manual typing
    Originally posted by caligula View Post
    Dynamic typing is less verbose and less typing means less bugs in code.
    That's disingenuous for two reasons:
    1).With strong static typing a language can be tooled, this means that I can use this really cool feature known as Intellisense. What I can do with this is type in just a few letters and it'll give me suggestions while providing documentation inline, as a result beyond the initial declarations of variable, class, and function names you're not typing much more than a few characters, and as a result you are inputing a significantly smaller number of characters by hand than you would using a dynamic language.

    2). The important static languages have this feature called type inferencing, and it works just the same way as a dynamic language except for it being a statically typed variable. which means that in the best case the dynamic languages are only saving 3 characters vs static languages for what is actually typed (very few people are going to write the boiler plate stuff by hand, most of them are going to have their IDE autogenerate it for them).

    Leave a comment:


  • Pajn
    replied
    Originally posted by Luke_Wolf View Post
    Again Javascript is fine as a UI-layer specific language, but it's folly to expand it beyond there.
    That is why Google have developed Dart.
    Whatever you think of Javascript (I don't like it) the web is the only truly portable
    platform and developing for it in sane languages (Dart) is a real possibility.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by ravyne View Post
    But why should it be that way and remain so?
    The reason why is that Javascript was not designed to be a general purpose programming language it was designed to be a domain-specific language and it shows all over the place in the design. Trying to take a domain specific language and force it to act as a general purpose language pretty much always causes trouble. Perl for instance is actually great at doing text processing and small shell utilities, the reason why it has the reputation it does of creating unmaintainable code is that people decided that they liked it so much that they were going to use it for everything and as a result they created unmaintainable horrors because Perl wasn't designed for that. You might think: "Oh but they can fix that by evolving the language" The problem is unless you're willing to do a complete break, you're going to have the Xorg problem where there's this core of the language that you cannot touch.

    Again Javascript is fine as a UI-layer specific language, but it's folly to expand it beyond there.

    Leave a comment:


  • Pajn
    replied
    Originally posted by Luke_Wolf View Post
    Well obviously you need the LLVM runtime in order to do the JITing, and assuming that you have installed LLVM on those devices and you bundled all of the libraries you required into it (and that the libraries support all of these platforms) then yes in theory it will. However last I checked Android doesn't have LLVM as part of it's image and the PS4 may or may not.

    That all said trying to run the same unmodified program across all of those platforms plus a desktop is stupid. You are going to at a minimum want different binaries with completely different UIs using paradigms appropriate for the platform coded into them which JS is not going to help with.
    No Android doesn't have it, nor does iOS, Ubuntu Touch, jolla or anyone else.
    However everyone got a browser.
    No I don't want completely different UIs, I want one UI that scales to whatever screensize
    it requires, that support both mouse, keyboard and touch. Doing that using modern
    web technology isn't hard and doesn't require much time if done properly from start.

    Leave a comment:


  • caligula
    replied
    Originally posted by Luke_Wolf View Post
    Pure Dynamic Types are evil. Period. Why?
    (if you don't see what's wrong with this picture... I don't want to maintain your codebase)
    Javascript also comes with a fixed equality operator. Problem solved. Just like PHP has one.

    Originally posted by Luke_Wolf View Post
    Oh yes because web browsers aren't binaries, clearly... Obviously I don't need anything at all to run the javascript. Nope.
    Fact: It's an interepreted language and as a result you need a binary, the interpreter, and JS needs it just as much as any other interpreted language so you get no points.
    Fact is, JS is NOT interpreted anymore, it's a JIT compiled modern language. Another fact is, I can't just install Python or Java on my iPad, Android phone, Chrome OS, Enterprise Windows at school or work. Why? The reason is not technical, it's political. The whole Mozilla is now run by JS inventor. Of course we will shove JS down our throats no matter what you think. They have been actively enforcing JS for ages. You've seen PDF.js in Firefox? I'll tell you. It's purely crap. It's slow and buggy, but they're enforcing it. You can't choose.

    Originally posted by Luke_Wolf View Post
    Works out of the box.... no... you still need a web browser or something else to interpret the JS code for you, just like anything else. Furthermore on almost every linux system BASH works "out of the box", but does that mean that I should be writing everything in BASH? Hell no.
    Some Linux systems have switched to dash so Bash is not a standard. I also don't know what shell my Android devices or iPad has. I doubt Bash. Anyways, think of the modern platforms: tablets, phones, smart TV, desktop, server, set top boxes, etc. They ALL are migrating towards a browser based interface. Browser is the de facto standard today. It's a terrible platform in many ways, but everybody seems to like it and that's where the money is.

    Originally posted by Luke_Wolf View Post
    No, no it really isn't. It's stupid-lazy friendly in that it's not particularly strict, it's loosely and dynamically typed, has significant amounts of brain damage (== vs ===) and in general it has the w3c's idiotic attitudes.
    Yes, but the big players are backing it.

    A user friendly language is toolable, a user friendly language tells you what you're doing wrong and what to change to fix things instead of trying to do weird shit behind your back, a user friendly language works with you to help you write better code. a user friendly language JS is not.

    You know the .NET and JVM Managed Language guys claimed the same thing... guess what hasn't happened? Because here's the problem, as people find new and better ways to to make compilers optimize code the ideas get shared around and everyone implements them. Now the .NET and JVM guys could actually have an argument here because of a trick called Profile Guided Optimizations which they could continuously do, as long as the bytecode is cached.
    JS now has SSE and AVX and GPU acceleration.

    And here you lose the point, because it's got such great standards support that half the internet is broken when using webkit proper with Rekonq and other browsers, and even in mainstream browsers there is significant breakage across various webpages usually exclusively favouring either Chrome or Firefox, textnow as an example only works with firefox.
    People are forced to use Firefox, Chrome, IE, Opera. All other browsers will be ridiculed and forgotten. Only hardcore nerds will use them and miss the old Web 1.0. Mainstream users want something that works.


    Actually it's neither new or the cool kid on the block. It's such the cool kid on the block that most of the major browser developers are trying to replace it entirely or create a variant of it fixing design flaws inherent in Javascript (Typescript, Coffeescript, Dart, et al).
    JS is the cool new intermediate language. It's probably worse than academic bytecode formats, but technical merits don't matter. JS will be replaced with something better in the future but now a great political force is pushing JS as intermediate format and there's nothing you can do about it.

    Surely you must be joking. Flash maybe since they're closish in terms of language and mozilla has decided to start on one (although in all likelihood it'll only get as far as Gnash, which is to say not far enough), Java and Silverlight though... hell no... not happening and you're completely daft if you think anyone but the most insane person is going to spend that kind of effort on a project like that. And if that person does the rest of the programming world will be looking at them with a cocked eye going WTF?
    Last time I checked, shumway was better than gnash. The developers and people who spread media hype also like the more liberal licenses and want to differentiate from toenail eating FSF guys.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by Pajn View Post
    So I can just take that and tun it on my phone, and my TV, and my PS4?
    I mean as you have said it so many times now it must be true sooner or later, right?
    Well obviously you need the LLVM runtime in order to do the JITing, and assuming that you have installed LLVM on those devices and you bundled all of the libraries you required into it (and that the libraries support all of these platforms) then yes in theory it will. However last I checked Android doesn't have LLVM as part of it's image and the PS4 may or may not.

    That all said trying to run the same unmodified program across all of those platforms plus a desktop is stupid. You are going to at a minimum want different binaries with completely different UIs using paradigms appropriate for the platform coded into them which JS is not going to help with.

    Leave a comment:


  • caligula
    replied
    Originally posted by Daktyl198 View Post
    I just want to hop in and say I kinda agree with Luke_Wolf on this argument.

    There are things JavaScript should be used for (interactive web pages, simple-and-stupid web games, etc) and things it really, really shouldn't be used for. Unfortunately, the die-hard JavaScript fans don't realize this, and think it can and should be use for _everything_. Hell, I saw a guy switch from cmake to node.js (writing the script himself), breaking all ARM compatibility along with introducing a ton of issues that weren't there previously. All because he "likes node.js" >_>
    There are many reasons to use dynamic languages. First, it can be tested even if it would not compile. TDD is the solution to problems, not limited static type checking. The green lights in test report are more useful than cryptic compiler errors or warning (why do they even need to show warnings). Dynamic typing is less verbose and less typing means less bugs in code. Some other good ideas http://boxbase.org/entries/2014/feb/...yping-is-good/

    Leave a comment:


  • Pajn
    replied
    Originally posted by abral View Post
    I would like to know where you take the data to back your assumptions.
    Without any statistics, talking is useless.
    Then why do you talk as you obviously have no data to back your statements?
    I however, do.

    The numbers of computers that have Java installed is in fact higher since a lot of browsers
    now have started to block Java until accepted.

    Originally posted by abral View Post
    asm.js is a subset of JavaScript. It is not bytecode.
    Anyway the point is that it's executable by a browser just like JavaScript, and with it you can reach performance similar to compiled programs.
    Asm.JS is a subset of Javascript yes. A totally static subset that is compiled from a language
    like C, but needs to be compiled again to be run on a processor natively. a.k.a. bytecode.
    Your point is correct, however it still isn't Javascript. Just a Javascript compatible bytecode.

    Leave a comment:


  • abral
    replied
    Originally posted by Pajn View Post
    Stop guessing when you have no idea what you are talking about.
    Most people have Java installed.
    Depending on Java in Linux isn't hard.
    Depending on Java in Windows is a bit harder but not hard.
    I would like to know where you take the data to back your assumptions.
    Without any statistics, talking is useless.

    Originally posted by Pajn View Post
    Asm.JS is not Javascript, it's bytecode. Just Javascript compatible but that have
    nothing to do with Javascript when it's run as it's supposed to.
    asm.js is a subset of JavaScript. It is not bytecode.
    Anyway the point is that it's executable by a browser just like JavaScript, and with it you can reach performance similar to compiled programs.

    Leave a comment:


  • ravyne
    replied
    Nay-saying for nay-saying's sake

    Originally posted by Luke_Wolf View Post
    Higher complexity games that need this kind of performance, emulators, and media processing should not be written in javascript. At most you can argue that the game scripts can be written in javascript but even then there's better options. It's the wrong tool for the job. Typescript and friends improve the situation but even then you're still in a horrible situation.

    Javascript is fine for simple games and things that aren't all that complex, animations, UI stuff, things like that. That said I really don't want to imagine the eye-burning horror that an emulator or encoder written in JS will look like in terms of the codebase.
    But why should it be that way and remain so? Because people like you think its unnecessary and that there are better tools today? Its not for you to decide what benefits others see in technologies you wouldn't choose for yourself.

    I mean, if that attitude were allowed to prevail we'd be writing games in assembler still. After all, early compilers for C and other contemporary languages didn't generate code that was as fast as even moderately skilled human programmers, and clearly games demand high performance and should therefore stick with an existing language that's a proven performance platform. Why bother even trying to make C faster, the obvious benefit of high-level programming is that code is more portable, not that it can be fast too. C and C++ certainly don't need SIMD intrinsics either, if you're willing to commit fully to your argument.

    We can't just say things don't work well enough now, and therefore we shouldn't make them better, and therefore they will never be work well enough. That's circular logic.

    Now, I'm fully aware of the history of Javascript being used at first for little hacks and mouse-overs, etc. So what? Name me a single mainstream programming language that predicted, rather than assumed, if and where it would be successful 20 years after its introduction? Today, following best practices, and avoiding certain parts of it--and I ask you: what language does not have its warts--you can write perfectly well-engineered code in JavaScript.

    I'm neither so naive to proclaim that Javascipt/HTML5 is a bastion of portability across browsers, especially in light of the more bleeding-edge features; nor am I silly enough to think this disproves those claims flatly -- you don't need the code to run the same on every browser to run on most platforms -- proclaim that Chrome (for example) is your client, concern yourself with support chrome to the fullest extent, and call it a day -- take tomorrow off, you've done good; 300 million people already have your client installed.

    Leave a comment:

Working...
X