5 ms·

Less is exponentially more (2012)

67 points by pieterr 4y ago

cma 4y ago
> At this point I asked myself a question: Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features? In the end I think c++11 did make things way better and less error prone than before, largely through new features.
- pencilguin 4y ago
  Yes. Programming in C++11 was an overwhelmingly better experience than before. C++14 is, additionally, much more fun. Coding C++17 is better than C++14, mainly for its destructured bindings and improved variadics. Coding C++20 is much better, again. chiefly because of Concepts, but co-routines will become increasingly important as library support surfaces. It has been a long time since I shipped a memory usage fault. Languages that promise to make those impossible are hyped now, but their promoters are "fighting the last war". What makes the difference today is productivity. C++ is still leading that charge. Hype notwithstanding, more people take up programming C++ professionally in any given week than the total paid to code Rust. Soon, many of those Rust coders will begin to jump ship for newer languages.
  - rhn_mk1 4y ago
    What makes you say that C++ is leading in productivity? I'm not seeing C++ web applications, or machine learning frameworks. From my own experience, managed languages are easier to write for as well, especially with the average C++ code base which barely touches upon C++14. If productivity is "the current war", then languages like Go, Python, Rust, Elixir, and TypeScript are definitely fighting it, and it's not clear to me that any has significant lead in anything but limited areas.
    - themoonisachees 4y ago
      Video games are overwhelmingly coded in c++. C# is now more and more popular because of unity, but most AAA games (and their engines) are still made in c++. Also consider the large amount of qt-based apps still running c++.
      - rhn_mk1 4y ago
        In the case of game engines, productivity is less important than performance. Most games use some scripting language on top of C++. I agree that C++ is somewhat productive through Qt, but then again Qt is just one area of many - and QML is an acknowledgement that JS can bring greater productivity than C++ within Qt.
        nottorp 4y ago
        >QML is an acknowledgement that JS can bring greater productivity than C++ within Qt. That's not what my friends who still do Qt jobs tell me. They consider it more of a hindrance because you're limited in what you can do. And it's buggy. But I guess if all you know is javascript...
        jcelerier 4y ago
        Having done lots of both QML and QWidgets there are many tasks for which I feel I'm more productive on the latter. There are also regular posts on the Qt mailing list asking for a complete c++ version of Qt Quick, and people who kinda implemented a similar thing in another library (QSkinny iirc?) Like, in c++, I just type approximately what I want, especially when writing glue code or creating a new api, and add compile-time checks & fix compiler errors until things build which is a super fast process ; with QML (or other less strict languages) it takes much more time in a slower edit-run cycle to write correct code. And this is mainly due to new c++ features: what would have taken fifty lines to define a static check for in c++03, 30 in c++11/14 with e.g. enable_if, takes at most a couple in c++20 with concepts
  - specialist 4y ago
    I accept your claims that modern C++ improves productivity. As well as joy. :) In your experience, are these improvements available to existing code bases, green field projects, or both?
    - pencilguin 4y ago
      In existing code bases, new subsystems can be fully modern. Old code can be modernized incrementally, e.g. replacing uses of naked pointers with smart pointers and then deleting destructor code, or replacing C-style for-loops with modern range-style for-loops or calls to standard algorithms, passing a lambda. Many class declarations can be eliminated by using lambdas inline. A sweep throughout a big codebase just modernizing one kind of thing may take only a few days. This typically results in deleting a great deal of code, and all the bugs in the deleted code evaporate. Deleting masses of code always feels great.
anon23anon 4y ago
So has Go still held true to this minimalist philosophy?
- doctor_eval 4y ago
  Well, I think so. I only became a Gopher about 5 years ago and the pace of change has actually been faster than I expected, but it always seems to be in the direction of simplification. Examples of things that made life easier since I started using Go are modules and go:embed. Of course, an exception is generics, which I haven’t yet had much to do with, and while it potentially scratches a personal itch of mine (I always felt that builtins like ‘append’ and ‘len’ were overly magical), I worry that it’s a complication. But only time will tell.
