What's your favorite language feature?

[tggzzz]

This is one of the reasons for using standardized languages only. You at least get some minimal consistency.

Like C/C++? Snort!

Or at least the "minimal" is too minimal to be trustworthy or of use.

[SilverSolder]

"Python 3.0, released in 2008, was a major revision of the language that is not completely backward-compatible, and much Python 2 code does not run unmodified on Python 3."

Just throw most existing code under the bus?!? Yessir, THAT's a "professionally managed platform" that I'd want to use as the basis for commercial projects. NOT.

Pretty much like Java which every 18 months comes out with a new revision that breaks all the existing code. This forces enterprise developers to include their own copy of Java in their product so it doesn't happen, but that has security vunl etc etc.   

DEATH TO JAVA

I'm so happy I managed to avoid "falling for" the Java hype originally.  I always thought it was too slow,  and I had already seen a similar approach fail in the past (the UCSD P-system).

[IDEngineer]

I'm so happy I managed to avoid "falling for" the Java hype originally.

I managed to avoid it until I had to write code for the Android platform. Tablets make incredibly convenient control panels for all sorts of things, and (at the time, maybe still) Apple would not give you access to the communication port without a license that I seem to recall cost $25K. Plus Android tablets use standard USB which was a big plus. So I started working with Java to write human interfaces on Android tablets. Worked fine, but having to navigate Java's various minefields was a nightmare. Like C++, it felt like someone just covered a language with a layer of Object Orientedness because it was fashionable.

As a side note, Java was NOT the worst part of that experience. I discovered a bug in the Android OS associated with USB connections. Briefly, the OS didn't properly handle physical disconnects and didn't report them to the application. It was impossible to authoritatively know if the remote device had simply stopped communicating or had physically decoupled. I brought it to the attention of the core devs, and it got lots of upvotes by others to be corrected ASAP. I and many others even added comments showing the (literally) one line of code necessary to clean it up. Yet to my knowledge it's still unfixed to this day. This was back in ~2014! Grrrrr. 

[tggzzz]

"Python 3.0, released in 2008, was a major revision of the language that is not completely backward-compatible, and much Python 2 code does not run unmodified on Python 3."

Just throw most existing code under the bus?!? Yessir, THAT's a "professionally managed platform" that I'd want to use as the basis for commercial projects. NOT.

Pretty much like Java which every 18 months comes out with a new revision that breaks all the existing code. This forces enterprise developers to include their own copy of Java in their product so it doesn't happen, but that has security vunl etc etc.   

DEATH TO JAVA

I'm so happy I managed to avoid "falling for" the Java hype originally.  I always thought it was too slow,  and I had already seen a similar approach fail in the past (the UCSD P-system).

That's a common misapprehension for those that don't realise the progress that has been made in the past decades[1]. Of course, the easiest course of (in)action is usually to avoid learning how to use a tool effectively.

When I last used Java to replace a telecoms C/C++ application, onlookers were gobsmacked at how much faster my Java code executed. All that was needed was imagination, and the understanding that comes from an enquiring mind plus experience.

[1] Example... They struggle to comprehend why a C/C++ program running in an emulated processor can run as fast as the same program running on the unemulated processor. Those same techniques are used in HotSpot. That was only published 21 years ago, so it is a little too recent for people to have noticed. Isn't it?! FFI https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

[IDEngineer]

When I last used Java to replace a telecoms C/C++ application, onlookers were gobsmacked at how much faster my Java code executed. All that was needed was imagination, and the understanding that comes from an enquiring mind plus experience.

That's what I've told my 18YO sophomore son at CalPoly. Architecture is crucially important. A good environment can be crippled by bad architecture, but good architecture can often compensate for a poor environment. True in hardware AND software.

[Siwastaja]

It is exactly the same with C/C++; you have to create your code in a VM with a specific compiler version and library version, and always use those forevermore. Why? Because new optimisations and flags are prone to breaking programs that were previously OK.

