Yeah don't worry too much about it. You are still young, this is your first book. That is a great accomplishment.
Don't let the comments discourage you, use them, learn from them and your next undertaking will be even better. Be proud of what you did. It is unreasonable that your first attempt would be perfect.
I see, you thought I meant that C was the only language with this property. No there are plenty of others, I was fully aware of that. I on the other hand thought you meant that JOVIAL in some way was even thinner or more tuned to underlying architecture in some way that made it thinner than C.
I am curious, what was it I said that you consider to be a myth? If I have some misunderstanding I would like to know. I looked at JOVIAL on wikipedia quickly but I can't see exactly how it would be thinner than C or if it's compiler would output something vastly different to a C compiler. Or did you mean it's as thin as C but it came out earlier?
True, it doesn't give you the bare machine. What it gives you is the thinnest of machine abstraction with the possibility of linking to your own assembly if you have the demand for it.
This is, perhaps surprisingly, what I consider the strength of C. It doesn't hide the issues behind some language abstraction, you are in full control of what the machine does. The bug is right there in front of you if you are able to spot it (given it's not hiding away in some 3rd party library of course) which of course takes many years of practice but once you have your own best practices nailed down this doesn't happen as often as you might expect.
Also, code doesn't need to be bulletproof. When you design your program you also design a scope saying this program will only work given these conditions. Programs that misbehaves outside of your scope is actually totally fine.
First off, I want to congratulate you on reaching this milestone. I think this is the state where the most seasoned programmers end up. They know how to write code that works and they don't need a language to "help" or "guide" them.
If Linux previously always outperformed Windows the result should be similar this time around as well. It could possibly be some missing feature or a bug in the linux drivers but it sounds unlikely to me. I mean the architecture isn't fundamentally different. Maybe windows ignores some thermal throttling? Something smells fishy here for sure.
I just want to be a bit picky and say that bike shedding means focusing on trivial matters while ignoring or being oblivious to the complicated parts. What he described sounded more like a combination of feature creep/over-engineering.
A command-line tool called berk that is a versatile job dispatcher written in c. It is meant to replace big clunky tools like Jenkins, Ansible etc. It has syntax similar to git. It works pretty well, just need to iron out some kinks before final release. https://github.com/jezze/berk
Yeah I am not advocating creating a new seperate register, even though that would be nice. Like the poster below said, there are usually some unpreserved registers to choose from but if you for some reason cant spare a register you could instead write the error code to any virtual address instead, or send a signal, a message or anything else you could come up with. Just some way that does away with this intermix of return types and error types.
I think it would have been better if they had designed it so that the error message from the kernel came in a seperate register. That would mean you didnt have to use signed int for the return value. The issue is that one register now is sort of disambigious. It either returns the thing you want or the error but these are seperate types. If you had them in seperate registers you would have the natural type of the thing you are interested in without having to convert it. This would however force you to first check the value in the error register before using the value in the return register but that makes more sense to me than the opposite.
I have no experience of using it so I might be wrong but AMD has ROCm which has something called HIP that should be comparable to CUDA. I think it also has a way to automatically translate CUDA calls into HIP as well so it should work without the need to modify your code.
Sad to hear this since I think this was the lander containing the Moonhouse art project. I would have loved to see the little red cottage on the moon with the earth as it's backdrop.
I know it didn't exactly serve any scientific purpose but an image like that could have been very inspirational to a lot of people.
I would buy one but only if I am guaranteed to be able to compile the source code somewhat easily and flash it to the device. Anyone knows if they have made any promises around that?
I like that everything starts with a keyword, it makes the language feel consistant and I assume the parser is simple to understand because of it.
I like that you distinguish a procedure from a function in regards to side-effects and that you support both mutable and immutable types.
I like that you dont have to put a semicolon after each line but instead just use newline.
I like that you don't need parenthesis for ifs and whiles, however I am not sure I like the while syntax. Maybe I need to try it a bit before I can make up my mind.
On the other hand I think the type system could be expanded to support more types of different sizes. Especially if you are going for a systems programming language you want to be able to control that.
I think you could have a nil type because it is handy but it would be good if the language somehow made sure that any variable that could potentially be nil has to be explicitly checked before use.
I don't understand the immediate concern about using 32 bits for file creation and modification times. Its reasonable to assume that if the value has overflown and is very low that its not indicating a date from 1970. There is probably room to add a single bit indicating if the epoch is 1970 or 2038.
A linker typically only includes the parts of the library it needs for each binary so some parts will definately have many copies of the same code when you statically link but it will not make complete copies.
But I wouldnt consider this bloat. To me it is just a better seperation of concerns. To me bloat would be to have a system that has to keep track of all library dependencies instead, both from a packaging perspective but also in runtime. I think it depends where you are coming from. To me static linking is just cleaner. I dont care much for the extra memory it might use.