31–40 of 42 posts
Nit-pick: This post seem to say the dynamic typing and duck typing are the same thing. They're not. Duck-typing means looking up method names runtime by name, and not compile time by interface. Dynamic typing is a much bigger concept.
Reminds me a bit of Julia[1], which allows optional static typing. [1] http://julialang.org/
sub fib (Int $n) returns Void {
my Int ($a, $b) = 0, 1;
while $a I've been thinking about this for a while: the benefit of static typing doesn't really come from being compile-time, it comes from making sure the causes of a certain category of errors must be local to the function where the error's seen. I suspect that a run-time static typing framework, which simply did the equivalent of asserting the type of any variable whenever it was assigned, would provide almost all of the s…
There's an old question: which benefits of static typing are needed - and are they worth it? (to the extent that static typed languages are successful). Performance is obviously important. But if dynamically typed languages were fast enough for most needs, would the bulk of users switch to them? (note: it doesn't matter if static typing is faster still, just that dynamic typing is fast enough.)
Would it follow the long-term trend, of performance being traded for developer productivity? The real question behind this being whether dynamic typing actually increases developer productivity (and if so, for which tasks). Obviously, dynamic typing requires fewer keystrokes, less up-front design, and is more flexible (when iterating lean/agile). But static typing prevents some bugs, aids documentation, and helps manage projects as they increase in size.
However, this may be moot. We're no longer getting the long-term increases in single-core performance, so this trade-off may no longer apply. And, note: we do actually have some excess performance, and what has happened is in some cases it is absorbed by dynamic languages (python/ruby on serverside), and it is used to create smaller computers, lower performance, using less wattage (smartphones/tablets). iPhones use objective-c, androids use a java variant.
Maybe we've reached a point of equilibrium in the trade-off, if we include the end-user's demands?
BTW: I'm personally at home with stating typing, but I can't remember the last time it prevented a bug for me. (other people using it in others ways might have different experiences).
PS: to give another answer to your question: Flash's ActionScript 3.0. It's javascript plus optional static typing. Coincidentally, flash is dying/dead.
> dynamic (or "duck") typing Nit-pick: This post seem to say the dynamic typing and duck typing are the same thing. They're not. Duck-typing means looking up method names runtime by name, and not compile time by interface. Dynamic typing is a much bigger concept.
> Performance > Static typing can give you high, scalable and predictable efficiency, without the slow warm-up seen in many JIT compilers. These are important for interactive applications and games, for example.
static vs dynamic typing has not much to do with performance, at least as exposed here: the most widespread JIT out there is for a static language: Java, all the while both Python and Ruby can be compiled AOT (both to bytecode and to native code). Now type information could add some data for static analysis, which may bring some performance benefits but given how static typing is optional, such analysis (and following benefits) would only go so far.
> Compile-time and runtime type checking > Static typing makes it easier to find bugs and with less debugging (and with less staring at long stack traces)
Well, for the breadth and depth of Java and C# stack traces I have enjoyed, they can be equally confusing, just as dynamic typing stack traces can be equally informative. More often than not, a confounding stack trace is a code smell of some architectural issue.
> Grow your programs from dynamic to static typing > You can develop programs with dynamic types and only add static typing after your code has matured. This way you do not have maintain type declarations in initial development when the code is still changing rapidly.
This sounds interesting, but it also sounds like in reality, few areas would end up being typed and probably not enough for static typing to be meaningful. Humans are lazy, and programmers even more (that's why we tell machines to do stuff for us after all). I'm thinking a bit like for test suites, written after the fact or too late in the game. I guess that, just like tests, responsible developers will end up doing the right thing.
Maybe it's just the way it's worded and the project fundamentals are solid, but this sounds too much like a bullet list of "why dynamic typing is bad" (not that they're a silver bullet either) from someone who does not grok dynamic typing (and form the about page that does not seem to be the case, which only adds to my unease).
Anyway I'll keep mypy in my peripheral radar.
Earlier quoted context omitted.
Thanks for mentioning pytyp! I have been using this recipe: http://code.activestate.com/recipes/572161/ to add type checking to Python for a while now, so it's nice to see a more mature and developed library that does the same (and more.) In your code examples I didn't see any decorators around the functions that were being typechecked, so how do you then enforce the type checking? In addition, is pytyp as fully-feat…
huh. i will fix that, thanks. there should be a @checked annotation on the function that is checked in the example there. pyptyp is pretty comprehensive. for example, Rec(a=Seq(Opt(int)),b=Alt(float,str)) is the type for something like a dict where a is a list that contains ints or None and b is either a float or a string. BUT it's pure python so it's not at all fast. i wouldn't use type checking throughout a codebas…
Earlier quoted context omitted.
Well, the only reason to remove it is to run multiple Python threads in parallel for efficiency...so efficiency is definitely the top concern here.
No the reason to remove it is to get parallelism from threads. Once you have parallelism, you can overcome a 2x slow down for a single thread by using more cores.
Remember, the ideas was not to have CPython and CPython-without-GIL, it was to have one unified GIL-less CPython.
For that, a 2x performance drop would not be acceptable for most code.
why doesn't this use the python standard for adding type information? it should be: def foo(n: int): not def foo(int n): then it would be valid python 3 code (and would also work with pytyp (disclaimer: mine)). http://docs.python.org/py3k/reference/compound_stmts.html#fu... http://www.python.org/dev/peps/pep-3107/ http://www.acooke.org/pytyp/
> Mypy will get rid of the Global Interpreter Lock (GIL) >Details of the concurrency model are still undecided, though Wait, what? There have been numerous attempts to get rid of the GIL, most of which failed miserably. A promise to get rid of the GIL without even deciding on a concurrency model seems a little premature.
We don't believe that it is practical to adapt the CPython VM incrementally for running parallel workloads efficiently. Instead, we are going to get rid of the GIL by having a new VM for running mypy code. The VM will be based on the Alore VM, but it will use compiled native code from the start (the Alore VM uses a bytecode interpeter). It will use a garbage collector instead of reference counting (CPython primarily uses reference counting), and it will also support a modified C Python extension API that will support proper multithreading without a GIL.
The CPython VM will still be used to run Python code and modules, and it will still be limited to running a single thread at a time (most of the time). Objects passed between the VMs will have to be copied or accessed using proxy objects, so there will be some performance overhead compared to native mypy modules. We plan to port commonly used, performance-sensitive Python modules to mypy and the modified C API to minimize performance bottlenecks.
Earlier quoted context omitted.
No the reason to remove it is to get parallelism from threads. Once you have parallelism, you can overcome a 2x slow down for a single thread by using more cores.
If 99% of your codebase uses one thread, then no, a 2x slow down is not acceptable, even if you can overcome it by using more cores. Remember, the ideas was not to have CPython and CPython-without-GIL, it was to have one unified GIL-less CPython. For that, a 2x performance drop would not be acceptable for most code.
And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes.
I speculate that the performance issue wasn't really the most important reason for rejecting the patch, but more so not wanting to deal with the complexity of maintaining the patch. It's a shame because the future is definitely going to have lots of cores, and not all problems are well-suited to multiprocessing.
Earlier quoted context omitted.
If 99% of your codebase uses one thread, then no, a 2x slow down is not acceptable, even if you can overcome it by using more cores. Remember, the ideas was not to have CPython and CPython-without-GIL, it was to have one unified GIL-less CPython. For that, a 2x performance drop would not be acceptable for most code.
But 2x was just with the initial, non-optimized patch. A language like Java seems to perform quite well even with fine-grained locking, so it's possible. And I don't see why performance is suddenly used as a deal breaker for a language primarily used for scripting and other non-CPU-bound purposes. I speculate that the performance issue wasn't really the most important reason for rejecting the patch, but more so not w…
People want to use Python for lots of CPU bound processes. A big Python niche is numeric and scientific computing.
You say that it is "primarily used for scripting and other non-CPU-bound purposes", but this is also a consequence of it being slow. If it was faster it would open MORE uses. LUA and C# got the games action. Go gets attention on the networking apps end, etc...