A picture book written in C code

topspin

@Gąska said in A picture book written in C code:

And as Rust has shown, being close to the metal has nothing to do with it.

But backwards compatibility has everything to do with it.

Look at how long Python 3 struggled to get people on board with their "clean break", and all they reallly changed was making print a function.

Gąska

@topspin I've heard that some people simply lack the part of the brain responsible for understanding pointers.

Gąska

@topspin said in A picture book written in C code:

@Gąska said in A picture book written in C code:

And as Rust has shown, being close to the metal has nothing to do with it.

But backwards compatibility has everything to do with it.

Before ~2010, it was widely believed that it's impossible to make a low-level language that doesn't feel like walking over hot coals while wearing socks filled with even hotter coals. C++ was considered necessary evil. It feels nice to finally have a counterargument.

topspin

@Gąska It probably was until then. It always is until someone comes around and changes it. I guess a lot of the necessary type theory details are relatively new outside academic uses, and it is still super slow to compile.

Interestingly, Pascal was so fast to compile I didn't even realize it did that.

dfdub

@Gąska said in A picture book written in C code:

needlessly verbose

Well, they're kind of fixing that part, and linting tools that check the new core guidelines may help with the pitfalls in the future.

Gąska

@dfdub certainly - and these tools already do great work - but you'll never going to get rid of having to explicitly declare your destructor as virtual. Someone mentioned string interpolation - it's also never going to happen (format strings just don't read as nicely). Defining iterators will always be incredibly complicated, and the committee will never include the basic iterator adaptors (map, flatmap, filter, fold etc.) in the standard library because they'll never agree on the exact set and on the names. I can't imagine modern programming without iterator adaptors.

As @topspin mentioned, Rust takes advantage of many "recent" developments in theoretical computer science. But even without all that, it's just a much nicer language overall. It really doesn't take a genius to fix most of the great many shortcomings of C++. But the backward compatibility and the design by committee mean it can never be fixed. It can be (and has been) improved a lot, but it can never be truly fixed - it will never be on par with C# 6 or Java 8, not to mention newer, less stuck-in-enterprise-past languages.

PotatoEngineer

@Zecc said in A picture book written in C code:

Flashbacks to having delayed a college project for a couple of hours after having added a printf for debugging, where the format string had a %s which should have been a %d

My (least) favorite C-debugging-printf errors were when I forgot to add a newline to the end of my printfs, and the terminal I was working on would erase the current line before printing the prompt. So when you forgot the newline, the previous printed line seemed to be the last-line-before-crash, which made you look in the wrong place for the error.

HardwareGeek

@Gąska said in A picture book written in C code:

some people simply lack ~~the part of~~ the brain ~~responsible for understanding pointers~~.

FTFY

dfdub

@Gąska
You don't have to convince me that Rust is a well-designed language and more modern than C++. But that just doesn't mean C++ is antiquated and that it's impossible or even hard to write modern code in C++, which is the statement I originally replied to.

Yes, C++ doesn't have string interpolation, but since we have std::format now, that's basically just nitpicking. And I wouldn't be so sure that we won't get better syntax for writing functional-style code in the coming years - there's a lot of demand for that and pretty much everyone agrees that std::transform, std::remove_if et al. aren't good alternatives since chaining them makes your code completely unreadable. The only problem I see is that it might take a while until it's standardized.

Edit: Actually, ranges in C++20 (which I hadn't looked at before) seem to solve that problem as well, even if the syntax isn't the prettiest. See the example here: https://en.cppreference.com/w/cpp/ranges

topspin

@Gąska said in A picture book written in C code:

@dfdub certainly - and these tools already do great work - but you'll never going to get rid of having to explicitly declare your destructor as virtual.

There's a proposal for that. (No idea about the status, don't really know how to track those.

Someone mentioned string interpolation - it's also never going to happen (format strings just don't read as nicely).

Eh, I don't really need string interpolation, something like e.g. Python's format (without f-strings) is good enough and easily achievable. Really, anything is better than the unreadable mess that is iostreams.
If they tried to implement string interpolation, they'd make it absolutely generic and create crazy core-language features just to support that. Maybe if they ever get the meta-programming game far enough to build on that...

Defining iterators will always be incredibly complicated, and the committee will never include the basic iterator adaptors (map, flatmap, filter, fold etc.) in the standard library because they'll never agree on the exact set and on the names. I can't imagine modern programming without iterator adaptors.

Something like LINQ would be really nice and we're very far away from that. The upcoming ranges at least are supposed to greatly improve on this.

Not quite sure if you mean using iterators or actually defining them. The latter I did just recently and good lord is that a lot of boilerplate if you don't use Boost iterator facade. That took way too much time and language lawyering to even come close to getting it right.
A recent post on reddit talked about a C++ 20 version of iterator facade and compared to the insane boilerplate of doing it manually the result is actually quite compact, only defining the non-redundant parts.

About the names, it's kind of a running gag (in the "it's funny because it's true" sense) that C++ has the worst names for literally everything. From the very beginnings with vector for arrays to newer things like unordered_map for hash-maps. But the actual hash function is called std::hash.

As @topspin mentioned, Rust takes advantage of many "recent" developments in theoretical computer science. But even without all that, it's just a much nicer language overall. It really doesn't take a genius to fix most of the great many shortcomings of C++. But the backward compatibility and the design by committee mean it can never be fixed. It can be (and has been) improved a lot, but it can never be truly fixed - it will never be on par with C# 6 or Java 8, not to mention newer, less stuck-in-enterprise-past languages.

The committee spends a whole lot of time coming up with ever more complicated syntax for new features, but doesn't deem it worthy to have stupidly trivial functions in the standard like trimming a string. And no "just define it yourself, it's 3 lines" or "just use boost/some-other-library" is not an acceptable answer.
But hey, at least C++20 will finally get a contains function for maps/sets and a starts_with function for strings. Baby steps.

dkf

@topspin said in A picture book written in C code:

Look at how long Python 3 struggled to get people on board with their "clean break", and all they reallly changed was making print a function.

Migrating to print-as-a-function is simple; the language implementation slaps you round the face if you fuck it up. Migrating the changes to other standard library bits is trickier. Migrating the change of division semantics is truly horrible. That was a change that should have been strangled at birth, its head chopped off and displayed on a pike in a public square in a major city, and the person who proposed it frozen out of doing any language development anywhere ever.

topspin

@dkf but it made for a nicer language in the end.

cabrito

@dkf said in A picture book written in C code:

Migrating to print-as-a-function is simple; the language implementation slaps you round the face if you fuck it up. Migrating the changes to other standard library bits is trickier. Migrating the change of division semantics is truly horrible.

Because

a = b / c was meaning int division if both b and c were int, else float, so "oh, those should be int, and we want int division, so lets put '/'...", or "those should be float, we want float division, lets use '/'".
symbols has no fixed type in python, and is not idiomatic to check arguments types
so when a value expected to be int was really a float, or viceversa, things go boom.
Really, the old way was ambiguous semantic, and prone to errors; the py3 way is "be explicit" ie, 'you want int division', use '//', else use'/'.
The weakness in the old ways is why conversion to py3 is not immediate: you must explore the context to see what was the semantic intended in each case.

That was a change that should have been strangled at birth, its head chopped off and displayed on a pike in a public square in a major city, and the person who proposed it frozen out of doing any language development anywhere ever.

If in a piece of code is not immediate to decide between '/' and '//' you realistically don't know what division is correct. How would you expand / modify / re-use / test that code if you don't know the semantics ?

So the new style is objectively better, the old style was worse and the difficulty to upgrade the code was proportional to technical debt old code have in this respect

Benjamin Hall

@cabrito Personally, I found the old (2.X) way to be the abomination. Floating-point division is what I wanted (scientific code) 99.999999999+% of the time but most of the explicit division was by integer factors. Like 2. That bit me so many times....

Gąska

@topspin said in A picture book written in C code:

@dkf but it made for a nicer language in the end.

"What did it cost?" "Everything."

Parody

@Mason_Wheeler said in A picture book written in C code:

@Kamil-Podlesak said in A picture book written in C code:

Actually, even Pascal pointers are very, very hard to explain.

Not particularly. I don't recall anyone in my Pascal class in high school having much trouble with them. (What really messed with most folks was PRNGs, bit twiddling, and string manipulation.)

I don't think we used pointers in my high school Pascal class. By that point I'd already been writing programs in a bunch of languages, though. Also it was years ago so I barely remember what we did in it. :)

