Language preferences and safety features aside, I for one am 100% convinced that a/the upcoming language to rule "systems programming" (in a FOSS world with community participation) MUST have strong support for dynamic linking. If you look at something like `apt-cache show podman | grep ^Built-Using:` (Output: https://paste.debian.net/plain/1225449 ) on Debian 11, you will see why. Imagine a few of those components s…
Writing New System Software
31–40 of 158 posts
Re: Writing New System Software
#32I think C++ is just fine. Memory management is not that hard anymore using smart pointers. I prefer that to java at any time of the night or day. Such an ugly verbose language. The buzz word laden stuff is actually quite bad. I have seen what could be rather simple systems be very unreliable and slow because of the many microservices all in their own container. Then if one is sensible enough to avoid that there is an…
This feels like Stockholm syndrome to me. 1. I’m amazed that you call Java ugly and verbose but recommend C++. Apart from files not needing to be classes in C++, they feel similarly verbose to me with C++ slightly winning on ugliness. 2. I basically don’t believe that memory management is not hard. The reason is that plenty of programs written in ‘modern’ or ‘safe’ C++ in the style you recommend continue to have plen…
I've always found java much much more verbose. here's e.g. hello world in javafx:
package helloworld;
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class HelloWorld extends Application {
public static void main(String[] args) {
launch(args);
}
@Override
public void start(Stage primaryStage) {
primaryStage.setTitle("Hello World!");
Button btn = new Button();
btn.setText("Say 'Hello World'");
btn.setOnAction(new EventHandler() {
@Override
public void handle(ActionEvent event) {
System.out.println("Hello World!");
}
});
StackPane root = new StackPane();
root.getChildren().add(btn);
primaryStage.setScene(new Scene(root, 300, 250));
primaryStage.show();
}
}
here's a Qt version: #include
int main(int argc, char** argv) {
QApplication app{argc, argv};
QPushButton button{"Say 'Hello World'"};
button.setWindowTitle("Hi");
QObject::connect(&button, &QPushButton::clicked, [] {
puts("Hello world !");
});
button.setMinimumSize({300, 250});
button.show();
return app.exec();
}
notice for instance creating an object just with {} ; just that saves me I don't know how many hundreds of keystrokes. Also no need to ever `new` anything, just name the types directly. No need to repeat types à la StackPane root = new StackPane();
C++ would just be StackPane root;
or maybe auto root = StackPane{foo, bar};
observer pattern can be much less braindead thanks to the early existence of templates, and let's not even talk about https://docs.oracle.com/javase/8/docs/api/java/util/function...Quoting stackoverflow:
https://stackoverflow.com/questions/18400210/java-8-where-is-trifunction-and-kin-in-java-util-function-or-what-is-the-alt
> There are ready to use Consumer3..Consumer8, Function3..Function8, Predicate3..Predicate8 in reactor.function package of Reactor Addons library that is bundled with Spring Framework.like, come on...
same for Optional which gets some unrelated custom OptionalInt because there was no value type and adds boilerplate for nothing.
Re: Writing New System Software
#33If you're good at C or C++ why use another language you don't have deep knowledge of just to say I didn't write it on a language I know.
Re: Writing New System Software
#34Language preferences and safety features aside, I for one am 100% convinced that a/the upcoming language to rule "systems programming" (in a FOSS world with community participation) MUST have strong support for dynamic linking. If you look at something like `apt-cache show podman | grep ^Built-Using:` (Output: https://paste.debian.net/plain/1225449 ) on Debian 11, you will see why. Imagine a few of those components s…
How does having strong support for dynamic linking prevent someone from copypasting insecure code or just linking statically with your .so? Dynamic linking just makes deployment and compatibility a pain for some very dubious advantages
It doesn't. But it gives people a real alternative to doing what you describe! And only when a real alternative to something bad exists, one can reasonably demand that people stop doing the bad thing (Debian does, so does Fedora and a few other distros I believe).
Re: Writing New System Software
#35Sure, it is not as "complete" as standard libraries in Python, Go, etc. It is rather a different kind of beast than those standard libraries, not as high-level, more building blocks oriented.
Re: Writing New System Software
#36I tend to disagree. (Modern) C++ is an incredibly powerful programming language. Contrary to some other languages it gives the developer maximal freedom and does not impose a particular way of doing things on the developer.
In theory, yes. In practice few people use C++ fully, too often you find in-house "style-guides" vetoing specific things, such as Google's famous "no exceptions". At the point you rule out using available facilities of the language you might as well use something else.
If I recall correctly, Google's rationale regarding exceptions is that their legacy code is not exception-safe, and so they were faced with the choice of either rewriting critical parts of their legacy code to handle exceptions, or don't use them.
Also, their "no exceptions" rule only applied to work involving their legacy code.
I'm too lazy to find the source, but that bit of trivia was already discussed ad nauseum even in HN.
The morale of the story is that you should not mindlessly repeat any opinion without knowing the rationale and instead pulling appeals to authority to cover up the logical hole. That's how you end up contradicting even your source, just because you believed that's how the cool kids do things.
Re: Writing New System Software
#37Re: Writing New System Software
#38Earlier quoted context omitted.
Ye I feel the author has no clue what he is talking about. "I can appreciate the “macho factor” of being able to write fast software in C or C++ (or even Objective-C), but most people aren’t going to be able to do that" I mean, C is probably the simplest tool to write fast software with, since there are so few hidden costs to know about. Like strdup does a malloc. What else? In C++ you have to know implementation det…
> I mean, C is probably the simplest tool to write fast software with The simplicity is the hard part. Fishing for compliments by "pretending" it's so trivial to you shows immaturity. The author definitely knows what he's talking about. Perhaps it's you who's doesn't?
Simpler in the amount of knowledge you need to have to write the fast program.
I mean just compare "C the programming language" with Stroustrup's "C++ the programming language". It took me years to understand even a fundamental thing as move semantics. When programming fast C++ you need to be able to see what is moved properly and optimized in the way you want. How classes are inlined into the code etc. What container do malloc on construction, what containers are cheap empty, and so on and on.
There is no such knowledge needed for C.
Re: Writing New System Software
#39It is not uncommon that older/senior developers hold an undeserved grudge against STL. STL was far from mature in the 90s, sometimes even rather bad (at least in Windows/Visual Studio). But that is simply not the case anymore. Modern STL is well-written and highly optimized IMHO. Sure, it is not as "complete" as standard libraries in Python, Go, etc. It is rather a different kind of beast than those standard librarie…
The whole team needs to care about secure code to turn on checked iteration in release builds, or write their own wrappers if portability to compilers without such support is a concern.
Re: Writing New System Software
#40There are multiple types of system software, and it wasn't specified which. If you're talking about Embedded or Kernel Systems, writing a layer that can efficiently and securely multiplex and abstract the hardware requires a much different set of tools than the rest of the system. Here I disagree with the author. Once you're no longer concerned with directly probing the hardware, it seems far more appropriate to worr…
Any language can have compiler extensions.
Heck we used to do it in BASIC.