Seeing you "have" to do that using such absolute terms is a sign you are likely working either in very incompetent teams, or doing something out of ordinary with external requirements for such practices. Or just have no idea how the C/C++ software development world actually runs.

After all, I'm quite certain 99% of the "the different compiler version broke my C program" problems are caused by very actual and real bugs in the code, relying on undefined or implementation-defined behavior the programmer didn't understand or even consider when writing it. Which is completely understandable, we all make mistakes, but the key to reducing mistakes is to look for the root cause and learn from it, not to hide it by preventing the detection of said bug.

Portable (across compilers and exact standard library versions; even across CPU architectures) POSIX C code is being written and maintained every day. Bugs that are being hidden with one (standard-compliant) compiler, then revealed with another (standard-compliant) compiler do happen, we are humans after all, but they are almost meaningless, minuscule portion of total bugs the developers need to deal with, and definitely no absolute showstoppers. Even bugs caused by a buggy compiler do happen, although much more rarely than an average developer wants to believe.

Yes, I agree such total version lockdowns and virtual machines to prevent such breakage are sometimes needed, but that is really a very sucky way to do it, and claiming that you absolutely need to lock to exact versions forever only shows you have no idea what you are talking about, and are just screaming "I can't do this, I give up!" Extraordinary claims require extraordinary evidence; clearly most of the world being run on C code being compiled on varying compiler and C standard library versions is "the wrong way to do it". Yet this is how it works, and majority of bugs that cause actual damage could not have been prevented by locking down to specific tool versions.

Bugs will always happen, and sidestepping the issues caused by different compiler versions will only help with those types of bugs, which are a stunningly small percentage of total bugs. Quite the opposite; if you test your software (using proper automated test suites, yeah?) in different environments, with different compilers, you are likely to catch more bugs, instead of hiding them by limiting to one compiler.

After all, porting to a new environment, or reusing part of your code in another project, compiled on a different compiler, will likely eventually happen. Your code is worth more when it's portable, reusable, and relatively bug-free, not some write-once kludge for one forever-locked environment.

And think about this: what if you have a difficult-to-reproduce bug that appears with 1% probability with compiler A, but with 100% probability with compiler B? Was locking down to compiler A the right thing? Was this choice really adding robustness to your project, or was it just an excuse to keep producing buggy code?

[tggzzz]

When I last used Java to replace a telecoms C/C++ application, onlookers were gobsmacked at how much faster my Java code executed. All that was needed was imagination, and the understanding that comes from an enquiring mind plus experience.

That's what I've told my 18YO sophomore son at CalPoly. Architecture is crucially important. A good environment can be crippled by bad architecture, but good architecture can often compensate for a poor environment. True in hardware AND software.

Yes, precisely.

The question then becomes whether one core technology helps or hinders radically different architectures.

Even as late as 2005, Hans Boehm (he of the "usually gets it right" C/C++ GC) found it necessary to point out that in C "Threads Cannot be Implemented as a Library". Remarkably many practitioners were ignorant of that, despite it being the case since K&R days! FFI http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

[tggzzz]

It is exactly the same with C/C++; you have to create your code in a VM with a specific compiler version and library version, and always use those forevermore. Why? Because new optimisations and flags are prone to breaking programs that were previously OK.

Seeing you "have" to do that using such absolute terms is a sign you are likely working either in very incompetent teams, or doing something out of ordinary with external requirements for such practices. Or just have no idea how the C/C++ software development world actually runs.

Having been programming in C since 1982, I have a good idea of how it runs - and falls flat on its face.

After all, I'm quite certain 99% of the "the different compiler version broke my C program" problems are caused by very actual and real bugs in the code, relying on undefined or implementation-defined behavior the programmer didn't understand or even consider when writing it. Which is completely understandable, we all make mistakes, but the key to reducing mistakes is to look for the root cause and learn from it, not to hide it by preventing the detection of said bug.

