4 ms·

> ...it might be a good opportunity to re-evaluate your choice of language. Transpilers for more easily-statically-analyzable languages do exist, after all. I

by paulgb 9y ago

> ...it might be a good opportunity to re-evaluate your choice of language. Transpilers for more easily-statically-analyzable languages do exist, after all. I find TypeScript does a pretty good job of allowing as much static analysis as you want without preventing you from using all the features of JS that break it if you wish. In an ideal world I'd work in a fully static language that transpiles to JS but the reality is it's usually necessary to deal with legacy JS libraries. I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that!

zbentley 9y ago
With regards to static-analysis capability as an aid to developer productivity, I agree with you: find the compromise that best suits your preference. With regards to static-analysis capability as a means of ensuring code reliability, I don't agree. Some people (I'm not characterizing you here since I am unsure if this is your position) consider static analyzability to be equivalent to a strong type system or various safety guarantees with regards to making code's behavior verifiable and/or predictable. If you subscribe to that belief, having an 'escape hatch' that lets you use features of a platform that violate the analyzability guarantees is a virtual guarantee of trouble. I'm put in mind of Rust's "unsafe" areas (there are many other examples of this phenomenon): not only do people routinely overuse them (out of ignorance or misplaced, incorrect, and unverified assertions of "elegance" or "performance"), but their existence at all compromises the ability to verify even small subparts of the greater program: https://news.ycombinator.com/item?id=15146330 https://news.ycombinator.com/item?id=15146330 Having analyzability/guarantees with an escape hatch is better than having none at all, but a lot of people don't understand the tradeoff there.
- paulgb 9y ago
  That's a good distinction, I agree with you. I hope that some day it's practical write code for browsers that is statically analyzable. I feel like the programming community was quick to give up static typing when CPUs got fast enough that the performance hit was irrelevant (for many uses), and now we are starting to realize that types were a good idea for correctness too.
sjrd 9y ago
> I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that! Scala.js is specifically designed to be very good at this. You might want to give a shot, if you haven't already ;) Usually you would stay within the type-safe Scala code, or even talk to JavaScript libraries in a type-safe way. But it will always let you do anything you could do in JavaScript (it is one of its core language design decisions). If you want to do something especially weird, the syntax to do so might be pretty awkward, but in most cases it will feel very natural.
- paulgb 9y ago
  Thanks, I'll take a look. I do like Scala. Do you recommend a particular editor?
- kbp 9y ago
  In ReasonML, most of your code is just Reason (which is just OCaml), but you can easily provide type declarations and use Javascript code in a typesafe way, or you can just drop to raw JS at any point in a Reason file.

by paulgb 9y ago

zbentley 9y ago

With regards to static-analysis capability as an aid to developer productivity, I agree with you: find the compromise that best suits your preference. With regards to static-analysis capability as a means of ensuring code reliability, I don't agree. Some people (I'm not characterizing you here since I am unsure if this is your position) consider static analyzability to be equivalent to a strong type system or various safety guarantees with regards to making code's behavior verifiable and/or predictable. If you subscribe to that belief, having an 'escape hatch' that lets you use features of a platform that violate the analyzability guarantees is a virtual guarantee of trouble. I'm put in mind of Rust's "unsafe" areas (there are many other examples of this phenomenon): not only do people routinely overuse them (out of ignorance or misplaced, incorrect, and unverified assertions of "elegance" or "performance"), but their existence at all compromises the ability to verify even small subparts of the greater program: https://news.ycombinator.com/item?id=15146330 https://news.ycombinator.com/item?id=15146330 Having analyzability/guarantees with an escape hatch is better than having none at all, but a lot of people don't understand the tradeoff there.

paulgb 9y ago
That's a good distinction, I agree with you. I hope that some day it's practical write code for browsers that is statically analyzable. I feel like the programming community was quick to give up static typing when CPUs got fast enough that the performance hit was irrelevant (for many uses), and now we are starting to realize that types were a good idea for correctness too.

sjrd 9y ago

> I haven't seen a fully static transpiled language deal with that gracefully, but I'd love to be wrong about that! Scala.js is specifically designed to be very good at this. You might want to give a shot, if you haven't already ;) Usually you would stay within the type-safe Scala code, or even talk to JavaScript libraries in a type-safe way. But it will always let you do anything you could do in JavaScript (it is one of its core language design decisions). If you want to do something especially weird, the syntax to do so might be pretty awkward, but in most cases it will feel very natural.

paulgb 9y ago
Thanks, I'll take a look. I do like Scala. Do you recommend a particular editor?
kbp 9y ago
In ReasonML, most of your code is just Reason (which is just OCaml), but you can easily provide type declarations and use Javascript code in a typesafe way, or you can just drop to raw JS at any point in a Reason file.