26 ms·

It's interesting how static type systems are slowly gaining more adoption now by being bolted on to popular dynamic languages. It feels like a weird approach co

It's interesting how static type systems are slowly gaining more adoption now by being bolted on to popular dynamic languages. It feels like a weird approach compared to using a language that was designed from the ground up to have a strong static type system but it's practical in terms of easing people into it.

aero142 9y ago
I think describing these as static type systems is a bit limiting. I prefer to think of them as static code analyzers. They don't change anything about the representations in memory, but they do validate invariants about the code. I actually hope we start seeing systems that validate invariants that are not type based like "SQL Injection Safe SQL Query" and "Range between 10-100".
- dragonwriter 9y ago
  > I actually hope we start seeing systems that validate invariants that are not type based like "SQL Injection Safe SQL Query" and "Range between 10-100". Both of those can be types in a rich enough type system; the latter is a fairly common example for dependent types, for instance.
- hellofunk 9y ago
  Agreed, it's like saying C++ has a borrow checker like Rust because memory sanitization tools exist.
kbd 9y ago
FWIW, static languages have added dynamic typing features as well: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
- jerf 9y ago
  But I suspect whereas the static type additions to Python will tend to spread throughout your entire system (the more you annotate, the more useful the feature is), the dynamic features of static languages tend to be used in specific places for specific reasons (the less you use the feature and the more you encapsulate it so the dynamism doesn't "escape", the better it works with the program as a whole).
  - cakes 8y ago
    This was pretty much true when I was last using C#. You would find specific places where you need "an object" (e.g. maybe you want to LINQ over some data in a method) so you could dynamically create it but if you wanted that object to go anywhere outside of scope you had to have a concrete definition.
- llccbb 9y ago
  Had a similar thought, but around C++. auto types and lambda functions are the ones that come to my mind. I am sure there are more features making their way into modern C++ versions.
  - symlinkk 9y ago
    Those are completely different concepts. You're confusing dynamic typing with type inference. Dynamic typing: C# "dynamic" keyword Type inference: C# "var" keyword, C++ "auto" keyword
  - looki 9y ago
    auto types really don't have anything to do with dynamic typing, in fact I would argue type deduction is an important tool in making static typing more attractive. An example of dynamic typing in C++ would be std::any (although you're still limited by what you can do with the contained object of course, for better or worse).
floatrock 9y ago
It's about having the right tool for the job. Type checking is all about complexity management... you don't need it if you're hacking on a weekend project, but when you have hundreds of developers on a million-line codebase, it can save you tons of time. Dynamic languages have their advantages too (productivity, REPL's, etc.) Why NOT combine the two features? Just because it's not built into the core of the language doesn't mean you can't benefit from the complexity management aspect if your job is to manage the code complexity in a large developer workforce.
- bennofs 9y ago
  Many of the "dynamically typed language" features can be had in statically typed languages as well: there are statically typed languages that have REPls for example. Your point about having higher productivity in the beginning and then retrofitting types after that still stands though.
- wvenable 9y ago
  > Type checking is all about complexity management... you don't need it if you're hacking on a weekend project I see this argument a lot but I don't buy it. You might not need Java's SimpleBeanFactoryAwareAspectInstanceFactory but I don't believe putting in types hinders quick prototype development; I think, in general, it helps it. Especially when combined with good tooling and a good IDE.
  - woolvalley 9y ago
    I code in mostly static languages, and even when I'm doing 1000 line python projects I miss types. It especially helps in refactoring things quickly without needing a special IDE environment. It also lets me skip an entire class of unit tests that boil down into type checking.
  - zeth___ 9y ago
    >Especially when combined with good tooling and a good IDE. Quite a few people, myself included, don't use IDEs.
- 9y ago
IshKebab 9y ago
It's because dynamic typing is easier for small programs and beginners, but sometimes the language becomes popular (e.g. Python or JavaScript) and people start trying to write large robust programs in it. Then you need static typing. I initially thought optional / gradual typing (a la Dart 1) was mad but when you think about it in this context it makes sense. However now Dart 2 has gone back to static typing so who knows...
- sametmax 9y ago
  Define large. I've built video streaming websites with a users account, uploads, votes, comments, many filters and hundred of thousand files, holding half a million user a day in Python. The server cost is around a fifth of the generated revenues. Most projects will never even reach this size, not to mention remotely approaching google size (from 2010).
  - IshKebab 8y ago
    Large as in lines of code and number of authors. Not how many people it serves - why would that matter? Something like 10k lines of code or three authors seems to be about the limit where dynamic typing becomes really painful.