karmakaze 4y ago
This bit doesn't make sense to me: > Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. Go always had generics: slice, map, channel. Writing without those I also could not imagine working in. And if anyone's curious how instead of making Go, C++ could be refactored into a smaller cleaner language, see "Can C++ be 10x Simpler and Safer?"[0]. It even allows for a memory arena that's managed by gc. [0] https://news.ycombinator.com/item?id=33573456 https://news.ycombinator.com/item?id=33573456
- valenterry 4y ago
  > Go always had generics That's not what people understand when you say a language "has" generics though.
  - thomascgalvin 4y ago
    Sure, when a random programmer on the street says a language "has generics," we mean "generics that I can use to extend my data model," or something similar. But in this talk, we have one of the creators of the language saying "you don't actually need generics," when what he meant was "you only need the generics I gave you." Go has, from the very beginning, acknowledged the importance of generics, and offered them to users of the language. But, until fairly recently, Go didn't trust users to use generics in any but a few specific cases.
  - karmakaze 4y ago
    The example in the article was about having arrays of ints and the like.
deleted 4y ago
[deleted]
NeoTar 4y ago
> name: 'go'. you can invent reasons for this name but it has nice properties. it's short, easy to type. tools: goc, gol, goa. if there's an interactive debugger/interpreter it could just be called 'go'. the suffix is .go. I'm surprised that the ability to search easily didn't come into their consideration, given ... well, it's Google. I'm not a Go developer, so I have no idea of how big of a problem this is, but the fact that there is a commonly used second name 'GoLang' hints to me that this became a problem quickly.
- 4ad 4y ago
  I have been using Go since the day of the public release. Search has never been a problem for me. I have never used the term "golang" when searching anything Go-related online. People do it, but it's not required.
  - dosethree 4y ago
    If you are searching for jobs or something, "go" is not sufficient
    - 4ad 4y ago
      Yes and no. If you are searching for jobs on a job board website, then perhaps, but to be frank, while the technology used is an important criteria in selecting for a job, if someone advertises as hiring "golang developers" I would never want to work in that shop and I do not believe I am particularly unusual in my choice.
      - pocketarc 4y ago
        Why would you not? Just curious as to what the red flag is, as it’s not clear to me.
        rpigab 4y ago
        Because it sounds like goulag
hoosieree 4y ago
How can less be more? It's impossible. More is more. -Yngwie Malmsteen, C++ developer
- dspillett 4y ago
  > How can less be more? Just overload the < and > operators to make it so…
hoosieree 4y ago
> Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration. C++: minimize CPU cycles, maximize benefit to user. Go: minimize developer cycles, maximize benefit to employer.
- lupire 4y ago
  Most go software runs on employer's computer.

67 points by pieterr 4y ago

cma 4y ago

> At this point I asked myself a question: Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features? In the end I think c++11 did make things way better and less error prone than before, largely through new features.

pencilguin 4y ago
Yes. Programming in C++11 was an overwhelmingly better experience than before. C++14 is, additionally, much more fun. Coding C++17 is better than C++14, mainly for its destructured bindings and improved variadics. Coding C++20 is much better, again. chiefly because of Concepts, but co-routines will become increasingly important as library support surfaces. It has been a long time since I shipped a memory usage fault. Languages that promise to make those impossible are hyped now, but their promoters are "fighting the last war". What makes the difference today is productivity. C++ is still leading that charge. Hype notwithstanding, more people take up programming C++ professionally in any given week than the total paid to code Rust. Soon, many of those Rust coders will begin to jump ship for newer languages.
- rhn_mk1 4y ago
  What makes you say that C++ is leading in productivity? I'm not seeing C++ web applications, or machine learning frameworks. From my own experience, managed languages are easier to write for as well, especially with the average C++ code base which barely touches upon C++14. If productivity is "the current war", then languages like Go, Python, Rust, Elixir, and TypeScript are definitely fighting it, and it's not clear to me that any has significant lead in anything but limited areas.
  - themoonisachees 4y ago
    Video games are overwhelmingly coded in c++. C# is now more and more popular because of unity, but most AAA games (and their engines) are still made in c++. Also consider the large amount of qt-based apps still running c++.
    - rhn_mk1 4y ago
      In the case of game engines, productivity is less important than performance. Most games use some scripting language on top of C++. I agree that C++ is somewhat productive through Qt, but then again Qt is just one area of many - and QML is an acknowledgement that JS can bring greater productivity than C++ within Qt.
      - nottorp 4y ago
        >QML is an acknowledgement that JS can bring greater productivity than C++ within Qt. That's not what my friends who still do Qt jobs tell me. They consider it more of a hindrance because you're limited in what you can do. And it's buggy. But I guess if all you know is javascript...
      - jcelerier 4y ago
        Having done lots of both QML and QWidgets there are many tasks for which I feel I'm more productive on the latter. There are also regular posts on the Qt mailing list asking for a complete c++ version of Qt Quick, and people who kinda implemented a similar thing in another library (QSkinny iirc?) Like, in c++, I just type approximately what I want, especially when writing glue code or creating a new api, and add compile-time checks & fix compiler errors until things build which is a super fast process ; with QML (or other less strict languages) it takes much more time in a slower edit-run cycle to write correct code. And this is mainly due to new c++ features: what would have taken fifty lines to define a static check for in c++03, 30 in c++11/14 with e.g. enable_if, takes at most a couple in c++20 with concepts
