-
An extreme example of unportable C is the book Mastering C Pointers: Tools for Programming Power, which was castigated recently. To be fair, that book has other flaws rather than being in a different camp, but I think that fuels some of the intensity of passion against it.
This… rather grossly undersells how much is wrong with that book. The author didn’t understand scope, for crying out loud, and never had a grasp of how C organized memory, even in the high-level handwavy “C Abstract Machine” sense the standard is written to.
There are better examples of unportable C, such as pretty much any non-trivial C program written for MS-DOS, especially the ones which did things like manually writing to video memory to get the best graphics performance. Of course, pretty much all embedded C would fit here as well, but you’ll actually be able to get and read the source of some of those MS-DOS programs.
In so doing, the committee had to converge on a computational model that would somehow encompass all targets. This turned out to be quite difficult, because there were a lot of targets out there that would be considered strange and exotic; arithmetic is not even guaranteed to be twos complement (the alternative is ones complement), word sizes might not be a power of 2, and other things.
Another example would be saturation semantics for overflow, as opposed to wraparound. DSPs use saturation semantics, so going off the top end of the scale plateaus, instead of causing a weird jagged waveform.
As for the rest, it’s a hard problem. Selectively turning off optimization for specific functions would be useful for some codebases, but aggressive optimization isn’t the only problem here: Optimization doesn’t cause your
longtype to suddenly be the wrong size to hold a pointer on some machines but not others. Annotating the code with machine-checked assumptions about type size, overflow behavior, and maybe other things would allow intelligent warnings about stupid code, but… well… try to get anyone to do it.-
Re “Mastering C Pointers,” that’s fair. I included it because it’s one of the things that got me thinking about the unportable camp, but I can see how its (agreed, very serious) flaws might detract from the overall argument I’m making and that there might be a better example.
Re saturating arithmetic, well, Rust has it :)
-
My interpretation is that the point of C is that simple C code should lead to simple assembly code. Needing to write
SaturatedArithmetic::addWithSaturation(a, b)instead of justa + bin all arithmetic DSP code would be quite annoying, and would simply lead to people using another language.You could say ‘oh they should add operator overloading’, but then that contravenes the first point, that simple C code (like
a + b) should not hide complex behaviour. The only construct in C that can hide complexity is the function call, which everyone recognises. But if you see some arithmetic, you know it’s just arithmetic.-
You could say ‘oh they should add operator overloading’, but then that contravenes the first point, that simple C code (like a + b) should not hide complex behavior. The only construct in C that can hide complexity is the function call, which everyone recognizes. But if you see some arithmetic, you know it’s just arithmetic.
Not to mention that not everything can be overloaded, causing inconsistencies, and some operations in mathematics have operators other than just “+-/*”. Vector dot product “·”, for example. Even if CPP (or any other language) extends to support more operators, these operators can’t be reached without key composition (“shortcuts”), making it almost unwanted.
vec_dot()might require typing more, but it’s reachable to everyone, and operators don’t need to have hidden meanings.-
-
Perl does have more operators than C, but all of them are operators that can be typed using simple key composition, such as [SHIFT+something]. String concatenation for example.
My point, added with what @milesrout said, is that some operators (math operators) aren’t easy to type with just [SHIFT+something]. As result, operator overloading in languages that offer operator overloading will always stay in a unfinished state, because it will only compromise those operators that are easily composed.
-
-
-
-
-
Mastering C Pointers: Tools for Programming Power has several four-star reviews on Amazon uk.
Herbert Schildt’s C: The Complete Reference is often touted as the worst C book ever and here.
Perhaps Mastering C Pointers is the worst in its niche (i.e., pointers) and Schildt’s is a more general worst?
-
Mastering C Pointers: Tools for Programming Power has several four-star reviews on Amazon uk.
So? One of the dangers of picking the wrong textbook is thinking it’s great, and using it to evaluate subsequent works in the field, without knowing it’s shit. Per hypothesis, if it’s your first book, you don’t know enough to question it, and if you think it’s teaching you things, those are the things you’ll go on to know, even if they’re the wrong things. It’s a very pernicious bootstrap problem.
In this case, the book is objectively terrible. Other books being bad don’t make it better.
I do agree that Schildt’s book is also terrible.
-
-
-
I’ve written a few random things, including Rust, but don’t post much. I used to blog very extensively, and expect to pick up again.
-
Here’s his obituary; he died 11 years ago. He seems like he was a nice man.
-
I found that in my searches. He did seem like a good person. It’s unfortunate his book is really, really bad.
-
It says he’s a politician. That’s a professional bullshitter. That might corroborate he was doing this stuff on purpose for money. Unlike many politicians, he also seemed to use his influence to help and entertain a lot of people. Most (all?) of us do good and bad in our lives. I wouldn’t expect him to be any different, esp ambitious enough for writing books and taking office.
Note: The jumping in the pool with suit was funny. I’d have liked to see the reactions in person.
-
-
Longer post as promised: https://raphlinus.github.io/personal/2018/04/25/gpu-unescaping.html
-
I’m interested! I did a tiny bit of CUDA a few years ago. Looking at the code, I don’t know what
thrustis.Unescaping doesn’t seem parallelizable because you don’t know ahead of time where
\is. Or are you saying you can compute it both ways in parallel and then assemble the right pieces later? I’m interested in details.-
-
OK that roughly makes sense, but yes I’d like to hear details! Some questions:
- Does
thrust::transform_inclusive_scanhave anything to do with parallelism? From your description, it sounds like the version you posted is serial, but the next step is to parallelize it with “tiles”? (I just looked it up and learned thattransform_inclusive_scanis a C++17 thing) - Why is it faster, if you’re counting the time the round trip time to the GPU? Or does it make sense to render the result directly?
I think the CSV use case is pretty interesting. If you assume a relatively well-formed CSV, it has similar quoting with
". Newlines are also special though.-
No,
thrust::transform_inclusive_scanis already parallel (because it make the additional assumption that the function being scanned is associative, which is the case here). I think the reason why performance is not astonishing is that it’s spending a lot of time reading and writing global memory, which is expensive on a GPU. If it were possible to reorganize the computation so that most of it was in shared memory, I think it would be quite a bit faster still. But that’s hard.-
OK, that makes sense. I think I get the prefix scan thing now.
I’ve had to implement backslash-type escaping (and unescaping) in at least 5 places in http://www.oilshell.org/ , and this style is something I hadn’t considered. I use
re2cin a few places, which generates DFAs as switch/goto, rather than looping over characters by hand.Maybe for fun I’ll play around with SIMD vs. C loops. I don’t think a compiler would/could know to use SIMD in these cases without the STL style.
I think the problem is that the number of DFA states explodes quickly for other string processing problems, but for backslash escaping it seems managable, and the code doesn’t seem more complicated.
Although, for JSON, don’t you have to decode
\u1234, which leads to a lot more states than just\nand\"? Also, C/Python/shell as respect 8 hex digits like\u123456789as far as I know (but apparently JSON doesn’t).-
Right, I’m only detecting backslashes here, not mapping their decoding. But all the other stuff can be done with a small finite window of input, which is pretty easy as far as GPU goes. The problem with backslashes and quotes is that, for arbitrary input, a one-byte change at one location can have an effect at another location arbitrarily later.
JSON doesn’t respect unicode escapes larger than 4 hex digits, so uses the rather egregious hack of escaping the UTF-16 encoding.
Agree that this technique doesn’t work well for even medium-size, much less actually large automata.
-
OK it makes sense that you could break it up into 2 separate steps. But I wonder what the performance implications of that are.
And it seems like there is still a serial part, because after unescaping you don’t know what position each part will end up at. The
copy_ifpart of the algorithm callskeep, which is data-dependent and I think must be done serially.So I think you have two parallel passes and one serial pass to decode a string. I can imagine it’s a win in certain situations but it’s hard reason about.
In the shell, I thought about using a lazy tree representation of strings, where you only concatenate segments if someone actually uses a string as
argv– i.e. it needs to be passed to a system call. But it does introduce a lot of complexity, whereas copying small buffers is something computers are very good at. I haven’t gotten to the point where this matters yet.Anyway, I’m looking forward to the blog post!
-
-
-
-
- Does
-
-
FYI, here is a Thrust homepage.
-
-
Hi @raph, thank you for this enlightening talk and the wonderful work you (and other contributors) have put into Xi. I am a little confused about
xi-mac. From your talk, it seems like thexi-macfront-end is pretty independent of the Xi core. Thexi-macGitHub page says that it uses CoreText, but from your talk it seems like you had to work around CoreText and implement your own text rendering that is fast enough, is that correct?If
xi-macis not just a wrapper for CoreText, would it be possible to havexi-mac(or some subset of it) forked off into a general-purpose text rendering system? I think something like that could make for a very useful re-usable component that could be used for multiple editors, terminals, document creation platforms etc.-
We should update the readme. It still uses CoreText for shaping, but not for painting pixels.
I can imagine splitting off the TextPane into a separate module, depending on whether other applications would find it useful. Certainly it would be possible to use it for a terminal, but alacritty exists and iTerm2 has a new Metal renderer, so I’m not sure who exactly would use it.
-
-
-
Thanks to the Recurse Center for inviting me to speak and for making the video. I’m here if anyone has questions.
-
A very non-technical question: Why should Xi “only” be an editor for the next 20 years? In terms of text editors, that’s not that long. People, like me, use Editors that are nearly twice as old as I am, and the reasons don’t seem to be tied to performance or the internal structure of the implementations, but rather a core “philosophy” regarding how things are done, or how the programmer should relate to text. What does Xi have to offer regarding these “practical” qualities, that have made, for example Emacs or Vi(m) last for so long? Does Xi see itself in such a certain tradition, having a certain ideal that you aspire to, or do you set your own terms? These could seem important if one intends to write an editor that should be practically used, which is what I gathered from the video, as opposed to being a “purely academic” experiment, which would obviously have different goals and priorities.
-
-
-
Also, here is a cool demo of async loading of big text files – you can navigate and I think even edit while loading:
https://youtu.be/sPhpelUfu8Q?t=1601
Using immer, Clojure-like immutable data structures in C++:
https://github.com/arximboldi/immer
The editor is a demo of the library: https://github.com/arximboldi/ewig
-
I just watched the video. It looks really interesting, although a lot of it was over my head!
I more or less understand the process model, async architecture, and distributed data structures. I like that part – very Unix-y.
But there were a lot of rendering terms I didn’t understand. Maybe because some of it is Mac-specific. But also some of the OpenGL issues. Is there any background material on text rendering you’d recommend?
Also, I don’t understand the connection to Fuschia? I was under the impression that Fuschia was more consumer-facing, and Xi is more developer-facing. That is, I imagine most consumers don’t have text editors installed. There is no text editor on Android or ChromeOS.
Or is xi more general than a vi/emacs replacement – is it meant to be used as part of a browser for implementing text boxes?
-
Glad you enjoyed the talk!
Unfortunately, there really isn’t a lot of material on text processing, especially from a modern perspective. A lot of what I learned about rendering came from reading other code (alacritty in particular), and talking to people like Patrick Walton and my teammates on Chrome and Android.
There is an EditText widget on Android (a good chunk of my career involved working on it), but you certainly wouldn’t want to write code (or long-form text) in it. My goal with xi is to make a core lightweight and performant enough it can be used in such cases, easily embedded in apps, yet powerful enough for cases where you really do need a dedicated editor application.
-
-
I feel like it’s fairly out of my league, but I’ve been thinking about implementing a Sublime Text-like editor (multiple cursors, smart brackets/quotation marks) for arbitrary text fields in web sites. Would it be possible to use Xi as a backend for something like that? Perhaps via compilation to WASM?
-
Eventually it is my hope that something like that could work. There are some technical details (the current implementation uses threads), so it’s not an easy project. In the meantime, the excellent CodeMirror does multiple selections, and is very widely used embedded in websites.
-
-
-
The general approach reminded me of the X Window System: a client-server architecture and a very general design with the additional focus on performance. I was surprised that this was not lead by a study of the operations that an editor should support based on the tasks a user has. Are multiple cursors a new promising way? Should we better support fuzzy search beyond regexp? We probably want handling of variable-width fonts and font attributes. How to integrate IDE-like features? How to handle tables and images? Equations? Isn’t this also an aspect of performance: how fast a task can be solved given the tools available?
-
We’re thinking about most of those questions. I personally think multiple cursors are very powerful and useful, but recognize this is a question of user preference. Rich text (including variable width) is high on the roadmap, and support for Language Server not far behind. I’m not sure about equations, that seems possibly beyond the scope of the project, but it might be interesting to see how far that could go as a plugin.
And yes, how fast you can get your work done is ultimately the proper measure. It’s just a little harder to quantify, even with an Arduino :)
-
-
raph
7 months ago
|
link
| on:
atom/xray: An experimental next-generation Electron-based text editor
I’m having a little trouble understanding what’s the point of this when xi-editor already exists, including having an optional Electron front-end. I also feel strongly that the best experience is a native front end rather than Electron, particularly for startup time and RAM utilization. Performance of xi-mac is (as of recently) extremely impressive, not dropping frames on the 165 Hz gaming monitor I’m using for testing.
That said, I’m happy to share work we’ve done; in particular, I think the syntax highlighting is very nice, already quite a bit faster than Atom’s, and with the potential to adopt parser-based highlighting instead of being permanently stuck with regexes.
-
What’s the Xi plan for things like VCS integration? Reading the README and Roadmap, it looks like there’s no plan for UI-level extensions? I see https://github.com/google/xi-editor/issues/160 which makes it seem like xi-editor is going to punt extensions to the front-end for things that aren’t language features, do you think that’s a fair description?
I think that’s something that atom (and presumably whatever this turns into) has going for it; it’s extension story is really strong, and being tied to Electron (rather than being front-end agnostic) is a big piece of that. I wish Emacs had a UI library built in, rather than a bunch of TUI stuff.
EDIT:
also, not sure if this was you, but: Comparison to Xi #4 :D
-
We probably don’t have this written down very well, but the plan is to add to both the plugin and front-end protocols enough functionality to support language servers, VCS, and basically all useful functionality. Admittedly, this will be quite a bit of work; it’s a lot easier for plugins to just be able to manipulate HTML/DOM/CSS. I think that work will pay off in the form of better performance.
That said, I’m not especially dogmatic about architecture. It certainly would be possible to build a hybrid where the editing core is built on xi, and there’s an extension mechanism which is based around Electron. This personally feels a bit like a frankenbeast to me, but if it’s something people really want, and really want to build, I’ll help facilitate that.
I don’t think “punting extensions to the front end” is accurate. A good way to understand the architecture is that the front-end is a highly glorified terminal, with the document and its interactions owned by the core.
#4 wasn’t me :)
-
I don’t think “punting extensions to the front end” is accurate. A good way to understand the architecture is that the front-end is a highly glorified terminal, with the document and its interactions owned by the core.
Ok, that makes sense, thanks for the clarification, I think I get what you’re coming at.
Admittedly, this will be quite a bit of work; it’s a lot easier for plugins to just be able to manipulate HTML/DOM/CSS. I think that work will pay off in the form of better performance.
I feel like “easier” is a mischaracterization, in that it assumes you can build anything one wanted through whataver protocol you bake into the editor core. By way of example, I grabbed the currently featured 6 packages from atom’s package index
-
teletype- collaborative editing - totally doable with a “core” plugin -
scroll-through-time- scrolling mapped to undo/redo history - will scroll events be something that gets proxied through the front-end protocol? - hydrogen - jupyter kernel text + graphical output inline in the editor - will the front-end protocol handle inline images, or (if not inline) popups, etc. with arbitrary non-textual content?
- hey-pane - panel management, automatically making the currently focused pane larger - I could see something like this being part of the front-end protocol, but that would mean at a minimum forwarding focus/blur events and managing frame/panel state from the backend.
- atom-clock - show a clock in the toolbar - totally doable, but out of scope?
- zen-tabs - tab management - probably the same as hey-pane in terms of necessary api.
- (extra, not featured) https://atom.io/packages/git-gui - full UI for git management - table views, dropdowns, spinners, async network communication…
I think my point with this is that a front-end prototocol that doesn’t allow those sorts of extensions (whether you think they’re a good idea or not) is strictly less powerful than one that does, and I’m not certain you can build that protocol without it basically becoming a UI framework itself, and at that point, why bother being front-end agnostic, or not taking advantage of the UI framework that is HTML/DOM/CSS?
It feels to me like Xi is going for replacing (n)Vim (which is noble and awesome!) but the Electron editors have a different selling point, which is that it’s trivial to build graphical UI extensions. I think that’s a valid argument to have (it’s an editor, not a web browser, get your nyan cats out of here…) but it’s a different argument than “we already have this, why bother?”
feels a bit like a frankenbeast
I think, given the above, the frankenbeast of “Xi backend, Electron frontend” makes a lot of sense; by keeping front end stuff out of the editor core, the front end is able to use it’s entire feature set, and not have to settle for extensions or UI paradigms that are supported by the least common denominator frontend (a simple grid of monospace unicode characters).
Also:
I’m having a little trouble understanding what’s the point of this when
xi-editornvimviskakoune already exists:)
EDIT: Actually, with the Fuscia mentions in the Xi editor tickets, would it be more correct to assume that Xi’s goal is to replace Vim or to say it’s meant to replace GTK’s SourceView for some future UIKit?
Cheers, thanks for the discussion.
-
Thanks, that clarifies a lot.
Any new editor should have a story explaining why. I’d like to think that for xi I’ve made the case: an editor that feels like a modern GUI app and has uncompromising performance. At first, I thought the goals of xray were the same, but now I see more clearly that the focus is more on preserving the deep customizability that Electron affords.
The list of top plug-ins is helpful. I think xi will support some of these (and add UI elements to be controlled over RPC as needed), but not others. In particular, I’m not planning to allow the same level of UI customization. That said, part of the appeal is the front end is modular, so it’s possible people will go wild with, say, xi-electron.
For Fuchsia, the idea is the xi-editor is a text editing service provided system-wide, and that for Flutter apps on Fuchsia, the standard text editing widget is based on it.
-
I thought the goals of xray were the same, but now I see more clearly that the focus is more on preserving the deep customizability that Electron affords.
Full disclosure, I have nothing to do with this project outside of being interested, so I can’t speak to the motivations of the Atom team with regards to x-ray outside of educated guesses, but it feels right.
And I think your explanation is spot on, and works well for other editors: it seems really similar to the extensibility stories in nvim and sublime, which is a totally valid direction.
For Fuchsia, the idea is the xi-editor is a text editing service provided system-wide, and that for Flutter apps on Fuchsia, the standard text editing widget is based on it.
Badass! That’s pretty awesome, I wish you luck.
Cheers, friend
-
-
-
-
-
-
Great stuff! Glad to see the crossword tool Phil on there, I worked on it with Keiran during our batch.
-
Recently there’s been a lot of discussion of keyboard latency, as it is often much higher than reasonable. I’m interested in how much the self-built keyboard community is aware of the issue. Tristan Hume recently improved the latency of his keyboard from 30ms to 700µs.
-
-
-
-
The end-to-end latency on a modern machine is definitely noticeable (often in the 100s of ms). Many keyboards add ~50 ms alone, and shaving that off results in a much nicer UX. It is definitely noticeable comparing, say, an Apple 2e (~25ms end-to-end latency) to my machine (~170ms end-to-end latency, IIRC).
-
-
I recall reading about that. I’ll see about getting some measurements made, and see what it’s like on my Planck.
I’m interested in how much the self-built keyboard community is aware of the issue
I haven’t really seen much about it :/ If we could find an easy way of measuring latency without needing the RGB LEDs and camera, that would be good.
-
a simple trick - use a contact microphone (piezo), jack it into something like https://www.velleman.eu/products/view/?id=435532
-
-
-
I also commented in the HN thread but here will be a little more personal. The main thing I worked on in 2017 was taking xi editor from being promising to almost something you’d want to use for your daily work. I also took 3 months off to do a batch at Recurse Center, which was great fun (crossword authoring, loading data through the Apple 2 cassette port, and logic). I somehow managed to interleave that with working on the Rust infrastructure for Fuchsia, which might well be the work with the most lasting impact.
For 2018, I’m planning to focus more on xi (I realize that too much multitasking is one of my weaknesses), and think there’s a good chance we (the community and I) can make it something really good and really usable.
-
I’ve cast off most other distractions and am planning on implementing a fast text plane for xi-editor’s macOS front end, in OpenGL and Swift. It is inspired by both alacritty and WebRender, but I’m specializing it for the exact needs of text editing. I also hope to measure performance (latency, smoothness, and power) and write up the results. Based on my experiments so far, I expect it to be significantly better in performance than any other editor.
-
If only json had allowed trailing commas in lists and maps.
-
-
-
-
-
-
Things don’t have to be black and white, and they don’t even have to be specifically designed to be something. I can’t know what Douglas Crockford was thinking when he proposed JSON, but the fact is that since then it did become popular as a data interchange format. It means it was good enough and better than the alternatives at the time. And is still has its niche despite a wide choice of alternatives along the spectrum.
What I’m saying is that adding comments is not essential a sure-fire way to make it better. It’s a trade-off, with a glaring disadvantage of being backwards incompatible. Which warrants my “please no”.
-
-
-
http://hjson.org/ is handy for human-edited config files.
-
-
-
The solutions exist!
https://github.com/json5/json5
I don’t know why it’s not more popular, especially among go people.
There is also http://json-schema.org/
-
I had to do a bunch of message validation in a
node.jsapp a while ago. Although as Tim Bray says the spec’s pretty impenetrable and the various libraries inconsistent, once I’d got my head round JSON Schema and settled on ajv as a validator, it really helped out. Super easy to dynamically generate per message-type handler functions from the schema. -
-
-
I think this only show that JSON has chosen tradeoff that make it more geared to be edited by software, but has the advantage of being human editable/readable for debugging. JSON as config is not appropriate. There is so many more appropriate format (toml, yaml or even ini come to mind), why would you pick the one that doesn’t allows comments and nice sugar such as trailing commas or multiline string. I like how kubernetes does use YAML as its configuration files, but seems to work internally with JSON.
-
IMO YAML is not human-friendly, being whitespace-sensitive. TOML isn’t great for nesting entries.
Sad that JSON made an effort to be human-friendly but missed that last 5% that everyone wants. Now we have a dozen JSON supersets which add varying levels of complexity on top.
-
-
-
-
<delurk>
I’ve been experimenting (in the context of making a low-level windows front-end for xi-editor with making a desktop UI that sends layers to the compositor, rather than rendering complete frames. Based on my experiments so far, I’m encouraged that the performance (latency and smoothness) will be qualitatively better than anything else out there. I think performant desktop UI is something of a lost art, all the attention seems to be in other areas.
I’m a little uncertain how much public noise to make, or whether I should just crank on this on my own until it’s a usable client (might be a while, since I’m interleaving this with lots of other things).
-
I don’t think it’s totally lost, but I really only hear noise about it from the video games space, which has mostly settled on the immediate-mode model for UI. There are a handful of projects like imgui but I think it’s mostly hand-rolled.
Make at least a little noise; marketing doesn’t have to be all-or-nothing. And if you start small, you’ll mostly only attract early adopters happy with incomplete experiments while planting those “oh yeah, I’ve heard of xi, I should check that out” seeds.
-
Agreeing with “make a little noise while attracting early adopters”. Check out how @crazyloglad has been writing up his work on Arcan.
-
-
…or we can finally stop using C. ;)
I touched on this. It’s not practical at all, not because we have to write programs in C, but because we have to use C ABI as a glue layer between modules of any modern system. It’s interesting to explore whether it would be possible to design something better, but actually getting it adopted would be an extreme uphill battle.
In a recent project, where I needed Python interface with an OCaml library, I quickly assessed performance requirements and ended up passing data serialized in JSON. Maybe I’ll change it to a faster or more type safe serialization method in the future. Algebraic types can be encoded in Protobuf relatively nicely.
It does feel like a dirty hack at one level, but if none of those have to actually interface with logic written in C, I really don’t feel like downgrading the data structures to the point where C would undersand what it passed between them.
In that case, you write in something better that:
Uses C’s data types and calling conventions.
Seemlessly imports C libraries with zero-overhead calls due to No 1.
Optionally outputs C code for use with arbitrary compilers.
You get the benefits of the better language while plugging into and using the C ecosystem. Anyone wanting a language project should consider converting a popular one that’s a contender for C replacement in some scenarios to use 1-3 if it doesn’t already. Both re-implementing the interpreter/compiler/JIT and some automated tool to convert the library where the data types matter. The fork might even take off when the performance benefits kick in.
Oh, I agree… but the problem of Undefined Behaviour will not go away.
My favourite example is….
Suppose you write a routine to calculate the square root.
Now you break it up into two parts, and outer “safe” variant, that checks for negative arguments and raises an exception or returns an error code or something.
And an inner routine that assumes the argument is positive and just goes ahead and calculates the sqrt of a positive float.
Now your cow-orker (or yourself on a bad day) comes across this and says, Nah, my values are always positive, I’ll optimize a bit and just call the inner routine directly.
Except when they aren’t.
Weeeeeehah! Undefined Behaviour is back! And it doesn’t matter which language you chose!
There are languages where “positive number” can be encoded at the type system level and cause compilation errors. And it’s not just dependently typed languages. In Ada it is trivial for example.
And no doubt there are some form of cast where the programmer can say “shutup compiler, I know what I’m doing”….. even when I don’t! Even if the idiot has to print to a string and read it back. (Seen it before, the stupidity of humanity has no limit)