In one sense, that used by language lawyers, that is a correct answer - but to an unimportant question.

The important questions are

• how many and what proportion of C programmers understand the language well enough to avoid all nasal dæmons. The answer to that is simple: only a vanishingly small proportion
• how many programs in production contain UB, and could therefore "rm -rf /" when used with the next version of the compiler. Again, the answer is simple: too many and far more than people believe

For examples, nip over to the usenet group comp.arch and have a look at the ongoing "UB and C" thread. There you will see extremely competent and experienced people discussing the difficulties.

Portable (across compilers and exact standard library versions; even across CPU architectures) POSIX C code is being written and maintained every day. Bugs that are being hidden with one (standard-compliant) compiler, then revealed with another (standard-compliant) compiler do happen, we are humans after all, but they are almost meaningless, minuscule portion of total bugs the developers need to deal with, and definitely no absolute showstoppers. Even bugs caused by a buggy compiler do happen, although much more rarely than an average developer wants to believe.

And there you gloss over the problem you are attempting to address. It isn't just "another compiler", the problems can appear with the next version of the same compiler, classically when the next version contains new optimisations.

And that is why it is prudent to nail down the compiler and library in a VM.

Please don't make claims to the effect that "testing will uncover problems", or "if it passes the tests then it is working".  Or rather, if you do then please provide a test suite that proves an in-memory database has ACID properties given multiple processors accessing it simultaneously.

Yes, I agree such total version lockdowns and virtual machines to prevent such breakage are sometimes needed, but that is really a very sucky way to do it, and claiming that you absolutely need to lock to exact versions forever only shows you have no idea what you are talking about, and are just screaming "I can't do this, I give up!" Extraordinary claims require extraordinary evidence; clearly most of the world being run on C code being compiled on varying compiler and C standard library versions is "the wrong way to do it". Yet this is how it works, and majority of bugs that cause actual damage could not have been prevented by locking down to specific tool versions.

"Most of the world doesn't do it" proves nothing, of course. Most of the world doesn't have access to decent sanitation and drinking water!

Bugs will always happen, and sidestepping the issues caused by different compiler versions will only help with those types of bugs, which are a stunningly small percentage of total bugs. Quite the opposite; if you test your software (using proper automated test suites, yeah?) in different environments, with different compilers, you are likely to catch more bugs, instead of hiding them by limiting to one compiler.

Writing a good test suite is more difficult than writing the program itself.

At best a test shows that a bug exists; so what! The next bug will be due to something you didn't test, recursively!

Too many of the test suites I've come across are incompetent, and are little more than fig-leaves to make it look like the code is being tested. That's language independent, unfortunately.

After all, porting to a new environment, or reusing part of your code in another project, compiled on a different compiler, will likely eventually happen. Your code is worth more when it's portable, reusable, and relatively bug-free, not some write-once kludge for one forever-locked environment.

And think about this: what if you have a difficult-to-reproduce bug that appears with 1% probability with compiler A, but with 100% probability with compiler B? Was locking down to compiler A the right thing? Was this choice really adding robustness to your project, or was it just an excuse to keep producing buggy code?

I'm not sure what point you are trying to make there.

[SilverSolder]

"Python 3.0, released in 2008, was a major revision of the language that is not completely backward-compatible, and much Python 2 code does not run unmodified on Python 3."

Just throw most existing code under the bus?!? Yessir, THAT's a "professionally managed platform" that I'd want to use as the basis for commercial projects. NOT.

Pretty much like Java which every 18 months comes out with a new revision that breaks all the existing code. This forces enterprise developers to include their own copy of Java in their product so it doesn't happen, but that has security vunl etc etc.   

DEATH TO JAVA

I'm so happy I managed to avoid "falling for" the Java hype originally.  I always thought it was too slow,  and I had already seen a similar approach fail in the past (the UCSD P-system).

