Live data from Hacker News

Bjarne Stroustrup Quotes

stroustrup.com

161–170 of 173 posts

Re: Bjarne Stroustrup Quotes

#161
post #102

“The problem with many professors is that their previous occupation was student” This one is one of the more impactful on our industry in my opinion. I have a “side gig” as an external examiner, which means that every half year I get to sit through examinations on topics that I know most of the students will never ever have to use. And that’s the best case for much of it, the worst case is all the stuff they’re going…

>And that’s the best case for much of it, the worst case is all the stuff they’re going to need to unlearn to actually become good programmers in a world where much of the academic programming that is taught today is the same I learned more than 20 years ago. Not commenting on the general picture of "student to professor without any industrial experience in the middle", just this point. At some point, you have to acq…

I don’t disagree that some of the CS education is fine. A lot of the algorithm/math curriculum is fine even though it’s very old. I’m talking more about the systems design, systems architecture and project management which is sorely outdated compared to what most of the students will meet in the real world.

It wasn’t when I stated, but in the 20 years since then, things have just evolved so much. Nobody really does OOP around here anymore. Parts of it, sure, but for the most parts functions live on their own and “classes” are now mainly used as state stores for variables, and that’s in languages that don’t have a real alternative to “state store” because people vastly prefer types that can’t have functions to protect themselves from bad habits. But fresh from CS hires come out expecting to build abstract classes that are inherited, and then they meet the culture shock, and sometimes some of them don’t even know you can write functions without putting them inside an object. They come out with the expectation that “agile good, waterfall bad” but modern project and contract management has long since realised that “pure agile” just doesn’t work unless you’re in a specified team in a massive tech company. Because in smaller companies nobody is going to sign a contract that’s based on agile promises, and anyone who uses Scrum by the Book has basically gone bankrupt because they got outcompeted by more adaptable ways of working. It’s not that modern things aren’t inspired by what came before, and there is even a lot of research and good books available on things like team-topologies and how to work as fast delivery teams, but it’s just not what’s being taught in traditional CS around here.

Re: Bjarne Stroustrup Quotes

#162
post #59

Earlier quoted context omitted.

