1,475 karma · joined November 14, 2013
I don't understand your comment on magic comments. You don't need them to cross-compile a program. I was already doing that routinely 10 years ago. All I needed is a `GOOS=LINUX GOARCH=386 go build myprog && scp myprog myserver:`
You can't do that with python for instance. First, you need a python interpreter on the target machine, and on top of that you need the correct version of the interpreter. If yours is too old or not old enough, things might break. And then, you need to install all the dependencies. The correct version of each, as well. And they might not exist on your system, or conflict with some other lib you have on your target machine.
Same problem with any other interpreted language, including Java and C# obviously.
C/C++ dependency management is a nightmare too.
Rust is slightly better, but there was no production-ready rust 16 years ago (or even 10 years ago).
I disagree. The development of non-euclidean geometry broke a lot of theorems that were used for centuries but failed to generalize. All of a sudden, parallels could reach each other.
> Can we write a family of nested programming languages where core features are guaranteed not to change in breaking ways, and you take on progressively more risk as you use features more to the "outside" of the language?
We could, the problem is everyone disagrees on what that core should be. Should it be memory-efficient? Fast? Secure? Simple? Easy to formally prove? Easy for beginners? Work on old architecture? Work on embedded architecture? Depending on who you ask and what your goals are, you'll pick a different set of core features, and thus a different notation for your core language.
That's the difference between math & programming languages. Everyone agrees on math's overall purpose. It's a tool to understand, formalise and reason about abstractions. And mathematical notation should make that easier.
That being said, the most serious candidate for your "core language guaranteed not to change and that you can build onto" would be ANSI C. It's been there more more than 35 years, is a standard, is virtually everywhere, you can even write a conforming compiler for a brand new architecture, even an embedded microchip very easily, and most of not all the popular languages nowadays are build on it (C++ of course, but also C#, java, javascript, python, go, php, perl, haskell, rust, all have a C base), and they all use a C FFI. I'm not sure ANSI C was the best thing that ever happened to our industry, though.
Not sure this is the best example. Mathematical notation evolved a lot in the last thousand years. We're not using roman numerals anymore, and the invention of 0 or of the equal sign were incredible new features.
> You've never been in a Uber that took a wrong turn? Never argued with a cab driver about a route?
If a cab driver keeps cricling on a parking lot, again and again and again, never finding the obvious exit, I'll get a bit concerned and eventually tell him "OK, never mind, I'll find another way, just drop me there". If he refuses to let me off, and locks the doors, and keeps circling, I'll be extremely anxious. This is horror movie material.
Sounds like a recipe for failure, to be honest. In a potentially life or death situation, the last thing I want is to rely on a remote human being. Plus, if the device entered an erroneous state, I certainly don't trust it to correctly interpret a remote "emergency stop" signal.
If the machine goes crazy (and there is no world where driving around a parking lot until the end of time is the rational expected behavior), the only safe option is a big, red, cut-circuit emergency stop button.
I never had any issue. The program still compiles perfectly, cross-compiles to windows, linux and macos, no dependency issue, no breaking change in the language, nothing. For those use-cases, go is a godsend.
But then you're eating during your worktime. I'm pretty sure your "check out, order, take it, bring it back, eat it" routine takes more than 30 minutes total time. Your employer might be OK with that, and I don't know if that's common in the US, but in France, that's illegal (many people still do it, though). You're not supposed to take your lunch break while working (or else it wouldn't be a "break" in the first place).
"80.000 people live within 0 km of Paris." (ditto, 2 millions live there).
There are many other cities where the numbers are absurdly wrong. Don't take this tool too seriously, if at all.
The most famous example is the pigeonhole problem, when given to SAT solvers. Definition of the problem is: I have n pigeons and m pigeonholes, with n = m + 1. Can I put all n pigeons in a different pigeonhole? The answer is obvious to a human. If I have 20 pigeons and only 19 pigeonholes, I won't make it. But even state of the art SAT solvers will fail at solving this in a reasonable amount of time. Because of the way the problem is represented (a conjunction of boolean clauses). With just a slightly more expressive modeling language (such as pseudo-boolean representation / reasoning), you solve it with the blink of an eye.
We humans are efficient because we recognize the underlying structure of the problem. You'll solve the pigeonhole problem in a split second. But if I encode the problem in CNF (the language of SAT solvers) and give it to you without more information, you won't be able to do it anymore.
Not sure it would really improve the signal to noise ratio.
Browne allocation's Sharpe ratio (0.67) is better than yours' (0.60). They serve different purposes and cater to different investors.
I personally wouldn't use Browne's because I'm still young(ish) and have a very, very stable income and will get a pension from my government, so I can stomach the volatility and better take the best average return. But if I were a freelance of some sort in my late fifties or older, I'd get closer to Browne's allocation.
Your portfolio lost 26% of its value that year, and losing 1/4 of your life's saving isn't something most people are ready to stomach, especially when they need it the most (year just before or just after retirement, typically).
At the same time, Browne's allocation lost less than 1%. Since 2007 it had just one really bad year (2022, -13%, and even then it wasn't as bad as the above allocation), other than that, it was always positive or close to zero.
A simple portfolio that almost never loses money and still has a decent, yet significantly smaller than its competitors, CAGR. That's a pretty good option for very conservative investors, IMO.