Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++: Is It Really a Cruel Joke? (2003)

webhome.phy.duke.edu

Post reply on HN
Print view View original

151–155 of 155 posts

Re: C++: Is It Really a Cruel Joke? (2003)

#151

Post by mlthoughts2018 »

Araq wrote: post #150
mlthoughts2018 wrote: post #148

Earlier quoted context omitted.

Briefly re: discard — since void is not a proper type like say Unit in Scala, it makes void functions (especially with type parameters) very awkward in general. Adding the additional confusion that you can treat a value-returning function as if it was a void function with discard, and it further destroys clarity of the meaning of types, encouraging developers to shoe-horn side-effectful computation into value-returni…

I'm not following you really. 'discard' is an enforced, explicit statement about that you throw away information/the result of a computation. That's against "nice if you are programming alone" as much as it can get.

Huh? What does it’s status as an explicit language construct have to do with the situations when it’s useful for design?

I’m saying when you program alone, you know when to use discard on your otherwise value-returning function. Other people don’t, and the use of the return type actually suggests the opposite. That you should intentionally invoke that proc for its return value.

> “That's against "nice if you are programming alone" as much as it can get.”

I don’t understand this claim. Nothing about the formal definition of a language is for or against being “nice if you program alone” — rather it is what patterns of usage does it encourage or facilitate.

It’s like “C++ without exceptions”. The formal implementation is just some factoid of the language, but the usage that arises around discard is a bad anti-pattern in terms of communicating intended usage and whether / when to rely on side-effects.

Re: C++: Is It Really a Cruel Joke? (2003)

#152

Post by Araq »

mlthoughts2018 wrote: post #151
Araq wrote: post #150

Earlier quoted context omitted.

I'm not following you really. 'discard' is an enforced, explicit statement about that you throw away information/the result of a computation. That's against "nice if you are programming alone" as much as it can get.

Huh? What does it’s status as an explicit language construct have to do with the situations when it’s useful for design? I’m saying when you program alone, you know when to use discard on your otherwise value-returning function. Other people don’t, and the use of the return type actually suggests the opposite. That you should intentionally invoke that proc for its return value. > “That's against "nice if you are prog…

I agree that 'discard' is usually a code smell, but how would implicitly ignoring the result be any better? It wouldn't be better at all, and that means Nim's discard feature is rather well designed as it improves the status quo.

Re: C++: Is It Really a Cruel Joke? (2003)

#153

Post by mlthoughts2018 »

Araq wrote: post #152
mlthoughts2018 wrote: post #151

Earlier quoted context omitted.

Huh? What does it’s status as an explicit language construct have to do with the situations when it’s useful for design? I’m saying when you program alone, you know when to use discard on your otherwise value-returning function. Other people don’t, and the use of the return type actually suggests the opposite. That you should intentionally invoke that proc for its return value. > “That's against "nice if you are prog…

I agree that 'discard' is usually a code smell, but how would implicitly ignoring the result be any better? It wouldn't be better at all, and that means Nim's discard feature is rather well designed as it improves the status quo.

Why is implicitly ignoring the result the option you’re comparing with? Instead, create language features that encourage you to separate side-effectful functions from value-returning ones.

Also many languages use a very standard convention of assigning underscore to parts of a result value to be ignored, and discard has no clear advantages over this in my mind.

Re: C++: Is It Really a Cruel Joke? (2003)

#154

Post by mwcampbell »

rwmj wrote: post #104
cogs wrote: post #45

I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..

I was involved with a large OCaml project with a GUI which was compiled on Windows and Linux. We didn't try macOS but it would probably have been possible to port it there too. For the GUI we used Gtk (with a Windows-flavoured theme on Windows). It was written with emacs, built using a bunch of Makefiles, and shipped as a native binary on both platforms, with an NSIS-based installer on Windows.

A warning for anyone thinking of doing their cross-platform GUI this way: GTK only supports accessibility tools (such as screen readers for blind users) on Unix (via AT-SPI), not Windows or macOS. I'd suggest using wxWidgets or Qt instead. Of course, both of those use C++ as their native language, so creating bindings to other languages isn't as easy as for something C-based like GTK.
Post reply on HN