acdha 9y ago
Programming languages are too complicated to distill down to one feature; it won’t make sense if you look in isolation. Python became popular after strong typing was known but before academic research into more advanced systems had entered the mainstream. For many programmers, that experience meant slow compilers, unhelpful error messages requiring ugly syntax to fix, recreating a lot of practical things which were built in to Python, etc. We don’t know how many of them would have preferred something with e.g. Rust-level tooling and capabilities if that had been available.
- pjmlp 9y ago
  I learned Caml Light and SML in 1996. Our university had quite a few courses where ML was the goto language for project assignments. In those days Python was hardly used, still trying to get adoption. By 2000 most Python projects were all about Zope, which I was surprised to find out it is still around.
  - acdha 9y ago
    I think there’d be an interesting study about why that happened, and why languages like Perl peaked and declined so quickly. Anecdotally, I noticed a lot of people who missed some feature from Lisp, C, etc. but generally decided that Python made everything else enough easier that they didn’t mind very much. There’s probably an interesting discussion of language usability in that.
    - crdoconnor 9y ago
      I think it was one of the first (possibly the first) to introduce serious package management and that had a lot to do with its sudden popularity. Suddenly developers could build upon each other's work really easily. That was definitely the jesustech of its day. Perl's weak type system and cryptic syntactic muck probably had a lot to do with its decline.
      - acdha 8y ago
        One of Perl 5’s big flaws was not having an object system in the language. Different people wrote different modules on CPAN, which was deservedly popular in those days, but it often meant you’d have to kludge interfaces between multiple third party systems and other things people hacked together. That and the syntax were why I added Perl to my bash policy that any program big enough to require scrolling would be ported to Python. Usually the richer standard library also meant that the new version ended up considerably smaller, too.
sametmax 9y ago
It's because you believe the pros of type checking always surpass the cons. But the Python user base is very diverse, with a huge difference in tastes, skills, goals, time and constraints. That's why you can code in imperative, OO or functional and not just one paradigm. That's why you can choose between threads, processes and asyncio, or callbacks vs await. And of course, declaring your types or not. This allows Python to be suitable for geography, data analysis, scripting, web dev, sysadmin, machine learning, UI, pentesting, etc. Python is never the best language at anything. But it's a damn good language at most things. It's an invaluable powerful versatile toolbox because it gives you the margin to adopt the style that fits your problem instead of forcing one on you. It also has the benefit of not getting out of fashion precisely because of that.
- ksec 9y ago
  >Python is never the best language at anything. But it's a damn good language at most things. It's an invaluable powerful versatile toolbox because it gives you the margin to adopt the style that fits your problem instead of forcing one on you. I think this so much. What the best programming languages for me isn't necessarily the best at anything, and shouldn't be at all. But it should be 80% of everything the best. And that in itself is possibly even harder to achieve. I really wish Ruby was the case here. But clearly Python is taking this title.
  - msie 9y ago
    If only Ruby had as strong an ecosystem as Python. But right now it's Rails 95% of the time and the documentation sucks most of the time.
    - goatlover 9y ago
      I hate that Rails came to dominate the Ruby language in most people's minds. It's such a nice dynamic language on it's own that you can use anywhere you use Python (if the libraries exist for it). And there were minimal frameworks like Sinatra when everyone was running to Node to use Express because of Rails, ignoring that Rails wasn't the only Ruby game in town.
