4 ms·

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+

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 plenty of memory unsafety based bugs, crashes, and vulnerabilities. P.S. Most async systems try to keep things on a single thread. Their main purpose is allowing a higher level of parallelism than can be economically achieved with threads, and normal good async style is to have most things non-async and therefore single-threaded. On Linux, a lot of the purpose of the thread pool is doing system calls that are blocking. io_uring makes it less necessary but many people use kernels that are too old.

jcelerier 5y ago
> 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. 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<ActionEvent>() { @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 <QtWidgets> 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/package-summary.html 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.
- pjmlp 5y ago
  Lost with the times? Since Java 10, var root = new StackPane();
  - jcelerier 5y ago
    ah, my java projects only very recently could migrate past jdk8, good to know there's this now.
- KronisLV 5y ago
  You know, to be honest with you, i feel like both are pretty verbose. Admittedly, with modern Java, you can slightly shorten the code there, it becomes the following: package dev.kronis.jfxdemo; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class HelloApplication extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { primaryStage.setTitle("Hello World!"); var btn = new Button(); btn.setText("Say 'Hello World'"); btn.setOnAction(event -> System.out.println("Hello World!")); var root = new StackPane(); root.getChildren().add(btn); primaryStage.setScene(new Scene(root, 300, 250)); primaryStage.show(); } } That's now 26 lines and 765 characters. Well, more like 18 lines of actual code, since imports will almost never be written manually and my IDE collapses them by default, and 505 characters. For comparison, the code for Qt is 16 lines and 335 characters. To me, those differences are not significant enough for them to matter all that much. As for the whole TriFunction thing, i feel like most modern languages are bad in regards to handling functions and their parameters as well as their return values. The thing that i've found most annoying is having container/wrapper objects for function returns when you need to return more than one thing from a function, or alternatively have to pass in a mutable container object of sorts which muddies things (much like how on the DBMS side you have OUT parameters). In contrast, just look at how Go does things, you can return multiple values from any function! Here's hoping that Java and other languages keep improving in the future and we get more tasteful syntactic sugar to cut out the unimportant and menial boilerplate code. In the mean time, Kotlin is also decent, look at the following function syntax wise: override fun start(primaryStage: Stage) { primaryStage.title = "Hello World!" val btn = Button() btn.text = "Say 'Hello World'" btn.onAction = EventHandler { println("Hello World!") } val root = StackPane() root.children.add(btn) primaryStage.scene = Scene(root, 300.0, 250.0) primaryStage.show() } (purposefully excluded the @JvmStatic companion object here, since didn't bother much with the Java to Kotlin conversion, though IntelliJ IDEA is pretty good for that)
jstimpfle 5y ago
> 2. I basically don’t believe that memory management is not hard. If you try to write Java in C++ then probably the result is verbose. With some practice though, memory management needn't be hard - if memory management is hard that hints lack of organization. Smaller, script-like programs where there is no place for large-scale organization, are a different story (especially in C and C-like C++) and GC'ed languaged might be more convenient.
- dan-robertson 5y ago
  I think the evidence outweighs opinions, and I think the evidence says that it is hard to avoid memory management problems in C++.
  - FpUser 5y ago
    I do not have single explicit memory management call in my product of very decent size written in modern C++. So no , I have no idea where did you fish your "evidence" from.
    - dan-robertson 5y ago
      I don’t understand what you’re trying to say? Do you mean that you don’t call malloc? Because that is totally not the point. For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable. Nowhere do you need to call malloc or do any explicit memory management and yet you have a use-after-free bug. Some evidence can be found in my reply to the sibling comment which talks about chrome, a large and very well-tested C++ application mostly in a modern style. There are also surveys of security vulnerabilities that find a large percentage are due to incorrect memory management. Maybe I’m just missing the point though as I think I’m only writing obvious well-known things and you probably mean something more nuanced?
      - FpUser 5y ago

jcelerier 5y ago

> 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. 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<ActionEvent>() { @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 <QtWidgets> 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/package-summary.html 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.

pjmlp 5y ago
Lost with the times? Since Java 10, var root = new StackPane();
- jcelerier 5y ago
  ah, my java projects only very recently could migrate past jdk8, good to know there's this now.
KronisLV 5y ago
You know, to be honest with you, i feel like both are pretty verbose. Admittedly, with modern Java, you can slightly shorten the code there, it becomes the following: package dev.kronis.jfxdemo; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; public class HelloApplication extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { primaryStage.setTitle("Hello World!"); var btn = new Button(); btn.setText("Say 'Hello World'"); btn.setOnAction(event -> System.out.println("Hello World!")); var root = new StackPane(); root.getChildren().add(btn); primaryStage.setScene(new Scene(root, 300, 250)); primaryStage.show(); } } That's now 26 lines and 765 characters. Well, more like 18 lines of actual code, since imports will almost never be written manually and my IDE collapses them by default, and 505 characters. For comparison, the code for Qt is 16 lines and 335 characters. To me, those differences are not significant enough for them to matter all that much. As for the whole TriFunction thing, i feel like most modern languages are bad in regards to handling functions and their parameters as well as their return values. The thing that i've found most annoying is having container/wrapper objects for function returns when you need to return more than one thing from a function, or alternatively have to pass in a mutable container object of sorts which muddies things (much like how on the DBMS side you have OUT parameters). In contrast, just look at how Go does things, you can return multiple values from any function! Here's hoping that Java and other languages keep improving in the future and we get more tasteful syntactic sugar to cut out the unimportant and menial boilerplate code. In the mean time, Kotlin is also decent, look at the following function syntax wise: override fun start(primaryStage: Stage) { primaryStage.title = "Hello World!" val btn = Button() btn.text = "Say 'Hello World'" btn.onAction = EventHandler { println("Hello World!") } val root = StackPane() root.children.add(btn) primaryStage.scene = Scene(root, 300.0, 250.0) primaryStage.show() } (purposefully excluded the @JvmStatic companion object here, since didn't bother much with the Java to Kotlin conversion, though IntelliJ IDEA is pretty good for that)

jstimpfle 5y ago

> 2. I basically don’t believe that memory management is not hard. If you try to write Java in C++ then probably the result is verbose. With some practice though, memory management needn't be hard - if memory management is hard that hints lack of organization. Smaller, script-like programs where there is no place for large-scale organization, are a different story (especially in C and C-like C++) and GC'ed languaged might be more convenient.

dan-robertson 5y ago
I think the evidence outweighs opinions, and I think the evidence says that it is hard to avoid memory management problems in C++.
- FpUser 5y ago
  I do not have single explicit memory management call in my product of very decent size written in modern C++. So no , I have no idea where did you fish your "evidence" from.
  - dan-robertson 5y ago
    I don’t understand what you’re trying to say? Do you mean that you don’t call malloc? Because that is totally not the point. For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable. Nowhere do you need to call malloc or do any explicit memory management and yet you have a use-after-free bug. Some evidence can be found in my reply to the sibling comment which talks about chrome, a large and very well-tested C++ application mostly in a modern style. There are also surveys of security vulnerabilities that find a large percentage are due to incorrect memory management. Maybe I’m just missing the point though as I think I’m only writing obvious well-known things and you probably mean something more nuanced?
    - FpUser 5y ago