Notices by Panicz Maciej Godek (paniczgodek@functional.cafe)

On various occasions, I think about C++.
I devoted a few years of my life developing a 3d engine in C++. I learned the language from Stroustrup's book ("The C++ Programming Language"). I also developed a Qt-like widget framework using boost::signals

Also, many examples from "The Game Programming Gems" were using C++, and even some of the chapters in those series were devoted to some specific language features (such as template metaprogramming)

But only after I decided to embed #Guile #Scheme into my engine - which resulted in rewriting the whole thing in pure C - I got enough perspective to criticize the language

I have a strong feeling that the popularity of C++ stems from three factors:
- convincing a lot of people that "C++ is a better C, so if you're using C, you can as well use C++"
- lack of critical thinking among most programmers
- the love of complexity among (usually inexperienced and naively enthusiastic) programmers

I started learning C++ around 2003 (so that was ISO/C++98), but - using macros and a GCC extension - I came up with my own range-based for loop:

#define for_every(ITERATOR, COLLECTION) \
for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \
ITERATOR != COLLECTION.end(); \
++ITERATOR)

I don't love the C programming language, but one thing it is fairly good at is modeling what the computer is going to do, and how the system is going to be organized (especially if you work with it at the level of object files)

C++ makes this so much harder, with all of its templates, overloading and name mangling. And its design methodology really is reminescent of a kid in a toy store pointing fingers at different toys and saying, "I want this! and that! oh this is so cool can I have it as well?"

There seems to be very little thought, and design thinking, in C++, on a very fundamental level. (And I liked how the recent drama-blog post pointed out Stroustrup's lack of experience)

But the worst thing, let me tell you, the worst thing, are all those proponents of C++ that you meet on the Internet, who have very little to no experience with anything else, and even their experience with C++ is somewhat miniscule (so that they don't even know about the existence of weird entities such as "r-value references"), and they appear every now and then to tell you how wrong you are in your criticism of C++, because it's the best single language ever invented, but somehow they are never able to refute your arguments

I met dozens of them

@lfa Overflow is something that happens during arithmetic operations. When I set 0x80 to a char variable (assuming it's at least 8-bit wide), that variable contains exactly this value: 0x80 (or bit pattern 0b10000000). There is no overflow.

The problem arises with the operator ==, which performs a widening conversion of the variable to the "int" type, because it treats that variable as a signed value (which is implementation-dependent, which is a problem on its own), and instead of treating it as 0x80, it treats it as 0xFF80 (on 16-bit platforms) or 0xFFFFFF80 (on 32-bit platforms), because this is how widening conversion with 2's complement number representation works.

@lfa I tested here https://www.onlinegdb.com/8ejcl5Le9A (gcc 11.4.0) and on clang 16.0.4, and only clang behaved sanely.

@lfa (but I trust that they both conform to the C language specification)

@lfa but I still don't get what this has to do with int overflow

@lfa what does int overflow have to do with that?

@lfa no it doesn't. It is implementation-dependent.

@lfa

char c = 0x80;
if (c == 0x80) {
puts("C is OK");
}
else {
puts("there's something wrong with C");
}

@lfa

other than that (and silent implicit conversions), C has its charm

Now, C++ - what an abomination!

There is an old Common Lisp style guide written by Peter Norvig and @kentpitman that can be found here:

https://www.norvig.com/luv-slides.pdf

It's generally well written, and it parallels Grice's maxims of communcation.

However, it provides some examples that I, coming from the Scheme world, find hard to accept.

In particular, it explicitly recommends writing

(if (numberp x) (cos x) nil)

instead of

(and (numberp x) (cos x))

backing it up with the more general recommendation to use "and" and "or" for boolean values only.

In my understanding, this recommendation comes from the attempt to mimick the usages of natural language.

I already gave some consideration to this question (again, contrasting Scheme with Common Lisp) in one of the Quora answers that I once wrote: https://www.quora.com/What-are-the-pros-and-cons-of-functional-programming-compared-to-imperative-programming/answer/Panicz-Godek

The bottom line is that while there are some valuable traits of natural languages that should definitely be considered with care and attention, programming languages have a potential of being *better* than natural languages in some regards - especially if we take their compositionality to extreme with all due seriousness.

I remember asking a question on comp.lang.scheme about a function like "find" which - instead of an element satisfying a "predicate", would return the value of that "predicate". Someone replied that I can use the SRFI-1's "any" "quantifier" for this, and then I thought: of course! because it's a generalization of the "or" connective!

In the same vein, SRFI-2, written by Oleg Kiselyov, provides the and-let*, which is pretty much like Haskell's "do" notation over the Maybe monad (for those of you who haskel). And while the name "and-let*" is indeed a terrible one (although admittedly it does indicate that it's a combination of the "and" operator with the "let*" operator), the operator itself is very useful.

I devised its improved variant, described in the SRFI-202 document, which also has a capability of destructuring, and of receiving multiple values, and I use it a lot.

I don't have too much hands-on experience with Common Lisp to say anything significant about its coding style, but I remember how awkward it felt when I was working through Norvig's PAIP that he had to use '((t . t)) to represent empty bindings, because the empty list in Common Lisp is indistinguishable from the false value - and how much more natural it felt when I could use '() to represent empty bindings and #f to represent the match failure

#PlottingScheme

There is a lot of excellent books about #Scheme and #Lisp - my favorite ones are Structure and Interpretation of Computer Programs and Paradigms of AI Programming.

The latter is a book that uses Common Lisp, and the presented programs are written with great style and taste.

When I was working through that book, I was translating some of the examples to Scheme. I was only a beginner, so I'd dare to say that I wrote fairly awkward Scheme at that time. It took me many years before I developed my current style of programming.

I was starting out with Guile (because I embedded it in the 3d games engine that I was developing at that time), and one of the greatest revelations was the discovery of the (ice-9 match) module, which contained the "match" macro that I later called the Wright-Cartwright-Shinn matcher, when I wrote SRFI-200.

I rediscovered SICP after I was already using Guile for some time. When I first encountered that book - a few years earlier - I only skimmed through some initial chapters and I thought to myself that I know that already and that the book may be interesing to beginners, but not to me. (Boy I was wrong.)

And in order to absorb the content of this book, I had to unlearn a lot of things that I have had already learned up to that point (mainly from the books about C and C++). The fact that the book didn't just pile more and more language features (hey Bjarne!), but instead carefully provided each new feature with the means of program analysis (such as the substitution model, or the environment model) was such a breakthrough. (And I find it very sad that maybe, like. 0.001% of programmers seem to understand that).

It is often said that even though SICP uses Scheme, it is not a book that teaches or promotes Scheme, but that it instead focuses on some fundamental concepts.

Yet, all the adaptations of the book to various different programming languages seem to fail at capturing the hallmark of SICP, namely - the metacircular evaluator. So instead of, say, presenting JavaScript evaluator in JavaScript, they build a Scheme interpreter in JavaScript - which kind of misses the point of metacircularity.

However - while I would claim that SICP actually promotes Scheme, it does not teach Scheme programming - and definitely not the "modern Scheme programming".

One thing that I consider awful about it, is overusing function aliases to car/cdr functions. I also don't like SICP's object-orientation.

(oops, character limit)

@nedbat

I think of a script as a program that only automates what would otherwise be manual interactions of a human operator with the computer (so it does not create any - or many - new layers of representations)

@technomancy

what about graphs?

@aw

@hergertme If you named it CheckGTK 4, you could possibly still get it on the hype bandwagon