gingerBill quotes

There is zero influence from Haskell in Odin

discord

At the turn of 2016, I gave myself a New Year’s Resolution to start any new personal programming project in pure C to see what I really needed from a language. It turned out that I needed very little to be very productive. The friction from having to remember many of the features in C++ and other languages reduced my productivity a lot more than I realised.

https://www.gingerbill.org/article/2019/05/13/a-reply-to-the-road-to-zig/

The most important one is the degenerate state issue, where all values can degenerate to a single type. It appears that you and many others pretty much only want to know if there was an error value or not and then pass that up the stack, writing your code as if it was purely the happy path and then handling any error value. Contrasting with Go, Go a built-in concept of an error interface, and all error values degenerate to this interface. In practice from what I have seen of many Go programmers, most people just don’t handle error values and just pass them up the stack to a very high place and then pretty much handle any error state as they are all the same degenerate value: “error or not”. This is now equivalent to a fancy boolean.

https://www.gingerbill.org/article/2021/09/06/value-propagation-experiment-part-2/

A lot of the problems related to responsibility are better solved with forms of “subsystems” within programs which handle groups of “things” and give out handles of the “thing” instead of a direct reference. This is related to the approach many people use already to bypass the borrow checker through using indices/handles. Handles can contain a lot more information than a singular number. A common approach is to store a generation number alongside the index in the handle. If a generation has died, but the handle is asked to be used, the subsystem can give out a dummy sentinel value and report an error.

Other approaches are to reduce the need for responsibility in the first place. By keeping data structures POD, trivially copyable, and the zero value of it useful, can help you change the way you think about the problem at hand and simplify code. It places more emphasis on the data and algorithms themselves rather than the relationships between objects and types.

https://www.gingerbill.org/article/2020/06/21/the-ownership-semantics-flaw/

against the worship of (nasal) demons

🧵I want to clarify my position on "Undefined Behaviour" (UB) in programming languages and why @odinlang will not have any UB. It's a pretty simple position: the specification for the language will states who defines what, and then that thing defines it.

A language specification usually does two things: defines the syntax, semantics, and general functionality of a language, and the ranges/minimums/maximums of how a compiler can implemented for that language.

It is not possible to define everything in the main language, so that means that some behaviour must be either platform-defined behaviour (architecture and/or OS) or vendor-defined behaviour.

This means that there will effectively be "mini specs" (albeit implicit or explicit) about how Odin will run with the given platform or vendor.

Most (systems level) languages today do not do this and many compiler writers act like lawyers with "the spec doesn't say what can be done here, so that means anything can be done that is wanted, and write the compiler with any assumptions wanted".

There cannot be a systems level programming language that is consistent across all platforms but this does not defend the position that therefore you must have UB. It states that "mini specs" are needed for those platforms to define things further.

http://nitter.net/TheGingerBill/status/1495004577531367425

gB recommendations

• https://www.kenney.nl/ - royalty-free game assets

quotes that prove that gB is secretly a terrible person

• "[Python]'s my favorite scripting language." - discord