That's a common misapprehension for those that don't realise the progress that has been made in the past decades[1]. Of course, the easiest course of (in)action is usually to avoid learning how to use a tool effectively.

When I last used Java to replace a telecoms C/C++ application, onlookers were gobsmacked at how much faster my Java code executed. All that was needed was imagination, and the understanding that comes from an enquiring mind plus experience.

[1] Example... They struggle to comprehend why a C/C++ program running in an emulated processor can run as fast as the same program running on the unemulated processor. Those same techniques are used in HotSpot. That was only published 21 years ago, so it is a little too recent for people to have noticed. Isn't it?! FFI https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

My bad experiences might have been bad code / older Java implementations, fair enough.  I had the team re-write everything in C++ and all the problems disappeared...  only to be replaced by new problems, obviously, but that's life!

[GeorgeOfTheJungle]

 

[tggzzz]

"Python 3.0, released in 2008, was a major revision of the language that is not completely backward-compatible, and much Python 2 code does not run unmodified on Python 3."

Just throw most existing code under the bus?!? Yessir, THAT's a "professionally managed platform" that I'd want to use as the basis for commercial projects. NOT.

Pretty much like Java which every 18 months comes out with a new revision that breaks all the existing code. This forces enterprise developers to include their own copy of Java in their product so it doesn't happen, but that has security vunl etc etc.   

DEATH TO JAVA

I'm so happy I managed to avoid "falling for" the Java hype originally.  I always thought it was too slow,  and I had already seen a similar approach fail in the past (the UCSD P-system).

That's a common misapprehension for those that don't realise the progress that has been made in the past decades[1]. Of course, the easiest course of (in)action is usually to avoid learning how to use a tool effectively.

When I last used Java to replace a telecoms C/C++ application, onlookers were gobsmacked at how much faster my Java code executed. All that was needed was imagination, and the understanding that comes from an enquiring mind plus experience.

[1] Example... They struggle to comprehend why a C/C++ program running in an emulated processor can run as fast as the same program running on the unemulated processor. Those same techniques are used in HotSpot. That was only published 21 years ago, so it is a little too recent for people to have noticed. Isn't it?! FFI https://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

My bad experiences might have been bad code / older Java implementations, fair enough.  I had the team re-write everything in C++ and all the problems disappeared...  only to be replaced by new problems, obviously, but that's life!

As they say, you can write Fortran in any language! My attitude to C/C++ is that the tools (and many applications!) have become castles built on sand, and hence become part of the problem, rather than part of the solution.

Java has its own set of problems, to be sure. But it avoids many of the problems found in C/C++, and allows me to concentrate on finding interesting problems that are related to my application.

It will be interesting to see whether Go and Rust have similar benefits.

[GeorgeOfTheJungle]

I like:

-closures
-dynamic typing
-nested functions
-async/await
-event loops
-the (function () {})(); form
-the C syntax
-JSON
-impure functional

=> I like JavaScript

There's a problem though: it lets you build objects in a zillion different ways => there's no easy way for an IDE to keep track (static analysis) of what objects there are, what properties and methods they have (or not), the hierarchy, and makes it difficult to interoperate with other peoples' code/libraries. Most of which is solved by TypeScript. => I like TypeScript better (a superset that compiles to JS).

[SilverSolder]

I like:

-closures
-dynamic typing
-nested functions
-async/await
-event loops
-the (function () {}}(); form
-the C syntax
-JSON
-impure functional

=> I like JavaScript

There's a problem though: it lets you build objects in a zillion different ways => there's no easy way for an IDE to keep track of what objects there are, what properties and methods they have (or not), the hierarchy, and makes it difficult to interoperate with other peoples' code/libraries. Most of which is solved by TypeScript. => I like TypeScript better (a superset that compiles to JS).

Is TypeScript the one that was designed by Anders Hejlsberg?  - he has done a lot of good work in the software industry (e.g. Delphi, C Sharp)

[GeorgeOfTheJungle]

