Comments

[magic]

At least with Java it is impossible to have incorrect type casting. Most incorrect typecasts never even reach the compiler, since the strong typing allows the IDE "cntl-space" to avoid suggesting them. Any incorrect typecasts that cannot be detected at compile time will be trapped at runtime.

That's still lame. Are there really legitimate reasons to even permit downcasting an Animal to a Horse (only to find that it was a Camel after all)?
Surely sounds like at least a violation of the OO dogma.

Then an IDE or stacktrace leads to the cause of the problem

Stack traces lead to the cause of the problem as surely as call graphs show the full extent of control flow

[tggzzz]

At least with Java it is impossible to have incorrect type casting. Most incorrect typecasts never even reach the compiler, since the strong typing allows the IDE "cntl-space" to avoid suggesting them. Any incorrect typecasts that cannot be detected at compile time will be trapped at runtime.

That's still lame. Are there really legitimate reasons to even permit downcasting an Animal to a Horse (only to find that it was a Camel after all)?
Surely sounds like at least a violation of the OO dogma.

Before Java had generics, downcasting was unavoidable every time you pulled something from a container class. Unpleasing and unsatisfactory, and generics help in that use case

Nowadays the use cases are going to be far more restricted and containable (ho ho). Reflection and demarshalling are the obvious cases.

Then an IDE or stacktrace leads to the cause of the problem

Stack traces lead to the cause of the problem as surely as call graphs show the full extent of control flow

All you have to do is guess which of the many possible paths actually occurred this time Plus, of course, the call graph doesn't contain the offending data, whereas the stacktrace can be inspected to find it.

Good luck using a debugger on an arbitrary C stack trace, especially with -O3 etc

One of the better feature of the JVM is that it is permitted to cheat like crazy provided it isn't visible outside the JVM. That enables HotSpot "profile guided optimisations" to occur on the fly and without the application programmer being aware of whether or not it is happening. Think of HotSpot as being JIT on steroids, or data dependent peephole optimisations. I wonder if the latter will ever be practical with C 

[tggzzz]

<omitted points that I agree with>
I'm highly suspicious of people who use the term "syntactic sugar". They are usually people writing obtuse code, badly laid out on the page, which is easily screwed up by the odd misplaced bracket that is hard to count your way through and check. Syntax means little to a machine, but is means a HUGE amount to a developer trying to keep things clear.

In any sane language, wrong syntax leads to a compilation failure.

The counter example to your point is that too often people claim that new language features are a great advance, when all they manage to do is save a little typing. That's syntactic sugar. I think Java is tending to get to that stage with some of its newer language features.

OTOH different semantic structures mean you can express new concepts, and ways of solving problems, and ways of avoiding problems. Adding semantic structures to an existing language usually fails: it is better to either encapsulate the benefts in a library, or use a different language built around the concepts.

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

Those operations are foolproof in Java and impossible in C/C++, due to the crappy syntax and pre-processor.

Don't get me started on the modern fashion where indentation indicates nesting. Good luch pretty printing that!

[tggzzz]

I don't think it matters who created Rust, but the more languages they knew the better. The more languages the higher the probability they will extract the good bits and avoid the bad bits. That was very clearly demonstrated in Gosling's 1996 Java whitepaper.

If Rust was only a "simple safe subset" of C++, that would be a beneficial step. Rust adds extra novel capabilities on the form of ownership and non-mutability. That is absolutely vital with today's multicore processors and MCUs. C/C++ is painfully inadequate for those.

I never said it's simple and it isn't. Maybe simpler than C++ by the looks of it, but that's not saying much and it isn't worth much unless you are migrating from C++ rather than C. My recollection of reading their documentation and tutorials was "lots of language features, lots of jargon, lots of cryptic syntax" and you won't get far without being familiar with it all because the features are tangled with each other and widely used. Deciphering Rust code made me feel like I'm reading STL headers.

I haven't had occasion to use Rust, unfortunately.

Rust introduces new and valuable concepts and capabilities that should lead to good code well suited to modern machines. It is unsurprising that comes with new jargon and new syntax. Given the above caveat, the syntax and jargon doesn't strike me as any more challenging than equivalents in OOP languages, FSM languages, hardware description languages, statistics processing languages.

I'm happy if all the concepts have to be understood together, since that implies they are a coherant whole. The C++ alternative is an indiscriminate hodgepodge rammed together, leaving programmers to choose which subset they can use alongside the different subset used by other programmers.

