Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed.
Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (with Flow), it's an amazing tool for static code analysis and avoid errors at the runtime. I would suggest everyone give it a try (with TypeScript, Flow or whatever).
With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!
I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.
My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.
Their algorithm always fails on certain cases. If your code base is larger, it's more likely to contain those cases.
Example case that will always fail:
const x = { foo: () => {} }
x["f" + "oo"]();
Yes, this is a contrived case, but we had similar code in production at my last job.
```javascript
var foo = {
a: true, // Find all references on "a" here...
b: "hello"
};
foo.a = false;
bar(foo);
function bar(obj) {
obj.a = false; // Won't find this "a".
}
```
```typescript
interface Foo {
a: boolean;
b: string;
};
var foo: Foo = {
a: true, // Find all references on "a" here...
b: "hello"
};
foo.a = false;
bar(foo);
function bar(obj: Foo) {
obj.a = false; // Will be found, renamed if refactored, etc..
}
```
There is some support for JsDoc in the engine, so code like the below will work:
```javascript
/** @typedef {{a: boolean, b: string}} Foo */
/** @type {Foo} */
var foo = {
b: "hello"
};
foo.a = false; // Find all refs here
bar(foo);
/**
* @param {Foo} obj - Some object
*/
function bar(obj) {
obj.a = false; // will find this one
}
```
As you work on this, do you know if the refactoring tools would fully work with my code typed with Flow instead of TypeScript?
(I use the official flow-for-vscode extenstion, idk if it's relevant)
Edit: Ok I just tried and it works, even with the extension disabled.
type Foo = {
a: boolean,
b: string,
}
var foo: Foo = {
a: true, // Find all references on "a" here...
b: "hello"
};
foo.a = false;
bar(foo);
function bar(obj: Foo) {
obj.a = false; // Found it.
}- If you don't have any calls to the function yet (i.e. "bar(foo)" wasn't there above), then there is nothing to infer from, so you have no idea what the type is at this point (other than by the use of the parameter inside the function).
- Is your call-site wrong? If the parameter type is explicit, this is easily checked. If not, then again you can only go by what the function does with it. (Which may not be much help if it's something like "RestAPI.post(JSON.stringify(theParamInQuestion))" ).
Disclaimer: I'm working on a competing tool
If a particular function can be tied to particular variable from scoping block, then the function is not entirely useful. On the other hand, if a function is general and has the same argument name as variable from scoping block, which is going to be passed in, mentally it is difficult to analyse the function without thinking about the variable which may shadow bugs in function. E.g. square root function may omit negative argument check, because variable from scoping block is always positive.
Instead of knowing scoping rules I advocate for distinct variable names, so scoping rules (name shadowing) do not even come into play.
function Person(name) {
var person = this;
person.name = name;
}
var person = new Person("Jon Doe");
alert("Welcome " + person.name);
person.name = "Harry Houdini";
// ES6 example:
var messages = people.map( person => person.name += " is a rock star" )I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.
I'd really recommend trying it again. On a performant machine, VS Code feels like a native app to me aside from a slightly slower start up time, whereas Atom is noticeably slow. On my bottom spec 12" Macbook the difference is more noticeable, but everything feels slow on there.
If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.
That right there is the whole essence of typed programming :)
Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.)
Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)
But sometimes I don't care exactly what sort of number is used. This is where many type systems go overboard, by forcing me pick a 64 bit unsigned integer or whatever.
I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.
One big thing is TypeScript classes are entirely different than standard JS classes. I guess you don't have to use them but it adds Abstract classes, interfaces and access control (eg private, protected vars).
Elm is sometimes on the frontpage of HN but let's be honest, it's not really used.
TypeScript is a highly practical and pragmatic language. Use it for anything serious.
It is a cool language and platform, but to me it looks like with time it has actually become more conservative.
TS on the other hand appears to contain some interesting new things on each release (possibly too many). Case in point, Lookup and Mapped types in 2.1 seem like a brilliant idea.
Elm is pretty neat if you want to build a reactive GUI framework with everything immutable by default and have lots of functional programming idioms at your disposal. However that's all it does: if you want to do e.g. server-side rendering or use it in an angular project you're out of luck; if you want to interop with other JS code then it's a pain.
Typescript doesn't enforce any paradigm or bring any particular framework with it. It's just Javascript with type annotations and some extra features. So you can use it with React and Redux to create something like Elm's framework, but it won't be quite as safe or concise as you'd get with Elm. However it fits in much nicer with other JS libraries and can run on the server or alongside any JS GUI framework of your choice.
Elm is also still officially beta, and new releases often involve fairly large breaking changes.
Personally I started off a big fan of Elm but fell off the bandwagon as I ran into its limitations.
[Pros]
- Good language design (immutable, based on haskell+OCaml, nice type unions/pattern matching, everything is an expression, etc) Most people who write Elm are seduced by its elegance.
- Very, very typesafe. If it compiles, 99.5% of chances that you won't get runtime errors (baring a few bugs) handy when you're tired.
- It was made for beginners, it's easy to pick up, the tooling is simple, the compiler errors are easy to read.
- The "Elm architecture" provides a way to build simple SPAs, out of the box, without having to use 10 libraries like some people do in the JS world.
[Cons]
- The community is tiny
- Elm is... by far the most opinionated environment I've ever seen. More so than RoR/Ember. Elm the language and Elm the framework have no clean escape hatches. It provides guidance for newbies, but when you encounters problems, it stings.
- The Elm framework is entangled with the Elm language. One person pretty much maintains both; developments go at a very slow pace and potential contributors don't feel overly welcomed.
- Elm's type system is extremely simplistic. You won't be able to express many things with it, and your code will have a LOT of boilerplate.
- if you're a front end developer with a sharp attention to details, it's a pain to build complex things with it, especially SPAs who have a lot of state. You need hacks all the time as the language + the framework are fairly under powered and it gets new features once every blue moon. There are many things that are impossible to do in pure Elm, so you have to write javascript anyway. The official way is to use ports, but many teams seem to rely on the frown upon Native modules, which are written in awkward JS.
- Talking to Javascript (foreign interface) is a bit of pain (less so now than in the past though!) and so is reading/writing JSON, compared to typescript.
-------------- Typescript --------------
[Pros]
- Extremely productive, you're never stuck with a problem
- There is an entire team of professional developers behind this project. beta and RCs are actually more robust than Flow releases, for instance. You can even depend on nightly builds... It's solid.
- Very typesafe (way more than Java for instance), if you know what you're doing.
- The type system is now very, very expressive (version 2.0 and 2.1 helped a lot)
- It's extremely easy to use JS libs in your typescript project
- Performances are good as the generated JS is pretty much just the TS without the types annotations. There is no runtime, shim, etc.
- You still have access to everything JS, so for instance you can use CSS modules with webpack just like if you were using JS. The community is enormous.
[Cons]
- It's still crappy old javascript underneath. Everything is mutable (worse, Array apis mix mutable and immutable styles), if/else are not expressions, the "this" keyword, prototypes, classes are complete madness.
- Not typesafe enough if you are careless. Lots of traps. Unlike Elm, you can actually shoot yourself in the foot by not knowing about certain compiler flags, using <any> too often (I use a no-any tslint rule) or generally not paying attention enough (you need to give hints to the compiler in the right places) It's always going to be less typesafe than Elm though. For instance, functions are bivariant, ewww.
So for me, Elm is interesting conceptually and it has the potential to become good in a few years (perhaps compiling to web assembly) but typescript is the pragmatical choice in the short/medium term, unless you're building something fairly simple, in which case you can use absolutely whatever you want anyway!
So how do TypeScript and Elm compare to OCaml?