> But after writing some real programs with other people I realized the idea that every codebase has its own DSL and languages is actually stupid, doesn't scale and hard to maintain. Code bases can use DSLs. DSLs should used judiciously. For example, if you need an LALR parser, you'd probably wouldn't code it all by hand, and you'd probably use a DSL. Just like we use libraries judiciously in many languages. (Well, w…

> Is this a problem when Haskell is used professionally by software engineering teams? Yes, large segments of Haskell culture love complex language features and wild abstractions. Unfortunately that mindset seeps into everyday code because key libraries depend on the complex features. The Simple Haskell movement ( https://www.simplehaskell.org/ ) tried to develop a pragmatic culture but it fizzled. Back when Simple H…

> it was fun watching advocates of complex, abstract Haskell argue against straightforward programming that normal developers can understand

I don't think that's what they were arguing against. I think they were arguing against equating straightforward programming with basic language features.

Re: Bjarne Stroustrup Quotes

#163
post #149
post #139

Earlier quoted context omitted.

If basketball is so hard, then how did Michael Jordan score so many points?

Also I pointed out an issue in my comment that C# got wrong, then fixed -- closures created in loops

I didnt say that C# is perfect

But it feels like there is at least order or two of magnitude of difference. Especially if you start comparing std libs.

Re: Bjarne Stroustrup Quotes

#164

Earlier quoted context omitted.

Thats very bad take. Concepts are above languages.

I would respectively beg to differ. Getting your hands dirty actively engaged in the practice of building software in multiple languages is needed to get good, diverse sets of experience around what works and why. Reading books or worse, opinions on HN, just isn’t sufficient to claim a robust and well-rounded resume.

Nowadays languages are huge enough to cover various paradigms and countless concepts

That should enough, right?

Re: Bjarne Stroustrup Quotes

#165
post #91

“C++ is a language, not a religion.” I swear Stroustrup said this at the beginning of his EE380 (CS Colloquium) talk at Stanford around 1986. At the time we (grad students) were all C programmers and we were sure that C was the best language evar, at least, better than Pascal, which was the language Stanford used for teaching back then. So we all wanted to see this person who had the temerity to claim that he had imp…

I disagree so, so strongly with this. C++ programmers are one of the most religious groups around, eclipsed only recently by the rust community. Try telling a C++ programmer RAII is not a good idea. I dare you. Or smart-pointers. Or that the STL is mostly-garbage.. Trying to honestly have these conversations is typically an exercise in starting a religious flame-war.

"Man annoyed no fish wants to have a debate about his position that being wet is evil. Convinced this makes him right by default"

Re: Bjarne Stroustrup Quotes

#166

Earlier quoted context omitted.

I mean, sure, Bjarne calls his proposed way forward "safety profiles". Most fundamentally, this completely misunderstands the nature of the problem. This is a technical change, but the most important problem C++ has is cultural. So, they're not even addressing the right problem. In his original talk about this Bjarne even repeatedly describes his approach as a "strategy" which practically begged someone to say "Cultu…

> but the most important problem C++ has is cultural That part, Bjarne and others have been working on for at least two decades I think. There's a lot of indoctrination/education about "staying safe" so to speak, through better coding practices, extended standard library facilities, static analysis and so forth. And from the little I can see, this is seeping into the C++ culture. > The many different kinds of "safety…

> I was under the (possibly wrong) impression that you have the binary of either safe or unsafe

No, that completely misunderstands what the unsafe keyword is for. Rust has some very strict rules to preserve safety and everybody has to obey those rules. However, in safe Rust you don't need to think about that - or even know what the rules are exactly - because the safe Rust subset always obeys the rules. In unsafe Rust you are responsible for upholding all the rules, which means you need to properly understand what the rules are and be careful to do your job properly, the same responsibility you have in every single line of C++.

Another way to think about it is that "unsafe" means "trust me, this is OK". You may find that a more helpful way to understand what unsafe blocks do, but the reason I don't prefer it is that people (including Herb and Bjarne) seem to imagine we're just "switching off" the safety rules, and that's not what happens in any way, semantically, syntactically or de facto. Suppose I have an group of three integers (indexes start at zero) let group = [1, 2, 3]; println!("{}", group[5]); -- that won't work, Rust will reject that because it's a bounds miss†. But if we replace that println! with println!("{}", unsafe { group[5] }); the Rust compiler doesn't shut up and let us do it, in fact it complains even more, in addition to saying we can't do an out-of-bounds access it also warns that this unsafe block is futile, unsafe doesn't make bounds misses magically OK.

† We can tell the Rust compiler we insist on seeing this through to the bitter end, it will emit the program, and then when this code executes there's a bounds miss and it panics. The default is to reject programs which always just panic when executed.

Re: Bjarne Stroustrup Quotes

#167
post #105

Earlier quoted context omitted.

Profiles will help on the domains where C++ is going to stay for a long time, like HPC, GPUs, game development, GCC/LLVM. However it is kind of late in domains where Rust, or other safer languages are already being used. They won't rewrite back into C++.

> domains where Rust ... [is] already being used The point is that Rust usage is still quite limited. This is a bit like C++ and D, two decades back; or perhaps even Scala and Java. The analogy isn't perfect, but the point is you had a language with a lot of potential usability-domain overlap which addressed some or many pain points and failures of the older, more popular language - but the older language embraced so…

D suffered from lack of focus, and company sponsoring, hence why it hardly mattered to C++ folks.

The domains that Java and .NET took away from C++ aren't coming back to C++, even if now they feel the pressure to have AOT and value types with better low level coding primitives.

Additionally Java and .NET applications that get rewritten, most likely will be in one of those C++ wannabe successors, even if C++ is part of the equation by using GCC/LLVM backends.

Re: Bjarne Stroustrup Quotes

#168
post #162

Earlier quoted context omitted.

> Is this a problem when Haskell is used professionally by software engineering teams? Yes, large segments of Haskell culture love complex language features and wild abstractions. Unfortunately that mindset seeps into everyday code because key libraries depend on the complex features. The Simple Haskell movement ( https://www.simplehaskell.org/ ) tried to develop a pragmatic culture but it fizzled. Back when Simple H…

> it was fun watching advocates of complex, abstract Haskell argue against straightforward programming that normal developers can understand I don't think that's what they were arguing against. I think they were arguing against equating straightforward programming with basic language features.

That's true, much of the technical discourse haggled over favorite language features. But that missed the much bigger point: If we use complex, abstract Haskell for practical apps, what are the consequences of alienating the vast majority of professional developers?

Unfortunately the answer is clear: Haskell's arcane reputation has solidified.

Re: Bjarne Stroustrup Quotes

#169
post #167

Earlier quoted context omitted.

> domains where Rust ... [is] already being used The point is that Rust usage is still quite limited. This is a bit like C++ and D, two decades back; or perhaps even Scala and Java. The analogy isn't perfect, but the point is you had a language with a lot of potential usability-domain overlap which addressed some or many pain points and failures of the older, more popular language - but the older language embraced so…

D suffered from lack of focus, and company sponsoring, hence why it hardly mattered to C++ folks. The domains that Java and .NET took away from C++ aren't coming back to C++, even if now they feel the pressure to have AOT and value types with better low level coding primitives. Additionally Java and .NET applications that get rewritten, most likely will be in one of those C++ wannabe successors, even if C++ is part o…

The thing is, that the "C++ successor language" sometimes ends up being C++ itself, a decade or two later.

As an example, take this question from 2008:

"How do I tokenize a string in C++?" https://stackoverflow.com/q/53849/1593077

A very popular, straightforward, and traditional-style answer to this question, , given early on, was:

  vector split(const char *str, char c = ' ') {
      std::vector result;
  
      do {
          const char *begin = str;
          while(*str != c && *str) { str++; }
          result.push_back(std::string(begin, str));
      } while (0 != *str++);
      return result;
  }
but a recent answer is:

   auto results = str | ranges::views::tokenize(" ",1);
which is in lazy-evaluated functional style, and doesn't even directly utilize the fugly standard C++ string class. This example is of course a bit simplistic (since the main change exhibited here is in the standard library), but the point is that the language has demonstrasted strong abilities to reconfigure how users tend to write code. But - perhaps I'm giving it more credit than it's due any this won't comen to pass.

Re: Bjarne Stroustrup Quotes

#170
post #152
post #20

I'll see you Bjarne Stroustrup, and raise you Alan Kay, "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind." https://en.wikiquote.org/wiki/Alan_Kay

A selective quotation which misses the point. "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind. The important thing here is that I have many of the same feelings about Smalltalk."

I did not know this, or forgot, thank you for saying! There's applause and laughter after the short version of the quote, so it struck a nerve, and not without reason.

There are comments on Smalltalk at various places in the talk, but after the quote, all he says is, ..."There is one really important thing about Smalltalk, and some of languages like it, that we should pay really really close attention to, but it has almost nothing to do with the syntax and accumulated superclass library," ....

Quote is here: https://www.youtube.com/watch?v=oKg1hTOQXoY&t=634s

Post reply on HN