241–250 of 285 posts
Fuck you fanboy...
You've been breaking the HN guidelines repeatedly. We ban accounts that do this, so please don't do this any more.
Following the guidelines means posting civil and substantive comments, or no comments.
Earlier quoted context omitted.
You can totally use JS libraries with Elm. Source: we do it all the time at NoRedInk, and we've been using Elm in production for our millions of users (as our go-to for all front-end work at the company, not just as a side thing) for the better part of a year now. :) Details about our experience with Elm in production: https://www.youtube.com/watch?v=R2FtMbb-nLs
Just for the obligatory record: Purescript is basically "Elm evolved". Everything Elm does, Purescript does better (FFI for example is such a chore in Elm). Drawback: the learning curve is basically as steep as Haskell's.
People make basic mistakes routinely with types. Even with very sophisticated type systems, like the one used in Haskel. There's evidence that in rare cases where people could have been "helped" by a type system, the cost of finding and fixing such a bug is far lower than using a type system to enforce correctness in the first place. You will write automated tests whether you're using a type system or not.
I am hesitant to start the whole typed vs untyped debate here, but this is exactly what your comment is highlighting. Where does all this evidence come from? I have recently started using Scala and while initially the learning curve was quite high, I have been so happy to have such a comprehensive type system.
Earlier quoted context omitted.
Just for the obligatory record: Purescript is basically "Elm evolved". Everything Elm does, Purescript does better (FFI for example is such a chore in Elm). Drawback: the learning curve is basically as steep as Haskell's.
My experience with Purescript/pulp was rather negative. Basic commands were throwing errors (pulp init IIRC) so I decided to not even consider it for anything serious.
I recommend you try again and file a bug or look for help in irc if something breaks again (although I've never seen pulp init throw an error).
Earlier quoted context omitted.
That's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger. You're never debugging TypeScript separately from JavaScript.
I see the following code in https://github.com/Microsoft/TypeScriptSamples/blob/master/t... , For me, it is definitively not the JS I know. declare var _: { each (arr: T[], f: (elem: T) => U): U[]; delay(f: Function, wait: number, ...arguments: any[]): number; template(template: string): (model: any) => string; bindAll(object: any, ...methodNames: string[]): void; }; declare var Store: any; If there is bug in this co…
This is akin to saying "Every C++ library should be written in Objective C." EDIT: Hey people down voting me; it literally is the same. C++ is a standard, JS is a standard. TypeScript is (like Objective-C) a compatible alternative.
a better (but still imperfect) comparison would be suggesting to rewrite c libs in c++, given the latter's somewhat better type safety.
I would use Typescript, but its type system isn't smart enough to handle the complexity of JS ecosystem. The other day I wanted to move my project to typescript, the first module needed ambient definition that didn't exist in Definitely Typed repo, it was quite annoying to create, and I am not even sure it's correct, then I wanted to type some parsed JSon that had a TYPE_NAME property with a string giving its type, i…
Absolutely not. This is the opposite of what you should do in my opinion. If you're writing an API to be consumed in language X then you need to write the API itself in language X. This will help you capture and handle edge cases, language idiosyncrasies and other similar issues the way you want. Using a different language that gets transpiled into a target language also increases your surface area for bugs because n…
I have to agree with the OP's point if your writing a library you should write it in the base language (common denominator). I work on JVM stuff and nothing is more annoying then dealing with a very nice library written in Scala, Clojure or Groovy and have it not work in plain Java. Plain Java on the other hand works fine in Scala,Clojure, and Groovy.
The above JVM languages compile to byte code (which I guess would be analogous to WebAssembly).
Thus I'm not sure if transpiling is as bad since Xtend (which is more analogous since its a Java transpiler) is very interoperable AND does not compile to bytecode directly.
So WebAssembly might end up being just as bad as the plethora of JVM languages that are sort of interoperable.
Earlier quoted context omitted.
I cannot vote this up enough. It really is such a different experience to developing in "plain" JavaScript.
It's so much more pleasant to write and maintain than wild, un(type)safe javascript.
Earlier quoted context omitted.
The problem is with the author's assertion that all libraries should be using TypeScript and not, say, Flow, or some other alternative that achieves the same goals, perhaps better.
Does Flow offer type definition files?
[1] A hand-maintained definitions file: https://github.com/facebook/immutable-js/blob/master/type-de... . Sure, it's nice as documentation, but that is a lot of redundant effort if you already have separate documentation, and types and documentation in the original source code too. [2] https://github.com/AgentME/contain-by-screen is one simple example.