6 ms·

It's interesting to observe how almost all mainstream dynamic languages move from "who needs types? types are very very bad and just get in the way!" to some so

by pka 10y ago

It's interesting to observe how almost all mainstream dynamic languages move from "who needs types? types are very very bad and just get in the way!" to some sort of gradual typing or runtime type validation. * Javascript has Flow/TypeScript * Python has PEP 484 * Perl6 has some sort of types * Clojure/Script has core.typed, schema and now clojure.spec * Don't know about Ruby, but I've seen articles on type checking/annotations * Erland has Dialyzer (although this is not a recent development)

dominotw 10y ago
> Javascript has Flow/TypeScript This is not an example of language moving to gradual typing. Typescript is an entirely new language.
protomyth 10y ago
I have a bit of a theory on that, which I bet will be a bit unpopular but is based on some social things I have seen. A dynamic language gets popular[1]. As more people show up, they want to bring their way of doing things (e.g. "prototypes are stupid, we need classes") instead of fully adopting the language. Improvements are cool but some of the changes alter things in a fundamental way (e.g. dynamic to static). Sometimes it leads to second systems (e.g. Objective-C to Swift) and is often accompanied by "the need to grow up". Then we get a new language. 1) could actually be any language that doesn't fit the mainstream mold
- slowmovintarget 10y ago
  Which is why what Rich Hickey did with clojure.spec is so important... He acknowledged the deficiency, but worked through it to understand what the problem actually is. Then he created a solution that solves the real problem, in a way that avoids diminishing the character of the language. Have a read through the rationale on the design of clojure.spec to see what I mean. http://clojure.org/about/spec http://clojure.org/about/spec
agumonkey 10y ago
They're also converging on other features: - lexical closures - common set of base types (lists; dicts; sets) - literals for said types - immutability - generators - asynchrony Also from rust and golang, built-in "project lifecycle" with sane fs template, dependencies, build, deploy, test...
nemoniac 10y ago
Common Lisp has (always had) a rich type system. You hardly pay any attention to it at all when you're prototyping but once your code has taken shape you can start adding type annotations and then it can really fly. So yes, types do get in the way while prototyping but it's great to have them available when refining code.
- catnaroek 10y ago
  Are Common Lisp's type annotations for consistency checking or just to improve performance? Haskell and ML have types, Pascal and C also have types, but they serve very different purposes. And types can also help you prototype and then polish rough ideas. For example, I'm exploring a programming style where no unreachable code paths are allowed: in a circumstance where you'd throw an exception or return an error sentinel, I'd refactor the code to eliminate the unreachable branch. This means that abstractions must have the “right shape” (that is, not leak), and types are fundamental to make this work.
  - nemoniac 10y ago
    Both. When I start adding type annotations, I'm usually aiming for a speed-up but more often it leads to reorganization and rationalization of the code. The code becomes more streamlined and beautiful. The post below resonates with me. He calls it 'programming by teaching', where you gradually shape a program to solve your problem. I think of it as 'programming by learning', where the Lisp way of developing helps me learn about my problem. It's only when you have the final version of your code that you fully understand the problem by seeing its solution in front of you. https://news.ycombinator.com/item?id=11834887 https://news.ycombinator.com/item?id=11834887
    - catnaroek 10y ago
      What I do can also be called “programming by learning”, but it has a fundamentally different flavor than what Lispers do. I present my ideas to the Poly/ML REPL as a hopefully coherent argument, and it tells me whether, at the very least, the argument is internally consistent. ML doesn't “know” about my specific problem domain, but it does know logic, and it's very good at nit-picking, which makes up for my human inability to exhaustively pay attention to an ever-growing number of tricky details. Furthermore, ML has all of nominal, structural and abstract types, which lets me “steer the reasoning” in the desired direction: (0) Nominal types correspond to primitive domain entities. (1) Structural types correspond to compound entities, built from simpler ones. (2) Abstract types regulate the interaction between different subdomains of a larger domain. The net result is that the REPL's feedback helps me identify those parts of the problem domain where my understanding is weak. Not only the REPL's feedback, of course. For instance, if my program contains unreachable code paths, it means that I haven't yet found the right abstractions. The philosophy behind this methodology is that: (0) The cost of having a wrong program is actually larger than that of having no program, because it takes too much effort to identify the wrong parts so that one can fix them. (1) When the size a program exceeds a certain threshold, it becomes impossible for ordinary human reasoning to determine with full certainty that a program contains no errors. Only formal logic can help, and only machines can do formal logic at a large scale. (2) It isn't practical to tackle large problems without a properly enforced separation of concerns. --- By the way, ironically, I never make an explicit type annotation, except perhaps, perhaaaps, at module boundaries. Figuring out the boring details of how to connect the pieces of a puzzle is a job for computers (type inference), not humans.
deleted 10y ago
[deleted]
k__ 10y ago
I'm drinking the TypeScript Kool Aid right now and I'm still not convinced. Ill give it a chance, since I'm still early in the project. The good: it uses a structural type system. For someone who got the good old 'JavaScript is a toy language you should try Java or C#' at university, this feels really refreshing. It mostly works as JS and you get some nice auto complete. So it feels dynamic and not clunky, like the aforementioned 2 'true' languages. The bad: the tools seem to work random. Sometimes they pick up the definitions, next time you open a file, 'cannot find module 'react'' or numbers in import paths break the auto complete etc. also often you don't find type definitions for you libs and as a type-n00b you often lack the skills to create good ones yourself. Anyway, I hope with TS 2.0 things will get better. Especially with strict null checks, which hopefully will be a giant win.
cle 10y ago
As a language grows in popularity, so does its use cases. There are use cases where static typing adds a lot of value, and use cases where it detracts value. In my opinion, a general purpose language will (and should!) try to cover both use cases. You see the inverse evolution with static languages--a hard-lined static language evolving more dynamic features--for example Java and its dynamic counterparts (Spring, AspectJ, annotations, etc.).

