It’s true that the go-to feature is more general, that’s actually the problem. It’s what Dijkstra’s famous letter (“Go To Statement Considered Harmful”) is talking about.
With this generality it’s impossible to work efficiently at a higher level. As a result modern languages (even from the 1980s) tend to either neuter this feature or eliminate it entirely. In C or C++ a remnant remains, a goto statement which can be used locally within limits (and then the longjmp function to go-to a pre-determined further away point in the program, now with even more stringent limits and likely Undefined Behaviour) but the full throated go-to feature is not present. In a language like Java, Rust or Python there isn’t even the neutered goto statement.
Abstractions allow us to handle much more complicated systems, without needing to care in great detail all the time about the finer details, and something like a go-to feature interferes badly with that capability, it’s not worth it for these larger systems.
It isn’t true that the go-to feature is necessary, that same Dijkstra letter explains that it was already known how to write the same programs without Go To, it’s just that in some cases such a transformation wouldn’t aid clarity.
I think that nearly every programming language refuses to reuse default libraries is a bad thing. So imho it’s good if a language supports calling C libs. That ability unfortunately doesn’t keep programmers from re-inventing the wheel again and again. Look at Python. I mean, Python is a nice language, but the way they re-implement every little thing a second, third and sometimes fourth time is bad.
OOP allows plugging in various override calls. Just making it system-specific or trying to enforce every API has a façade (Is that how it’s spelled?) to keep the syntax friendly to the application developers is a difficult task.
Oh and of course, when needing a configuration language, scripts are the way.
I personally think, interpreted languages are trash, but I try to be no longer that negative, because every programming language has its advantages, even when I grumble about it.
What makes you say that? Java is very different to C#. I would say the syntax of C# is closer to C++, and the features of the language are closer to traditional C++ also.
namespace X
{
class x : y
{
public:
void someFunction();
}
...
void x::someFunction() {} // body is normally not inline
namespace X
{
class x : y
{
public SomeFunction() {} // body is inline
}
}
package X;
class x extends y
{
public someFunction() {} // body is inline
}
But honestly, they are all pretty similar. C++17 just went off on a wild tangent.
I do C/C++ and C# on a daily basis. I have not touched Java in years, and I opted to use Xamarin for the Android dev we are doing because Kotlin is a pointless extra diversion for us.
Sure, but that is a little different to the reality of anything outside of Web and Desktop development really. Embedded still uses C99. We still have hardware with ram measured in KiB and flash in MiB. You need to be able to actually code to make use of stuff like that. Even talking to those devices, the code needs to be able to speak in terms of bits and bit packed bytes to fully utilise every single part of the hardware effectively. Bare metal embedded is hard.
I get that we are teaching the next generation that programming should be easy, but sadly it makes them completely inadequate.
I worked on such platforms with a few KiB of RAM. My job was writing a Java virtual machine that made our customer’s life quite a bit easier. With a JVM you could do crazy things such as defragmenting the RAM using the garbage collector, dynamically allocating space for thread stacks as needed, and also easily port a complex GUI application to completely different hardware for a diverse set of products that were developed over several years, using newer microcontrollers as they became available.
So, even in these conditions, sometimes having to use a low level language like C is more constraining than you’d think. It’s not always true, of course, some things had to be done in low level realtime code. For example on one of our platforms there was no LCD controller for the display, and instead we were driving it using DMA and timers to generate the correct signal from the framebuffer in RAM. That was quite difficult to get right, but the customer application was written in Java and fully isolated from that part of the code.
We could also provide quite useful tools to help analyzing the memory usage: reporting on the size of each class in RAM and of each function in ROM, in a nice GUI that made it easy to identify the biggest things to optimize first (that’s also possible for C code to some extent, but to manage memory you’ll have to use something a bit more high level than malloc(), or go the other direction and do everything with static allocations).
So, yes, having a good understanding of computer architecture is useful, but not everyone really needs to dig into such details in their everyday job.
I think having a good understanding of the language you code in is also essential, and this includes getting your head around how memory allocation works, and how to optimise memory and data. This is probably off topic, but the issue I see hiring new recruits these days is that they tend to not be able to code without hand holding. They need the IDE to tell them where syntax errors are, suggest what they will type next and basically try to make them not have to think or know what they are doing. We struggle to find good people recently becaye you ask them pretty straight forward questions and they stare blankly back at you…
What does the program print?
If we add : uint8_t v5;
to the struct, what does the program print?
If we change the pragma to #pragma pack (2), what does the program print?
Very rare anyone knows the correct answer past the first question, but those that try to work it out are also pretty rare. Most just pass.
Well it depends how you introduce this in an interview.
You are asking questions about #pragma pack (1) which is a nonstandard gcc extension. What do you expect as an answer? People who have read the whole gcc documentation? Or are they allowed to search the documentation during the interview or ask the interviewer about it? That would make the question a lot more interesting and likely more people will manage to get somewhere with it.
Unfortunately in interviews I don’t get “I don’t know but I would search the documentation” as an answer often enough.
It is also supported under MSVC++ so, as far as we are concerned, it is pretty much standard for our toolset. It also appears to work with Clang, so… yeah. It’s just sets the padding for aligning the bytes in the struct. So, you would get 8, for the first example, 9 for the second and 10 for the third. You would also get 8 if it was set to pack (2) in the first. By default Windows uses 8 byte alignment I believe, so it is pretty costly.
You can test it yourself on various compilers at godbolt.org (edit: though some of the compilers don’t appear to pipe the output to the virtual console… gcc does, clang does and so does ICX, a lot of others compile it without errors, including the MSVC he has hooked up. )… here is the full source:
Every new framework that comes out means you have to start learning all over again. Can we just stop, please? These frameworks have gotten too easy to write and too hard to learn every new nuance. I’m at least happy Java is going down.
