These are chat archives for jdubray/sam

13th
Jun 2017
Antanas A.
@antanas-arvasevicius
Jun 13 2017 05:18
I'd really recommend to try TypeScript with allowJs and checkJs compier options which enables .js usage. It will infer all type definitions from javascript itself also from jsdoc blocks. I'm sure that you'll benefit just from that in the beginning.
Fred Daoud
@foxdonut
Jun 13 2017 12:09
The benefits of TypeScript are far beyond just autocomplete: it can be used as an alternative to Babel for using ES6; types are opt-in so you can gradually add types; you are catching errors at compile-time instead of runtime; and so on.
Johan Alkstål
@johanalkstal
Jun 13 2017 12:25
I dislike TypeScript after having used it in a project. I do enjoy Flow though.
I believe there's a fundamental difference. Writing TypeScript makes you a TypeScript developer. You use tools specific for TS.
Using Flow, you're writing JS with added annotations. Your code is still just JavaScript of the version you choose (ES5/ES6). Flow just strips the annotations from your code when it needs to be run in the browser.
I found TS to be a horrible programming experience.
That's me though.
Fred Daoud
@foxdonut
Jun 13 2017 12:36

@johanalkstal I'm not a TS fanatic by any means, I've tried it on some examples and didn't have any problems with it. I have not used it on large projects with multiple devs.

I'd be interested in hearing about your experience and what made it horrible.

Johan Alkstål
@johanalkstal
Jun 13 2017 12:40

I mentioned some issues. That you're not writing JS anymore, you're writing TS. So it has its own ecosystem variations of normal JS tools. You become a TS dev and not a JS dev.
I also spent more time making the TS compiler happy than writing code of value to me. Too much code got added just to please the compiler.
It was more in my way then it was helpful.
And working with definition files was a horrible experience.

I know lots of people love TS but I'm not one of them. :)

Antanas A.
@antanas-arvasevicius
Jun 13 2017 13:37
Here we have an ERP solution with over 150k+ lines of TypeScript and it works perfectly. What I can see that JavaScript developers doesn't like compiler errors, but Flow also emits errors if it finds any type errors, so what's difference?
As I said you can just use plain javascript (enable checkJs / allowJs compiler flag) in TypeScript
no specific Typescript annotations is needed, TS will infer your types from javascript directly and also parses jsdocs for type information
By adding "d.ts" type definitions you'll get more type information for free, TypeScript will look in import / require statements and implicitly find out which types to use for that specific library
if it wont find any, types will be "any" of that module
Didn't get why are you saying that writing it TypeScript I'm not writing in JavaScript? Because semantics is identical, just I'm choosing to add more meta information on my JavaScript or not. In either case you'll add that information inside library documentation or comments aka jsdoc.
Antanas A.
@antanas-arvasevicius
Jun 13 2017 13:46
We are having a client zone module written in pure JavaScript and it contains 10x less code than ERP it self and developers complains that it's more harder to work on than on 10x bigger code size, just sharing my experience
Jean-Jacques Dubray
@jdubray
Jun 13 2017 13:49

Personally I am on the fence, happy to use it when I have too, but in all honesty I don't see the value of static types. I never have undefined errors because I always initialize my arguments upon entry of a function like this:

function f(args) {
    args = args || {} ; //could be [] if array
    // I also do that for props
    (args.myArray || []).map( row => ...)

I accept the critic that the code doesn't look as pretty but it works really well.
The thing that gets me the most is 0 is-equal-to false

Johan Alkstål
@johanalkstal
Jun 13 2017 13:53

@antanas-arvasevicius My remark on "you are writing TS, not JS" was in comparison to Flow.
You are writing TypeScript, which implements similar syntax to JS, but its still TypeScript. If by chance something is supported by JS but not TS, you can't use it.

Flow is just a type checker. You add types to your JS. Nothing more, nothing less. It is JavaScript.
Flow then just removes all type code from your code and leaves your JS as is.

Mind you, it's been 2 years now since I used TS.
But I'm quite happy to never look back. :)
If it works for you, great.
Fred Daoud
@foxdonut
Jun 13 2017 14:03

@johanalkstal not trying to convince you or anything! ;) But

If by chance something is supported by JS but not TS, you can't use it.

Sure you can, you can require any plain JS module in TS.