ericmoritz 9y ago
Java's verbosity made us all hate type systems in the early 2000s so many of us migrated to dynamic languages such as Python, Ruby in the mid 2000s that allowed us to work fast and loose and get things done. After about 10 years of coding in a fit of passion we ended up with huge monolithic projects written in dynamic languages that where extremely brittle. Fortunately languages with type inference (Rust, Golang, OCaml, Scala, etc) started becoming the answer to our problems. (We also collectively decided that Microservivces were another solution to our woes though that cargo cult is being questioned). So we have a decade of code and packages written in Python and JavaScript that work well for our use cases (Data Science, MVP web apps/services, Database integration, etc) that is hard to give up. Often because alternatives aren't available yet in the statically typed languages (Hurry up Rust!). There is often a lot of friction to get new languages introduced. I love Rust, but I don't think I can introduce it into our Golang/NodeJS/Javascript environment anytime soon.
- notheguyouthink 9y ago
  > I love Rust, but I don't think I can introduce it into our Golang/NodeJS/Javascript environment anytime soon. Rings especially true for my shop as well. I had to introduce Rust or Go, and went with Go. Seeing the mild pushback I get from Go's type system makes me especially glad I didn't choose Rust. ... though, in some cases, Rust+Generics would be easier than Go.
  - masklinn 9y ago
    > Rings especially true for my shop as well. I had to introduce Rust or Go, and went with Go. Seeing the mild pushback I get from Go's type system makes me especially glad I didn't choose Rust. An other possibilities is that Go's static types feel like a lot of ceremony for too little benefit. That was one of my biggest issues with Java, and though Go's lighter it also provides less benefits… By contrast, Rust is in the camp of requiring a higher amount of ceremony but providing a lot of benefits from it (sometimes quipped as "if it compiles it works").
    - skybrian 9y ago
yason 9y ago
That's often a good direction. When developing, you don't necessarily know about your types yet. And you might not even want to think about them. It's easier to shove in assumptions because things will change as you begin to understand what you want to build as you spend time writing the software. It's not until later when the code has partially stabilised that you can start spotting what data structures are robust enough to be close to final and actually do benefit from being blessed by typing, locking down the inputs and outputs. Traditionally, in a dynamically and/or weakly typed language, when the program grows large enough those parts could have been rewritten in a statically and strongly typed language. But if the dynamic language also offers some, even just basic tools for static typing then it all becomes much easier.
- grumpyprole 9y ago
  > When developing, you don't necessarily know about your types yet. This is absolutely not true for myself and my coworkers. We think in types first. Typically we write out high-level functions with type signatures and make sure they all fit together and everything type-checks. Then, we'll fill in the detail and actually implement the functions. Often this process is recursive and we need to repeat it until we get small functions that are either easy to implement or available in a library. We have a type-based search tool to facilitate finding such library functions. Sometimes there are problems and alternative abstractions that only come to light when filling in the details. When a large re-organisation of code is necessary, types again help to get this right. Personally, I could never build a non-trivial piece of software in a dynamic language. Perhaps I just don't have the brain power to track the types manually in my head.
  - halbritt 9y ago
    That's kind of the thing, though: Folks are using python to bang out trivial pieces of software all the time. Dynamic types are great for that. Occasionally, those trivial pieces of software become non-trivial, in which case, having the ability to refactor with type hints is a good thing vs. a complete rewrite in a strongly typed language.
dnautics 9y ago
I'm not sure the static type system thing is real. Ultimately for 90% of workflows you wind up reserializing into a very much not-static-datatype (JSON, e.g.)
- always_good 9y ago
  I don't see how that matters -- it seems to indicate a misunderstanding of what type systems are. Type systems obviously have boundaries whether you're interchanging with another type-safe system or not, that's irrelevant. Every program has to deserialize data like JSON into types and enforce its assumptions about that data whether you have static analysis tooling at compile-time or not.
  - dnautics 9y ago
    It absolutely matters, type systems don't exist in a pure universe, they are important because we use them to interact with human needs. A good type system pushes out typing concerns to the outer boundary of of the system. For that you don't need static typing, you need strong typing. Refactoring in a statically typed system can be an incredibly tedious process with tons of boilerplate. At the other extreme if you allow duck typing and monkeypatching then you wind up with a problem where debugging becomes a problem. There's a middle ground that a lot of very good and productive programming languages occupy.
    - coldtea 9y ago
      >A good type system pushes out typing concerns to the outer boundary of of the system. No, that would be a BAD type system. A good type system puts type concerns to the very core of the language and program, where they belong. A program is a proof, and types are elements (like axioms) in this proof.
      - dnautics 9y ago
        By 'type concerns' i mean coercing the real world into the type system. You want that to be at the edge. IMO, treating a program as a proof is somewhat impracticable as you see with very pure functional programming paradigms struggle with universal state monads.
