"Design for Good Programmers" should be rewritten

[xgalaxy]

This whole section should be rewritten or removed. I don't think it paints the language in a good light and is divisive. 'Good' programmers vs 'Bad' programmers. What does that even mean. You can be a good programmer and still make mistakes. Should bad programmers not even attempt to use the language?

It sets a us vs them mentality that I don't think is very healthy. And I think its a bit of a mischaracterization of the intent of the language.

[LongBoolean]

Personally I don't have any problem with how it is currently worded.

You can be a good programmer and still make mistakes.

Correct, and that section states that as well.

Programmers do make mistakes and cause crashes, perhaps even serious ones,...

I can see how someone might take this as an "us vs them" kind of thing, but I don't really think that it is.
"Good Programmer" and "Bad Programmer" are not explicitly defined in this section. Someone could misinterpret what is being said and think that the section is saying "Bad Programmer" = "Java Programmer", but that is not what is being said at all. More like, it is the responsibility of the employer/project leader to decide who is and who is not a "Good Programmer"(for their team anyway) and this language is not going to make any assumptions about how you should be coding something. Well for the most part, jblow is not going to add something to the language just because people want it if he thinks it is a bad thing to add, but he isn't designing the language to enforce the use of a particular style, OOP, functional programming, TDD, and garbage collection, for example. (these things can all be added/enforced by the programmer if desired) In fact the language offers ways for the programmers to set up custom compiler errors, code generation, and code checking abilities to fit the unique style/programming methodologies that the project leader/employer requires. (If this section were to be redone I would add something to that effect)

[LongBoolean]

Also, the phrase:

if you don’t want idiots writing bad code for your project, then don’t hire any idiots

is pretty much a quote from jblow, iirc
Some might find this phrase insulting. Just know, that this phrase does not mean that if you don't like the jai language that you are an idiot.
The whole idea is that the language will not be designed to keep you from shooting yourself in the foot if doing so will limit the effectiveness of the tool when put into good hands. (Rubber bullets are less likely to kill/injure the hunter, but it will make it much harder to down a caribou for meat.)

[BSVino]

When I wrote that section I agreed with it, but today I don't think I do. I'd be happy to see a pull request if you want to take a stab at rewriting it.

[ghost]

I'm very interested in a 100% fully open source engine + compiler + language, so I'm looking forward to Jai, but yes that part really came off as off putting, it was really pretentious.

It didn't tell me much about the project itself, I think the whole section should just be removed. Ideally the language shouldn't have such arbitrary self imposed limitations, as far as to who can use it, and who cannot.

I feel like a better approach would be to just, assume that the language is for everyone who wants to do their best, without being constrained by the current existing tools.

If anything, anyone could be a good programmer, if the tools didn't make them go insane. If you wasted less time "learning", and more time actually doing, then the code quality would most likely increase.

Anyway is the engine still stuck on DirectX \ OpenGL \ Vulkan? I really don't want another API, I want a truly open source rendering backend. Rasterizer and all of that.

[ghost]

I'm a bit ignorant on the topic though, is Vulkan actually 100% open source? I'm trying to get informed, but I really would like the ability to customize, literally, everything, if possible.

I really want to throw myself into the deep end, I don't care how long it takes me. From my own personal experience, I've accomplished things I never ever thought I could, with no experience, but when I'm insistent enough, I always seem to prove other people wrong, it often proves that it is duable, given enough time and patience.

I don't know anything, but I do feel like I know what I'm looking for. It's difficult to explain.

[ErikWallstrom]

@RaTcHeT302 Yeah, Vulkan is probably as good as you can get. It does not depend on closed source drivers as much, which means you have much more control over everything. It is much more lower level compared to OpenGL.

[refi64]

Vulkan and OpenGL are essentially direct APIs to contact the graphics driver, so it being open or closed largely depends on the driver itself. Regardless, there's really no way to get cross-platform hardware-accelerated drawing from userspace without one of them.

[ghost]

Vulkan and OpenGL are essentially direct APIs to contact the graphics driver, so it being open or closed largely depends on the driver itself. Regardless, there's really no way to get cross-platform hardware-accelerated drawing from userspace without one of them.

I don't care too much about cross platform support, I would rather do one thing well and do it once, I can't support multiple platforms all on my own either way, and I still don't get why everything isn't cross platform by default either way, I feel like all source code should work on literally any platforms, even ones that don't exist. I'm not a fan of having to define specific sizes just for something as simple as an integer, but I don't know how any of this stuff really works, but I would love to see things like these standardized, but maybe it doesn't make sense? Sorry guys, I'm very ignorant on the topic.

From what I understood compiled code is mostly just really fancy math, but I guess an integer on Windows might have a different size than on Linux, depending on the implementation?

I would love true cross platform (if possible), right now it mostly feels like "cross platform", as in OS X, Linux and Windows.

[refi64]

I mean, we have a tiny bit of a standard in POSIX. The problem is just that different architectures and operating systems fundamentally handle a lot of things differently.

[ghost]

I mean, we have a tiny bit of a standard in POSIX. The problem is just that different architectures and operating systems fundamentally handle a lot of things differently.

Ah, ok.