That's not correct. For ordinary computers there is Landauer's principle, which gives a theoretical lower limit for the energy needed for computation [0].
I say "ordinary computers" because other comments mentioned "reversible computers" for which this limit doesn't apply.
According to the linked wikipedia page, this theoretical limit is around a billion times smaller than current computers use for an operation, so you may call me pedantic.
I came to like auto over the years, although I also use it sparingly.
Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators:
auto it = some_container.begin();
Not even once have I wished to know the actual type of the iterator.
Damn, I always thought Fuchsia is just a colour, but today I learned
- Fuchsia is a flower
- which is named after a German botanist (Leonhart Fuchs)
- Fuchsia in English is pronounced completely different than in German.
- Google is surprisingly bad at naming their products
Julia is always the odd one out, when talking about dynamic vs. static dispatch, because its JIT compiler acts more like an Ahead-of-Time compiler in many regards.
In the best case, types are statically decidable and Julia's compiler just produces a static dispatch and native code like e.g. a C compiler would.
In the worst case, there are a big (or unlimited) number of type candidates.
The grey area in between, where there are a limited number of type candidates, is interesting. As far as I understand, Julia does something similar to the link you provided. Based on some heuristics it will compile instances for a "sealed" number of candidates and fallback to a fully dynamic dispatch, if there are two many type candidates.
For the worst case scenario, Julia chooses what's in my regard the nuclear option: If the types are not decidable, it just ships the whole compiler with your code and tries again at runtime.
But I guess, that's not the only possible solution. Presumably, it would also be possible to fallback to a Julia interpreter for dynamic code. That would be more similar to what JavaScript is doing, just the other way around. Instead of interpreting the majority if the code and optimising hot paths with a JIT, our alternative Julia would compile most code statically and use the interpreter for the dynamic parts.
Seems a bit early to come to this conclusion, but I would also suspect, that the value of a parking garage full of EVs is not in providing energy to the grid but as a large scale consumer for load shaping.
Counterintuitively Julia recommends the use of immutable data types for performance reasons, because immutability enables more flexible compiler optimisations
An immutable variable can be savely shared across functions or even threads without copying.
It can be created on the stack, heap or in a register, whatever the compiler deems most efficient.
In the case, where you want to change a field of an immutable variable (the use case of lenses), immutable types may still be more efficient, because the variable was stack allocated and copying it is cheap or the compiler can correctly infer, that the original object is not in use anymore and thus reuses the data of the old variable for the new one.
Coming from the C++ world, I think immutability by default is pretty need, because it enables many of the optimisations you would get from C++'s move semantics (or Rust's borrow checker) without the hassle.
There is nothing counter-intuitive or julia-specific about it:
Fastest way is to have your datastructure in a (virtual) register, and that works better with immutable structures (ie memory2ssa has limitations). Second fastest way is to have your datastructure allocated on the heap and mutate it. Slowest way is to have your datastructure allocated on the heap, have it immutable, copy it all the time, and then let the old copies get garbage collected. The last slowest way is exactly what many "functional" languages end up doing. (exception: Read-copy-update is often a very good strategy in multi-threading, and is relatively painless thanks to the GC)
The original post was about local variables -- and const declarations for local variables are mostly syntactic sugar, the compiler puts it into SSA form anyway (exception: const in C if you take the address of the variable and let that pointer escape).
So this is mostly the same as in every language: You need to learn what patterns allow the current compiler version to put your stuff into registers, and then use these patterns. I.e. you need to read a lot of assembly / llvm-IR until you get a feeling for it, and refresh your feelings with every compiler update. Most intuitions are similar to Rust/clang C/C++ (it's llvm, duh!), so you should be right at home if you regularly read compiler output.
Julia has excellent tooling to read the generated assembly/IR; much more convenient than java (bytecode is irrelevant, you need to read assembly or learn to read graal/C2 IR; and that is extremely inconvenient).
> Most of Europe became rich under imperialist, authoritarian governments not with their current system
Europe prospered under democratic governments after the second world war.
My particular region of Germany was rural, agrarian and piss poor before the war. Now it is an industry hub and one of the richest regions in Germany, all thanks to a democratic government, which prioritised development of rural areas.
The wealth we now enjoy is incomparable to what we had under authoritarian rule before.
Let's also not forget, that the Cold war divided Europe in two halves, one with democratic governments and one under authoritarian rule, an A/B test so to say. The end result was, that they needed a wall in Berlin to keep the people from fleeing to the west.
> Look around the world and see how many countries managed to achieve similar success using the same liberal principles
Beside the whole of Europe, Japan, Canada, Australia, New Zealand, South Korea, Uruguay and Taiwan come to mind.
Taiwan has a per capita GDP 2.5x that of mainland China.
Sorry but I have to mention that Nazi Germany became incredibly prosperous, but it decided to use its wealth to obtain military power.
Also, Europe dominated the world for a couple of hundred years before the Great War. Some parts of Europe may have been poor during that time, but compared to the rest of the world I do think it was a whole lot better.
Japan was incredibly rich in the beginning of the 20th century - and it was definitely not a democracy. Australia, Canada and NZ are all part of the ex-British Empire and I would say that's what made them prosperous, not their political system.
South Korea rode on the back of US support, like Japan after the war, but I do agree they did that while being mostly democratic.
Uruguay has just very recently become a nice place due to basically a single guy! That president, Jose Mujica, was such a legend! And a big critic of capitalism , by the way.
Taiwan was what we used to call the "Asian Tigers" that became rich in an incredibly fast manner... I don't know that you can attribute that to a political system at all: Singapore was and is a dictatorship and is perhaps the best example of Asian Tiger - it became richer than Australia in like 20 years!
All in all: you do not convince me. You do not seem to understand what made those countries rich in my opinion and you haven't really reflected on it if you really think that democracy was the common theme.
EDIT: Taiwan is a tiny island, China is a huge country. The GDP percapita of Shanghai and Beijing is about the same as Taiwan... Hong Kong and Macau, also part of China, have much larger GDP/pc still.
> Advent calendars in their earliest forms were invented approx. 80 years ago.
Well, Wikipedia starts its "History" section in 1945, which is 80 years ago. But what it says about advent calendars in 1945 is that they were lower-quality reprints of earlier designs. This strongly implies that they weren't a new concept in 1945.
The German wikipedia is more interested in the concept and cites the word Adventskalenders to the novel Buddenbrooks, which features one set in the year 1869 but was published in 1901. Either way, the calendars were clearly an established cultural phenomenon well before 1945.
Looking at the talk page (for the English article), it seems that the history section was provided by a "translation group" from their translation of a matching section of the German article. It's not clear why they began with the post-war period; the German page goes back much further than that, which was also true at the time they provided their translation. But this does explain why the English "history" section begins by referring to prior context that doesn't exist in the English article.
Good to hear. Keep up the good work.