zeth___ 9y ago
It doubly interesting since python does not have types. It has builtin classes, unlike every other popular language out there.
zem 9y ago
[stanza](http://lbstanza.org/ http://lbstanza.org/) is one of the more interesting recent languages i've seen - it is designed from the ground up to be gradually typed, which is the end goal of projects like pyre.
- elbear 8y ago
  This looks at first sight like a cross between Python and LISP without parentheses (not saying that in a bad way). I'm actually glad that they choose this syntax, because a lot of people get hung up on the parentheses. Have you used this for anything? If so, how was the experience?
  - zem 8y ago
    no, just wrote a couple of toy programs. but it's on my short list of languages i keep an eye on because it looks like they hit a sweet spot in language design, implementation and ergonomics, and they might be exactly what i need for some future project. (d and pony are a couple of others in that camp)
wpietri 9y ago
For me this not only matches ease of onboarding new users, but also what experts like over the lifespan of a project. So often I start out just by banging on something. My domain model isn't well defined, I'm very tolerant of errors, and I really value quick exploration and a fast iteration cycle. If a project starts to mature, though, I start wanting more things that aid long-term maintainability. More type checking. More controlled error handling. More constraints on what code is ok. Maybe a good example is checked exceptions. Everybody hated those in Java, because it imposed a discipline that's only really valuable in certain situations. In contrast, something like Ruby or Python lets you have a single high-level error handler to start, and gradually tighten things up. Java's type system similarly pushed a lot of people away, because it made them pay up-front costs for down-the-road benefits they might never need. Hopefully this will be a similar thing, where projects big enough to benefit from type discipline will add it as they go.
1024core 9y ago
And, ironically, static typed languages like C++ are moving to more "dynamic" (actually, inferred) type systems via 'auto'
- leshow 8y ago
  Inferred is very different from dynamic.
talltimtom 8y ago
Strict static typing incours a cost at development time whether you need it or not. Being able to develop quickly with dynamic typing and then add static typing checks afterwards is just such a huge productivity boost really exposing the best of both worlds.

aero142 9y ago

I think describing these as static type systems is a bit limiting. I prefer to think of them as static code analyzers. They don't change anything about the representations in memory, but they do validate invariants about the code. I actually hope we start seeing systems that validate invariants that are not type based like "SQL Injection Safe SQL Query" and "Range between 10-100".

dragonwriter 9y ago
> I actually hope we start seeing systems that validate invariants that are not type based like "SQL Injection Safe SQL Query" and "Range between 10-100". Both of those can be types in a rich enough type system; the latter is a fairly common example for dependent types, for instance.
hellofunk 9y ago
Agreed, it's like saying C++ has a borrow checker like Rust because memory sanitization tools exist.

kbd 9y ago

FWIW, static languages have added dynamic typing features as well: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

jerf 9y ago
But I suspect whereas the static type additions to Python will tend to spread throughout your entire system (the more you annotate, the more useful the feature is), the dynamic features of static languages tend to be used in specific places for specific reasons (the less you use the feature and the more you encapsulate it so the dynamism doesn't "escape", the better it works with the program as a whole).
- cakes 8y ago
  This was pretty much true when I was last using C#. You would find specific places where you need "an object" (e.g. maybe you want to LINQ over some data in a method) so you could dynamically create it but if you wanted that object to go anywhere outside of scope you had to have a concrete definition.
llccbb 9y ago
Had a similar thought, but around C++. auto types and lambda functions are the ones that come to my mind. I am sure there are more features making their way into modern C++ versions.
- symlinkk 9y ago
  Those are completely different concepts. You're confusing dynamic typing with type inference. Dynamic typing: C# "dynamic" keyword Type inference: C# "var" keyword, C++ "auto" keyword
- looki 9y ago
  auto types really don't have anything to do with dynamic typing, in fact I would argue type deduction is an important tool in making static typing more attractive. An example of dynamic typing in C++ would be std::any (although you're still limited by what you can do with the contained object of course, for better or worse).

floatrock 9y ago

It's about having the right tool for the job. Type checking is all about complexity management... you don't need it if you're hacking on a weekend project, but when you have hundreds of developers on a million-line codebase, it can save you tons of time. Dynamic languages have their advantages too (productivity, REPL's, etc.) Why NOT combine the two features? Just because it's not built into the core of the language doesn't mean you can't benefit from the complexity management aspect if your job is to manage the code complexity in a large developer workforce.

