Like some of the sibling posters, I'll use this opportunity to share my feelings on Ada. I checked it out a few years ago, and I was amazed at how much it has to offer. Despite being designed by committee in the late 70s, Ada has many features that remain novel by today's standards. I'd say Ada is a 'must see' for anyone interested in implementing new programming languages, there are many great lessons language designers can take away from Ada.
It was also heavily negatively influenced by C++. If you like reading lots of hilarious ideological, syntactic, and semantic ranting and raving about how terrible C++ is, pick up one of Bertrand Meyer's original Eiffel books (from before Java, which is another negative reaction to C++ in a different direction), you'll love it!
Where I think it broke down is with multithreading, because you can't reason about preconditions and postconditions of a method if there are other threads banging away at it. But maybe that's been solved since when I read the Eiffel book.
Sather is an open source language that was originally based on Eiffel, but developed in its own direction. Named after the Sather Tower at Berkeley instead of the Eiffel Tower in Paris.
One benefit I had from learning Ada was that it treats encapsulation, implementation hiding, inheritance, subclassing, message passing, etc. as separate mechanisms that you can opt into individually.
This is a huge difference compared to something like Java or Python where "everything is a class and a class is everything", and if you desire implementation hiding you sort of automatically also opt into get encapsulation and subclassing and the rest of it.
When you learn the mechanisms individually, object-oriented programming starts to make a lot more sense! Ada is worth looking at just for that experience alone! Then the other things are a bonus.
This connects to another of Ada's advantages: language-integrated support for
subsetting the language. In the C world, you can define a subset of the
language, but if you want a tool to ensure compliance, you're on your own.
With Ada, you can define a 'profile' and have the compiler check compliance.
This has been done with the Ravenscar profile (for real-time work) and, most
famously, the SPARK profile (for formal verification).
(There isn't integrated support for user-defined style guide conformance
though. From the perspective I've used here, MISRA C is both a subset and a
style guide.)
You can get going with the Alire package manager which installs the Free Software Foundations GNAT compiler (part of GCC) in a few minutes: https://ada-lang.io
Despite being designed by committee in the late 70s
You say that like it stayed there. Ada has been updated and refined continually since the first standard in 1983. Ada 2012 is the latest approved, and Ada 202x is in review.
Just like Fortran (see Fortran 90, 95, 2003, 2008 & 2018).
My apologies. I was only referencing the typical criticisms people have of the language. Most of which having absolutely nothing to do with the language itself. I'm very familiar with modern Ada. I've done lots of hobby programming in Ada 2012, and now Ada 202x.
You know what's a lot like Ada in a good way is Mesa, which evolved into Ceder, from Xerox PARC. I know people who really loved programming in it. They'd call it "Industrial Strength Pascal". It was a successful experiment in code reuse. A strongly typed language with strong separation between interfaces and implementations, which encouraged creating robust, hardened code.
>Mesa and Cedar had a major influence on the design of other important languages, such as Modula-2 and Java, and was an important vehicle for the development and dissemination of the fundamentals of GUIs, networked environments, and the other advances Xerox contributed to the field of computer science.
Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)
Mark Weiser and others at Xerox PARC's ported the Cedar environment to Unix, which resulted in the development of the still-widely-used Boehm–Demers–Weiser conservative garbage collection.
I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it.
Experiences Creating a Portable Cedar.
Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser.
>Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the performance of our "Portable Cedar".
PCR implemented threads in user space as virtual lightweight processes on SunOS by running several heavy weight Unix processes memory mapping the same main memory. And it also supported garbage collection. Mark Weiser worked on both PCR and the Boehm–Demers–Weiser garbage collector.
>Similarly, we treat any data inside the objects as potential pointers, to be followed if they, in turn, point to valid data objects. A similar approach, but restricted to procedure frames, was used in the Xerox Cedar programming environment [19].
[19] Rovner, Paul, ‘‘On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent Language’’, Report CSL-84-7, Xerox Palo Alto Research Center.
My guess is that the BDW garbage collector had its roots in PCR (pun intended, in fact this entire message was just an elaborate setup ;), but I don't know for sure the exact relationship between Cedar's garbage collector, PCR's garbage collector (which is specifically for Cedar code), and the Boehm–Demers–Weiser garbage collector (which is for general C code). Does anybody know how they influenced each other, shared code, or are otherwise related? Maybe there's a circular dependency!
This says “developed after the Star“ but imho the Dandelion (marketed as the star) was too slow for this environment and you needed one of the bigger machines (Dolphin or Dorado).
Actually it’s kind of amazing to realize that two years later youncould get a small Mac for about a fifth the price that sat on your desk (not rolled next to it on casters) and was much more responsive. Did less, but what it did it did well, and was all that most people needed.
In addition to the Smalltalk and Mesa environments mentioned in the post, there was the Interlisp-D environment too, which got much more use outside thanks to being used outside PARC.
pjmlp on Sept 13, 2020 | parent | next [–]
The Computer History Museum organized a session with Eric Bier, and several other folks demoing the Mesa/Cedar environment.
The only modern environments that seem to have kept alive several of these ideas are Windows/.NET/COM, the ones designed by Apple/NeXT and to certain extent Android (although with a messed up execution).
Even Linux could grasp many of these ideas, if D-BUS would be properly taken advantage of and settled on a specific development experience.
Somehow it looks like we are still missing so much from Xerox PARC ideas.
----
The Cedar Programming Environment:
A Midterm Report and Examination
Describes Portable Common Runtime (PCR), and the PostScript and Interpress decomposers implemented in Cedar, and includes many other interesting document about Cedar.
