201–210 of 282 posts
Earlier quoted context omitted.
I'm actually glad there isn't parallelism (well threads/actors/tasks). I'd go so far as to consider it a feature.
Honest question: How different is a web worker from an actor?
When people sat down and decided how workers are to act in browsers - Actors are what they had in mind.
This is why Web Workers don't have access to the window scope, use explicit message passing etc.
What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook & Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React…
Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…
Earlier quoted context omitted.
Hmm, so assembly code doesn't have any type safety or high level features. So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? What a load of crap and the op is down voted!!! You are writing java and barring some features like multi-threading,…
>So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? Javascript is not the equivalent of assembly. Javascript is, itself, a higher-level language. You're talking about translating from one high-level language to another, and expecting the inte…
What of it? You can write Javascript by hand which would be good strongly typed code, even if there is no compiler or runtime checks to enforce this. OCaml has js_of_ocaml, which can turn 99% of valid OCaml code into Javascript. And OCaml's type system is a hell of a lot more strict than Java's. Whether or not there are runtime checks is irrelevant. The fact that it is valid OCaml code gives you compile-time guarantees when it comes to the types involved. It's a bit like the way that type erasure works in Java. It gives you compile-time guarantees, but the runtime has no idea about it.
Earlier quoted context omitted.
> Javascript is a fine language if you do this. No,it's not fine, it's a horrible language,with a few good features that saves it from being a catastrophy.hence "Good Parts". Or we wouldnt be here talking about Flow,Typescript or others if the language was "fine". JS was clearly not designed for what we are making out of it today. But since there is no way around Javascript in webdev,good or bad,it doesnt even matter…
nonsense. Just because people and companies have contributed new features and capabilities to the language doesn't make your point. It's not a horrible language, any more than any language. Of course it has things that aren't ideal, but it's highly expressive and if you know what you're doing it can be elegant.
Earlier quoted context omitted.
IMO OCaml is the wrong tool for the job in this case (even if it is a better language for this sort of tool). JavaScript has a weird ecosystem where it is extremely helpful to have all of your tools in the same language. browser-based IDEs, Node, portability, etc, and just one fewer runtime to juggle. Same reasons why closure is awkward as a Java program.
OCaml has excellent compile-to-JavaScript support. Facebook use this to compile their Hack type-checker for an in-browser IDE. I imagine they do something similar for Flow.
See the related discussion on packaging it in the OPAM pull request: https://github.com/ocaml/opam-repository/pull/3083
Direct link
Earlier quoted context omitted.
I'm actually glad there isn't parallelism (well threads/actors/tasks). I'd go so far as to consider it a feature.
May I ask why? Not having parallelism seems like a net negative to me...
This is a long and complicated answer. I doubt I'll do it justice in a few paragraphs, but I'll try.
In one word: simplicity. Primarily, not having parallelism is far simpler than having it. Yes, some models of parallelism are simpler than others but at the end of the day I think we can all agree none of these models are as simple as not having parallelism. As per "net negative": yes, ofcourse, not having parallelism is a "negative". However, "net negative" is interestingly more linked to the applied domain rather than the actual concept. Simply put, the domains that JavaScript is used in don't heavily rely on parallelism (or rather, require the optimization of parallelism).
Thinking about this now, its sort of similar in nature to why people like garbage collection. There is an inherent negative to using a garbage collector, however, (I think we can both agree) in certain (most) domains it turns out to be a net positive. Why? For the same reason, simplicity.
I mean, I could go on, but I'm trying to be as concise as possible. Hopefully, that was a useful. I'm happy to elaborate if you have more specific questions about this.
* s/simplicity/developer efficiency + implicit safety guarantees/g -- Since "simplicity" is quite vague;
Who writes JS these days? Will it go with Angular/jQuery?
Earlier quoted context omitted.
Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with. I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's some…
ES6 adds lambdas, destructing assignment, default/rest/ spread arguments and template strings - all of those reduce verbosity. And there is `let` which has a "normal" scope, although I'm not really sure it needs that. Additionally, generators let you use normal control flow constructs for IO, if you prefer that to FP. While its no Haskell, it certainly isn't much more verbose than other dynamic languages anymore. And…