Is TypeScript the one that was designed by Anders Hejlsberg?  - he has done a lot of good work in the software industry (e.g. Delphi, C Sharp)

Yes.. 

https://channel9.msdn.com/Events/Build/2017/B8088/

[tggzzz]

It is exactly the same with C/C++; you have to create your code in a VM with a specific compiler version and library version, and always use those forevermore. Why? Because new optimisations and flags are prone to breaking programs that were previously OK.

Seeing you "have" to do that using such absolute terms is a sign you are likely working either in very incompetent teams, or doing something out of ordinary with external requirements for such practices. Or just have no idea how the C/C++ software development world actually runs.

Having been programming in C since 1982, I have a good idea of how it runs - and falls flat on its face.

After all, I'm quite certain 99% of the "the different compiler version broke my C program" problems are caused by very actual and real bugs in the code, relying on undefined or implementation-defined behavior the programmer didn't understand or even consider when writing it. Which is completely understandable, we all make mistakes, but the key to reducing mistakes is to look for the root cause and learn from it, not to hide it by preventing the detection of said bug.

In one sense, that used by language lawyers, that is a correct answer - but to an unimportant question.

The important questions are

• how many and what proportion of C programmers understand the language well enough to avoid all nasal dæmons. The answer to that is simple: only a vanishingly small proportion
• how many programs in production contain UB, and could therefore "rm -rf /" when used with the next version of the compiler. Again, the answer is simple: too many and far more than people believe

For examples, nip over to the usenet group comp.arch and have a look at the ongoing "UB and C" thread. There you will see extremely competent and experienced people discussing the difficulties.

Portable (across compilers and exact standard library versions; even across CPU architectures) POSIX C code is being written and maintained every day. Bugs that are being hidden with one (standard-compliant) compiler, then revealed with another (standard-compliant) compiler do happen, we are humans after all, but they are almost meaningless, minuscule portion of total bugs the developers need to deal with, and definitely no absolute showstoppers. Even bugs caused by a buggy compiler do happen, although much more rarely than an average developer wants to believe.

And there you gloss over the problem you are attempting to address. It isn't just "another compiler", the problems can appear with the next version of the same compiler, classically when the next version contains new optimisations.

And that is why it is prudent to nail down the compiler and library in a VM.

Here's today's examples from a different thread in comp.arch; you may recognise the author I've very heavily snipped it to highlight the relevance to the above point; don't complain to David! For full context, have a look at the original.

Re: [OT] Anton Ertl has been proven right
On 19/06/20 12:16, David Brown wrote:
> Here are a couple of references that could be of interest here:
>
> <https://devblogs.microsoft.com/cppblog/new-code-optimizer/>
>
> That is an MSVC developer blog saying that their new (in 2016) optimiser
> "takes advantage of signed integer overflow being undefined".  It
> mentions an /undocumented/ compiler flag "d2UndefIntOverflow" to disable
> this behaviour (undocumented means you can try it, but it is not
> guaranteed to work as you think or to remain available in later compilers).

Now, what action do you suggest is practical and sufficient to defend against that kind of thing?


> Here is a feature request from an MSVC user for type-based alias
> analysis to give more efficient code:
>
> <https://developercommunity.visualstudio.com/idea/513950/structure-usage-is-not-optimized-by-compiler.html>
>
> The second last comment, by an MSVC developer (AFAICS) says:
>
> """
.......
> This is a feature we might consider implementing if there is enough
> support in the community for it.
> """
>
> Read that last line.  Read it again, and then a third time.
......
>  From the final comment in that post, you can see that people are
> sceptical that introducing strict aliasing will cause trouble for
> existing C and C++ code written for MSVC, and thus such a change should
> require explicit enabling.

Again, given that we live on planet earth (not in nirvana), what is your recommended practical course of action?

[Siwastaja]

Practical course of action is accepting that the world isn't perfect, bugs happen, they need to be dealt with properly; and that the fact C standard leaves some things implementation-defined probably wasn't the best idea, but all in all, we can deal with this, and very few will find this a showstopper.