bennofs 9y ago
Many of the "dynamically typed language" features can be had in statically typed languages as well: there are statically typed languages that have REPls for example. Your point about having higher productivity in the beginning and then retrofitting types after that still stands though.
wvenable 9y ago
> Type checking is all about complexity management... you don't need it if you're hacking on a weekend project I see this argument a lot but I don't buy it. You might not need Java's SimpleBeanFactoryAwareAspectInstanceFactory but I don't believe putting in types hinders quick prototype development; I think, in general, it helps it. Especially when combined with good tooling and a good IDE.
- woolvalley 9y ago
  I code in mostly static languages, and even when I'm doing 1000 line python projects I miss types. It especially helps in refactoring things quickly without needing a special IDE environment. It also lets me skip an entire class of unit tests that boil down into type checking.
- zeth___ 9y ago
  >Especially when combined with good tooling and a good IDE. Quite a few people, myself included, don't use IDEs.
9y ago

IshKebab 9y ago

It's because dynamic typing is easier for small programs and beginners, but sometimes the language becomes popular (e.g. Python or JavaScript) and people start trying to write large robust programs in it. Then you need static typing. I initially thought optional / gradual typing (a la Dart 1) was mad but when you think about it in this context it makes sense. However now Dart 2 has gone back to static typing so who knows...

sametmax 9y ago
Define large. I've built video streaming websites with a users account, uploads, votes, comments, many filters and hundred of thousand files, holding half a million user a day in Python. The server cost is around a fifth of the generated revenues. Most projects will never even reach this size, not to mention remotely approaching google size (from 2010).
- IshKebab 8y ago
  Large as in lines of code and number of authors. Not how many people it serves - why would that matter? Something like 10k lines of code or three authors seems to be about the limit where dynamic typing becomes really painful.

acdha 9y ago

Programming languages are too complicated to distill down to one feature; it won’t make sense if you look in isolation. Python became popular after strong typing was known but before academic research into more advanced systems had entered the mainstream. For many programmers, that experience meant slow compilers, unhelpful error messages requiring ugly syntax to fix, recreating a lot of practical things which were built in to Python, etc. We don’t know how many of them would have preferred something with e.g. Rust-level tooling and capabilities if that had been available.

pjmlp 9y ago
I learned Caml Light and SML in 1996. Our university had quite a few courses where ML was the goto language for project assignments. In those days Python was hardly used, still trying to get adoption. By 2000 most Python projects were all about Zope, which I was surprised to find out it is still around.
- acdha 9y ago
  I think there’d be an interesting study about why that happened, and why languages like Perl peaked and declined so quickly. Anecdotally, I noticed a lot of people who missed some feature from Lisp, C, etc. but generally decided that Python made everything else enough easier that they didn’t mind very much. There’s probably an interesting discussion of language usability in that.
  - crdoconnor 9y ago
    I think it was one of the first (possibly the first) to introduce serious package management and that had a lot to do with its sudden popularity. Suddenly developers could build upon each other's work really easily. That was definitely the jesustech of its day. Perl's weak type system and cryptic syntactic muck probably had a lot to do with its decline.
    - acdha 8y ago
      One of Perl 5’s big flaws was not having an object system in the language. Different people wrote different modules on CPAN, which was deservedly popular in those days, but it often meant you’d have to kludge interfaces between multiple third party systems and other things people hacked together. That and the syntax were why I added Perl to my bash policy that any program big enough to require scrolling would be ported to Python. Usually the richer standard library also meant that the new version ended up considerably smaller, too.

sametmax 9y ago

