Shells are much better than python at managing and orchestrating process execution. Also the pipes and filters model is simple and powerful when it fits your problem, which for me is many times a day.
The interviewer was clearly annoyed at my questions, it was not that I didn't discuss the right things, it was that I asked too much and drew too little.
I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store.
They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram.
I'm sure they hired someone who drew a lot of boxes with cute logos because webscale.
If you don't like fiat there is always gold. If you really care about value, independent from the monetary system (post-apocalyptic safety), buy tools, grain, generators and oil, though many of these things are perishable and storage comes at a cost.
One must ask whether the Bitcoin valuation has raised 1000% because the fiat has inflated as much, or is it mostly driven by speculation. For reference point, the buying power of fiat currency has not changed dramatically during the same period.
Some years ago, at the height of the Augmented Reality bubble, I had a hackathon idea about smart sunglasses that would replace any detected poster and billboard with information of your choosing - your favorite art, personal photos, notifications about upcoming alarms.
I am no longer into hackathons, but I would pay good money for such a product. Bonus points if it is styled like Nada's glasses from They Live.
I tried to skim-read through the Unison About page, but all I saw was an under-designed variation of Jetbrains MPS for a single language. I assume you have spent longer with the project - do you care to summarize the differences?
From my experience, using the Google maps within the city, it tends to ne pretty sparse with labels by default.
This is a good thing because in a place like tokyo there is just too much stuff - if I care for aometgubd I either search for it, or drop a pub and check what is around.
On the other hand, Maps always shows the labels of things I have searched for in the past, yielding a customized legend of landmarks+things that matter to me.
From my experience, using the Google maps within the city, it tends to ne pretty sparse with labels by default.
This is a good thing because in a place like tokyo there is just too much stuff - if I care for aometgubd I either search for it, or drop a pub and check what is around.
On the other hand, Maps always shows the labels of things I have searched for in the past, yielding a customized legend of landmarks+things that matter to me.
I really like SemanticMerge, in its current shape it is litte more than a fancy proof of concept.
Its biggest limitation on real projects is that it works on a single-file level, while all the interesting stuff happens on patch level. You may browse their forums to get an idea of what else is missing.
That said, I wish all the best to Codice and I really hope that they continue to invest in this tool.
By "native" they mean JVM-native (not OS-native). I believe what they really mean is that they use JVM primitives for dispatch, as opposed to building their own using functor objects and reflection-like API (which was the only way to implement MOP pre-InvokeDynamic).
It is a bit misleading as there is still a lot that would have to be be emulated - the JVM does not support open types and the Java is centered around classes, which makes prototype mutation hard to implement efficiently ( InvokeDynamic somewhat helps, but would still impose a performance penalty when the prototype is changed).
>> There's an interesting point to be made here, though - "wrapping everything up in one type" is essentially what dynamic type systems do, except that it's baked into the language instead of being implemented by the programmer on an as-needed basis.
This is imprecise - a dynamic language does not really need to "wrap everything in one type" - look at Dart or Groovy. What makes it 'dynamic' is the dynamic dispatch. All dynamic languages I know dispatch based on runtime argument types, but this is only one particular form of dynamic dispatch. Declaring types in dynamic language typically is used at runtime merely as an assertion, that at this point the argument must conform to the said type.
Dynamic dispatch differs from Polymorphic dispatch in the way that polymorphic dispatch takes in account the runtime type of the target (the object whose method you are calling), but the types of the parameters are fixed at compile time.
Many dynamic languages also provide a way to customize the dispatch logic (i.e. call a default handler if no match exists) - typically via some form of Meta Object Protocol. Often the dynamic languages provide features like higher order functions, continuations, pattern matching, etc. but this has nothing to do with their dynamicity - same features are available in some static languages as well.
In a dynamic languages you can do dynamic dispatch - i.e. dispatching based on the actual runtime type of the arguments of a function, as opposed on the declared or statically inferred type. That among other things obviates the need for the visitor pattern and can also be used as rudimentary form of pattern matching.