This isn't any trickery, this is a file format. One that actually avoid the uncontrollable computational photography done by default and actually changes the nature of the picture without the input of the user. This is helping conserve what we think of pictures as a digital capture of light. Rather than what it's becoming, which is the product of hallucinated details by a neural network.
Is this person actually asking for Monads and Higher Kinded Types?
It would solve the problem they're raising but somehow I suspect that's now the solution they want to hear. And also the rust version would be quite hard to use due to the memory management model.
This asking GPT for inference needs to stop immediately before it becomes accepted and commonplace. This is almost the same as "I flipped a coin and the gods spoke to me"
I'm quite surprised but how large and extensive this guide is.
As someone who learned to drive in Europe I've always been extremely confused by the signage and road layout of American roads. There is a pretty big difference in quality between state roads and federal roads. The former seem to have no coherent style, layout or identity while the latter seem pretty consistent. Given the above documents I can see there is a consistent style but the style does not seem to translate to a consistent user experience.
The three things that stand out to me are the amount of text on each sign, the lack of standardized rule about entries and exists, and the lack of road markings, specially at intersections.
The first one isn't necessarily a big problem but it's very weird to have all this text when you could have instead a very recognizable sign that you can understand from afar (the one way sign is a great example), instead of a white sign with black text that you can only read once you're close to it and only understand if you know English.
The second one makes highway layout extremely confusing and, at least for me, feel dangerous and stressful. Some Signs can tell you to take an exit with make 20m of notice and it's a 90° right turn and you also need to go from 120 kmph to 30 in that span. The reduced speed sign is only visible after you've turned so if you dont know the area you're almost always going too fast. Because it's a 90° turn with trees in the sides you can't anticipate what the traffic is like after the turn. If you know the area you probably have no problem handling this situation, but driving there for the first time feels like driving through a minefield. There are other instances of this with left exits, overtaking from both sides, turn right on red, stop sights everywhere, no priority system, and more.
The last one is incredibly frustrating when you come from Europe because over there, most intersections have redundant signage and markings. Intersections have street lights that tell you where to go, the road layout is advertised on a sign well in advance, and the paint on the road tells you how to turn and where to stop and even indicates speed limits or directions. Intersections in americas provide no such affordances. Intersections are basically a free for all between the incoming trafic, the people turning right on red and the pedestrians. I was expecting a lot more from a country which is built for cars.
It feels like roads are built for cars but not for drivers.
You simultaneously make a great and stupid point. The stupid part is obvious: operations are allowed because writing programs is useful. Now for the great, nuanced and complicated point: How do we detect errors when manipulating floats while allowing us to write the useful programs?
This boils down to two things:
1. What do we think is correct at any given time for any given program? The compiler can't know so we have to tell it, which brings us to 2
2. How do we write down in our programming language what is supposed to be correct?
The problem with floats is that sometimes you care about precision, sometimes you don't sometimes you care about overflows, sometimes you don't. Sometimes you care about inverse operations, sometimes you don't. Commercial programming language which only expose a "float" types usually are unable to deal with the greater complexity of _ensuring_ that some property you care about isn't broken. That is why compilers let you operate on floats and shoot yourself in the foot when you divide and then multiply back.
On the other hand, one could imagine a future programming language (and some academic experiments already exist) where you can tell the computer "in this part of the code, it's important that I never overflow" or "in this function, I expect multiplication and division to be inverses of each other". In which case the compiler will display diagnostic information if you do something that break those properties.
It's not clear yet what is the most convenient user interface to write down and check those properties. But many believe it by using even more advanced type systems than Rust. Many other believe that we can add static analysis atop existing programming languages to obtain the same result.
TLDR: Rust allows it for now because 50-100years in the future we'll have to tools to tell when it's ok and when it's not ok to multiply floats together. Right now we're still smacking rocks together to make fire.
Tokens of recognition aren't currency that you can use to buy redemption, I find this comment particularly ironic when this other article exists, perfectly capturing a symptom of the state of denial that the US find themselves in wrt to their tumultuous history: https://news.ycombinator.com/item?id=30261610
Germany didn't get over their trauma by having "Jew day" and "please stop treating humans like cattle" bill while routinely allowing their members of society to deny education to their children
I need my answer was focused on runtime performance, thanks for pointing it out. However, They are related for two reasons:
- idris is written in idris so any improvement in the language results in faster compile-times, if more things are annotated with 0 in the compiler, thing will compile faster.
- if some variable is only important at compile-time, the compiler doesn't have to look at it with very much scrutiny. That saves you a lot of time when typechecking
Yes. Multiplicity 0 removes the value from the runtime avoiding allocations and garbage collection. That particularly handy for type-level indices and type-level programs in general.
Technically speaking multiplicity 1 (linear variable) can be subject to arbitrary inclining though it's not implemented in the compiler.
I'm working on other multiplicities that could allow you to describe which values are "compile-time" available, and therefore subject to optimisations
I reckon we can get the raw performance quite low, but it might be a challenging environment to program in, the ergonomics of programming linear types aren't figured out and it would involve a lot of memory management. While safe, reasoning about memory can be quite hard, just like anyone learning how to handle the borrow checked in rust can tell you.
It's currently one of my project to use QTT to statically enforce performance invariants and optimisations, currently I am looking at partial evaluation of programs and explicit annotations to control which parts need to be partially evaluated and which parts need to remain Unevaluated.
Regarding the benchmarks there are two things to address to make them go faster:
- the idris parser is actually pretty slow so we should get working on that
- the examples use explicit runtime bindings for type parameters which force the types to be allocated and available at runtime, which destroys the performance of some programs (stlc notably)
It's not expected to write idris code in that way since linearity annotations also allow you to _remove_ values from the runtime and make dependent programs go faster, if you were to be concerned about runtime performance you would use _runtime erased_ type variables instead of _runtime relevant_ variables. Some of this is due to the foreign nature of QTT, and we should do a better job at teaching how to use it for performance.
On the other hand someone could argue "if idris is that smart can't it warn/perform those optimisations automatically?" And maybe that's the way to go, but we need more eyes and brain looking at the problem and coming up with prototype solutions to make progress. idris is still a small project so we don't have enough people working on it to implement those smart features
I'm a phd student working on Idris and I used to work with Edwin on this, if you want more info or want to see more practical applications of idris2, Dependent types, or QTT, here are a couple links:
- my own projects in idris include a purely declarative server library where you give the API and the server is completely implemented and instantiated from your description https://gitlab.com/avidela/recombine
In what you describe the difference would be that HSBC doesn't get fined and neither HSBC or Revolut does any check. How does that help?