Looking at the photos, I can imagine it is even rotating. Ok-ok, it is near the axle, but you do not see racing bikes with huge internally geared hubs neither, so...
> Using extension modules is just a time-tested, highly organized, modular, robust design pattern.
I really don't get this. I'am fully on the side that limitations may increase design quality. E.g I accept the argument that Haskell immutability often leads to good design, I also believe the same true for Rust ownership rules (it often forces a design where components have a well defined responsibility: this component only manages resource X starting from { until }.)
But having a performance boundary between components, why would that help?
E.g. This algorithm will be fast with floats but will be slow with complex numbers. Or: You can provide X,Y as callback function to our component, it will be blessed and fast, but providing your custom function Z it will be slow.
So you should implement support for callback Z in a different layer but not for callback X,Y, and you should rewrite your algorithm in a lower level layer just to support complex numbers.
Will this really lead to a better design?
> “But having a performance boundary between components, why would that help?”
It helps precisely so you don’t pay premature abstraction costs to over-generalize the performance patterns.
One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t. Sometimes I’m way better off if not everything up the entire language stack is differentiable and carries baggage with it needed for that underlying architecture. But Julia hasn’t given me the choice of this little piece that does benefit from it vs that little piece that, by virtue of being built on top of the same differentiability, is just bloat or premature optimization.
> “you should rewrite your algorithm in a lower level layer just to support complex numbers.”
Yes, precisely. This maximally avoids premature abstraction and premature extensibility. And if, like in Cython, the process of “rewriting” the algorithm is essentially instantaneous, easy, pleasant to work with, then the cost is even lower.
2. Allow each to pursue optimization independently, with clear boundaries and API constraints if you want to hook in
3. When possible, automate large classes of transpilation from outside the separate restricted computation domains to inside them (eg JITs like numba), but never seek a pan-everything JIT that destroys the clear boundaries
4. For everything else (eg cases where you deliberately don’t want a JIT auto-optimizing because you need to restrict the scope or you need finer control), use Cython and write your Python modules seamlessly with some optimization-targeting patches in C/C++ and the rest in just normal, easy to use Python.
> One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t.
This sounds like it might be interesting, but your later comments about overhead and abstraction costs sounds like you maybe don't understand what Julia's JIT is actually doing and how it leverages multiple dispatch and unboxing. Could you be a bit more concrete?
No I think that’s what I’m saying. When raising the issue that using multiple dispatch this way is premature abstraction that has intrinsic costs, all I get is the religious pamphlet about multiple dispatch.
In practice the multiple dispatch overhead is elided by the compiler. If it can’t be you’re doing something truly dynamic, which is generally unavoidably slower. It’s still a better place to be than everything being a generic Object type.
The nice thing about Cython is that you can have both - all the multiple dispatch you want with fused types, or escape that paradigm to do other things if you desire. It gives a lot of surgical control.
I don’t think that is true. As far as I know, Cython let’s you do function overloading and single dispatch via class inheritance. I think you also miss out on the type inference that lets you do things like pipe dual numbers through functions without any dispatch related overhead.
Another, but much cheaper trick is to always leave the alarm on: then you have around 10 seconds of chance every morning to find it, if not - then better luck next day!
Yes. But economics is different for local and remote work:
Like it is natural to pay the same price for something we both order from China, and in the same time it is also completely normal that we will pay different prices for potatoes at our local market.
/When I tried Clickhouse, I managed to segfault it with NULL pointer dereference error. Ok it is anecdotal, and maybe I just had bad luck, same could happen with Postgres etc etc... But anyway: it can be a deciding factor.
(And they fixed it quickly - issue 7955 on github) /
I actually liked the mixed language approach (keywords/library functions in english, my stuff localized) when I've learned programming (and did not speak english well):
Even then, you can learn the keywords and standard library function names easily - but to name things, that needs a different level of language knowledge.
So teaching in mixed languages is a good compromise. And it is also very helpful to immediately distinguish between things that were already there, and things have been defined in the actual program. I remember this being a helpful feature to learn language/stdlib by simply reading others code.
The more I think of it: it would be good to get back this kind of easy differentiation (maybe with IDE extension?) now...
On the other hand Scratch have localization support, and lack of syntax errors - maybe the two largest blockers for smaller children...
So is it a joke on "Gilbert Ryle: The Concept of Mind"?
But it just reiterates his first example using breakfast instead of university...
'The first example is of a visitor to Oxford. The visitor, upon viewing the colleges and library, reportedly inquired "But where is the University?"[3] The visitor's mistake is presuming that a University is part of the category "units of physical infrastructure" rather than that of an "institution".'
1. certain (genetic) diseases lowers both intelligence and attractiveness
2. I vaugly remember some theory from the early time of population statistics (Galton maybe?), that if successful men (which may correlate with intelligence) tend to marry beautiful women - then on the long run we can expect attractivenes and intelligence to correlate more - but have not heard if it was ever empirically verified or not...
"Opposition parties are so inept: they could not even operate corruption."
(Do not know if it is original or some old joke: I have heard it from hungarian stand-up comedian Tibor Bödőcs - who is btw basically the only comedian left who dare (or talented enough to get away with) criticizing every side of the political spectrum here - nowadays mostly Orbán of course...)