hungrier

@Gąska said in A picture book written in C code:

Speaking of mnemonics - has there ever been any scientific evidence that they actually make things easier to remember?

I don't know about scientific evidence, but anecdotally I still remember something I learned in graphic design class 15+ years ago thanks to an offensive mnemonic I came up with

e: ... and then when I actually tried remembering the words, I could only come up with three of them . But I never forgot the mnemonic!

Gąska

@hungrier I remember in college physics course, I was studying with a friend for a thermodynamics exam. We had trouble remembering some equations, so we tried to make up some mnemonics. One was for the ideal gas law, in the form of . We came up with something stupid for the left side (don't remember what), but even after a long time, we couldn't think of anything for the right side.

Finally we settled on "no kurwa T".

Benjamin Hall

@Gąska said in A picture book written in C code:

@hungrier I remember in college physics course, I was studying with a friend for a thermodynamics exam. We had trouble remembering some equations, so we tried to make up some mnemonics. One was for the ideal gas law, in the form of . We came up with something stupid for the left side (don't remember what), but even after a long time, we couldn't think of anything for the right side.

Finally we settled on "no kurwa T".

I've always used that as PV = nRT (lowercase p is momentum, not pressure, and using moles and the molar gas constant instead of the particle number and boltzmann gas constant), in which case you have puvh-nert.

Zecc

@Benjamin-Hall I've memorized the individual letters.

But, with some imagination, they spell the sound of someone passing gas.

HardwareGeek

@Zecc said in A picture book written in C code:

@Benjamin-Hall I've memorized the individual letters.

But, with some imagination, they spell the sound of someone passing gas.

Bad imagination! Spank! Spank!

topspin

@hungrier said in A picture book written in C code:

15+ years ago thanks to an offensive mnemonic I came up with

A pussy so tight no dick penetrates...

Yes, that OSI layer model certainly turned out useful to remember ... exactly 0 times.
(And I can never remember the session or transport parts anyway)

Gąska

@topspin actually, I think I'd find it useful that 1 time I was asked it on exam in college. I remember all layers but always mess up the order.

bobjanova

@Benjamin-Hall said in A picture book written in C code:

the uses for inheritance in modern code basically come down to [GUI stuff]

Everything else is better done with interfaces (if available) and/or composition

I dunno man, I still write a lot of abstract base classes for common functionality. (Insert joke about how my code isn't modern here.) There are a few environments where component- and composition-based architectures have really taken off - though even then you'll likely have base classes for 'things like this which have the same components and component relations' - but in most mainstream OO languages and applications it hasn't really.

dkf

@bobjanova said in A picture book written in C code:

There are a few environments where component- and composition-based architectures have really taken off - though even then you'll likely have base classes for 'things like this which have the same components and component relations' - but in most mainstream OO languages and applications it hasn't really.

Composition makes a ton of sense for user interfaces (you really want to build as much of those as possible out of visual metaphors that users already know) but is totally different for back-end code. For back-end code, the key things are often to do with understanding/controlling equality and ensuring that services are delegated to sensibly.

pie_flavor

@Byte9 said in A picture book written in C code:

It allows you to write high-level code

No.

slapout1

@Byte9 Constructive Criticism: The video needs to be re-recorded with a better microphone.