Fundamentally new syntax is easy; you have to learn such every few years when a (worthwhile) new language comes along. New semantics are usually harder to get your head around.

The part about knowing other languages and extracting good bits from them is actually ironic, because what I forgot previously is that Rust designers were apparently ML fanboys too as the language borrows a bunch of syntax from there. ML has generics, but Rust chose templates and code generation as the answer to everything.

My impression is that it's at best a "sidegrade" from C. May fix some problems, will create others.

I've never bothered with ML or any of its many derivatives; they've never matched my objectives and constraints. I have no strong opinion about ML, either for or against.

In some senses yes it is a "sidegrade", e.g. still procedural (not OOP, FSM etc). In some senses no, e.g. built-in multiprocessing and memory safety.

Being a "sidegrade" is beneficial: it forces people into new (hopefully better) ways of thinking, rather than toddling along the the old way in an old language.

The potential attraction of Rust to me is it being easier and more reliable to produce efficient safer faster object code than with C/C++.

[tggzzz]

No idea.

I agree; you don't have any idea.

[aeberbach]

I worked (recently) with a guy who insisted on no comments because "code should be self documenting". Ignores the fact that months later when you come back to it, it is a lot quicker to read a succinct comment than to read the code and understand it in the context of everything it interacts with.

[coppice]

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

People are much too creative in misplacing bracket for that to catch a lot of errors.

[coppice]

I worked (recently) with a guy who insisted on no comments because "code should be self documenting". Ignores the fact that months later when you come back to it, it is a lot quicker to read a succinct comment than to read the code and understand it in the context of everything it interacts with.

On first release a good percentage of the comments don't say what the code does, due to poorly written comments, and things that changed during development. After 5 years of further development the comments and code are usually like elements of completely different projects. Comments aren't compiled, so there is no checking on their validity. If you are relying on comments, rather than using them to fill in gaps in understanding as a you read confusing bits of the code, you are not usually going to get very far.

A corollary which offers excellent results is something which got a lot of momentum in the late 80s, and faded away for political reasons. You use a tool to simulate what the product should do. You get the specifiers to work with the model, and find where its results agree and disagree with the model, and where the model has shown them their own thinking was woolly. You then correct the model to be in line with expectations. Rinse and repeat until everyone agree you have an accurate model. Now that model is a great document of the requirement. You develop production code, checking it against the model. When it agrees with the model there is an excellent chance it does exactly what it required.... as long as the model was thorough. I experienced things being handled in this way internally, but I am not aware of anyone ever signing off on a model like this as a specification between supplier and customer. As management realised they had a thorough, and near water tight, spec, they panicked at the lack of wiggle room, and insisted the formal spec between the two parties be the traditional woolly descriptive document.

[tggzzz]

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

People are much too creative in misplacing bracket for that to catch a lot of errors.

I don't think that can happen in Java. The nearest would be an omitted pair of brackets altering the intent, but overturning would reveal that as unwanted/unexpected indentation.

Parentheses are more problematic, with Java having marginally better syntax in that respect.

[tggzzz]

A corollary which offers excellent results is something which got a lot of momentum in the late 80s, and faded away for political reasons. You use a tool to simulate what the product should do. You get the specifiers to work with the model, and find where its results agree and disagree with the model, and where the model has shown them their own thinking was woolly. You then correct the model to be in line with expectations. Rinse and repeat until everyone agree you have an accurate model. Now that model is a great document of the requirement. You develop production code, checking it against the model. When it agrees with the model there is an excellent chance it does exactly what it required.... as long as the model was thorough. I experienced things being handled in this way internally, but I am not aware of anyone ever signing off on a model like this as a specification between supplier and customer. As management realised they had a thorough, and near water tight, spec, they panicked at the lack of wiggle room, and insisted the formal spec between the two parties be the traditional woolly descriptive document.

There are at least two technical concerns with that.

Firstly, as the saying goes, "all models are wrong, but some are useful". Without an accompanying set of comments about the model, the useless and incorrect attributes can become enshrined in the application.

Secondly, it is unlikely that any model will incorporate important aspects of the application's behaviour, e.g. ACID properties, high availability properties.

Yes, such things are also the downfall of overzealous belief in TDD.

[aeberbach]

The full-on model/test jig approach only works if time and budget are not your main concerns (or even a concern at all), and if comments can be poor, or things can change during development, that goes double for a model.

[coppice]