- specialist 4y ago
  I accept your claims that modern C++ improves productivity. As well as joy. :) In your experience, are these improvements available to existing code bases, green field projects, or both?
  - pencilguin 4y ago
    In existing code bases, new subsystems can be fully modern. Old code can be modernized incrementally, e.g. replacing uses of naked pointers with smart pointers and then deleting destructor code, or replacing C-style for-loops with modern range-style for-loops or calls to standard algorithms, passing a lambda. Many class declarations can be eliminated by using lambdas inline. A sweep throughout a big codebase just modernizing one kind of thing may take only a few days. This typically results in deleting a great deal of code, and all the bugs in the deleted code evaporate. Deleting masses of code always feels great.

anon23anon 4y ago

So has Go still held true to this minimalist philosophy?

doctor_eval 4y ago
Well, I think so. I only became a Gopher about 5 years ago and the pace of change has actually been faster than I expected, but it always seems to be in the direction of simplification. Examples of things that made life easier since I started using Go are modules and go:embed. Of course, an exception is generics, which I haven’t yet had much to do with, and while it potentially scratches a personal itch of mine (I always felt that builtins like ‘append’ and ‘len’ were overly magical), I worry that it’s a complication. But only time will tell.

karmakaze 4y ago

This bit doesn't make sense to me: > Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. Go always had generics: slice, map, channel. Writing without those I also could not imagine working in. And if anyone's curious how instead of making Go, C++ could be refactored into a smaller cleaner language, see "Can C++ be 10x Simpler and Safer?"[0]. It even allows for a memory arena that's managed by gc. [0] https://news.ycombinator.com/item?id=33573456 https://news.ycombinator.com/item?id=33573456

valenterry 4y ago
> Go always had generics That's not what people understand when you say a language "has" generics though.
- thomascgalvin 4y ago
  Sure, when a random programmer on the street says a language "has generics," we mean "generics that I can use to extend my data model," or something similar. But in this talk, we have one of the creators of the language saying "you don't actually need generics," when what he meant was "you only need the generics I gave you." Go has, from the very beginning, acknowledged the importance of generics, and offered them to users of the language. But, until fairly recently, Go didn't trust users to use generics in any but a few specific cases.
- karmakaze 4y ago
  The example in the article was about having arrays of ints and the like.

deleted 4y ago

[deleted]

NeoTar 4y ago

> name: 'go'. you can invent reasons for this name but it has nice properties. it's short, easy to type. tools: goc, gol, goa. if there's an interactive debugger/interpreter it could just be called 'go'. the suffix is .go. I'm surprised that the ability to search easily didn't come into their consideration, given ... well, it's Google. I'm not a Go developer, so I have no idea of how big of a problem this is, but the fact that there is a commonly used second name 'GoLang' hints to me that this became a problem quickly.

4ad 4y ago
I have been using Go since the day of the public release. Search has never been a problem for me. I have never used the term "golang" when searching anything Go-related online. People do it, but it's not required.
- dosethree 4y ago
  If you are searching for jobs or something, "go" is not sufficient
  - 4ad 4y ago
    Yes and no. If you are searching for jobs on a job board website, then perhaps, but to be frank, while the technology used is an important criteria in selecting for a job, if someone advertises as hiring "golang developers" I would never want to work in that shop and I do not believe I am particularly unusual in my choice.
    - pocketarc 4y ago
      Why would you not? Just curious as to what the red flag is, as it’s not clear to me.
      - rpigab 4y ago
        Because it sounds like goulag

hoosieree 4y ago

How can less be more? It's impossible. More is more. -Yngwie Malmsteen, C++ developer

dspillett 4y ago
> How can less be more? Just overload the < and > operators to make it so…

hoosieree 4y ago

> Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration. C++: minimize CPU cycles, maximize benefit to user. Go: minimize developer cycles, maximize benefit to employer.

lupire 4y ago
Most go software runs on employer's computer.