11–20 of 131 posts
I am currently limiting myself to 500 lines of (particle engine) code while listening to visual artists talking about their workflow in UE5 or Houdini, and Odin+Raylib are lovely to work in. GingerBill has shouted out Go, but Odin doesn't particularly feel like a Go flavo(u)r.
Capitalizing method calls (`rl.InitWindow()`) seems to place the importance on the Method being called, but at first glance (ASP, or Go off the top of my head) it muddies the waters. If this isn't clear, consider that capitalizing ALL code would reduce clarity as all letter shapes are now essentially the same (a box).
I spend most of my time in c, c++, ruby, and javascript, but maybe I should try to do a personal project in Go (or Odin) for this reason alone.
As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being ca…
In Go it has a specific meaning: starting an identifier with a capital causes it to be exported for use in other packages. Identifiers with a starting lowercase char are package private.
Apologies if this is explaining what you already know...
> This is the polar opposite of Zig’s embracing of metaprogramming for as much as possible. I found this claim a bit strange. do people actually use metaprogramming in Zig a lot?
As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being ca…
The original UNIX folks really love lowercase. Executables are lowercase, most file names are lowercase, file extensions are, etc. That extends to C where DMR and Ken Thompson chose lowercase names for keywords, built-in types, and standard library functions. If I remember right, Thompson uses all lowercase in most of his communications too, so I suspect it comes from him. Or maybe it was a flex because the PDP-11 could do lowercase when some other early computers didn't support it at all?
The early Pascal compilers from Niklaus Wirth and friends appear to be all caps, probably because that's all the machines supported. The language itself generally isn't case sensitive. (I say "generally" because there are many flavors of Pascal.)
When Anders Hejlsberg created Turbo Pascal (which is also case-insensitve), he introduced a convention of lowercase for keywords what we now call PascalCase for function and type names and (judging by the Wikipedia article) a mixture of PascalCase and camelCase for variables.
Perhaps because Straustrup built on C but is a Dane like Hejlsberg, he picked a mix for C++: camelCase function and variable names with PascalCase type names.
These conventions then flowed down through time. Java was heavily inspired by C++ and takes the same convention. C# is another Hejlsberg creation and follows his preferences. JavaScript follows Java. (It must annoy Hejlsberg to no end that his third baby TypeScript breaks with his own convention.)
> This is the polar opposite of Zig’s embracing of metaprogramming for as much as possible. I found this claim a bit strange. do people actually use metaprogramming in Zig a lot?
IMO it's one of Zig's advantages over C (text substitution macros are both too powerful and not powerful enough). If you're using Zig without metaprogramming, you're leaving a useful (if advanced) tool on the table.
IMO AST Macros are an even bigger problem than text substitution. Debugging metaprogramming of any kind past a certain point of complexity is a royal pain in the ass (even in a Lisp, Forth or Prolog), but AST explorers are next to useless for complicated logic problems that involve needle in a haystack searches of side effects. If you're dealing with a large AoS of heterogeneous SoAs which influence each other to shuffle around, and most of the related code and the structures themselves are generated via AST macros, you better be really comfortable with assembly analysis and debugger scripting.
FWIW, another take on "C Alternative" is the D programming language: https://wiki.dlang.org/Tutorials Comparatively mature, there's even a freeware book which is quite good: http://www.ddili.org/ders/d.en/index.html
https://news.ycombinator.com/user?id=WalterBright
Zig is also worth mentioning, and pops up frequently.
Odin really hits the sweet spot for everything you would want from a language for the game dev and game-dev-adjacent space in terms of simplicity, convenience, and speed. I think a major design decision of the language that will make or break it for users is the fact that the language gives you common features instead of giving you the means of abstraction to make those features yourself. For example, instead of prep…
For anyone unfamiliar with Odin that might misinterpret this, Odin has structs and parametric polymorphism for those structs. What it does not have is operator overloading or methods (which also means no constructors or destructors). In this sense, its product types are like ocaml's, only without methods too. Odin is not object oriented.