A corollary which offers excellent results is something which got a lot of momentum in the late 80s, and faded away for political reasons. You use a tool to simulate what the product should do. You get the specifiers to work with the model, and find where its results agree and disagree with the model, and where the model has shown them their own thinking was woolly. You then correct the model to be in line with expectations. Rinse and repeat until everyone agree you have an accurate model. Now that model is a great document of the requirement. You develop production code, checking it against the model. When it agrees with the model there is an excellent chance it does exactly what it required.... as long as the model was thorough. I experienced things being handled in this way internally, but I am not aware of anyone ever signing off on a model like this as a specification between supplier and customer. As management realised they had a thorough, and near water tight, spec, they panicked at the lack of wiggle room, and insisted the formal spec between the two parties be the traditional woolly descriptive document.

There are at least two technical concerns with that.

Firstly, as the saying goes, "all models are wrong, but some are useful". Without an accompanying set of comments about the model, the useless and incorrect attributes can become enshrined in the application.

Secondly, it is unlikely that any model will incorporate important aspects of the application's behaviour, e.g. ACID properties, high availability properties.

Yes, such things are also the downfall of overzealous belief in TDD.

I've been involved in projects where model driven specification was used and they are the only things I've ever done where the spec really tied things down at all well. Its not perfect, but its far ahead of anything else I've seen close up.

TDD is such a stupid concept. If you aren't testing extensively as you build things, for a variety of reasons, you are a moron, and if you think testing as you go is a profound new paradigm you are also a moron. The software business is a religion, constantly looking for its next guru to worship.

[coppice]

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

People are much too creative in misplacing bracket for that to catch a lot of errors.

I don't think that can happen in Java. The nearest would be an omitted pair of brackets altering the intent, but overturning would reveal that as unwanted/unexpected indentation.

Parentheses are more problematic, with Java having marginally better syntax in that respect.

What's the difference between parentheses and brackets? They are synonyms. Most modern languages use all three types in the ASCII character set.

[tggzzz]

A corollary which offers excellent results is something which got a lot of momentum in the late 80s, and faded away for political reasons. You use a tool to simulate what the product should do. You get the specifiers to work with the model, and find where its results agree and disagree with the model, and where the model has shown them their own thinking was woolly. You then correct the model to be in line with expectations. Rinse and repeat until everyone agree you have an accurate model. Now that model is a great document of the requirement. You develop production code, checking it against the model. When it agrees with the model there is an excellent chance it does exactly what it required.... as long as the model was thorough. I experienced things being handled in this way internally, but I am not aware of anyone ever signing off on a model like this as a specification between supplier and customer. As management realised they had a thorough, and near water tight, spec, they panicked at the lack of wiggle room, and insisted the formal spec between the two parties be the traditional woolly descriptive document.

There are at least two technical concerns with that.

Firstly, as the saying goes, "all models are wrong, but some are useful". Without an accompanying set of comments about the model, the useless and incorrect attributes can become enshrined in the application.

Secondly, it is unlikely that any model will incorporate important aspects of the application's behaviour, e.g. ACID properties, high availability properties.

Yes, such things are also the downfall of overzealous belief in TDD.

I've been involved in projects where model driven specification was used and they are the only things I've ever done where the spec really tied things down at all well. Its not perfect, but its far ahead of anything else I've seen close up.

TDD is such a stupid concept. If you aren't testing extensively as you build things, for a variety of reasons, you are a moron, and if you think testing as you go is a profound new paradigm you are also a moron. The software business is a religion, constantly looking for its next guru to worship.

Agreed.

There can be some places where TDD is beneficial, but they are limited to where the incremental functionality is directly related to the specification, and where there is a good specification. They fail completely for the <ugh> "non-functional requirements" </ugh> such as reliability, performance, availability, etc.

[tggzzz]

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

People are much too creative in misplacing bracket for that to catch a lot of errors.

I don't think that can happen in Java. The nearest would be an omitted pair of brackets altering the intent, but overturning would reveal that as unwanted/unexpected indentation.

Parentheses are more problematic, with Java having marginally better syntax in that respect.

What's the difference between parentheses and brackets? They are synonyms. Most modern languages use all three types in the ASCII character set.

(parentheses)
[brackets]
{braces}
https://practicaltypography.com/parentheses-brackets-and-braces.html

However there are different terms in English and American English, and some parts of the computer industry habitually use terminology lazily
https://en.wikipedia.org/wiki/Bracket