It's because you believe the pros of type checking always surpass the cons. But the Python user base is very diverse, with a huge difference in tastes, skills, goals, time and constraints. That's why you can code in imperative, OO or functional and not just one paradigm. That's why you can choose between threads, processes and asyncio, or callbacks vs await. And of course, declaring your types or not. This allows Python to be suitable for geography, data analysis, scripting, web dev, sysadmin, machine learning, UI, pentesting, etc. Python is never the best language at anything. But it's a damn good language at most things. It's an invaluable powerful versatile toolbox because it gives you the margin to adopt the style that fits your problem instead of forcing one on you. It also has the benefit of not getting out of fashion precisely because of that.

ksec 9y ago
>Python is never the best language at anything. But it's a damn good language at most things. It's an invaluable powerful versatile toolbox because it gives you the margin to adopt the style that fits your problem instead of forcing one on you. I think this so much. What the best programming languages for me isn't necessarily the best at anything, and shouldn't be at all. But it should be 80% of everything the best. And that in itself is possibly even harder to achieve. I really wish Ruby was the case here. But clearly Python is taking this title.
- msie 9y ago
  If only Ruby had as strong an ecosystem as Python. But right now it's Rails 95% of the time and the documentation sucks most of the time.
  - goatlover 9y ago
    I hate that Rails came to dominate the Ruby language in most people's minds. It's such a nice dynamic language on it's own that you can use anywhere you use Python (if the libraries exist for it). And there were minimal frameworks like Sinatra when everyone was running to Node to use Express because of Rails, ignoring that Rails wasn't the only Ruby game in town.

ericmoritz 9y ago

Java's verbosity made us all hate type systems in the early 2000s so many of us migrated to dynamic languages such as Python, Ruby in the mid 2000s that allowed us to work fast and loose and get things done. After about 10 years of coding in a fit of passion we ended up with huge monolithic projects written in dynamic languages that where extremely brittle. Fortunately languages with type inference (Rust, Golang, OCaml, Scala, etc) started becoming the answer to our problems. (We also collectively decided that Microservivces were another solution to our woes though that cargo cult is being questioned). So we have a decade of code and packages written in Python and JavaScript that work well for our use cases (Data Science, MVP web apps/services, Database integration, etc) that is hard to give up. Often because alternatives aren't available yet in the statically typed languages (Hurry up Rust!). There is often a lot of friction to get new languages introduced. I love Rust, but I don't think I can introduce it into our Golang/NodeJS/Javascript environment anytime soon.

notheguyouthink 9y ago
> I love Rust, but I don't think I can introduce it into our Golang/NodeJS/Javascript environment anytime soon. Rings especially true for my shop as well. I had to introduce Rust or Go, and went with Go. Seeing the mild pushback I get from Go's type system makes me especially glad I didn't choose Rust. ... though, in some cases, Rust+Generics would be easier than Go.
- masklinn 9y ago
  > Rings especially true for my shop as well. I had to introduce Rust or Go, and went with Go. Seeing the mild pushback I get from Go's type system makes me especially glad I didn't choose Rust. An other possibilities is that Go's static types feel like a lot of ceremony for too little benefit. That was one of my biggest issues with Java, and though Go's lighter it also provides less benefits… By contrast, Rust is in the camp of requiring a higher amount of ceremony but providing a lot of benefits from it (sometimes quipped as "if it compiles it works").
  - skybrian 9y ago

yason 9y ago

That's often a good direction. When developing, you don't necessarily know about your types yet. And you might not even want to think about them. It's easier to shove in assumptions because things will change as you begin to understand what you want to build as you spend time writing the software. It's not until later when the code has partially stabilised that you can start spotting what data structures are robust enough to be close to final and actually do benefit from being blessed by typing, locking down the inputs and outputs. Traditionally, in a dynamically and/or weakly typed language, when the program grows large enough those parts could have been rewritten in a statically and strongly typed language. But if the dynamic language also offers some, even just basic tools for static typing then it all becomes much easier.