by pka 10y ago

dominotw 10y ago

> Javascript has Flow/TypeScript This is not an example of language moving to gradual typing. Typescript is an entirely new language.

protomyth 10y ago

I have a bit of a theory on that, which I bet will be a bit unpopular but is based on some social things I have seen. A dynamic language gets popular[1]. As more people show up, they want to bring their way of doing things (e.g. "prototypes are stupid, we need classes") instead of fully adopting the language. Improvements are cool but some of the changes alter things in a fundamental way (e.g. dynamic to static). Sometimes it leads to second systems (e.g. Objective-C to Swift) and is often accompanied by "the need to grow up". Then we get a new language. 1) could actually be any language that doesn't fit the mainstream mold

slowmovintarget 10y ago
Which is why what Rich Hickey did with clojure.spec is so important... He acknowledged the deficiency, but worked through it to understand what the problem actually is. Then he created a solution that solves the real problem, in a way that avoids diminishing the character of the language. Have a read through the rationale on the design of clojure.spec to see what I mean. http://clojure.org/about/spec http://clojure.org/about/spec

agumonkey 10y ago

They're also converging on other features: - lexical closures - common set of base types (lists; dicts; sets) - literals for said types - immutability - generators - asynchrony Also from rust and golang, built-in "project lifecycle" with sane fs template, dependencies, build, deploy, test...

nemoniac 10y ago

Common Lisp has (always had) a rich type system. You hardly pay any attention to it at all when you're prototyping but once your code has taken shape you can start adding type annotations and then it can really fly. So yes, types do get in the way while prototyping but it's great to have them available when refining code.

catnaroek 10y ago
Are Common Lisp's type annotations for consistency checking or just to improve performance? Haskell and ML have types, Pascal and C also have types, but they serve very different purposes. And types can also help you prototype and then polish rough ideas. For example, I'm exploring a programming style where no unreachable code paths are allowed: in a circumstance where you'd throw an exception or return an error sentinel, I'd refactor the code to eliminate the unreachable branch. This means that abstractions must have the “right shape” (that is, not leak), and types are fundamental to make this work.
- nemoniac 10y ago
  Both. When I start adding type annotations, I'm usually aiming for a speed-up but more often it leads to reorganization and rationalization of the code. The code becomes more streamlined and beautiful. The post below resonates with me. He calls it 'programming by teaching', where you gradually shape a program to solve your problem. I think of it as 'programming by learning', where the Lisp way of developing helps me learn about my problem. It's only when you have the final version of your code that you fully understand the problem by seeing its solution in front of you. https://news.ycombinator.com/item?id=11834887 https://news.ycombinator.com/item?id=11834887
  - catnaroek 10y ago
    What I do can also be called “programming by learning”, but it has a fundamentally different flavor than what Lispers do. I present my ideas to the Poly/ML REPL as a hopefully coherent argument, and it tells me whether, at the very least, the argument is internally consistent. ML doesn't “know” about my specific problem domain, but it does know logic, and it's very good at nit-picking, which makes up for my human inability to exhaustively pay attention to an ever-growing number of tricky details. Furthermore, ML has all of nominal, structural and abstract types, which lets me “steer the reasoning” in the desired direction: (0) Nominal types correspond to primitive domain entities. (1) Structural types correspond to compound entities, built from simpler ones. (2) Abstract types regulate the interaction between different subdomains of a larger domain. The net result is that the REPL's feedback helps me identify those parts of the problem domain where my understanding is weak. Not only the REPL's feedback, of course. For instance, if my program contains unreachable code paths, it means that I haven't yet found the right abstractions. The philosophy behind this methodology is that: (0) The cost of having a wrong program is actually larger than that of having no program, because it takes too much effort to identify the wrong parts so that one can fix them. (1) When the size a program exceeds a certain threshold, it becomes impossible for ordinary human reasoning to determine with full certainty that a program contains no errors. Only formal logic can help, and only machines can do formal logic at a large scale. (2) It isn't practical to tackle large problems without a properly enforced separation of concerns. --- By the way, ironically, I never make an explicit type annotation, except perhaps, perhaaaps, at module boundaries. Figuring out the boring details of how to connect the pieces of a puzzle is a job for computers (type inference), not humans.

deleted 10y ago

[deleted]

k__ 10y ago

I'm drinking the TypeScript Kool Aid right now and I'm still not convinced. Ill give it a chance, since I'm still early in the project. The good: it uses a structural type system. For someone who got the good old 'JavaScript is a toy language you should try Java or C#' at university, this feels really refreshing. It mostly works as JS and you get some nice auto complete. So it feels dynamic and not clunky, like the aforementioned 2 'true' languages. The bad: the tools seem to work random. Sometimes they pick up the definitions, next time you open a file, 'cannot find module 'react'' or numbers in import paths break the auto complete etc. also often you don't find type definitions for you libs and as a type-n00b you often lack the skills to create good ones yourself. Anyway, I hope with TS 2.0 things will get better. Especially with strict null checks, which hopefully will be a giant win.

cle 10y ago

As a language grows in popularity, so does its use cases. There are use cases where static typing adds a lot of value, and use cases where it detracts value. In my opinion, a general purpose language will (and should!) try to cover both use cases. You see the inverse evolution with static languages--a hard-lined static language evolving more dynamic features--for example Java and its dynamic counterparts (Spring, AspectJ, annotations, etc.).