"Gothic cathedrals and Doric temples are mathematics in stone. Doubtless Pythagoras was the first in the Classical Culture to conceive number scientifically as the principle of a world-order of comprehensible things—as standard and as magnitude—but even before him it had found expression, as a noble arraying of sensuous-material units, in the strict canon of the statue and the Doric order of columns. The great arts are, one and all, modes of interpretation by means of limits based on number (consider, for example, the problem of space-representation in oil painting). A high mathematical endowment may, without any mathematical science whatsoever, come to fruition and full self-knowledge in technical spheres." ~ Spengler, Decline of the West
> in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust
imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.
Completely agree! The author made a buggy android port of nintype (called keyboard 69) that I used for years. The UX was incredible, and every swipe system I've tried since feels downright clumsy by comparison. Two finger swipe is peak ergonomics, but unfortunately I think it's an innovation that's simply too niche.
I find matplotlib to be clunky and verbose compared to ggplot. When using python, I will often use https://plotnine.org/ because it gives me a nice ggplot like API.
Even taking the author's criticism about large context windows for granted, which in my experience are exaggerated, they are still a huge UX improvement over short windows. That reason alone is enough for me to support them.
Feel free dismiss my option by assuming I'm some ignoramus that doesn't know anything about how databases work.
I'm well aware of the underlying challenges that SQL provides convenient abstractions over, and what I'm saying is that it actually isn't all that helpful for complex use cases unless you know a decent amount about dbs; which at that point, I'd rather program against a thinner
, less abstract persistence API.
The flip-side of what you've stated is that SQL makes doing things that that SHOULD be hard, because they are stupid, stupidly easy. For instance, it's dead simple to make read queries with complex filters that join together an arbitrary number of tables and transactional updates that change values in rows across multiple tables. However, on large datasets or application that need high throughout, relying on those kinds of queries would be a terrible idea.
Furthermore, databases like Postgres use SSI by default which means that complex transactions that mix reads with writes can have subtle and hard to catch bugs that are completely non-obvious to new comers. I could easily forgive a junior developer for thinking they could implement an accurate counter in postgres using a transaction with a select then update to increment a value in a given row.
Scoffing and acting exasperated doesn't actually refute anything I said. I obviously don't disagree with you that SQL has been wildly useful and popular, but that has very little to do with my comment. SQL is an outdated and flawed technology, that is propped up by decades of institutionalization. You can say a similar thing about C++: that's it's one of the most popular and useful languages in existence, yet it's also a total trash fire that owes it's lasting success more to historical trends and institutional adoption then technical merit.
Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. If it's an issue that you have to chain one extra collect call, just write a helper function for splitting that returns a vec.
The comparison with JavaScript as an exemplary imperative language is silly. You can find examples of C code from 40 years ago that still work perfectly with modern compilers. Like C, SQL is a technology that has far outlived its usefulness, though, for very different reasons. SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, raw strings, macros/preprocessors) comes with unpleasant rough edges. The best thing young developers can do is read a book like "Designing Data-intensive Applications" and learn how the fundamental technology behind databases work. Learning relational modelling is great, but learning SQL itself, unless you actively have to work with it, is a waste of time.
Too bad it will not be adopted for anything serious in the next 50 years. There is no reasonable value proposition from a business standpoint for picking zig over rust. It is already the reality in much of the tech industry that Rust is filling the space previously occupied by C++. The fact that there now exists a safe low level language is legitimately a paradigm shift. It doesn't matter how many shiny cool things zig adds, being unsafe means it a technology stuck in the past.
Really? You are telling me that the discovery/development of general relativity or quantum mechanics has not thrown new increasingly complex doubts on the accuracy of previous physical models due to these new "essences" implying contradictions with classical "essences". What could possibly make you so confident that new datapoints, theories, and discoveries as it relates to consciousness will be completely flawless?
It absolutely is a problem with the article. Science deals with physical phenomena; metaphysics quite literally means beyond physics. It's ridiculous to say that consciousness is the last hold out, as if there aren't a million other unanswered questions about meaning, essenence, and experience.
Here is a parallel argument for you. The history of science has been one discovery after another which leaves us with new, increasingly complex unanswered questions about phenomena. It is reasonable to think that if/when we reduce consciousness through science we will find that there are more increasingly complex unanswered metaphysical gaps.
> It is because of the hundreds of years of astonishing and unexpected success of the sciences that have convincingly shown that apparent metaphysical gaps are never such.
This has to be one of the most dumbfounding pseudo-philosophical sentences I've ever read. Metaphysics by definition is unfalsifiable and unscientific; it exists on a parallel plane from empiricism and is derived only through intuition, reason, and for the religious revelation. If this guy's claim for material consciousness simply rests on an intuitive argument from induction, it suffices as a counter argument to say "If I am mistaken, I am".
Bambu absolutely could create a system where their printers both communicate with the cloud and local devices, they just don't want to do the difficult software engineering necessary because it is difficult. This is not theoretical either; I work on production devices with hybrid cloud and local functionality. Engineering around a zero-trust threat model (as in you assume the user can and will tamper with the device) is completely doable.
For instance, using a push-only RPC model where only the cloud can initiate a request is one zero-trust strategy that can be used for ensuring a predictable network load on cloud infrastructure, which seems to be their main concern.
Yeah this is a good point, and maybe a hole wasn't the right way to explain myself. The point is that the way a WAL is supposed to work is that the main data store always lags behind the WAL, so that if a partial operation (always idempotent) occurs on shutdown it is replayed on start up and fixed. In the case I describe, because of a lack of fsync it's possible for the WAL to lag the main data store, so partial operations will not be fixed on start up.
Unless I am mistaken, it seems like there is a glaring flaw in this scheme, which is that without fsync you cannot guarantee the previous WAL blocks have been persisted before the current one, so a power loss event could leave a hole in the log and cause erroneous recovery. I believe that SSDs reorder writes internally so even having atomic batched O_DIRECT is not a strong enough guarantee for durability. I'll admit that I could be misunderstanding something about the system that alleviates this concern.
For the uninitiated who didn't watch Terry's streams, HolyC is both an AOT and JIT language, but the JIT was in some ways much more rudimentary and in some ways much more powerful than a typical JIT compiler. Like this CJIT project, it basically could dynamically link and compile source code, spit the assembly into memory and proceed to immediately execute it. In fact, the system shell was literally JIT compiled HolyC. Which also meant you can do fun things like call kernel functions directly from the command line.