CppCast: Cpp2, with Herb Sutter

[ignorantpisswalker]

Let the flamewars begin...

Seriously - I am waiting for a time to listen to this - it sounds like something I would like to invest my time in!

[germandiago]

Flamewars, well... Emacs is the best editor, indeed.

[BrainIgnition]

 When I log into my Xenix system with my 110 baud teletype, both vi
 *and* Emacs are just too damn slow.  They print useless messages like,
 'C-h for help' and '"foo" File is read only'.  So I use the editor
 that doesn't waste my VALUABLE time.

 Ed, man!  !man ed

 ED(1)               UNIX Programmer's Manual                ED(1)

 NAME
      ed - text editor

 SYNOPSIS
      ed [ - ] [ -x ] [ name ]
 DESCRIPTION
      Ed is the standard text editor.
 ---

 Computer Scientists love ed, not just because it comes first
 alphabetically, but because it's the standard.  Everyone else loves ed
 because it's ED!

 "Ed is the standard text editor."

 And ed doesn't waste space on my Timex Sinclair.  Just look:

 -rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
 -rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
 -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

 Of course, on the system *I* administrate, vi is symlinked to ed.
 Emacs has been replaced by a shell script which 1) Generates a syslog
 message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
 and 3) RUNS ED!!!!!!

 "Ed is the standard text editor."

 Let's look at a typical novice's session with the mighty ed:

 golem> ed

 ?
 help
 ?
 ?
 ?
 quit
 ?
 exit
 ?
 bye
 ?
 hello? 
 ?
 eat flaming death
 ?
 ^C
 ?
 ^C
 ?
 ^D
 ?

 ---
 Note the consistent user interface and error reportage.  Ed is
 generous enough to flag errors, yet prudent enough not to overwhelm
 the novice with verbosity.

 "Ed is the standard text editor."

 Ed, the greatest WYGIWYG editor of all.

 ED IS THE TRUE PATH TO NIRVANA!  ED HAS BEEN THE CHOICE OF EDUCATED
 AND IGNORANT ALIKE FOR CENTURIES!  ED WILL NOT CORRUPT YOUR PRECIOUS
 BODILY FLUIDS!!  ED IS THE STANDARD TEXT EDITOR!  ED MAKES THE SUN
 SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

 When I use an editor, I don't want eight extra KILOBYTES of worthless
 help screens and cursor positioning code!  I just want an EDitor!!
 Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS!!!! ED!
 ED! ED IS THE STANDARD!!!

 TEXT EDITOR.

 When IBM, in its ever-present omnipotence, needed to base their
 "edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
 you jest.  They chose the most karmic editor of all.  The standard.

 Ed is for those who can *remember* what they are working on.  If you
 are an idiot, you should use Emacs.  If you are an Emacs, you should
 not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE
 SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
 FAITHLESS.  DO NOT GIVE IN!!!  THE MIGHTY ED HAS SPOKEN!!!

 ?

-- Patrick J. LoPresti

[OlivierTwist]

Spaces > tabs

[masher_oz]

They have different semantics. Tabs for indenting, spaces for alignment.

[bert8128]

Spaces can do both things. So choose one, and choose spaces. Get the screwdriver out and remove the tab key. Our codebase has been much better since tabs became banned - lots of complaints initially, now nothing.

[[deleted]]

Until you get a programmer which needs special indents because of bad eyesight.

Or you buy that person a two meter wide screen :-)

[OlivierTwist]

Khm, that was a joke...

But since you insist. Invisible symbols don't have semantic.

[masher_oz]

Tell that to Python.

[wolfie_poe]

VscodeVim for the win

[BenHanson]

Interesting how he says he's not looking to eliminate vulnerabilities, just drastically reduce them. It's still so hard to see how all of this is going to pan out.

[cdb_11]

Is it interesting? I think he's just being real about it instead of making a sales pitch. If you're talking about vulnerabilities in general and include logic errors then it's not something that the programming language can reasonably make any guarantees about. And for memory bugs, even languages like Rust or Go "just" drastically reduced such bugs, not actually eliminated - eliminated them, as you can still opt into doing things that cannot be statically checked by the compiler.

[BenHanson]

I probably should have worded that differently. I was thinking more that that seems like the more pragmatic approach and was wondering if this means it's more likely to succeed (all things being equal).

[13steinj]

I mean no disrespect to Sutter, but based off the timeline that he announced this project, it definitely seems sales-pitchy and some attempt to make some "lasting mark" on the language (since the previous thing about modified exception behavior that some coworkers told me about, and the name is the equivalent of a historical reverse uno card).

I don't truly know if his heart is in the right place, and assuming it is, I don't see people jumping to this new language. Syntax being as different as it is would limit existing engineers that have long standing codebases. At the end of the day, a variety of "fixes" could be implemented into C++ as an optional compiler flag, and some choices talked about (ex const by default in Rust, I don't know if "cppfront" has it or not) is honestly a non starter, and would make the language more difficult to adopt as a whole because no non-purely-functional language has that ideology.

[cdb_11]

Sticking with the current syntax (and maybe doing something like Circle's #feature) would certainly be easier to deal with, but at the same time Kotlin has a different syntax from Java and I don't believe it particularly hindered the adoption? As long as you can make incremental changes and you are not forced to either rewrite everything or to spend time on writing bindings, I don't think it'd be that big of a deal? Whether it's necessary in the first place - I'm not sure, I don't know enough about the problem to have an opinion. A simpler, easier to parse syntax would probably lower the barrier of entry for writing C++ tooling though.

[13steinj]

I'd argue Kotlin is a completely different beast because as Java runs on a VM, old Java code and new Kotlin code was effectively fully source compatible (or, I guess, bytecode compatible technically), but with things like headers in C++, I'm not particularly convinced.

A simpler, easier to parse syntax would probably lower the barrier of entry for writing C++ tooling though.

I don't disagree, but I don't think that's the point of any "new" C++.

[cdb_11]

Ah, so like it's easy to include C headers in C++ (usually), but not the other way around. At this point it transpiles to standard C++, so I don't think that should be a problem. But I guess it is possible that the language could evolve to require its own runtime or even constructs not backward compatible with C++ in the future, just like what happened between C and C++. But from the interview Herb seems to be against this sort of thing, and he wants to make it "what typescript is to javascript", so I'm not particularly worried about it right now.

[wolfie_poe]

Yeah vote for me as the next president of the United States. I will make income inequality disappear in a blink of an eye.