> A substantial portion of the initial manuscript was generated with the assistance of artificial intelligence. The author provided the underlying concept and creative direction and worked extensively with AI tools throughout the development of the book, selecting, restructuring, editing, rewriting, and refining the material. The final book reflects the author’s creative vision and editorial decisions.
I'm wondering how the author convinced the AI to forget about decades of prior work on describing programming language implementation and produce a work that seems to have no prior art.
I had similar? thought many years ago when strong typing became another one of the programming mantras touted on the internet.
Even dynamically type programming languages will layout what types the languages has. But that is usually the conventions built off of years of history, usually based on C.
But what if you wanted to define a custom type to use? Say you wanted to make type mysmallint, and it was an integer that is between 1 and 1000. Now, you can write up code to do this but it is not the same thing as declaring type int. *
*unless you are using Haskell, F#, or others I am not aware of.
What if you wanted to define a custom type that says this string only contains ascii characters? You can not easily define that as a type and pass it around the code. You have to write custom code and do checks.
This is one of the beauties of Clojure’s spec. You can define a ‘type’ that is a string which length is a prime number and contains only Ascii characters but ‘x’. To put those invariants in code and not in your head is so liberating.
Can't really have it all. If you want runtime assertions on your data/state, that has a cost. Nothing is stopping you from writing that logic out and having all your inputs and outputs sanitized for "semantic invariance". But if you want the language to implicitly do that, you're gonna have overheads. Pick a different systems language in that case, and deal with the tradeoff.
Well, sure they make reference. Borrow checkers and memory ownership concepts, like in Rust, are pretty good at giving a very low overhead improvement over bare C pointers. But they're not as flexible. Shared memory complicates ownership rules. And invariably, any Rust program that involves real hardware will require dropping down into unsafe at some points. A safer program with an unsafe kernel is an improvement, don't get me wrong.
I'm not sure how a type system would "solve" arithmetic overflow / bounds dynamically, without expensive overhead (boxed types).
Sorry but, ain't we tired of beating that dead horse again and again? We got it, C is a portable assembler and as such, is barely more "secure" than assembler. And yes, 50 years after C you finally have something as fast as it and more secure, congratulations.
Can the rust community please just go and do their own things already? Seems like the only thing they can do is convert mature C projects to rust and write essays criticizing C.
I'm wondering how the author convinced the AI to forget about decades of prior work on describing programming language implementation and produce a work that seems to have no prior art.
Even dynamically type programming languages will layout what types the languages has. But that is usually the conventions built off of years of history, usually based on C.
But what if you wanted to define a custom type to use? Say you wanted to make type mysmallint, and it was an integer that is between 1 and 1000. Now, you can write up code to do this but it is not the same thing as declaring type int. *
*unless you are using Haskell, F#, or others I am not aware of.
What if you wanted to define a custom type that says this string only contains ascii characters? You can not easily define that as a type and pass it around the code. You have to write custom code and do checks.
I'm not sure how a type system would "solve" arithmetic overflow / bounds dynamically, without expensive overhead (boxed types).