Going even more practical, this means: treat the bugs caused by C UB or implementation-defined behavior like any other bugs: analyze for root cause, fix your code not to rely on nasal daemons. Learn, and write better code in the future. In very rare cases of compiler bugs, communicate with the compiler team.

This is wildly related to the SiliconWizard's original remark of getting "at least some minimal consistency" with "standardized languages". C fits that bill just right: bugs caused by problems in standardization and hence differences in (all standard-compliant) compiler versions happen and are widely documented, but are rare enough, and OTOH, well documented enough not to matter too much.

Perfect is the enemy of good.

The very practical thing you can do is to learn these pitfalls and start writing code that does not rely on undefined or implementation-defined behavior. Your bug-free, portable, reusable code is more valuable than your locked-down kludge that was verified to work once in 1985.

See linux kernel for example, it's being compiled with new GCC versions all the time. In it's history, there have been a handful of problems due to this, but the linux kernel is fairly reliable and staying modern, is powering most of this modern world (like it or not), handling very critical and important tasks as well.

Even if we lived in a magical world where this issue wouldn't exist, the number of bugs would be approximately the same, maybe 1% less. The process for dealing with bugs would be exactly the same.

OTOH, you propose a solution where there exists two processes for bugs, the "normal" process for most bugs, and then the "lock down development environment to hide some UB bugs by preventing them popping up" version regarding the bugs caused by writing non-standard-compliant code. Call this strawman if you want to, but this is essentially what you propose, and it sounds so bad because it is so bad.

This is analogous to the comment I remember seeing from Linus Torvalds regarding the stupidity of handling "normal bugs" and "security bugs" so differently, while in reality, it's a made-up line. You can have higher-priority and lower-priority bugs, but you deal with them the same way.

Lockdown to a particular compiler version and toolset environment could be warranted for a life support device, for example. Even then, I wouldn't suggest doing that choice prematurely. And in such projects, writing unambiguous and standard-compliant code to begin with becomes increasingly important! But such projects must be verified to be safe on the binary level, and you just don't go and make small changes to the codebase without verifying the binaries.

We all can probably agree we would like to have something that completely fixes problems of the C language, but giving up and requiring silly coping methods like "always lock down your development tool versions totally" is making things worse, not better.

[tggzzz]

Practical course of action is accepting that the world isn't perfect, bugs happen, they need to be dealt with properly; and that the fact C standard leaves some things implementation-defined probably wasn't the best idea, but all in all, we can deal with this, and very few will find this a showstopper.

Going even more practical, this means: treat the bugs caused by C UB or implementation-defined behavior like any other bugs: analyze for root cause, fix your code not to rely on nasal daemons. Learn, and write better code in the future. In very rare cases of compiler bugs, communicate with the compiler team.

How precisely do you achieve that in the real world with reasonable quality programmers. Assume there is no unexpected behaviour with today's compiler. But next years compiler, with the new and undocumented work-around flags, causes the behaviour to become unexpected.

That's an example of why people "archive" the build environment in a VM or, deity help them, in Rational Clearcase.

This is wildly related to the SiliconWizard's original remark of getting "at least some minimal consistency" with "standardized languages". C fits that bill just right: bugs caused by problems in standardization and hence differences in (all standard-compliant) compiler versions happen and are widely documented, but are rare enough, and OTOH, well documented enough not to matter too much.

As illustrated above, a standardised language is insufficient.

If correctness doesn't matter "too much" then I can develop code arbitrarily fast

The very practical thing you can do is to learn these pitfalls and start writing code that does not rely on undefined or implementation-defined behavior. Your bug-free, portable, reusable code is more valuable than your locked-down kludge that was verified to work once in 1985.

In the real world, that is nirvana. If you listen to those with a lot of experience and knowledge of the subject, you will find them saying how difficult that is - to the point of them presuming that any arbitrary program will have UB somewhere.

