2015-02-22 16:38 GMT-04:00 Stanislav Malyshev <smalys...@gmail.com>:
> Yes, that's not the case, at least nobody ever showed that to be the
> case. In general, as JS example (among many others) shows, it is
> completely possible to have JIT without strict typing. In particular,
> coercive typing provides as much information as strict typing about
> variable type after passing the function boundary - the only difference
> is what happens _at_ the boundary and how the engine behaves when the
> types do not match, but I do not see where big performance difference
> would come from - the only possibility for different behavior would be
> if your app requires constant type juggling (checks are needed in strict
> mode anyway, since variables are not typed) - but in this case in strict
> mode you'd have to do manual type conversions, which aren't in any way
> faster than engine type conversions.
> So the case for JIT being somehow better with strict typing so far
> remains a myth without any substantiation.
>
>
Well, strict on a JIT environment may haven't been proved, but it surely
has been proved on statically compiled languages like C. Currently, a JIT
in the most cases can't compete to the bare performance of a static
compiled language, both in resources and CPU, so how is non strict better
in that sense? You can argue a lot about nodejs, but as I said on previous
message, at runtime it consumes more memory and cpu and this is mostly due
to all the type checking it requires. In that sense if the strict proposal
could improve that situation it would be a benefit.
> No, it can't be (at least it can't be the _entire_ code of this
> function), since the user still can pass non-int into this function -
> nothing introducing strict typing in functions, as it is proposed now,
> prevents it. What strict typing does is to ensure the error in this
> case, but to generate the error you still need the checks!
> BTW, your weak mode code is wrong too - there's no need to generate
> Variants if you typed the variables as int. You know once coercion is
> done they are ints. At least in the model that was now proposed.
>
>
I thought those checks could be optional if generated at call time, thats
why I gave these 2 examples:
calc(1, 5) -> no need for type checking or conversion, do a direct call
calc("12", "15") -> calc(strToInt(value1), strToInt(value2))
calc($var1, $var2) -> needs type checking and conversion if required
I was thinking on the sense that before calling a function, type checking
could take place and conversion if required, but may be thats even more
complicated...
So what you are saying is that there is no way of determining the type of a
variable (only at runtime), as Zeev explained on the previous messages,
since variables aren't typed, checks are mandatory either way.
> Please provide a substantiation for this opinion. So far what was
> provided was not correct.
>
Static typed languages -> Direct conversion to machine code
Dynamic typed languages with JIT -> Intermediate representation -> Checks
-> Conversion to machine code with checks.
> Please do not strawman. A lot of people here care about performance, and
> you have not yet made case that strict typing has any benefit on
> performance, so implying that opponents of strict typing somehow don't
> care about performance while you champion it does not match the real
> situation.
>
My intention is just that, clear the doubts, I thought and may still think
that strict has some advantages, but I'm been proven wrong and many people
with all these insightful information might as well.