grumpyprole 9y ago
> When developing, you don't necessarily know about your types yet. This is absolutely not true for myself and my coworkers. We think in types first. Typically we write out high-level functions with type signatures and make sure they all fit together and everything type-checks. Then, we'll fill in the detail and actually implement the functions. Often this process is recursive and we need to repeat it until we get small functions that are either easy to implement or available in a library. We have a type-based search tool to facilitate finding such library functions. Sometimes there are problems and alternative abstractions that only come to light when filling in the details. When a large re-organisation of code is necessary, types again help to get this right. Personally, I could never build a non-trivial piece of software in a dynamic language. Perhaps I just don't have the brain power to track the types manually in my head.
- halbritt 9y ago
  That's kind of the thing, though: Folks are using python to bang out trivial pieces of software all the time. Dynamic types are great for that. Occasionally, those trivial pieces of software become non-trivial, in which case, having the ability to refactor with type hints is a good thing vs. a complete rewrite in a strongly typed language.

dnautics 9y ago

I'm not sure the static type system thing is real. Ultimately for 90% of workflows you wind up reserializing into a very much not-static-datatype (JSON, e.g.)

always_good 9y ago
I don't see how that matters -- it seems to indicate a misunderstanding of what type systems are. Type systems obviously have boundaries whether you're interchanging with another type-safe system or not, that's irrelevant. Every program has to deserialize data like JSON into types and enforce its assumptions about that data whether you have static analysis tooling at compile-time or not.
- dnautics 9y ago
  It absolutely matters, type systems don't exist in a pure universe, they are important because we use them to interact with human needs. A good type system pushes out typing concerns to the outer boundary of of the system. For that you don't need static typing, you need strong typing. Refactoring in a statically typed system can be an incredibly tedious process with tons of boilerplate. At the other extreme if you allow duck typing and monkeypatching then you wind up with a problem where debugging becomes a problem. There's a middle ground that a lot of very good and productive programming languages occupy.
  - coldtea 9y ago
    >A good type system pushes out typing concerns to the outer boundary of of the system. No, that would be a BAD type system. A good type system puts type concerns to the very core of the language and program, where they belong. A program is a proof, and types are elements (like axioms) in this proof.
    - dnautics 9y ago
      By 'type concerns' i mean coercing the real world into the type system. You want that to be at the edge. IMO, treating a program as a proof is somewhat impracticable as you see with very pure functional programming paradigms struggle with universal state monads.

zeth___ 9y ago

It doubly interesting since python does not have types. It has builtin classes, unlike every other popular language out there.

zem 9y ago

[stanza](http://lbstanza.org/ http://lbstanza.org/) is one of the more interesting recent languages i've seen - it is designed from the ground up to be gradually typed, which is the end goal of projects like pyre.

elbear 8y ago
This looks at first sight like a cross between Python and LISP without parentheses (not saying that in a bad way). I'm actually glad that they choose this syntax, because a lot of people get hung up on the parentheses. Have you used this for anything? If so, how was the experience?
- zem 8y ago
  no, just wrote a couple of toy programs. but it's on my short list of languages i keep an eye on because it looks like they hit a sweet spot in language design, implementation and ergonomics, and they might be exactly what i need for some future project. (d and pony are a couple of others in that camp)

wpietri 9y ago

For me this not only matches ease of onboarding new users, but also what experts like over the lifespan of a project. So often I start out just by banging on something. My domain model isn't well defined, I'm very tolerant of errors, and I really value quick exploration and a fast iteration cycle. If a project starts to mature, though, I start wanting more things that aid long-term maintainability. More type checking. More controlled error handling. More constraints on what code is ok. Maybe a good example is checked exceptions. Everybody hated those in Java, because it imposed a discipline that's only really valuable in certain situations. In contrast, something like Ruby or Python lets you have a single high-level error handler to start, and gradually tighten things up. Java's type system similarly pushed a lot of people away, because it made them pay up-front costs for down-the-road benefits they might never need. Hopefully this will be a similar thing, where projects big enough to benefit from type discipline will add it as they go.

1024core 9y ago

And, ironically, static typed languages like C++ are moving to more "dynamic" (actually, inferred) type systems via 'auto'

leshow 8y ago
Inferred is very different from dynamic.

talltimtom 8y ago

Strict static typing incours a cost at development time whether you need it or not. Being able to develop quickly with dynamic typing and then add static typing checks afterwards is just such a huge productivity boost really exposing the best of both worlds.