OTOH, you propose a solution where there exists two processes for bugs, the "normal" process for most bugs, and then the "lock down development environment to hide some UB bugs by preventing them popping up" version regarding the bugs caused by writing non-standard-compliant code. Call this strawman if you want to, but this is essentially what you propose, and it sounds so bad because it is so bad.

It is the practical solution to having code continue to work. It isn't nice, it isn't good, but it is practical and it works.

I'm still waiting for someone to suggest something else that can be predicted to work in real-world situations.

Lockdown to a particular compiler version and toolset environment could be warranted for a life support device, for example. Even then, I wouldn't suggest doing that choice prematurely. And in such projects, writing unambiguous and standard-compliant code to begin with becomes increasingly important! But such projects must be verified to be safe on the binary level, and you just don't go and make small changes to the codebase without verifying the binaries.

I have written code that could kill people, even if it is worklng correctly and to specification!

The phrase "verifying the binaries" is a red flag statement. Example: do please tell us how to verify that a multithread/multicore/multicomputer database application doesn't violate ACID guarantees.

We all can probably agree we would like to have something that completely fixes problems of the C language, but giving up and requiring silly coping methods like "always lock down your development tool versions totally" is making things worse, not better.

How is it making things worse?

[SilverSolder]

[...] See linux kernel for example, it's being compiled with new GCC versions all the time. In it's history, there have been a handful of problems due to this, but the linux kernel is fairly reliable and staying modern, is powering most of this modern world (like it or not), handling very critical and important tasks as well. [...]

If you think about it, this feeds back to the compiler writers too,  i.e. the toolchain makers respond to how the tools are used, so we end up with both better products and better tools.

It is never a good idea to let things stagnate - software, hardware, or even life in general.

[rstofer]

It always seemed to me that nested functions fit cleanly into Wirth's Syntax Diagrams and the recursive descent approach of the Pascal compiler.  The code looked a lot like the diagram.

Another language feature I like(d) is from COBOL

MOVE CORRESPONDING identifier-1 TO identifier-2

Moves identically named fields of record identifier-1 to the fields of record identifier-2

[golden_labels]

I wonder, why are people so often choosing to depict the interaction between UBs and optimization in C in a manner that suggests compiler designers are intentionally breaking programs. It’s ridiculous. :/

It’s basically like not reading a datasheet, not knowing maximum ratings, applying 300V to a 3.3V chip and crying that the IC designers are stupid, because they should’ve made their device working up to 1000V and making it PITA for everyone else.

While there are cases in which it goes another way, most often the reasoning is not: find potential UB → use it to remove some code. It is: find a possible optimization → check if it works for all cases → if there are any UB cases, ignore them. What else do you people expect? That optimizations will be ruined for everyone just because there are people, who don’t care enough to learn and understand the language? Or that compiler creators will spend their time identifying each UB, determining what’s the “sane behaviour” for what is meaningless in the first place, and spending resources of maintaining the code? And making it more complex, as if it wasn’t a monstrum yet? Sure, putting guards like that everywhere is not insane, but it’s not free and I do not see people lining up to pay for it.

[SilverSolder]

It always seemed to me that nested functions fit cleanly into Wirth's Syntax Diagrams and the recursive descent approach of the Pascal compiler.  The code looked a lot like the diagram.
[...]

If you think about the alternative...   placing the nested sub-function outside the scope of the function that actually uses it...   that is a less "clean" solution (less encapsulation) and doesn't convey the design intent in the same way.  Of course, nested functions can be overdone and if they get too long, it's time to reconsider what's going on.

[tggzzz]

I wonder, why are people so often choosing to depict the interaction between UBs and optimization in C in a manner that suggests compiler designers are intentionally breaking programs. It’s ridiculous. :/

That would indeed be a ridiculous depiction!

