What exactly is the ask here? Do you want input for a programming model? Practical advise for building a compiler? Do you want to target real hardware or a software simulator?
> I'd settle for a good way to express said tree in a plain text file
What you are referring to is commonly called an IR (intermediate representation). Compilers typically take the AST generated by the parser and translate (“lower”) it into increasingly hardware-near and optimized IRs before performing instruction selection.
I briefly browsed through the links you provided. IIUC, BitGrid is essentially one of the Turing-complete 2-D cellular automata. This Reddit thread might be interesting to you [0].
I think this question mixes up two orthogonal dimensions: transactionality (i.e., OLTP vs. OLAP) and data model (relational, document-based, graph, vector, ...).
Regarding transactionality: There is an entire area of research on "hybrid transactional and analytical processing" (HTAP) systems that unifies OLAP and OLTP systems. Hyper [1] pioneered this path at TU Munich, it's successor Umbra [2] recently incorporated as CedarDB [3]. There are lots of others. Most of these systems, AFAIK, are relational.
Regarding data model: What we've seen in the past few decades is that non-relational DBMS (excluding key-value stores) only make sense in rare edge cases that require huge scale. There has, e.g. been research [4] that shows that graph databases are still, well, lacking, compared to relational systems. The common pattern seems to be: unless you need to service very specific workloads at huge scales, SQL is probably enough [5]. Then again, it really comes down to intrinsics. If you were to, for example, implement distributed locking using Postgres, you would likely run into problems with MVCC and Xids very quickly.
So, as you already mentioned, there is no silver bullet. But even today, unless you are Meta or Google, SQL is probably enough for a long time and lots of use cases.
(Full disclosure: I'm working on Hyper full-time).
My read is that investing into AI is the trendy thing to do in 2024. No CEO will have to justify pouring money into AI; they would probably be seen as negligent if they don’t. It’s just the zero-risk strategy at this point in time. That’s not to say that there is no value to be realized, it’s more a question of how much value and at what price. If in the next 12-24 months we find out that AGI, robotics and the end of labor is not as imminent as some have hoped and that perhaps not every car dealership needs an AI chat assistant, and the first companies announce reductions in their AI spending, the dominos might begin to fall. Or not, let’s see.
And Hyper is alive and well at Salesforce/Tableau! The team working on it is still in large parts the original Hyper team from TUM. You can actually download Hyper (as a binary with language bindings) and play around with it [2] for non-commercial use cases.
If you think Hyper/Umbra is cool, the TUM database group has lots of other very interesting projects going on at the moment. LingoDB [3] pushes the database-as-a-compiler idea to the extreme by implementing query optimization and compilation query compilation in MLIR. LingoDB is open-source. Also Viktor Leis, who stands behind (among many other things) Hyper's Morsel scheduling and ART indexes as well as Umbra's buffer management recently started a very interesting project [4] to heavily co-design the DBMS together with the OS in a unikernel approach. Really interesting stuff!
I believe this is a rational assessment in general. A lot of the discussion around this topic seems to be negligent of market dynamics.
However, the crux is in the details:
> You can increase the % enough so that overall demand for developers goes down or doesn't grow as much as it would have otherwise.
I would be at least skeptical of this. Every push for commodification that we've seen in the software space so far has been absorbed by demand. Will this continue forever? Nobody knows. At least where I work the backlog is filled to the brim, and every new iteration of tooling begets more babysitting to unlock the promised gains. And customers still have a never-ending list of hyper-specific feature requests.
The friends and colleagues at the Senior/Staff level who are using Copilot/GPT-4 (and have admittedly become much better than me at prompting) didn't exactly become "hyper-productive". Sure, they get code pushed out faster, but they still work long hours and complain about deadlines.
This is not to say that we're all fine forever and things will not change. But as long as we don't experience an across-the-board temperature shift in the job market decoupled from macro-economic events I wouldn't put too much attention there. In the end, doom scrolling is also just a form of procrastination.
Look — I appreciate that you want to help OP out here, but please keep HN free from low-effort LLM-generated answers like this. Everyone here has access to chatGPT, so the added utility of pasting responses from it is close to zero.
As someone who never owned cryptocurrency and frankly never cared that much: could you ELI5 the idea of a Bitcoin ETF? Is it just a vehicle to trade Bitcoin (as in a single cryptocurrency; BTC) on a normal stock exchange? Is it an index-weighted portfolio of BTC and other (e.g. Ethereum)? Does the fund actually own BTC or is it technically a derivative like a synthetic (regular) ETF?
Absolutely. I also believe that Copilot is getting more flak than appropriate at the moment.
To rephrase my comment above: I don't want to blame the team behind Copilot for not getting everything right on the first try. Neither am I in a position to do so, nor would I want to live in a world where smart people aren't allowed to make mistakes.
What irritates me is that there are two possible scenarios here:
1) They knew about potential issues and decided to release it anyway (without at least addressing them verbally).
2) They didn't.
And frankly, I don't know which one I like less. Even though it's still a beta/preview, either option seems to signal a degree of negligence? that feels unnerving given the potential impact of such a system.
That being said, if we do live in scenario 1) than I am certain that better framing could have prevented the PR fallout that we're seeing right now (at least partially). IMHO, GitHub (the platform) is still a great product after all.
What amazes me is how predictable(?) all of the recent issues were.
Don't get me wrong, the folks behind Copilot are clearly, without any doubt smart, creative, and capable. But then... None of these issues (reproducing licensed code ad verbatim, non-compiling code, getting semantics wrong, and now this) are 0.01% edge cases that take specialized knowledge to see or trigger. I remember some of them being called days ago in the initial HN thread by people who haven't had beta access.
I really wonder how this announcement/rollout looked like on the management side of things. Because a) these shortcomings must have been known beforehand and b) backlash from people who feel threatened for their jobs/"stolen" of their open source work was (I guess) foreseeable? I've already read calls to abandon GitHub for competitors; this can hardly have been an acceptable outcome here.
Nevertheless, Copilot is still one of the most innovative and interesting products I've seen in a while.
This might be a fair assumption from a birth statistics viewpoint, but completely misses immigration.
I met a lot of brilliant people from all over the world during my undergrad at TU Munich; many of them stayed. Google, Apple, Microsoft have expanded rather aggressively over the past years, and the startup scene is growing. Berlin, Hamburg, Frankfurt seem to follow suit.
Granted, it's much less likely (and also less politically incentivized) to become a "millionaire employee", but I guess ultimately, the correlation between wealth and wellbeing is simply weaker in (northern) European economies? As long as immigration policies don't change (and why would they? the current model aligns well with lobby incentives), I don't see much reason for this to change.
Also, Poland, Romania, Bulgaria, Spain, and Greece have a different political and economic history than Germany, France, Denmark, Sweden, etc.
I use a setup like this. Essentially, I use pyenv [1] to manage Python versions and Poetry [2] [2](https://python-poetry.org/) for virtualenvs/dependencies.
The workflow for creating a new project looks like this:
1. Create a project directory (e.g. 'myproject') and `cd` into it.
2. `git init`
3. Fixate the Python version for that project with the `pyenv local` command (e.g. `pyenv local 3.8.6`). This creates a `.python-version` file that you can put under source control. Within the `myproject` directory tree, `python` will now be automatically resolved to the specified version. Your system Python (in fact, any other Python versions you might have installed) remain untouched.
4. Create a new poetry project (`poetry init`). This creates a `pyproject.toml` which contains project metadata + dependencies and can also be checked into git.
5. Add dependencies with `poetry add`. Here, you could for instance add Jupyter Lab (`poetry add jupyterlab`).
To access installed dependencies, such as the `jupyter lab` command, you can either execute one command in the virtualenv directly (`poetry run jupyter lab`) or spawn a shell (`poetry shell`). If you open a Jupyter Notebook that way, the packages installed in the virtualenv are directly available from within Jupyter Notebooks, without having to mess around with installing IPython kernels.
I like this approach, because it gives you full flexibility, while being portable and easy to use. It gets you around having to deal with conda (which I found to be frustrating at times). Also, you're not tied to the Jupyter frontends, but could e.g. just install `ipykernel` and open notebooks in VSCode.
I don't pretend to know the numbers, but my guess is that Survivorship Bias might account for that to a substantial amount. I just can't imagine that there are people with glass bowls that good to make consistent alpha over the long term.
I loosely followed the work of the "Kohlekommission" (i.e. the panel that was responsible for negotiating the exit plan) through various German news outlets.
The strategy agreed upon today was a revision of an earlier plan that would have cost a "mere" 5bn euro. This deal was however opposed by the individual federal states of Germany, which demanded 60bn – just to put the final 40bn in perspective.
40bn is still a huge sum of money (about 1/3 Jeff Bezos, for scale), but as a German voter and tax payer I have to say that I am entirely fine with this. Germany is a very prosperous country, and we have to get away from coal, the sooner the better. True, it probably could have been done with less money, but to me 40bn is still a favorable deal over no deal at all.
They do.
As an annecdote, the professor who formerly held the "Machine Learning" course at TU Munich left for VW's AI research group (https://argmax.ai) a few years ago. Whether that qualifies as "science" may be debatable, but the larger players in the automotive space are definitely invested in this kind of research.
> I'd settle for a good way to express said tree in a plain text file
What you are referring to is commonly called an IR (intermediate representation). Compilers typically take the AST generated by the parser and translate (“lower”) it into increasingly hardware-near and optimized IRs before performing instruction selection.
I briefly browsed through the links you provided. IIUC, BitGrid is essentially one of the Turing-complete 2-D cellular automata. This Reddit thread might be interesting to you [0].
[0]: https://www.reddit.com/r/computerscience/s/IE5WRIrKsR