Antanas A.
@antanas-arvasevicius
Jun 13 2017 14:04
:D Yeah, I think now it's 2.4 version, before 2 years it was I think ~1.0 release, you should try it again and see what's changed ;)
No, TypeScript by it's goals is strict superset of JavaScript, TypeScript itself do not contain anything special, it only follows ES standards and allows to use latest ES standards in a project and transpile down to a specified version. Before 2 years it looks like it has "something" new, but it was only ES6 implementation. TypeScript team do not accept any pull request which adds something new which is not in ecmascript.
And TypeScript also do exactly the same as Flow, it will strip out your type information from your source code and emits the same code without types
even there is a compiler option emitOnError: true, that it will ignore an errors and in either case will output your files (works only like linter)
Fred Daoud
@foxdonut
Jun 13 2017 14:06
@jdubray rather than undefined errors, I find it more useful for things like if you change the parameters of a function, right away you will get errors for other places in the code that calls that function with the wrong parameters. Things like that caught at compile-time are valuable.
Antanas A.
@antanas-arvasevicius
Jun 13 2017 14:06
To be exact TypeScript is Babel + Flow + ESLint all in one :)
Fred Daoud
@foxdonut
Jun 13 2017 14:07
That being said, it's true that in some cases TS feels like "more work" than plain JS.
Daniel Neveux
@dagatsoin
Jun 13 2017 14:08
especially if you come from JS without any compiler/webpack mess.
Antanas A.
@antanas-arvasevicius
Jun 13 2017 14:09
And I've seen many node js libraries will check passed arguments inside javascript, typeof ... and using some validation libraries
which is just runtime overhead, if you have types inside a code there is no need to add many javascript lines just to validate inputs
What's nice about TypeScript that it's type system is not nominal typing like regular strong type languages (Java, C#, C++), but structural typing which lets easily express JavaScript semantics
Antanas A.
@antanas-arvasevicius
Jun 13 2017 14:15
sure, first dive into TypeScript type system takes a little bit time, but remember that writing API doc, writing comments in jsdoc also takes time constantly. Flow itself has a type system which you must learn to be able to use it.
If you love Flow for it's type autodetection, TypeScript now also does that, it detects type information by inspecting assignments return types etc. AllowJs/CheckJs flags allows to use your existing code with TypeScript compiler and Flow can be replaced instantly.
It's strange to see complex build pipelines in projects like Source Code -> Flow -> Babel -> Some SourceMap demangler, instead of just writing tsconfig.json and running typescript in watching mode ("tsc -w") and do real coding instead of babelifying..
Jean-Jacques Dubray
@jdubray
Jun 13 2017 14:20
@foxdonut I am a "forward compatibility" guy, I don't believe we should touch existing calls when a function signature is updated. TS got it right with optional parameters, otherwise I would never even consider touching TS.
Antanas A.
@antanas-arvasevicius
Jun 13 2017 14:21
TypeScript is really underrated technology in Javascript community and it's sad, maybe due M$ logo.. who knows
Fred Daoud
@foxdonut
Jun 13 2017 14:23
@antanas-arvasevicius I am a long-time M$ hater and the only windows in my house are to look outside and let in the sun.
But despite that, I have to admit that TS has been a positive experience for me and I now use Visual Studio Code.
Jean-Jacques Dubray
@jdubray
Jun 13 2017 14:48
@antanas-arvasevicius I don't think MS has anything to do with it this time, I'd just say that once you are used to a language it's hard to switch.
Daniel Neveux
@dagatsoin
Jun 13 2017 17:58
TS is for the bold. Period.
Slađan Ristić
@sladiri
Jun 13 2017 18:35
@antanas-arvasevicius I think that the benefits of typings are just not that great in many situations. I would be worried too that it not an ECMA standard. The most troublesome bugs and problems in our typical web-projects were not helped by a type system.
Javascript is not perfect of course, there are approaches like COQ. Also the automatic typing in vanilla JS allows for nice style of code. Specialized projects might benefit from TS of course, but in my situation I tend to agree with this https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 and https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b.
Antanas A.
@antanas-arvasevicius
Jun 13 2017 20:39
"If TypeScript’s tools would provide hints and type inference for standard JS files by default, I’d use it instead of Tern.js and recommend that setup to everybody. Easy choice."
So YES, from TypeScript 2.3 version it's possible with allowJs / checkJs use standard JS files by default.
post was written on Dec 6 it's outdated
I agree that type systems wont catch bugs, but they help a lot with code usability, you don't need to read comments and look what first parameter must be string, bool, some object with options, what options?
Many libraries are only specs of API with definition of what exactly can be passed to arguments and that information is placed inside some markdown document
Antanas A.
@antanas-arvasevicius
Jun 13 2017 20:44
I think TypeScript solves an API documentation problem
On top of that we are getting correct IDE autocomple and linting capabilities
To write down manually generic or higher kind functions is also not easy especially if more objects are evolved (e.g. mocking/asserting frameworks)
Antanas A.
@antanas-arvasevicius
Jun 13 2017 21:02
Nice thing about generics and higher kind type definitions is that once you declare it properly on top API functions the TypeScript will infer types further down the line without any explicit typing, actually it can easily handle complex inferring situations without any type information. You can try it on plain javascript with TypeScript (+ checkJs/allowJs options)
I'd really recommend to look this talk about real essence why TypeScript: https://www.youtube.com/watch?v=d1f6VBmWg6o
Jean-Jacques Dubray
@jdubray
Jun 13 2017 21:50

@sladiri

I think that the benefits of typings are just not that great in many situations.

I am with you, there is so much more than data structures when it comes to validation

Jean-Jacques Dubray
@jdubray
Jun 13 2017 21:57
@foxdonut I have no doubt that TS has the potential to replace JS (especially with Angular and React behind it), but as we all know language adoption is not an exact science and I am deeply troubled that the aficionados of FP or RFP see "types" are inherently beneficial in an environment where they are de facto relegated as second class citizens. It's probably the influence of Elm again.
It's really strange how things play out in the software industry (say compared to other engineering discipline). We never try to go back to the foundational principles of programming. Someone walks in and say "I have an idea, what if we would write code as if everything was an object", twenty year later another guy walks in and say bullshit we have to write code as if "everything was a absolutely pure function", yet again, a few year later, someone claims that "everything should be a stream" and we never ever go back to some basic principles to validate any of these ideas. As long as there is enough people on board the ship we can't be wrong.
I call that the Channel 9 syndrome. A bit more than a decade ago Microsoft created Channel 9, a propaganda channel that would make every Microsoft technology look like it was a finished product adopted by thought leading customers. Channel 9 alone nearly killed Microsoft by encouraging teams to polish their message without ever worrying about the substance.
Jean-Jacques Dubray
@jdubray
Jun 13 2017 22:04
It looks like we are at that stage now in the entire industry, everyone can come up with their own Channel 9 and as long as there is enough viewers you are good or god or both.
Jean-Jacques Dubray
@jdubray
Jun 13 2017 22:10

I challenge anyone to get a reasonable answer or even an answer at all when you ask simple questions like:

could we walk through the rationale for stating that "everything is a pure function" is the correct programming paradigm?

Except for "Eric Meijer or Evan Czaplicki said so", I don't get other answers.
Beware of Cargo Cults
Vincent Jo
@chiwoojo
Jun 13 2017 23:03
My experience with TypeScript has been very good, except if you are lazy it's not for you because there is a set up stage
you have to set up the transpilers and figure out how to download the Type definition files
but it was worth it and I loved writing it because it had Types next to parameters, that helps the readability alot.
And Interfaces.. those are just amazing.
Fred Daoud
@foxdonut
Jun 13 2017 23:15
@jdubray I agree with you. Thanks for sharing your thoughts, they are always interesting. Hopefully you did not think that I share Staltz's view on TS, I posted that to show how some people are (extremely) converted to TS.
Jean-Jacques Dubray
@jdubray
Jun 13 2017 23:24
@foxdonut it's ok, I like to hear from everyone, I am not selective. He is obviously a smart and articulate developer, and in the end if we all just here to preach our own stuff we'll never make progress. I am just trying to identify the science behind what everyone says because in the end we would not fly or build a mile tall skyscrapers or land on the moon or fix environmental issue without science . For some reasons the software engineers feel that the science is optional in their engineering discipline. It seems that we are still in its alchemy days and there are lots of alchemists... and lots of people content to listen to them.
Even this TS debate is all about I like, I prefer, it's better... in reference to what? Is software engineering just a great big soup where we throw ingredients and some taste better than others? or is there a structure behind what we are all saying?
For instance, what does a type/class plays in mutation?
Is a type/class about validation then?
Or perhaps a type should only be used to structure messages?
Jean-Jacques Dubray
@jdubray
Jun 13 2017 23:29
All these questions are super important, but we seem to stick to syntactic views all the time.
It's only when you have a commonly agreed foundation (like other disciplines, and yes, sometimes the foundation itself needs to be upgraded) that you can discuss all these questions.