My personal experience with GLP-1s was starting at 5 units, then progressing to 10, 15 and max it with 20 units. Where exactly do you see benefits of a personalized treatment: in the gaps between the existing doses, in ability of having even higher doses, or in dynamically changing the dose every month?
The worst designs evap up to 80%. New designs use closed-loop system where very none to little evaps (0-6%) depending on the system.
Many designs in-between with air cooling, hybrid, etc.
Still a non-issue, it's going back into the water cycle.
Any water issue would be specific to the municipality, it's not a national issue, nor is it an issue specific to datacenters, it's true for anything being built in the town (golf courses, power plants, etc.)
Okay I feel like maybe I'm missing something. In a closed loop system, nothing evaporates. If you use an air cooled design, nothing evaporates.
If you use a hybrid design, you still evaporate ~80% of your cooling water - you just use less overall cooling water.
The water going back to the water cycle doesn't mean it's potable.
And yes, I do understand that it is a very small fraction of overall water use. I am actually in favor of using water where it will reduce electricity use. But let's not be inaccurate - the water used for cooling is absolutely evaporated or sent to sewage, with the exception of whatever sits inside the system's closed loop (which exists whether or not the system is cooled evap/dry/hybrid).
Hybrid systems keep the primary process fluid in a closed loop, they spray water on pads to cool the coils during the hotter parts. Basically a stop gap when air cooling is not enough.
There's also close loop systems that lose none, it's just more expensive to build. They are already being deployed in areas with scarce water. Microsoft and a quite a few others already built a few.
I've entered books from The Expanse and Lockwood & Co series and its output was not really overwhelming:
- other books from the series (duh, I don't need a recommender for that recommendation)
- Hobbit, Harry Potter, Azimov etc (duh, I like scifi and surely I've already read all the classic works).
This was actually a potential problem, at least on Commodore machines.
On those machines you were able to abbreviate keywords.
At the same time, they support full screen editing. That meant you could just cursor up over some code, make changes, hit enter, and the changes would take place.
However, when using the abbreviations, it was possible to create lines that were too long. I don't recall the specifics, but there was a line limit for BASIC input. Lets say it was 80 chars (for discussion).
Using abbreviations (like ? for print) and you could end up with a line that would LIST for more than 80, but if you tried to change it with the screen editor, the lines would be too long, and truncate silently.
So you had to be cautious with your use of the abbreviations.
Similar, and maybe more related to the article's topic: Commodore BASIC also saved the commands as tokens, so you could enter abbreviated commands like
10 ? "Hello"
20 gO 10
and a LIST command would yield
10 print "Hello"
20 goto 10
So saving commands as tokens in memory and formatting them on output was somewhat common back then.
The speccy was more advanced in terms of this (as mentioned in the parent comment), and it had the better BASIC for sure.
Or think about the M (aka MUMPS) language, which allows you to type just the first letter(s) of a keyword and considers it valid syntax.
Imagine Java if you could…
na com.mycompany.myapp;
pu cl MyClass {
pro sta i = 42;
pri fi ch[] MAGIC = ['a', 'b'];
pu sta v main(String[] args) {
OtherClass otherClass = n OtherClass();
f (i i = 0; i < MyClass.i; i++) {
otherClass.hex(i, this.MAGIC);
}
}
}
Ignoring the prediction that everything will be decentralized in the near future (it probably won't), how about this scenario: you want to see if the voting activity (recorded in your events) correlates with the number of times you went to the doctors in the year prior to election (as recorded in your health records). If we want to be able to run such a distributed query, we need to be sure that each node stores the data in predefined format ("tables") and that one of their services run a service that will receive the distributed query request, decide whether or not it wants to participate, and then execute the business logic of the conditions (healthevent.year > getdate() - 365), probably defined in some programming language ("SQL").
> decentralized in the near future (it probably won't)
I may be optimistic on this one. But it feels like dead internet is encroaching everywhere. There aren't many centralized services I can think of that people actually like. Perhaps Steam, but most of them are hated by their users. Currently, I'm imagining that more and more of our digital interactions are going to go through AI helpers. Agents that will filter out ads, and likely also hold onto our information for us. At a certain point, centralized DBs just become an unnecessary middleman with privacy concerns. If I want photos of my friends, why not just have my assistant ask their assistant?
> how about this scenario: ....
It seems like all of this data could easily fit into a 10MB of text. This is the kind of thing an assistant would be likely to churn through without issue. It could also search for other interesting correlations while it's at it.
1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history
2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this.
3) The biggest challenge about data models is not auto-generated code (that many people would avoid in principle anyway), but compressed, optimized wire serialization. So you START with selecting this for your application (eg. AVRO, CapnProto, MessagePack etc) and then use the schema definition language coming with the serialization tool you've chosen.
> 3) The biggest challenge about data models is not auto-generated code
I would say auto-generated code is most definitely the harder problem to solve, and I’d also go out on a limb and say it is THE problem to solve.
Whether it’s JSON, XML, JavaScript, SQL, or what have you, integrating both data and behavior between languages is paramount. But nothing has changed in the last 40+ years solving this problem, we still generate code the same clumsy way… Chinese wall between systems, separate build steps, and all the problems that go with it.
Something like project manifold[1] for the jvm world is in my view the way forward. Shrug.
LINQ, Splunk, and KQL are all proprietary. For the purposes of setting new standards, they might as well not exist.
PRQL is the only real entrant in your list when it comes to adding a pipelining syntax to a language for relational queries in a way that others can freely build on.
