-
Ada was tainted by being European, DoD, and having normally expensive tools.
The main reason C and Unix became dominant was that it was given away free to universities, so students became familiar with it.
As usual, technical merit is only one point, and not the most important point.
The first version of SPARK was produced at my alma mater, by one of my lecturers, Bernard Carre. Even in 77 he was interested in program correctness, and introduced us to the concepts of assertions and contracrs. -
Popularity with students and hobbyists is the key.
Do you realize that Fortran still exists and apparently got a minor spec revision last year?
I didn't know about the latter until a minute ago, but I know about the former because I briefly worked with Fortran some decade ago and I'm sure this project still exist. -
Fortran is unparalleled for numerical analysis, and is still important for HPC.
It has many numerical libraries that have been designed by mathematicians and competent engineers that know their job. If only that was true of all libraries. -
A lot of the HPC code running on large Linux clusters is written in Fortran. Partly for historical reasons, and partly because HPC type code runs fast without much optimisation effort. Updates have done a lot to make the new code look less like spaghetti, so its a much better language to write in than it used to be.
-
A lot of the HPC code running on large Linux clusters is written in Fortran. Partly for historical reasons, and partly because HPC type code runs fast without much optimisation effort. Updates have done a lot to make the new code look less like spaghetti, so its a much better language to write in than it used to be.
C has many features that mean the compiler cannot output optimal code. Command line arguments can be used to tell the compiler "I promise this code won't do X, honestly", but they aren't as good as a decent language that doesn't have pessimising features.
Two of the most obvious pessimising features are pointer aliasing, and the heavy use of pointer themselves.
Fortran is fundamentally array based without aliasing, and that "plays nicely" with caches and prefetching. Pointers bust both, since the dereference address is unpredictable. -
Yeah, not sure what makes people frown upon Ada.
To me, the biggest thing is GNAT being the only open source compiler, and a lot of people saying the commercial ones are way better.
The first programming languages I learned, in order, were BASIC, 6502 assembly, and (Borland Turbo) Pascal, so I don't mind the language itself at all; it's quite comfy to me. (Then again, when you're happy to write code in more than a dozen different programming languages, you tend to not care that much about syntax nitpicks. Perl is the only one I avoid, and that just because I have kinda-sorta "PTSD" from having to work on a horrible code base written by people I like: talk about emotional and cognitive dissonance!)
I haven't looked at AdaCore embedded stuff, but I once spent quite some time to get a distributed HPC simulator written in GNU Fortran (95/2003) to read and write non-native binary files, and really missed hardware-defined types. At some point I read The Implementation of Ada 2005 Interface Types in the GNAT Compiler (PDF at AdaCore), which discusses the changes they did to GNAT type implementation to simplify interfacing to C++ code, which indicated to me that such low-level interfacing to native code is nontrivial in Ada, and likely requires native/machine code shim or interface layers –– just like Fortran in practice. So, I basically put Ada mentally in the same category of domain-specific languages. (Fortran is still heavily used in numerical computation, for mostly non-technical reasons; I know Ada has several niches especially in aviation and other safety-critical systems.)
Now, I'm fully aware that most of my assessment of Ada is likely wrong. Because of the single open source implementation, I haven't even tried to correct them. I just don't like being dependent on a single vendor, or dependencies on singular things in general: I need options. -
Unfortunately in the 1990s C also fell into the trap of trying to be both a low level and an application level language. Either choice would have been OK, but the result is a mess. Hence we have Java and Python taking over the application domains, and C becoming too complex for low level stuff.
This I think is the downfall of all of the one size fits all solutions. Be it Ada or Rust or whatever.
I started on Algol, then cycled through FORTRAN, Basic, Pascal, Visual Basic and finally in the last decade have been forced into C and Python. Developed an ability to read, but not write several other languages along the way. I chose not to make software the core of my career back in university when I realized that I didn't want to be fighting these battles every day of my working life. But working in the industry you can't avoid contact with it, and I lived through the forced use of Ada in US DoD projects in the 80s and 90s, have watched coding teams that believe a GUI is the right answer for every kind of software, right down to the safety timer in a coffee maker, and so on.
There seems to be a great lack of understanding by the designers of languages/compilers of the actual applications that their gems will be used to implement. Many marvel at the survival of FORTRAN. Some ascribe it to the well tuned math libraries that are available. I agree that is part of it. But I also believe that a hidden element associated with those libraries is that FORTRAN is designed with a native complex number type. The mathematics of engineering and physics rely heavily on complex arithmetic and huge fractions of the code depend on this. I am not aware of any other language that address this directly. Several including C++ and Ada do allow you to define your own data types and use operator overloading to attempt the same thing. But these are local solutions, the software written under them is not portable. There is no reason that complex could not be a native type in other languages, but the designers of most languages just don't see the need.
Similar problems beset other languages trying to be all things to all people. -
But I also believe that a hidden element associated with those libraries is that FORTRAN is designed with a native complex number type.
C has three (complex float, complex double, and complex long double, although the latter two usually have the same range and precision), exposed by including <complex.h>, in the standard C math library.
Addition, subtraction, multiplication, and division using these types do the corresponding complex arithmetic operations. For standard library math functions, the function names are prefixed with c. For standard C library functions, see man 7 complex.
With respect to complex number support in the language/standard library itself, C and Fortran do not have significant differences. (And I have done HPC software development in both languages, mostly using MPI for distributed parallel processing.)
For further details in complex arithmetic support, see ISO C99/C11/C17/C23 standard, chapter 7.3 Complex Arithmetic <complex.h>. -
Apparently the compilers of C that I have seen don't implement the full language. I haven't looked at gcc.
-
Apparently the compilers of C that I have seen don't implement the full language. I haven't looked at gcc.
It is an optional feature. If the preprocessor macro __STDC_NO_COMPLEX__ is defined and equals to 1, then the C compiler and/or standard C library does not support complex types. There is also no requirement to implement <complex.h> for freestanding environments, for example embedded or kernel development. You only see it used in fully featured, hosted environments –– but if the target hardware supports single- and double-precision hardware floating point, you can expect these complex types to be available.
The native C complex types are also supported by the common math libraries, including FFTW.
AMD Optimizing C Compiler, Clang, GCC, IAR, Intel oneAPI and classic C compilers, Open64, Pelles C, and Portland Group C Compiler do support complex types. (Of course, they also require the target standard C library to support the complex types, because the compiler only provides support for the base complex arithmetic.)
Of these, I've used GCC, Intel, Open64, and PGI on x86 and x86-64 (Linux, with glibc as standard C library) for complex number stuff in C, when I did some sonification research. I just checked my local installation of Clang 10, and it too supports complex types on x86-64 using glibc and newlibc. -
C99-compliant compilers should have reasonable support for complex numbers. GCC sure does.
I don't use them when I need performance though. The reason is that GCC has apparently favored correctness over performance, more so than with basic FP operations. Yes, even with -ffast-math. You'll usually get much better performance implementing the complex operations yourself. This point may change as GCC evolves, though, so YMMV. And yes, there are potential pitfalls when naively implementing complex operations "by hand" (rounding and precision issues), so I'm not saying that what GCC does is wrong. Just mentioning that sometimes you need extra performance at the expense of those edge cases, and as I mentioned, last I tried, even with the '-ffast-math' option, GCC would generate suboptimal (in terms of performance, again) code for complex operations - at least for multiply, divide.
OTOH, if you need the compiler to take care of those precision issues for you, do use the C complex types instead of hand-implementing complex numbers, it'll save you a lot of time.
Commercial C compilers for embedded targets are a lot less likely to include support for complex numbers, so wouldn't be surprised there. As to MS C compilers, it took them so much time (apparently completely on purpose) to have anything C99-compliant than here again, no surprise. They have caught up though, I believe, and you now have reasonably good C11 compliance. My understanding is that MS hasn't cared for C for over 25 years and did focus on C++. Of course they still needed C for the Windows kernel and drivers, but they would only require C89 and they have never cared about using more recent versions of the standard.
Haven't used the Intel C compiler (which was very good in terms of performance for x86 targets) in a good while, but I'm pretty sure it has been supporting complex numbers for a long time.
-
Yeah, not sure what makes people frown upon Ada.
To me, the biggest thing is GNAT being the only open source compiler, and a lot of people saying the commercial ones are way better.
Yes, that was also one of my points, the tooling. But at least there are many options, including an open-source one. Sure most others (all others?) are commercial proprietary stuff. This single-option problem also bothers me in theory, but OTOH this is the case for most other newer languages, like Rust, and nobody seems to care (and I find it even more concerning as there isn't any standard nor even any formal spec yet from which others could at least develop their own compiler).
As I said, yep, that's also what I've constantly heard regarding GNAT being poor compared to the commercial compilers, but I don't know if it holds true. When was the last time pro users of Ada did use a recent version of GNAT on real projects and found it problematic? I don't know. I suspect that doesn't happen very often and suspect most opinions are built on prejudice.
But as I mentioned in another post, the ecosystem is a real culprit. Good luck finding bindings for all the libraries you routinely use, GUI toolkits, and so on. I know there are Gtk bindings for Ada, but for Qt, I don't know. Ada (at least via GNAT) has relatively good support for interfacing with C. But with C++? Not so sure. Then again, who wants to *implement* interfacing with C++, talk about a nightmare.
Been meaning to invest some time seeing how I could use it for embedded dev, but thing is, I must admit that C still fits the bill pretty well and I am unsure if this time would be well invested. What I dearly miss in C are modules and some generic programming - I do use macros for that, but that's not the most elegant thing you can think of.
-
Apparently the compilers of C that I have seen don't implement the full language. I haven't looked at gcc.
Well, there's a surprise.
Firstly which C or C++?
Secondly a couple of decades ago I remember seeing a press release triumphantly proclaiming their compiler was the first to support the full language (C or C++, can't remember). That was 6 (six) years after the relevant standard was published.
I won't bother to note that in the late 90s (and presumably later) compiler writers were having considerable difficulties understanding the C/C++ standards w.r.t. how all the different bits interacted. Unsurprisingly different compilers had different understandings. If you are really interested in deep language infelicities, search out Nick MacLaren's posts on usenet. Nick MacLaren worked at the University of Cambridge, supporting people working on bleeding edge HPC applications in many languages. He knew where the skeletons were buried, and exhumed them when beneficial.
Here's one example: https://www.open-std.org/jtc1/sc22/wg14/9350 Notice the provenance.
A few choice snippets, out of context...QuoteTo: [email protected]
Subject: What is an Object in C Terms?
Date: Wed, 26 Sep 2001 16:52:10 +0100
From: Nick Maclaren <[email protected]>
The actual incompatibility is that C defines all parallelism and 'real'
or external signal handling to be undefined behaviour, as it is outside
C's mode, and that POSIX leaves all language issues to C, as it is
mainly a library interface. Therefore such things may be well-defined
in POSIX terms, but have undefined effects on the program which uses the
POSIX facilities! The incompatibility is therefore of the form that
POSIX relies on C to define behaviour that is explicitly undefined!
Obviously, the solution is for POSIX to define the language aspects that
it needs, but the problem is that doing so is very tricky.
It was pretty complex in C90, but C99 has complicated this area very
considerably, and the problems are going to cause major difficulty over
the next decade....
...
The vast majority of commercial implementors and important users are not
members of SC22/WG14 or even any national body affiliated with it, and
work solely from the standard. As they should, because ISO rules (and
all normal commercial practice) specify that the standard is the
official document, and records of its development should be used for at
most clarification.
I can witness that this area has caused major headaches ever since C90
was developed, and that many implementors are very seriously unhappy
about C99. They simply do not know what most of it implies and, as is
generally agreed, the subtleties in this area are critical for both
optimisation and the development of robust applications. Most of the
ones that I have contacts with had severe problems deciding exactly
what optimisations were allowed in C90, and often went through several
iterations before and industry consensus emerged.
...
C99 introduced the concept of effective type (6.5 paragraph 6), but it
has had the effect of making a confusing situation totally baffling.
This is because it has introduced a new category of types, it has
invented new terminology without defining it, its precise intent is most
unclear, and it has not specified its effect on the library. The first
aspect was mentioned above.
...
In this section, the question being asked is how large the array object
that corresponds to a pointer value is. Please ignore any assumptions
that can be used by the fact that two constructions are in the same
compilation unit, as they could easily be separated. For the purposes
of these examples, let us assume no padding and that all structures have
the same alignment.
(code omitted for brevity)
Now, which of the first five calls are conforming? There are obviously
plausible interpretations of the standard that allow all of them, all of
them except THREE, or only ONE and FIVE. But consider TWO: exactly
WHICH construction breaks any wording in the standard? There is clearly
nothing in either ONE or TWO on their own that is not conforming, and
the standard has no explicit concept of a value having a 'history' that
affects its semantics. And is the intent REALLY to distinguish FOUR and
FIVE?
OK; I lied: I did note it. So sue me
-
I won't bother to note that in the late 90s (and presumably later) compiler writers were having considerable difficulties understanding the C/C++ standards w.r.t. how all the different bits interacted.
That's why C11 went completely off the rockers, adding things only implemented by a single vendor (who didn't even have a native C compiler, only a C++ one that supported a subset of C).
C99 and C23 standardized things that have been found to work in practice first. That is how it should be for a language with sufficient history: you don't develop the standard text first, then try to implement it; you implement various things, let them compete, and extend the language when a consensus appears or users agree.
In other words, if you try to further develop a language with as wide existing code base and history as C standard-first, hoping/demanding compiler implementers will follow it, you're doing it wrong. Only if you extend it carefully, with implementations tested and verified to work for the vast majority of the user base, makes it sense to codify it into the standard.
It is different when the language itself is still being developed, still looking for its niche. Then, it does need strict focus and careful planning, so that it does not fall into the everything-for-everyone trap. White papers and exact specifications for languages are excellent. But there comes a point when any radical change should be ruled out (and instead create a new language, not just a new version), and further development of the language limited to extensions, practice first, what users find most useful, without breaking the existing code base. Consider Python 2 vs 3 as an example, and all the pain and extra work that created.
-
That is how it should be for a language with sufficient history: you don't develop the standard text first, then try to implement it; you implement various things, let them compete, and extend the language when a consensus appears or users agree.
For the same reason, complaining about existence of extensions, like often happens in recurring train wreck threads on the microcontroller subforum, is ridiculous*. It is important for standard to allow extensions. Only that enables progressive innovation. If we cannot have extensions, this only leaves three choices:
1) proactive standardization of features committees think are important, in ways committees think are correct
2) inventing completely new languages from scratch, or
3) stopping all innovation and advances in languages
which are all much more problematic than the simple option of using extensions to drive solutions to real needs programmers see, and codifying those that stand the test of time to standards, which leads to a combination of finding local maximum while still producing a stable, well-understood, standardized language.
*) it is extremely funny though that the same people for whom allowing extensions and leaving some details undefined is poison, do not see any problem in using languages with no stable specifications at all. -
I won't bother to note that in the late 90s (and presumably later) compiler writers were having considerable difficulties understanding the C/C++ standards w.r.t. how all the different bits interacted.
That's why C11 went completely off the rockers, adding things only implemented by a single vendor (who didn't even have a native C compiler, only a C++ one that supported a subset of C).
C99 and C23 standardized things that have been found to work in practice first. That is how it should be for a language with sufficient history: you don't develop the standard text first, then try to implement it; you implement various things, let them compete, and extend the language when a consensus appears or users agree.
In other words, if you try to further develop a language with as wide existing code base and history as C standard-first, hoping/demanding compiler implementers will follow it, you're doing it wrong. Only if you extend it carefully, with implementations tested and verified to work for the vast majority of the user base, makes it sense to codify it into the standard.
It is different when the language itself is still being developed, still looking for its niche. Then, it does need strict focus and careful planning, so that it does not fall into the everything-for-everyone trap. White papers and exact specifications for languages are excellent. But there comes a point when any radical change should be ruled out (and instead create a new language, not just a new version), and further development of the language limited to extensions, practice first, what users find most useful, without breaking the existing code base. Consider Python 2 vs 3 as an example, and all the pain and extra work that created.
From the emboldened statement, can we presume that C and C++ are not "still being developed"?
As for "going off the rockers", I lost interest in the languages during the endless (i.e. years) long discussions in the 90s as to whether or not to allow "casting away constness". There are good arguments for both.
I believe it has been decided that you can "cast away constness". That allows optimisations which rely on const behaviour (especially valuable in performance critical libraries), but also allows other code that silently violates the guarantees, e.g. by users of the library.
Castles built on sand. No wonder people are pushing for better alternatives. -
From the emboldened statement, can we presume that C and C++ are not "still being developed"?
Human languages are vague, and I'm not very proficient in English phraseology. Choosing proper words with the correct associations is hard.
I meant "still being developed" in the sense of not being feature-complete yet; being still in the development stage where changes to planned/designed features are still considered generally acceptable.
After a language is feature-complete, you stop changing things, and instead only extend and increase specificity. I believe those extensions should be tried in practice first, preferably more than one implementation, before codified in a new version of the standard. Changes are reasonable only when they no longer affect widely available hardware; when they do not break existing code using widely available hardware.
For example, C could easily "fix" right-shifting negative values for two's complement types (intN_t, int_fastN_t, int_leastN_t) by standardizing it the way all compilers that don't produce garbage do it (which is right shifting the storage bit pattern, duplicating the sign bit). This is the right approach, because it has been shown in practice to work –– C99, C23, Fortran 95, Fortran 2003 for example.
In this sense, C is already feature-complete. Changes to the standard must not break existing code. Changes that codify implementation defined behaviour or even undefined behaviour, to how all "sane" compilers already implement them, or when one single behaviour makes sense and is useful on current hardware, are good. New keywords like constexpr (C23) fix historical mistakes/issues (const in particular), but do not break existing code; they are more like bugfixes that have been shown to be useful and acceptable to the vast majority of C users.
(constexpr is a bit special, because while it hasn't been implemented by any C compiler before inclusion in the standard, it was implemented in C++ in basically all compiler families that support both C and C++. So, while it doesn't fit into the literal "implemented by C compilers first" category and is more like an import from C++, the two languages are close enough for this kind of cross-importation to make sense. Another example is the C++11 memory model, and how GCC and Clang imported that for C atomic built-ins, as the sync built-ins Intel designed for Itanium that GCC supported just didn't cut the mustard on other architectures.)
I knew when I posted my previous post I wasn't expressing "still being developed" correctly, and am not sure I expressed it here much better. When Python 2 to 3 was done, I considered Python 2 to be feature-complete, and the change too great for a simple new version, and would rather have seen a new language been created (say, Pythoff). In comparison, I see the changes from ISO C90 to C99, and from C99 to C23 (regardless of whether you consider C11 and/or C17 in between), as integrating the changes existing compilers had basically already implemented and agreed to. (Not all, of course, but sufficient majority to show that they are preferable to users. And including the cross-importation from C++, which for the related features is close enough to C, for that to make sense as "prior art" if you will.) -
What a lot of people do not seem to realize, is how tiny and simple the freestanding C language itself is. The vast majority of the C standard is about the Standard C Library, which is not available in freestanding C (which is a reasonably well defined part of the ISO C standards).
That compactness is what a new low-level language should target. Ignore the entire standard library until well after the language itself has stabilized, and focus on low-level compatibility with existing binary ABIs (including syscall interfaces when running under a fully featured OS) and microcontroller and embedded environments. ELF object file format has shown its superiority compared to others, so integrate its features (at least the concept of being able to name an arbitrary linker section for each function/variable/object).
I personally don't like the abstract machine concept. The current one used in the C standard is too simple to reflect current hardware. Any abstract machine model will similarly lag behind, because hardware development has been shown to well outpace programming language development. The main problem in low-level language definition approaches seems to be operation ordering, or rather, specifying the ordering of observable side effects. The C++11 memory model semantics shows that such ordering is not unique from a validity point of view: each side effect has a range where it is valid, when the program works as intended in all situations (assuming correctly written code here). The abstract machine model the C standard uses specifies a single step for each observable effect, which makes designing and implementing optimization strategies quite difficult.
Defining the language based on the observable side effects, while leaving maximum control of their ordering to the code written in that language, is what I'd want. As of right now, I have no idea how that could be done, or whether it is even possible in the first place. -
From the emboldened statement, can we presume that C and C++ are not "still being developed"?
Human languages are vague, and I'm not very proficient in English phraseology. Choosing proper words with the correct associations is hard.
Just so. In addition I was being too terse. Apologies.
I think strict focus and careful planning is required at all stages of language design and extension/development.
The "cast away constness" dichotomy is real and important, and indicates that the language's focus has been lost and is being extended beyond reason.
Analogy: construction scaffolding used to be made from wood, and bamboo is still used in developing countries. Just because it can and is used for large constructions, doesn't mean that it wouldn't be better to use steel scaffolding. Large C programs are like this:
-
Analogy: construction scaffolding used to be made from wood, and bamboo is still used in developing countries. Just because it can and is used for large constructions, doesn't mean that it wouldn't be better to use steel scaffolding. Large C programs are like this:
That's a bad analogy. Wooden scaffold is a bit iffy, but developed places, like Hong Kong, still use bamboo almost exclusively. In the hands of competent people its quick and cheap to install, and does the job well. The people working with it love it, as its so light and easy to handle. If you actually get the job done, and the scaffold removed before materials start to degrade, its fine. China banned bamboo in favour of steel, largely to divert attention for the kind of ham fisted, unskilled people who were doing the work, and how long many half completed structures remained like that with a scaffold in place until the materials degraded.
-
Analogy: construction scaffolding used to be made from wood, and bamboo is still used in developing countries. Just because it can and is used for large constructions, doesn't mean that it wouldn't be better to use steel scaffolding. Large C programs are like this:
That's a bad analogy. Wooden scaffold is a bit iffy, but developed places, like Hong Kong, still use bamboo almost exclusively. In the hands of competent people its quick and cheap to install, and does the job well. The people working with it love it, as its so light and easy to handle. If you actually get the job done, and the scaffold removed before materials start to degrade, its fine. China banned bamboo in favour of steel, largely to divert attention for the kind of ham fisted, unskilled people who were doing the work, and how long many half completed structures remained like that with a scaffold in place until the materials degraded.
Analogies are always dangerous. People concentrate on the analogy rather than the original topic.
BASIC programs are a bit iffy, but developed places, like Hong Kong, still use BASIC almost exclusively. In the hands of competent people its quick and cheap to install, and does the job well. The people working with it love it, as its so quick and simple to use. If you actually get the job done, and the program does its job before maintenance start to degrade it, its fine. -
For example, C could easily "fix" right-shifting negative values for two's complement types (intN_t, int_fastN_t, int_leastN_t) by standardizing it the way all compilers that don't produce garbage do it (which is right shifting the storage bit pattern, duplicating the sign bit). This is the right approach, because it has been shown in practice to work –– C99, C23, Fortran 95, Fortran 2003 for example.
myC refuses to compile and throws an error for any attempt to shift signed integers. To avoid the restriction, you need to manually define what is meant by "shift" signed things.
All undefined behaviors and implementation-defined behaviors are handled this way: it's the user that must define them, otherwiser the compiler refuses to compile!
- if it comes out garbage, it's not my fault - that's my approach
-
Analogies are always dangerous. People concentrate on the analogy rather than the original topic.
Hey, you are the one who started with the crappy analogy that fit like a meaningful response in 140 characters.
BASIC programs are a bit iffy, but developed places, like Hong Kong, still use BASIC almost exclusively. In the hands of competent people its quick and cheap to install, and does the job well. The people working with it love it, as its so quick and simple to use. If you actually get the job done, and the program does its job before maintenance start to degrade it, its fine. -
Bamboo is carbon negative and will remain available after the nuclear war. As will BASIC.
Computers fast enough to compile R@#$ code within human lifetime, not certainly
They know what they are doing. -
I am feeling less guilty about my ignorance of the complex data type in C. When googling C Data Types, the first five answers, starting with the new AI "summary", followed by Wikipedia and the next three returned responses don't mention a complex data type. Same with the 700 page C training book I got in 1997, even as a possibility for the future. So it didn't have complex data from its start at ATT, through its explosion in popularity, through ANSI C and the 1995 update. It seems that the vast majority of the users of the language didn't miss its absence much, and probably a significant proportion of that population is unaware of its availability to this day.