(And we'll skip over that I confused brackets and braces )

[coppice]

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

People are much too creative in misplacing bracket for that to catch a lot of errors.

I don't think that can happen in Java. The nearest would be an omitted pair of brackets altering the intent, but overturning would reveal that as unwanted/unexpected indentation.

Parentheses are more problematic, with Java having marginally better syntax in that respect.

What's the difference between parentheses and brackets? They are synonyms. Most modern languages use all three types in the ASCII character set.

(parentheses)
[brackets]
{braces}
https://practicaltypography.com/parentheses-brackets-and-braces.html

However there are different terms in English and American English, and some parts of the computer industry habitually use terminology lazily
https://en.wikipedia.org/wiki/Bracket

(And we'll skip over that I confused brackets and braces )

You can find some partisan somewhere on the internet to support pretty much any position. I can counter with https://shahadmahmud.medium.com/checking-parentheses-balance-using-stack-ce939faca1c3 after just 10s searching with Google.

[Siwastaja]

I worked (recently) with a guy who insisted on no comments because "code should be self documenting".

This is not a joke - it is mostly true. The opposite point is, if you need a lot of comments sprinkled everywhere, that's a super alarming red flag of the code quality. You only need a few comments describing some oddities that couldn't be avoided, plus actual documentation of the big picture and intent of the module / strategies used - this documentation can be in form of comments.

But most of the code will and must be self-documenting. That's why we have variable names, many different loop constructs, functions, data structures, enumerations, and so on. The information goes there. Then the information is always in the same format; it adhering to standard is easy to check; it's formal. Sprinkling comments that describe what the code does is just duplicated information, is not enforced to be formal, cannot be automatically tested / regression tested like code can, and needs to be manually synchronized to match with the code.

If, by comments, you meant the "bigger picture" thing, then I apologize. But usually I hear ridiculing the "self-documenting code" from people who expect to see a lot of trivial comments to describe what an obfuscated piece of code does, ridiculous stuff like using weird, abbreviated variable names then explaining in a comment what the variable really is about.

Self-documenting code is the correct approach. It may need supplementation from comments and separate documents, but it should be the baseline, always.

[tggzzz]

As for misplaced brackets, that doesn't occur with Java. All you have to do is invoke the IDE's "pretty print" operation (on code that compiles), and misplaced brackets are instantly visible in the indentation. Java also allows you to highlight a block of code, and invoke "convert to method"; the IDE automatically refactors the code, pulling out any method arguments that are required.

People are much too creative in misplacing bracket for that to catch a lot of errors.

I don't think that can happen in Java. The nearest would be an omitted pair of brackets altering the intent, but overturning would reveal that as unwanted/unexpected indentation.

Parentheses are more problematic, with Java having marginally better syntax in that respect.

What's the difference between parentheses and brackets? They are synonyms. Most modern languages use all three types in the ASCII character set.

(parentheses)
[brackets]
{braces}
https://practicaltypography.com/parentheses-brackets-and-braces.html

However there are different terms in English and American English, and some parts of the computer industry habitually use terminology lazily
https://en.wikipedia.org/wiki/Bracket

(And we'll skip over that I confused brackets and braces )

You can find some partisan somewhere on the internet to support pretty much any position. I can counter with https://shahadmahmud.medium.com/checking-parentheses-balance-using-stack-ce939faca1c3 after just 10s searching with Google.

Well, you have demonstrated that, which isn't a difficult task. 

So let's refer to an authoratative paper dictionary, the Websters New International Dictionary (Unabridged). If you have another authoratative paper dictionary, let's see its definitions

The entry for "parenthesis" is short and to the point; see meaning 2a and 2b. (Plus meaning 2c shows "brace")



The entry for "bracket" (unsurprisingly) much much longer, so I haven't shown it all; see meaning 4a and 4b

[aeberbach]

Self-documenting code is a good aim, but a blanket ban on any and all comments is blanket wrong.

[Siwastaja]

a blanket ban on any and all comments is blanket wrong.

I don't think anyone has seriously suggested doing that.

[Picuino]

Reddit meme.

[magic]

An actual programmer would write "90% of all comments" and that would be clear enough for the audience.

It looks like my tech-illiterate father's jokes about computers

[SiliconWizard]

Just about brackets - the term alone is ambiguous, at least in programming, it's more like a category of symbols than a particular pair.
The usual (although i'm sure some would find something to say) naming in english is:
- Square brackets: [ ]
- Angled brackets: < >

As for the braces, { }, they are usually called "curly braces". And for parentheses, ( ), I don't think it's too confusing. Normally.

[tggzzz]

Humpty Dumpty had a small speech about words and their meanings

[Nominal Animal]

- Angled brackets: < >

Unicode Miscellaneous Technical block contains 〈 (U+2329 left-pointing angle bracket) and 〉 (U+232A right-pointing angle bracket).  It's the section that also contains stackable (vertically, in different rows) forms:
  ⎛ ⎞ ⎡ ⎤ ⎧ ⎫ ⌠ ⎲ ⎰ ⎱
  ⎜ ⎟ ⎢ ⎥ ⎨ ⎬ ⎮ ⎳ ⎱ ⎰
  ⎝ ⎠ ⎣ ⎦ ⎩ ⎭ ⌡
as well as some useful button characters:
  ⏯ ⏸ ⏹ ⏺ ⏭ ⏮ ⏩ ⏪ ⏫ ⏬
Unicode Dingbats block does contain angle bracket ornaments in various thicknesses, too: ❬ ❭ ❮ ❯ ❰ ❱.
Unicode Miscellaneous Mathematical Symbols-A block contains ⟨ ⟩ ⟪ ⟫, and ⟦⟧ as Mathematical white square brackets, and ⟮ ⟯ as flattened parentheses.
Unicode Miscellaneous Mathematical Symbols-B block contains ⧼ ⧽ as curved angle brackets.
Unicode CJK Symbols and Punctuation has its own 〈 〉《 》.
The Basic Latin block (ASCII-compatible subset) has < (less-than) and > (greater-than), calls ( and ) parentheses, [ and ] square brackets, and { and } curly brackets.

(Note that wide ncurses (link against ncursesw) can use the above effectively even on terminals, pseudoterminals, and consoles, on Linux, Mac OS, BSDs; I'm only unsure about Windows and WSL, since traditionally Windows has required MS extensions to be used to read or write UTF-8 on the terminal console.  I do know PuTTY can handle those including colors and other ANSI escape codes in Windows when connecting to Linux/BSD/MacOS, if correct connection settings are used.)

I don't care much what people call each symbol or glyph (I'm fully aware of the differences), as long as they're consistent, and when asked, can refer to Unicode code points that correspond to what they mean, so I can use them in practice.


I've found Box Drawing and Block Elements Unicode blocks (list) extremely useful in code comments describing a table, graph, or simple curve, describing the behaviour of a function and why a specific approach was chosen in an intuitive manner, guiding any maintainer or code examiner a practical idea of what the code should accomplish.  These only really work with fixed-width (monospace) characters, and I wish there was a comment style, say //|, that told common editors to use a fixed-width font for the contents of that comment.  That would allow mixing normal text and such graphics in comments.  (I personally tend to use fixed-width fonts for source code myself.)

For math stuff, formulae and such, Arrows, Mathematical Operators, and Superscripts and Subscripts (and other related blocks) make it much easier to describe what a function or operation does in a mathematical manner.  For example, I believe "∑ A[i]·Cⁱ, 0 ≤ i ≤ n-1" is a better comment than say "A[0] + A[1]*C + A[1]*C**2 + ... + A[n-1]*C**(n-1)", because the former has less cognitive load than the latter.  Limiting oneself to Basic Latin, something like "sum(A[i]*C^i, i=0..n-1)" is a compromise, with less cognitive load to only those who are familiar with text-based Computer Algebra Systems that use a similar syntax.

Other Unicode blocks contain useful glyphs for drawing timing diagrams, etc. for electronics.

Because of this, while I only use Basic Latin Unicode block (i.e., printable ASCII plus newline plus Tab if already used in the sources) for the code itself (in C, C++, Python, Bash, etc.), I do like to use Unicode within comments, for the added expressibility.  This naturally means that I tend to use UTF-8 (without byte order mark, since it confuses pure-ASCII editors and utilities) for all my source code files.

(Using UTF-8 for source code, and non-ASCII characters only within comments, also means that you can write the correct form of peoples' names when needed.  I like being able to write "Bézier curve" and "Erdős–Szekeres conjecture, or happy ending problem" in a comment.)

Some like that, some dislike it, preferring to limit to Basic Latin ≃ ASCII, especially with C.  What grinds my gears is that browser developers have decided that UTF-8 is the only non-legacy character set, with the browser default character set having to be a legacy character set; i.e. that you should not be able to select UTF-8 as your default character set.  This means that if you open a file the browser considers a plain text file, and it contains aforementioned UTF-8 source code, the glyphs won't show up correctly by default; you have to fix or change the character encoding by hand for every new file displayed!
This annoys me to no end, because for the last two decades or so, all browser-displayable files (including plain text files like source code is) without an explicit browser-decipherable character encoding declared, have been in UTF-8.