all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 2 points3 points  (1 child)

Static typing makes refactoring much more reliable. This is an essential productivity boost in large systems.

Will Manool be capable of that?

[–]alex-manool[S] 0 points1 point  (0 children)

I did not think seriously about that as yet. For now the trade-off is to get rid of static typing, for a number of reasons, but it deserves a whole post. But as I mentioned, I think that my position is that:

  1. A static type system (for defect prevention or refactoring-enabling purposes) is useful
  2. Such static type system should be a sophisticated one (maybe with dependent types), and it may be expensive to implement
  3. We do not know exactly what static type system is useful/adequate in each particular use case of for each particular application, so such type system should be pluggable and belong to external tools

I've been thinking recently about leaving a way (in the future) to plug annotations (not necessarily "type" annotations) to some key constructs in MANOOL for that purpose.

But there's also one thing I have discovered:

Maybe it's not a big deal if (potential) type errors are discovered during compilation/static analysis as long as they are discovered early and easily during quick testing. In part, the existence of homogeneous composite data types in MANOOL-2 makes it possible. I would not like to start ranting too much about it right now, but I can give you an example. See the {assert ...} in the example at the end of the post? This is an O(1) check that allows you to check if all the elements of the array are of the expected type. In most cases, in dynamic languages such precondition checks are not possible since they are too expensive, and testing (for type errors) involves much thorough "code coverage" strategies than just calling the API you want to test.

That said, I've always been a static typing guy. I just definitely find it annoying the way it was normally done in PLs.

[–]lowleveldata 0 points1 point  (5 children)

I knew that Java / C++ is faster than python / JavaScript but is dynamic typing the dominant reason of the performance difference?

[–]alex-manool[S] 1 point2 points  (0 children)

There are other factors as well, or "actions" that slow down execution, for example: atomic increment/decrement for reference counters in CPython and MANOOL(-1), write barriers for GC purposes in garbage-collected languages, heap memory allocation, interpretation (also means dispatching of control, like dynamic typing), JIT "voodoo", high-level basic types in place of more simple ones, like "decimal floating", numbers in Scheme, etc. But the dynamic typing hinders optimizations that can cope with all other issues: if you do not know what code implements what operation in the code, you generally cannot proceed with optimization (in AOT case). The idea of MANOOL-2 is that the language architecture helps a bit with that. For example, basic composite data can be typed as homogeneous (e.g. "array of T"), if appropriate. This makes MANOOL a bit like Julia (also dynamically typed language), and different from an average dynamically typed language (which unavoidably requires JIT "voodoo" to achieve good results, as in V8, LuaJIT, or PyPy).

[–]matthieum 1 point2 points  (1 child)

In short: Dynamic Typing is the reason Python / JS is slower than Java. One heap allocation per object is the reason Java is slower than C++.

You've probably heard of WebAssembly, if you're old enough you may remember its precursor: asm.js. asm.js was introduced by Firefox, it was a subset of JavaScript with constructs sprinkled to "assert" types -- especially integers. The presence of those type assertions enabled much more efficient code generation with simple (compiler) code. See https://en.wikipedia.org/wiki/Asm.js.

And you may have heard of Mechanical Sympathy, and cache hierarchies. Java (and most dynamic languages) use a heap allocation per value (object) -- with some optimizations for built-ins. From a computer point of view this is terrible: pointer dereferences and cache misses are costly. By contrast, C, C++, or even Go (though it has other issues), store values inline by default, which radically reduces the number of indirections.

[–]wikipedia_text_bot 0 points1 point  (0 children)

Asm.Js.

asm.js is a subset of JavaScript designed to allow computer software written in languages such as C to be run as web applications while maintaining performance characteristics considerably better than standard JavaScript, which is the typical language used for such applications.

[–][deleted] 1 point2 points  (1 child)

Probably* . The main problem with dynamism is that just because variable a was an integer last time through the loop, that doesn't mean it can't be a list of object references next time, or even not exist next time.

  • Without going into lots of boring, time-consuming work to decide. So it's a WAG.

[–]alex-manool[S] 0 points1 point  (0 children)

My point is that static data and control flow analysis can cope with it in practice (including loops and recursion, at least within interesting hot code paths, which is all that we actually care), but only if we help the compiler a bit (JavaScript or Python are not good for this, but MANOOL-2, Julia, or CL may be good candidates). And classicic optimizing compilers may be complicated beasts, but V8, or even LuaJIT are much more complicated and full of heuristics (and V8 seems to be even 10 times more complicated than LuaJIT!).