However, in order continue to have competitive products (as per microbenchmarks), they are interpreting the language specs more aggressively and, when a problem happens to be noticed, saying "tough, we know the language, you don't, your problem".

Actually the users problem should not be the language, it is understanding the application domain and creating a program that solves the problem in that domain. If you add (new) problems in the tool then you have increased the users problems: the language has become part of the problem rather than part of the solution.

It’s basically like not reading a datasheet, not knowing maximum ratings, applying 300V to a 3.3V chip and crying that the IC designers are stupid, because they should’ve made their device working up to 1000V and making it PITA for everyone else.

Analogies are always dangerous

A better analogy (which hits people in practice) would be trying to find a replacement for an old deceased 2N3055 power transistor, only to find that the circuit now oscillates. Why? Because the modern device's f_t is much higher.

While there are cases in which it goes another way, most often the reasoning is not: find potential UB → use it to remove some code. It is: find a possible optimization → check if it works for all cases → if there are any UB cases, ignore them. What else do you people expect? That optimizations will be ruined for everyone just because there are people, who don’t care enough to learn and understand the language? Or that compiler creators will spend their time identifying each UB, determining what’s the “sane behaviour” for what is meaningless in the first place, and spending resources of maintaining the code? And making it more complex, as if it wasn’t a monstrum yet? Sure, putting guards like that everywhere is not insane, but it’s not free and I do not see people lining up to pay for it.

In many cases it is not even possible to uniquely define "sane behaviour"!

The point is that it is sufficient that the behaviour doesn't radically change over time. The practical way to ensure that is to preserve the toolchain in a VM, or similar.

[ozcar]

...

Another language feature I like(d) is from COBOL

MOVE CORRESPONDING identifier-1 TO identifier-2

Moves identically named fields of record identifier-1 to the fields of record identifier-2

One language feature I will never forget is Cobol OCCURS DEPENDING ON.

But I remember it only because because of a bug that IBM had in around 1997, which caused us a fair bit of angst, so it was not a favourite of mine at that time.

[Feynman]

The first things that came to my mind were operator overloading (e.g. C++) and negative array indexing (e.g. python).

[Mattjd]

Almost always when I found something annoying about Python, it was because I was slavishly following a design pattern, necessary in a prior language I had internalized, but now redundant in Python and agreeably forgotten.

I think the missing delimiters and significance of whitespace bit me once or twice the first couple days I used Python. That ended after I banished tabs and turned on Python mode: in the same old editor I have been using for the last forty years. The pretty printing I had always done, then mapped one-to-one to Python's indentation, and I promptly forgot about it.

I bet you are fighting the language in some way if its indentation is causing you grief,  If you could post some examples (perhaps starting another thread), I would be happy to try to smooth things out.

My biggest grief with python is that the interpreter seems to have a hard time with closing parenthesis. Many, many times I've missed a closing parenthesis, only for the interpreter to throw a fit at the next line under, saying that is invalid. When in fact that line is completely valid, its just getting picked up as an argument being passing in those un-closed parenthesis. I've scratched my head at that many times, not realizing the issue. Finally resolving it after a few minutes.

My favorite has to be comprehensions and duck typing.

So yeah, python.

Negative indexing is nice too.

Other than that, one of my all time favorites is broadcasting (as in numpy vector broadcasting) or implicit binary singleton expansion (as matlab calls it). Used to be called bsxfun() now you can just do A.*B' where A is a row vector and B is a transposed row vector (aka column) this creates a matrix.  https://blogs.mathworks.com/loren/2016/10/24/matlab-arithmetic-expands-in-r2016b/


edit: Oh I forgot, modules. Modules and nested modules are amazing as is aliasing of imports. #include and header macro guards are evil.

We've been fucked over at work a few times because of include-guard namespaces being taken up at some earlier time of compilation and then left wondering why this other header file (with unfortunately the SAME include-guard name) isn't being included. This isn't some small program either. Its simulation code for a system thats going to be used on a naval ship. Lots of cogwheels.