Replies: 7 comments 8 replies
-
|
Welcome to the community. I'll surely have more to say, but first, I have to
read your post.
…On 3/27/24 21:32, gundam00 wrote:
(* FROM C++ TO MODULA-3 --- (28 March 2024) *)
Greetings Modula-3 community, this is my first post.
This post may appear long-winded, but I have chronicled the early stages of my potential "Modula-3 Odyssey" in case this may save time (or add confidence) to others when/if deciding to engage this fine programming language.
I have been very impressed with my recent experiences with Modula-3.
My intent is for Modula-3 to replace C++ as my primary systems programming language.
I am confident in this intent; the Modula-3 language is well-endowed and a good tool for making libraries. As such, any future posts will have a similar title-format (with updated date field) to facilitate search of these posts.
BEWARE:
There may be some slight ranting and ideology-speak, connected to my interest for coding ....
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[INTRO]
A bit of my coding background:
* prior to 1991, coding with the BASIC programming language
* since 1991, coding using C/C++ languages; at the time (1991) the "trend" was the C-language and being an outsider (an applied-science guy starting his postgraduate research) I went with the "trend" but was always cognisant of PASCAL due to my interest in programming since my BASIC days.
* picked up a little Python when dealing with the SCONS C++ build tool back around 2010; was not really into that Python language
* recently learned Julia programming for a "stats/modelling" project I am working on ...
* since my postgraduate university days, Linux has been my primary operating system with less exposure to FreeBSD/OpenBSD/Windows.
About a year ago I had setup a multi-boot Windows/Linux/OpenBSD "box" for an engineer/finance guy and who happen to have a PASCAL programming background. This provided me an opportunity to check out what has been happening in the PASCAL side of the "programming universe"; I remember Borland's "Turbo Pascal" product back in the early days, I had used Borland's OWL/VCL C++ toolkits back then.
The "box" was setup and I moved on, continuing my C++ coding.
However, I had been sensing "issues" in the C++ programming language during recent years and my journey into the PASCAL side of the "programming universe" made me realise a replacement for C++ may exist.
Since the completion of the "box", I spent a few weeks of my personal time {reading, light-coding} on the Oberon and Modula-3 languages. Ultimately, I selected Modula-3. One of the main reasons was the thread/lock detail built into the Modula-3 language. For many years I have been using my own port of the DLIB C++ library, especially making use of it's concurrency patterns. I'll be porting these patterns to Modula-3 in future.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[GIVING MODULA-3 A TEST RUN]
Back in late November 2023, I started porting the C++ components of my OpenGL-based simulation/game engine to Modula-3. I gave myself a 2-month period, i.e. Dec-2023, Jan-2024, to assess the Modula-3 "effect".
As of Feb-2023, I am of the opinion that Modula-3 ..... ROCKS ...... !!!!!!!!!!!!!!!!!
As someone said back in the 1990's, Modula-3 is an "elegant" language.
The M3 (i.e. Modula-3) language has a degree of "polish" and "battle-hardness".
I suspect the programming language oracles/gurus/etc. at DEC/Olivetti/CM3/etc. (1990's) realised the problems the C++ language will have in the decades to come;
e.g. consider this comment from Scott Meyers back in 2018 [2] ...
"C++ is a large, intricate language with features that interact in complex and subtle ways,
and I no longer trust myself to keep all the relevant facts in mind." .
There is also that bit of history concerning the Modula-3 language designers giving themselves a "complexity budget" of fifty pages whilst others believed that a programming language had to be complex to be powerful.
Modula-3 shows effectively that there is
POWER in SIMPLICITY
and this is the paradigm I prefer.
My recent Modula-3 experience has made it obvious to me that:
* M3 is a better/safer tool than C++ for encoding knowledge into software code; "grass roots" module support is very important and M3 shines here.
* M3's strictness that generics only accept interfaces is a good idea (very practical as you'll quickly find out)
* M3's generics is a simpler/sane alternative to what templates is to C++; too many times I have fought the C++ compiler because of certain not-so-obvious complexities related to C++ templates
* M3 is more structured than C++, facilitating a "lower cognitive-load" (i.e. a "simpler experience") whilst producing code.
I am reminded of Modula-3 comments back in the 1990's implying the Modula-3 language having the power of C++/Ada languages but with a lighter footprint.
Don't be fooled into thinking that the small {late 1980's, early 1990's} temporal period used to develop/test/use the M3 language, prior to it's "vanishing" (related to DEC's "demise" ?), is a limiting factor. The language was/is "complete"; a good platform to make useful libraries.
In contrast, C++ was never "complete" as evidenced from successive committees growing/bloating the language. My questions are :
==> How far can you bloat the C++ language while it has it's dangerous C core detail ?
==> How many levels of abstractions/wrappers are you going to accept just so that you avoid that dangerous C core ?
==> How many more "concepts" are you going jam into an ever-growing C++ programming language, distracting the coder from the important "rule" that a programming language should be EASY TO USE.
--> A "concept" can be fine as long as it is introduced as early as possible in a framework (i.e. programming language) to allow for a natural/logical/simple amalgamation of that concept with the existing detail of that framework. Continuously tacking on a foreign/new concept to an existing mature framework without a periodic re-design (or review) of the original framework can be flawed and quite dangerous since a "stopping criterion" for avoiding the "tacking effect" get's more difficult as users of the framework get more reliant on the uber-tacked framework.
A deprecation model/paradigm helps, but requires discipline and we humans, at times, can be lazy.
We should not lose sight of CORE (commonly-used) concepts and ELECTIVE (not so commonly-used, specialised) concepts.
Leave CORE concepts in the programming language definition.
ELECTIVE concepts should be at library level and ideally, composed from CORE concepts.
Due to time constraints, a single programming language cannot be all things to everybody.
There is utility in DSLs; i.e. domain-specific languages.
e.g. Later, I will superficially describe my custom Modula-3 software development environment.
This environment could have been developed wholly in Modula-3, but that would not have been efficient use of my programming time. Through a DSL-like approach, better use of my programming time was achieved by leveraging the {bash, C (as script), AWK} languages.
An ever-growing C++ standard implies/assumes a broader use of C++ as being valid.
Is that assumption safe, whilst we know of the utility of the DSL paradigm ?
What I like about the Modula-3 programming language is that it "knows it place" and does what it was designed to do ... very well.
Modula-3 is a hidden gem and :
==> DEC's demise
==> copyright/licensing issues with GCC community
probably contributed to Modula-3 not being popular.
The Modula-3 distribution has an impressive list of libraries (packages).
These packages can be customised (enhanced) according to your own needs/design by simply :
==> copying the package's source code from "system" repository to own repository (i.e. filesystem)
==> modifying the copied package code.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[MODULA-3 TOOLING]
For some, the lack of "tools" can become a deal-breaker and they end up not embracing a programming language.
I tried the web-browser based "reactor" cm3-ide tool but was not my "cup of tea". Amongst other things, I did not want my programming workflow to rely on an Internet browser even if used in
context of a local connection.
I'm a "xterm"-jockey.
Being impressed with the Modula-3 programming language, I began development of Modula-3 tools in Feb-2024; analogous to tooling I have developed for my C++ programming workflow but customised for the Modula-3 case.
I am not fond of conventional IDE's (integrated development environments).
The last IDE I used was SunStudio's IDE in the OpenSolaris days.
Basically, I treat the operating system (OS) as an IDE and my IDE system relies on :
* bash language
* fltk-dialog program
* C-code script (executed by Tiny-C-Compiler)
* AWK script
* multiple xterm sessions
* JOE text editor with a Modula-3 syntax-highlighter
* Midnight commander visual shell
* command-line utilities like grep accessable from GUI (fltk) facade .
The result is a customised/practical/efficient GUI-dialog based programming
environment for the Modula-3 language. There is a "root" (i.e. top-level) dialog with
scrollable radio-button options. A radio-button is clicked with mouse, a "OK' button is
clicked with mouse, then something happens; detail is output to an associated xterm so the user always realises what's going on.
Tasks include :
==> package-directory creation and populating directory with template files (e.g. m3makefile)
==> per-package interface/implementation ("module") file-creation
==> package-building
--> building a specific library package
--> building a specific exe package
--> building multiple library packages
--> building multiple exe packages
--> building all library packages
--> building all exe packages
==> package-cleaning
--> ...
==> string search in Modula-3 source code files
==> checks for cyclic-importations between modules; I do this purposely, before the compiler realises the cyclic-imports.
==> maintains a package-dependency database so that lib/exe packages are always successfully built (assuming no syntax errors in Modula-3 source code); my IDE system forces the compiler to build less dependent packages before more dependent packages.
==> generates module-dependency diagrams (PDF files) to facilitate better code visualisation
==> generates/updates m3makefiles automatically,
==> etc.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[EXTERNAL C LIBs]
Some believe Modula-3 lacks support for a broad range of external C libraries.
Remember, Modula-3 did not reach mainstream status and, so, this should not be a surprise.
However, this problem is easily solvable since the Modula-3 FFI (foreign function interface) is fine (intuitive) through use of EXTERNAL pragma.
I built a Modula-3 version of GLFW's OpenGL "gears" demo [3] to test Modula-3's EXTERNAL pragma:
==> accessed GLFW [3] library detail using :
--> EXTERNAL pragma
--> GLFW C source code through c_source() calls in m3makefile
==> accessed GLAD2 OpengL loader detail [4] using :
--> EXTERNAL pragma
--> GLAD2-generated C source code through c_source() calls in m3makefile
==> "gears.c" [3] was the only C code that I ported to Modula-3
==> RESULT: hardware-accelerated OpenGL "gears" program executed fine.
If the external C library is relevant, then spend the time to port it to Modula-3 using the EXTERNAL FFI and possible use of c_source() statements in m3makefile.
NOTE:
The "reactor" CM3-IDE user's guide has a relevant section on accessibility between {Modula-3, C} languages, concerning the EXTERNAL pragma.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[UPPERCASE KEYWORDS]
Some may have a problem with Modula-3's uppercase {keywords, reserved words}; e.g. use of uppercase words would potentially provide a "productivity" hit due to use of extra caps-lock key.
Or, there may be too much visual-contrast when mixing frequent use of uppercase words with lowercase words.
I admit that when first encountering Modula-3, coming from a C/C++ background, the notion of "forced" use of uppercase words was "strange". However, you'll quickly accept the use of uppercase words as you realise the expressive-power that is the Modula-3 programming language.
The uppercase words, visually, act as good code-delimiters allowing the source code to be perceived, by us humans, as having more structure. The use of a syntax-highlighting-text-editor also helps make these uppercase words manifest well.
Up to now, porting of my C++ libraries/exes to Modula-3 has resulted in production of 69 library/exe packages.
I look at Modula-3 code and it's structured ...... "beautiful".
I don't see this with C++ code.
That's the Modula-3 effect ......
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[DOCUMENTATION]
There have been complaints about lack of documentation for the Modula-3 language.
I have noticed a good amount of documentation for the Modula-3 language especially for a language that did not hit mainstream status like C/C++/Java.
Documentation can be found in the "/docs/help" directory of the distribution
cm3-dist-AMD64_LINUX-d5.11.4 .
The "/docs/help/index.html" file is a top-level web-page used to access the info.
Note: The language reference is accessible from the tutorial page.
"Missing info" cases are probably related to extra detail for certain Modula-3 features being located in various other references and, hence, possibly difficult to find.
e.g.
While I like Nelson's book as a Modula-3 reference, a few times I did find lack of detail which was remedied with detail I found on the Internet.
e.g.
The "reactor" CM3-IDE user's guide has a relevant section on accessibility between {Modula-3, C} languages, concerning the EXTERNAL pragma. I would have liked Nelson's book to have similar concrete examples for EXTERNAL pragma.
TAKE THE TIME TO LIGHTLY READ ALL THE DOCUMENTATION MATERIAL, PRIOR TO DIGGING DEEPER.
Modula-3 is purposely feature-packed in a relatively small language footprint.
Initially, certain subtle features may be missed ... not learned.
I have seen questions about language features, from "new" users", which correspond to answers in the documentation material. i.e. READ THE DOCS .....
My only real hassle was the inability to link the system's Xlib (X11) library with my own-built Modula-3 coded executable program. Ultimately I resorted to viewing the Modula-3 distribution's .../AMD64_LINUX/.M3EXPORTS files for the built GUI-based packages to, hopefully, learn how a Modula-3 package implements linkage with the X11 subsystem.
I found the import_sys_lib("X11") command was being used.
I, now, use this command in my own m3makefiles.
My approach has been to create a ZIM desktop wikibook for the Modula-3 language, based on :
--> documentation in the Modula-3 distribution
--> detail learnt from Nelson's book
--> detail learnt from Harbison's book
--> internet references for Modula-3 detail
--> my own experiences porting my C++ code to Modula-3 .
This desktop wikibook has become my Modula-3 reference.
Some useful internet links for Modula-3 language info include :
https://modula3.github.io/cm3/tutorial/m3/m3_toc.html
https://modula3.github.io/cm3/help/interfaces.html
https://modula3.github.io/cm3/help/concise-bib.html
https://modula3.github.io/cm3/reference/complete/html/Modula_3_Language_definitio.html
http://www.faqs.org/faqs/Modula-3-faq/
The DEC SRC reports can be useful.
Articles related to the theme "How The Language Got Its Spots" can be useful
as they give insight to the design of Modula-3 language; the detail on generics
was very insightful.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[GARBAGE COLLECTION]
Garbage collection can be a very controversial/ideological topic for someone.
I'm a practical guy ... in general, something may either "work" or "not work" and will depend on the effort you put into design/implementation detail.
I have come across the the FUD related to garbage-collected languages but this should not scare
you from exploring the garbage-collection experience; especially when reading articles on the pros of garbage collection.
Modula-3 has both "traced references" and "untraced references".
Think of "references" in Modula-3 as being analogous to "pointers" in C/C++.
"traced references" refer to memory in the "traced heap" and managed by the garbage collector.
"untraced references" refer to memory not traced by the garbage collector.
Apart from the garbage-collector role, traced/untraced references are the same.
So, with Modula-3, you have access to both types of non-stack memory;
i.e. garbage-collected memory-management and human-based manual memory-management.
The latter is useful in case a program cannot afford the garbage-collection "cost".
Up to now, my Modula-3 demo programs did not use manual memory-management.
These programs build fast and execute fast.
My realtime, but simple, Modula-3 non-manual-memory-managed version of the OpenGL "gears" demo was executing fine/fast.
As I port concurrency patterns from C++ to Modula-3, this is where I'll be stress-testing Modula-3's garbage-collector; Re: concurrency related memory-management.
Ultimately, if required, I will use manual-memory-management for specialised
portions of source code to attempt to achieve "realtime" simulation performance targets
whilst the remaining code is garbage-collected.
The advantages of garbage-collection can be immense and would be foolish to
not explore this memory-management paradigm, at least to determine it's potential usefulness.
For example :
"A classic unsafe runtime error is to free a data structure that is still reachable by active references (or "dangling pointers"). The error plants a time bomb that explodes later, when the storage is reused. If on the other hand the programmer fails to free records that have become unreachable, the result will be a "storage leak" and the computation space will grow without bound. Problems due to dangling pointers and storage leaks tend to persist long after other errors have been found and removed. The only sure way to avoid these problems is the automatic freeing of unreachable storage, or garbage collection." [1]
Unlike C/C++, Modula-3 is "essentially" memory-safe.
I would rather spend time with the safe Modula-3 language (even with it's safety-overhead and extra time in designing optimal use of the garbage-collector by my algorithms) rather than relying on a slightly higher performing unsafe language like C++.
If coding was only about performance then we would all be assembly language programmers.
It's about balance of programming language features.
In Modula-3 :
--> REF is used to declare a traced-reference; Re: garbage-collected memory-management
--> UNTRACED REF is used to declare an untraced-reference; Re: manual memory-management.
--> avoiding the above keywords implies a stack-based declaration, analogous to other languages (e.g.C/C++).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[FINAL COMMENTS]
As in Geoff Wyant's 1994 article "Introducing Modula-3" in Linux Journal,
you'll especially appreciate Modula-3 after doing alot of C++ coding.
My Linux box used for exploratory Modula-3 development is :
==> single processor; 2014 Intel i5 CPU
==> 4GB system memory
==> OS (uname -a) --> Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux .
From what I have ported to Modula-3 (from C++), I can say that the cm3 compiler works fast.
Error message syntax gets more understandable as you use the language; a section-number quoted in an error message refers to a section in "language definition".
The grass-roots (fundamental) nature of the "modular programming" paradigm within the Modula-3 language has been a big game-changer for me in terms of programming language themes.
Sure, C/C++ can attempt to simulate a file-level "module" approach but this will always be a hack.
The fundamental nature of the Modula-3 version of "modules" is so much more than what C/C++ could ever achieve because these latter languages were not designed from scratch to support a module paradigm; e.g. consider the importance of the "module unit" in Modula-3's generics.
Note: I am fine when using the C language for low cognitive-load targets like producing small utilities; C was not designed to handle large scale projects as we know them now. That is, use a tool where it has scope, and not use it outside of it's practical scope.
I have been spreading the word about Modula-3 to acquaintances.
Modula-3 made me realise the kitchen-sink-C++-experiment existed for far too long.
It was beneficial that the Modula/Oberon series of languages learned and partitioned themselves
from the less desirable portions of their PASCAL base, unlike C++ and it's C base.
Some may think, possibly early-stage-programmers or non-programmers, that spending so many years and effort on an initial language (C++ in my case) and then dropping it for another language implies a waste of time spent on the former language.
NO, this is wrong-thinking.
The role of a computer programming language is to translate
the higher-level (abstract) representation of algorithms/ideas from our mind (brain)
to
a lower-level representation as computer source code (in a text file).
Any decent programming language does this translation at varying degrees of success.
I suggest the level of success is connected to "congnitive-load" implied by the translation process.
i.e.
A lower cognitive-load means simpler thinking, by the human, is required for the translation.
A higher cognitive-load means the translation is more difficult for the human.
As mentioned previously, and purposely designed/implemented by the language designers of Modula-3, Modula-3 enforces structured-coding through a relatively low cognitive-load.
My experience is that the C++ route involves a higher cognitive-load.
C++ has turned into a bloated mess.
I'd rather use all of the features of a well-designed smaller-conceptual-footprint language (Modula-3) rather than a kitchen-sink language (C++) having much/redundant conceptual detail you will never use much. Use the lightweight-core of Modula-3 to create custom concepts in your libraries.
I'm an applied scientist and prefer to unravel the complexity of certain favourite-to-me themes in science/mathematics whilst not expecting to be slowed down by the complexity of a computer language, hence my interest in Modula-3.
My main regret with C++ is that I spent too much time fighting the language,
implicitly thinking it was the be-all-end-all ....
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[REFERENCES]
1. https://modula3.github.io/cm3/reference/complete/html/0_0_0_6_1_4_6_Garbage.html
2. https://scottmeyers.blogspot.com/2018/09/the-errata-evaluation-problem.html
3. https://www.glfw.org/
4. https://gen.glad.sh/
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
—
Reply to this email directly, view it on GitHub <#1177>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNFDRJQX4FYBR5SD7ALY2N6LXAVCNFSM6AAAAABFL7POH2VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGQZDSOBZG4>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's very interesting article. Thank You! P.S. Are you use m3cc part of cm3? And are You try m3swig utility? |
Beta Was this translation helpful? Give feedback.
-
|
Hello Victor. Re: "m3cc" part of cm3 I am aware of m3swig but for now I have been manually coding foreign-function (C) support, through EXTERNAL pragma, due to small set of foreign functions used in demos. This provides opportunity to get familiar with Modula-3's support for foreign C function access. |
Beta Was this translation helpful? Give feedback.
-
I am not sure: may be m3back related, may be it's not related If Calculator and ( or) Cube application examples are in worked state then "all is good" Please, see latest error on GitHub I.e
Ok ( May be I will add links to m3swig to this msg) |
Beta Was this translation helpful? Give feedback.
-
|
This article was lying in my bookmarks for a year until I finally found the time to read it. I mostly agree with what you wrote and even our path through programming languages is similar, except that I started with Modula 2 ;-) Unfortunately, 15 years ago I parted ways with my academic work and went to work in a corporation. I no longer have the ability to decide for myself what code base I use, and here C++ reigns supreme. Young programmers get excited about new versions of the language standard and new versions of boost. As a result, I ended up as the maintainer of a program that needs Python/SCons, Perl, AWK, C, CPP, C++, C++ std, C++ boost and Qt to compile :-) Diversity is good, but fragmentation is a disaster... Your article reminded me of my plans to try to rewrite it for M3. Thanks. PS. This program I'm working on is a cli tool without a GUI but someone had the idea that QString could be useful ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Greetings. Your "C++ reigns supreme" comment is very familiar. The problem with "new versions of the language standard" is that it can lead to, in the long-term, recurring incrementalism and possibly leading to a bloaty language. Young, very "green", programmers won't see this coming and more likely embrace trends for the sake of embracing trends. I have written a follow-up (about one year later) article to this initial "28 March 2024" article at The second (12 Jan 2025) article is much much much shorter than this first (28 March 2024) article and is in agreement with most of my stances from "28 March 2024" article. The major change has been re-implementation (with enhancements) of my Modula-3 development environment from use of multiple-programming-languages (bash,C,C++,AWK) to a single programming language being the Icon programming language; https://www2.cs.arizona.edu/icon/ . Icon is a "gem". Previously, my M3-dev environment was a relatively high-cognitive-load "frankensteinish-beast". Again, thank you for the reply. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if it's the same Icon, but in the late 1980s I once wrote a program for symbolic differentiation in this language ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, David Hanson's name shows up there. He's the guy who ported
Modula-3 programming to C.
https://www.amazon.com/exec/obidos/ASIN/0201498413/drh-cii-20
…On Wed, Mar 19, 2025 at 4:53 AM Dariusz Knociński ***@***.***> wrote:
I don't know if it's the same Icon, but in the late 1980s I once wrote a
program for symbolic differentiation in this language ;-)
—
Reply to this email directly, view it on GitHub
<#1177 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJLWDSY3HMNXYJHLI2D2VFLCPAVCNFSM6AAAAABZAHFDOGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVGA3TENA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
. . . . . . {think} Okay, let's see. The user mentioned David Hanson and that he ported Modula-3 to C. I remember that Modula-3 is a programming language, but I'm not entirely sure about its specifics. Let me start breaking this down. {/think} David Hanson is indeed a notable computer scientist known for his contributions to programming languages and compiler design. While the statement about him porting Modula-3 to C might be slightly ambiguous, here's a clarified breakdown of his relevant work:
Clarifying the "Port": Legacy: |
Beta Was this translation helpful? Give feedback.
-
I have a good news to You: I go to library and take book. Modula-3, xi, 31, 63, 100, 161, 169, 180, 464, 466 P.S. Strange book . . . Sedgewick, R. 1990. Algorithms in C. Reading, Mass.: Addison-Wesley. And -- "all" Sorry: 1990 vs 1993 P.P.S. Please, See my post: Robert Sedgewick, Algorithms in Modula-3, Addison-Wesley, ISBN 0-201-53351-0, L.C.QA76.73.M63S43, 1993. ISBN-13 978-0-201-53351-4 |
Beta Was this translation helpful? Give feedback.
-
|
Wow that's very wordy and while it does (in the end) say something
relatively relevant, all I really meant was this:
1. Modular Programming in C:
• Hanson's book "C Interfaces and Implementations" (1997) demonstrates
how to structure C code using Modula-3-inspired modularity. It promotes
encapsulating data and functions into reusable, interface-driven modules
(split into .h and .c files), mirroring Modula-3's strict separation of
interfaces and implementations.
• This approach brought Modula-3-like clarity and safety to C, helping
developers manage large-scale projects more effectively.
But the AI has clearly not actually read the book.
I just dug up my copy ... not *everything* is online, you know. And the
AIs don't really understand anything anyhow.
The approach doesn't just mirror the separation of interfaces and
implementations. In the book, one thing he does is he basically re-codes a
bunch of the standard Modula-3 interfaces in C. A lot of it is
straight-out translated from SRC M3 sources directly to C.
There's also an implementation of Modula-3-like exceptions in C. And a
bunch of other relevant stuff.
Sorry I don't know how to feed the paper book into an AI to summarize it
for those who can't bother to read it.
Just buy a copy and read it if you have any interest in C programming,
especially if you also have interest in Modula-3. I've recommended it to a
lot of people who might have been forced to code in C for some reason.
Mika
…On Wed, Mar 19, 2025 at 10:50 PM VictorMiasnikov ***@***.***> wrote:
. . .
( . . .) book "A Retargetable C Compiler: Design and Implementation" by
Christopher Fraser and David Hanson describes lcc, their C compiler
. . .
LLM served by Perplexity Labs
{think} Okay, let's see. The user mentioned David Hanson and that he
ported Modula-3 to C. I remember that Modula-3 is a programming language,
but I'm not entirely sure about its specifics. Let me start breaking this
down.
First, who is David Hanson? A quick mental note: he's a computer scientist
who has contributed to several programming languages. I think he worked
with Brian Kernighan and Rob Pike, maybe on books like "The Practice of
Programming." Also, he’s known for his work on lcc, a C compiler. But the
user is specifically saying he ported Modula-3 to C. Hmm, porting a
language usually means translating its compiler or runtime to another
language. So Modula-3's compiler or runtime might have been implemented in
C by Hanson.
Modula-3 itself: I recall it's a successor to Modula-2, designed in the
late 80s, emphasizing safety, simplicity, and concurrency. It had garbage
collection, exception handling, and object-oriented features. Now, porting
it to C might have involved creating a compiler that translates Modula-3
code to C code, which is then compiled using a C compiler. That was a
common practice for portability, as C compilers are widely available.
Wait, but the user says "ported Modula-3 programming to C." Maybe that's
ambiguous. Does it mean he ported the Modula-3 language implementation to
C, or translated programs written in Modula-3 to C? Probably the former.
So, Hanson might have written a Modula-3 compiler in C, or created a
transpiler from Modula-3 to C.
Looking into historical context, there's a system called SPIN written in
Modula-3, but that's an operating system. Not sure about the connection.
Alternatively, maybe Hanson was involved in a project that used C to
implement Modula-3's features, like garbage collection or modules.
Wait, another angle: Modula-3's original implementation might have been in
another language, and Hanson ported it to C. Let me check my memory. I
think the original Modula-3 compilers were written in Modula-3 itself,
which is common for languages (self-hosting). To bootstrap, they might have
used a C-based compiler. That's possible. So Hanson might have created a
Modula-3 compiler in C to bootstrap the language on new platforms.
Alternatively, he could have worked on a system that allows Modula-3 code
to interface with C, or to translate Modula-3 code to C for better
portability. For instance, some compilers generate C as an intermediate
step, like how Vala translates to C.
But the exact details are fuzzy. I need to verify. From what I know, the
book "A Retargetable C Compiler: Design and Implementation" by Christopher
Fraser and David Hanson describes lcc, their C compiler. That's a primary
source. However, the connection to Modula-3 is unclear here. Maybe another
project.
Alternatively, Modula-3's official implementation from DEC and Olivetti in
the early 90s included a compiler that generated C as an intermediate. If
that's the case, Hanson might have been part of that effort. But I'm not
sure. Another possibility is that Hanson used techniques from Modula-3 in
C, perhaps in writing lcc, which is a retargetable compiler written in C.
Wait, the user might be conflating different projects. Hanson's main
contributions are in C compilers and programming tools. Maybe there's
confusion between Modula-3 and another language. Let me cross-reference.
Searching in my mind: Oh, wait, there's also the book "C Interfaces and
Implementations" by David Hanson, which talks about creating modular
programs in C, inspired by concepts from languages like Modula-3. This book
shows how to implement abstractions similar to Modula-3's modules in C,
using interfaces and implementations separated into .h and .c files. So
perhaps Hanson didn't port Modula-3 to C per se, but adapted some of its
design principles into C programming practices.
The user's statement might stem from that book. The techniques in the book
allow C programmers to use a style similar to Modula-3's modules, thus
"porting" the programming paradigm or methodology to C, rather than the
language itself. That makes sense. So, maybe Hanson's work is more about
adopting Modula-3's modular programming concepts in C, rather than a direct
port of the language.
Alternatively, he might have written a tool that converts Modula-3 code to
C code. But I don't recall such a tool being widely known. More likely, his
contributions are in applying Modula-3's ideas to C programming, especially
in creating modular and reusable components, as detailed in his book. This
approach would make C codebases more maintainable and modular, similar to
how Modula-3 enforces interface and implementation separation.
So, putting this all together: David Hanson is recognized for his work on
C compilers (like lcc) and for promoting modular programming techniques in
C, influenced by Modula-3. The "porting" might refer to transferring
programming concepts rather than the language itself. The user's statement
might be slightly misphrased, but the core idea is Hanson's influence in
bringing Modula-3-like modularity to C through his writings and compiler
work.
I should verify key points. The book "C Interfaces and Implementations"
does indeed present techniques for modular C programming, which are
inspired by Modula-3's design. Hanson's work with Fraser on lcc also
emphasizes portable and modular compiler design, which might draw from
Modula-3's principles. Therefore, the answer should clarify that Hanson
didn't port the language itself but adapted its concepts into C programming
practices and tools.
{/think}
David Hanson is indeed a notable computer scientist known for his
contributions to programming languages and compiler design. While the
statement about him porting Modula-3 to C might be slightly ambiguous,
here's a clarified breakdown of his relevant work:
Key Contributions and Context:
1. Modula-3 and Its Influence:
• Modula-3 (developed in the late 1980s) is a systems programming
language emphasizing safety, modularity, and concurrency. It introduced
features like garbage collection, interfaces/implementations, and exception
handling.
• Hanson did not "port" Modula-3 itself to C in the literal sense
(e.g., creating a full compiler or runtime). Instead, his work focused on
adapting Modula-3's design principles for use in C programming.
2. Modular Programming in C:
• Hanson's book "C Interfaces and Implementations" (1997) demonstrates
how to structure C code using Modula-3-inspired modularity. It promotes
encapsulating data and functions into reusable, interface-driven modules
(split into .h and .c files), mirroring Modula-3's strict separation of
interfaces and implementations.
• This approach brought Modula-3-like clarity and safety to C, helping
developers manage large-scale projects more effectively.
3. Compiler Work:
• Hanson co-authored the lcc compiler (a retargetable C compiler
described in "A Retargetable C Compiler: Design and Implementation" with
Christopher Fraser). While lcc is written in C and focuses on portability,
its design principles may reflect lessons from Modula-3’s emphasis on
simplicity and modularity.
4. Collaboration with Industry:
• During his career, Hanson worked at Bell Labs and collaborated with
figures like Brian Kernighan, contributing to tools like awk and
programming practices that emphasize code maintainability—principles
aligned with Modula-3's philosophy.
Clarifying the "Port":
The phrasing about "porting Modula-3 to C" likely refers to Hanson's
efforts to translate Modula-3's programming paradigms into C idioms, rather
than a direct technical port of the language. His work enabled C
programmers to adopt modular, type-safe patterns reminiscent of Modula-3,
bridging the gap between the two languages' design philosophies.
Legacy:
Hanson's ideas continue to influence modern C programming,
particularly in systems where modularity and code organization are
critical. His book remains a foundational resource for developers seeking
to write robust, maintainable C code.
—
Reply to this email directly, view it on GitHub
<#1177 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJMYZR6WGWFRSN6JU632VJJI7AVCNFSM6AAAAABZAHFDOGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVHE3DEOA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
( Sorry for GitHub e-mail robot formatted)I.e. AI write total false / anti- information? Good=} I will write to athtor of book and directly ask him.( About send money to America... Good =} Can You buy book "Эль-76"? First do it. Or, as minimum, send me algorithm.And where is my write rights to cm3 main branch?I read policy - no problem to do it after 5-6 years...)"Critics - I love it"
2025-03-21 : I start edit
2025-04-09: May be I don't do reformating . . . May be do . . .
|
Beta Was this translation helpful? Give feedback.
-
|
Ah, Belarus..?
On Thu, Mar 20, 2025 at 11:43 AM VictorMiasnikov ***@***.***>
wrote:
… ( Sorry for GitHub e-mail robot formatted)I.e. AI write total false /
anti- information? Good=} I will write to athtor of book and directly ask
him.( About send money to America... Good =} Can You buy book "Эль-76"?
First do it. Or, as minimum, send me algorithm.And where is my write rights
to cm3 main branch?I read policy - no problem to do it after 5-6
years...)"Critics - I love it"----------------
Кому: modula3/cm3 ***@***.***);
Копия: Comment ***@***.***);
Тема: [modula3/cm3] FROM C++ TO MODULA-3 ... (28 March 2024) (Discussion
#1177);
20.03.2025, 20:41, "Mika Nyström" ***@***.***>:
Wow that's very wordy and while it does (in the end) say something
relatively relevant, all I really meant was this:
1. Modular Programming in C:
• Hanson's book "C Interfaces and Implementations" (1997) demonstrates
how to structure C code using Modula-3-inspired modularity. It promotes
encapsulating data and functions into reusable, interface-driven modules
(split into .h and .c files), mirroring Modula-3's strict separation of
interfaces and implementations.
• This approach brought Modula-3-like clarity and safety to C, helping
developers manage large-scale projects more effectively.
But the AI has clearly not actually read the book.
I just dug up my copy ... not *everything* is online, you know. And the
AIs don't really understand anything anyhow.
The approach doesn't just mirror the separation of interfaces and
implementations. In the book, one thing he does is he basically re-codes a
bunch of the standard Modula-3 interfaces in C. A lot of it is
straight-out translated from SRC M3 sources directly to C.
There's also an implementation of Modula-3-like exceptions in C. And a
bunch of other relevant stuff.
Sorry I don't know how to feed the paper book into an AI to summarize it
for those who can't bother to read it.
Just buy a copy and read it if you have any interest in C programming,
especially if you also have interest in Modula-3. I've recommended it to a
lot of people who might have been forced to code in C for some reason.
Mika
On Wed, Mar 19, 2025 at 10:50 PM VictorMiasnikov ***@***.***>
wrote:
> . . .
> ( . . .) book "A Retargetable C Compiler: Design and Implementation" by
> Christopher Fraser and David Hanson describes lcc, their C compiler
> . . .
>
> LLM served by Perplexity Labs
> {think} Okay, let's see. The user mentioned David Hanson and that he
> ported Modula-3 to C. I remember that Modula-3 is a programming language,
> but I'm not entirely sure about its specifics. Let me start breaking this
> down.
> First, who is David Hanson? A quick mental note: he's a computer
scientist
> who has contributed to several programming languages. I think he worked
> with Brian Kernighan and Rob Pike, maybe on books like "The Practice of
> Programming." Also, he’s known for his work on lcc, a C compiler. But the
> user is specifically saying he ported Modula-3 to C. Hmm, porting a
> language usually means translating its compiler or runtime to another
> language. So Modula-3's compiler or runtime might have been implemented
in
> C by Hanson.
> Modula-3 itself: I recall it's a successor to Modula-2, designed in the
> late 80s, emphasizing safety, simplicity, and concurrency. It had garbage
> collection, exception handling, and object-oriented features. Now,
porting
> it to C might have involved creating a compiler that translates Modula-3
> code to C code, which is then compiled using a C compiler. That was a
> common practice for portability, as C compilers are widely available.
> Wait, but the user says "ported Modula-3 programming to C." Maybe that's
> ambiguous. Does it mean he ported the Modula-3 language implementation to
> C, or translated programs written in Modula-3 to C? Probably the former.
> So, Hanson might have written a Modula-3 compiler in C, or created a
> transpiler from Modula-3 to C.
> Looking into historical context, there's a system called SPIN written in
> Modula-3, but that's an operating system. Not sure about the connection.
> Alternatively, maybe Hanson was involved in a project that used C to
> implement Modula-3's features, like garbage collection or modules.
> Wait, another angle: Modula-3's original implementation might have been
in
> another language, and Hanson ported it to C. Let me check my memory. I
> think the original Modula-3 compilers were written in Modula-3 itself,
> which is common for languages (self-hosting). To bootstrap, they might
have
> used a C-based compiler. That's possible. So Hanson might have created a
> Modula-3 compiler in C to bootstrap the language on new platforms.
> Alternatively, he could have worked on a system that allows Modula-3 code
> to interface with C, or to translate Modula-3 code to C for better
> portability. For instance, some compilers generate C as an intermediate
> step, like how Vala translates to C.
> But the exact details are fuzzy. I need to verify. From what I know, the
> book "A Retargetable C Compiler: Design and Implementation" by
Christopher
> Fraser and David Hanson describes lcc, their C compiler. That's a primary
> source. However, the connection to Modula-3 is unclear here. Maybe
another
> project.
> Alternatively, Modula-3's official implementation from DEC and Olivetti
in
> the early 90s included a compiler that generated C as an intermediate. If
> that's the case, Hanson might have been part of that effort. But I'm not
> sure. Another possibility is that Hanson used techniques from Modula-3 in
> C, perhaps in writing lcc, which is a retargetable compiler written in C.
> Wait, the user might be conflating different projects. Hanson's main
> contributions are in C compilers and programming tools. Maybe there's
> confusion between Modula-3 and another language. Let me cross-reference.
> Searching in my mind: Oh, wait, there's also the book "C Interfaces and
> Implementations" by David Hanson, which talks about creating modular
> programs in C, inspired by concepts from languages like Modula-3. This
book
> shows how to implement abstractions similar to Modula-3's modules in C,
> using interfaces and implementations separated into .h and .c files. So
> perhaps Hanson didn't port Modula-3 to C per se, but adapted some of its
> design principles into C programming practices.
> The user's statement might stem from that book. The techniques in the
book
> allow C programmers to use a style similar to Modula-3's modules, thus
> "porting" the programming paradigm or methodology to C, rather than the
> language itself. That makes sense. So, maybe Hanson's work is more about
> adopting Modula-3's modular programming concepts in C, rather than a
direct
> port of the language.
> Alternatively, he might have written a tool that converts Modula-3 code
to
> C code. But I don't recall such a tool being widely known. More likely,
his
> contributions are in applying Modula-3's ideas to C programming,
especially
> in creating modular and reusable components, as detailed in his book.
This
> approach would make C codebases more maintainable and modular, similar to
> how Modula-3 enforces interface and implementation separation.
> So, putting this all together: David Hanson is recognized for his work on
> C compilers (like lcc) and for promoting modular programming techniques
in
> C, influenced by Modula-3. The "porting" might refer to transferring
> programming concepts rather than the language itself. The user's
statement
> might be slightly misphrased, but the core idea is Hanson's influence in
> bringing Modula-3-like modularity to C through his writings and compiler
> work.
> I should verify key points. The book "C Interfaces and Implementations"
> does indeed present techniques for modular C programming, which are
> inspired by Modula-3's design. Hanson's work with Fraser on lcc also
> emphasizes portable and modular compiler design, which might draw from
> Modula-3's principles. Therefore, the answer should clarify that Hanson
> didn't port the language itself but adapted its concepts into C
programming
> practices and tools.
>
> {/think}
>
> David Hanson is indeed a notable computer scientist known for his
> contributions to programming languages and compiler design. While the
> statement about him porting Modula-3 to C might be slightly ambiguous,
> here's a clarified breakdown of his relevant work:
> Key Contributions and Context:
>
> 1. Modula-3 and Its Influence:
> • Modula-3 (developed in the late 1980s) is a systems programming
> language emphasizing safety, modularity, and concurrency. It introduced
> features like garbage collection, interfaces/implementations, and
exception
> handling.
> • Hanson did not "port" Modula-3 itself to C in the literal sense
> (e.g., creating a full compiler or runtime). Instead, his work focused on
> adapting Modula-3's design principles for use in C programming.
> 2. Modular Programming in C:
> • Hanson's book "C Interfaces and Implementations" (1997) demonstrates
> how to structure C code using Modula-3-inspired modularity. It promotes
> encapsulating data and functions into reusable, interface-driven modules
> (split into .h and .c files), mirroring Modula-3's strict separation of
> interfaces and implementations.
> • This approach brought Modula-3-like clarity and safety to C, helping
> developers manage large-scale projects more effectively.
> 3. Compiler Work:
> • Hanson co-authored the lcc compiler (a retargetable C compiler
> described in "A Retargetable C Compiler: Design and Implementation" with
> Christopher Fraser). While lcc is written in C and focuses on
portability,
> its design principles may reflect lessons from Modula-3’s emphasis on
> simplicity and modularity.
> 4. Collaboration with Industry:
> • During his career, Hanson worked at Bell Labs and collaborated with
> figures like Brian Kernighan, contributing to tools like awk and
> programming practices that emphasize code maintainability—principles
> aligned with Modula-3's philosophy.
> Clarifying the "Port":
> The phrasing about "porting Modula-3 to C" likely refers to Hanson's
> efforts to translate Modula-3's programming paradigms into C idioms,
rather
> than a direct technical port of the language. His work enabled C
> programmers to adopt modular, type-safe patterns reminiscent of Modula-3,
> bridging the gap between the two languages' design philosophies.
> Legacy:
> Hanson's ideas continue to influence modern C programming,
> particularly in systems where modularity and code organization are
> critical. His book remains a foundational resource for developers seeking
> to write robust, maintainable C code.
>
> —
> Reply to this email directly, view it on GitHub
> <
#1177 (reply in thread)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABKYNJMYZR6WGWFRSN6JU632VJJI7AVCNFSM6AAAAABZAHFDOGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVHE3DEOA
>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are
receiving this because you commented.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#1177 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJJBSX6T7VX4WCUFAYD2VMD6LAVCNFSM6AAAAABZAHFDOGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJWHAYDMMI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Ok: I'm on computer now... I'm think what it can sense create a new "GitHub Disccussion" P.S. I sent 2-3(6?) years e-mail messages to You Now I see potential problem. Please, send msg to ########### ( VVM: deleted by me) ( and I have 2-3 addressees on GMail , H-l , etc) P.P.S. And see fist in 2004 - 2005 .msi in Releases |
Beta Was this translation helpful? Give feedback.
-
|
Resending . . .
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
(* FROM C++ TO MODULA-3 --- (28 March 2024) *)
Greetings Modula-3 community, this is my first post.
This post may appear long-winded, but I have chronicled the early stages of my potential "Modula-3 Odyssey" in case this may save time (or add confidence) to others when/if deciding to engage this fine programming language.
I have been very impressed with my recent experiences with Modula-3.
My intent is for Modula-3 to replace C++ as my primary systems programming language.
I am confident in this intent; the Modula-3 language is well-endowed and a good tool for making libraries. As such, any future posts will have a similar title-format (with updated date field) to facilitate search of these posts.
BEWARE:
There may be some slight ranting and ideology-speak, connected to my interest for coding ....
[INTRO]
A bit of my coding background:
About a year ago I had setup a multi-boot Windows/Linux/OpenBSD "box" for an engineer/finance guy and who happen to have a PASCAL programming background. This provided me an opportunity to check out what has been happening in the PASCAL side of the "programming universe"; I remember Borland's "Turbo Pascal" product back in the early days, I had used Borland's OWL/VCL C++ toolkits back then.
The "box" was setup and I moved on, continuing my C++ coding.
However, I had been sensing "issues" in the C++ programming language during recent years and my journey into the PASCAL side of the "programming universe" made me realise a replacement for C++ may exist.
Since the completion of the "box", I spent a few weeks of my personal time {reading, light-coding} on the Oberon and Modula-3 languages. Ultimately, I selected Modula-3. One of the main reasons was the thread/lock detail built into the Modula-3 language. For many years I have been using my own port of the DLIB C++ library, especially making use of it's concurrency patterns. I'll be porting these patterns to Modula-3 in future.
[GIVING MODULA-3 A TEST RUN]
Back in late November 2023, I started porting the C++ components of my OpenGL-based simulation/game engine to Modula-3. I gave myself a 2-month period, i.e. Dec-2023, Jan-2024, to assess the Modula-3 "effect".
As of Feb-2024, I am of the opinion that Modula-3 ..... "rocks".
As someone said back in the 1990's, Modula-3 is an "elegant" language.
The M3 (i.e. Modula-3) language has a degree of "polish" and "battle-hardness".
I suspect the programming language oracles/gurus/etc. at DEC/Olivetti/CM3/etc. (1990's) realised the problems the C++ language will have in the decades to come;
e.g. consider this comment from Scott Meyers back in 2018 [2] ...
"C++ is a large, intricate language with features that interact in complex and subtle ways,
and I no longer trust myself to keep all the relevant facts in mind." .
There is also that bit of history concerning the Modula-3 language designers giving themselves a "complexity budget" of fifty pages whilst others believed that a programming language had to be complex to be powerful.
Modula-3 shows effectively that there is
POWER in SIMPLICITY
and this is the paradigm I prefer.
My recent Modula-3 experience has made it obvious to me that:
--> e.g. While C++ code often uses SFINAE (i.e. substitution failure is not an error) paradigm coupled with potentially elaborate template-like syntax (can quickly lead to relatively unreadable/complex code), Modula-3's generic code is very readable whilst leveraging the non-generic features of the Modula-3 language to impart power in Modula-3 generic code. i.e. The C++ template "framework" resembles another language built into C++, whilst Modula-3's "generics" are essentially plain (i.e. non-generic) Modula-3 code embedded in a small-footprint facade used to declare the generic code. It is very easy to respect Modula-3's simplistic, but powerful, approach to generics (after my years of C++ templating).
I am reminded of Modula-3 comments back in the 1990's implying the Modula-3 language having the power of C++/Ada languages but with a lighter footprint.
Don't be fooled into thinking that the small {late 1980's, early 1990's} temporal period used to develop/test/use the M3 language, prior to it's "vanishing" (related to DEC's "demise" ?), is a limiting factor. The language was/is "complete"; a good platform to make useful libraries.
In contrast, C++ was never "complete" as evidenced from successive committees growing/bloating the language. My questions are :
==> How far can you bloat the C++ language while it has it's dangerous C core detail ?
==> How many levels of abstractions/wrappers are you going to accept just so that you avoid that dangerous C core ?
==> How many more "concepts" are you going jam into an ever-growing C++ programming language, distracting the coder from the important "rule" that a programming language should be EASY TO USE.
--> A "concept" can be fine as long as it is introduced as early as possible in a framework (i.e. programming language) to allow for a natural/logical/simple amalgamation of that concept with the existing detail of that framework. Continuously tacking on a foreign/new concept to an existing mature framework without a periodic re-design (or review) of the original framework can be flawed and quite dangerous since a "stopping criterion" for avoiding the "tacking effect" get's more difficult as users of the framework get more reliant on the uber-tacked framework.
A deprecation model/paradigm helps, but requires discipline and we humans, at times, can be lazy.
We should not lose sight of CORE (commonly-used) concepts and ELECTIVE (not so commonly-used, specialised) concepts.
Leave CORE concepts in the programming language definition.
ELECTIVE concepts should be at library level and ideally, composed from CORE concepts.
Due to time constraints, a single programming language cannot be all things to everybody.
There is utility in DSLs; i.e. domain-specific languages.
e.g. Later, I will superficially describe my custom Modula-3 software development environment.
This environment could have been developed wholly in Modula-3, but that would not have been efficient use of my programming time. Through a DSL-like approach, better use of my programming time was achieved by leveraging the {bash, C (as script), AWK} languages.
An ever-growing C++ standard implies/assumes a broader use of C++ as being valid.
Is that assumption safe, whilst we know of the utility of the DSL paradigm ?
What I like about the Modula-3 programming language is that it "knows it place" and does what it was designed to do ... very well.
Modula-3 is a hidden gem and :
==> DEC's demise
==> copyright/licensing issues with GCC community
probably contributed to Modula-3 not being popular.
The Modula-3 distribution has an impressive list of libraries (packages).
These packages can be customised (enhanced) according to your own needs/design by simply :
==> copying the package's source code from "system" repository to own repository (i.e. filesystem)
==> modifying the copied package code.
[MODULA-3 TOOLING]
For some, the lack of "tools" can become a deal-breaker and they end up not embracing a programming language.
I tried the web-browser based "reactor" cm3-ide tool but was not my "cup of tea". Amongst other things, I did not want my programming workflow to rely on an Internet browser even if used in context of a local connection.
I'm a "xterm"-jockey.
Being impressed with the Modula-3 programming language, I began development of Modula-3 tools in Feb-2024; analogous to tooling I have developed for my C++ programming workflow but customised for the Modula-3 case.
I am not fond of conventional IDE's (integrated development environments).
The last IDE I used was SunStudio's IDE in the OpenSolaris days.
Basically, I treat the operating system (OS) as an IDE and my IDE system relies on :
The result is a customised/practical/efficient GUI-dialog based programming
environment for the Modula-3 language. There is a "root" (i.e. top-level) dialog with
scrollable radio-button options. A radio-button is clicked with mouse, a "OK' button is
clicked with mouse, then something happens; detail is output to an associated xterm so the user always realises what's going on.
Tasks include :
==> package-directory creation and populating directory with template files (e.g. m3makefile)
==> per-package interface/implementation ("module") file-creation
==> package-building
--> building a specific library package
--> building a specific exe package
--> building multiple library packages
--> building multiple exe packages
--> building all library packages
--> building all exe packages
==> package-cleaning
--> ...
==> string search in Modula-3 source code files
==> checks for cyclic-importations between modules; I do this purposely, before the compiler realises the cyclic-imports.
==> maintains a package-dependency database so that lib/exe packages are always successfully built (assuming no syntax errors in Modula-3 source code); my IDE system forces the compiler to build less dependent packages before more dependent packages.
==> generates module-dependency diagrams (PDF files) to facilitate better code visualisation
==> generates/updates m3makefiles automatically,
==> etc.
[EXTERNAL C LIBs]
Some believe Modula-3 lacks support for a broad range of external C libraries.
Remember, Modula-3 did not reach mainstream status and, so, this should not be a surprise.
However, this problem is easily solvable since the Modula-3 FFI (foreign function interface) is fine (intuitive) through use of EXTERNAL pragma.
I built a Modula-3 version of GLFW's OpenGL "gears" demo [3] to test Modula-3's EXTERNAL pragma:
==> accessed GLFW [3] library detail using :
--> EXTERNAL pragma
--> GLFW C source code through c_source() calls in m3makefile
==> accessed GLAD2 OpengL loader detail [4] using :
--> EXTERNAL pragma
--> GLAD2-generated C source code through c_source() calls in m3makefile
==> "gears.c" [3] was the only C code that I ported to Modula-3
==> RESULT: hardware-accelerated OpenGL "gears" program executed fine.
If the external C library is relevant, then spend the time to port it to Modula-3 using the EXTERNAL FFI and possible use of c_source() statements in m3makefile; I purposely used "c_source" calls to test the C-code compilation ability of the Modula-3 compiler. With "c_source", I now have a {Modula-3, C} software development environment via the cm3 (Critical Mass) Modula-3 compiler.
NOTE:
The "reactor" CM3-IDE user's guide has a relevant section on accessibility between {Modula-3, C} languages, concerning the EXTERNAL pragma.
[UPPERCASE KEYWORDS]
Some may have a problem with Modula-3's uppercase {keywords, reserved words}; e.g. use of uppercase words would potentially provide a "productivity" hit due to use of extra caps-lock key. Or, there may be too much visual-contrast when mixing frequent use of uppercase words with lowercase words.
I admit that when first encountering Modula-3, coming from a C/C++ background, the notion of "forced" use of uppercase words was "strange". However, you'll quickly accept the use of uppercase words as you realise the expressive-power that is the Modula-3 programming language.
The uppercase words, visually, act as good code-delimiters allowing the source code to be perceived, by us humans, as having more structure. The use of a syntax-highlighting-text-editor also helps make these uppercase words manifest well.
Up to now, porting of my C++ libraries/exes to Modula-3 has resulted in production of 69 library/exe packages.
I look at Modula-3 code and it's structured ...... "beautiful".
I don't see this with C++ code.
That's the Modula-3 effect ......
[DOCUMENTATION]
There have been complaints about lack of documentation for the Modula-3 language.
I have noticed a good amount of documentation for the Modula-3 language especially for a language that did not hit mainstream status like C/C++/Java.
Documentation can be found in the "/docs/help" directory of the distribution
cm3-dist-AMD64_LINUX-d5.11.4 .
The "/docs/help/index.html" file is a top-level web-page used to access the info.
Note: The language reference is accessible from the tutorial page.
"Missing info" cases are probably related to extra detail for certain Modula-3 features being located in various other references and, hence, possibly difficult to find.
e.g.
While I like Nelson's book as a Modula-3 reference, a few times I did find lack of detail which was remedied with detail I found on the Internet.
e.g.
The "reactor" CM3-IDE user's guide has a relevant section on accessibility between {Modula-3, C} languages, concerning the EXTERNAL pragma. I would have liked Nelson's book to have similar concrete examples for EXTERNAL pragma.
TAKE THE TIME TO LIGHTLY READ ALL THE DOCUMENTATION MATERIAL, PRIOR TO DIGGING DEEPER.
Modula-3 is purposely feature-packed in a relatively small language footprint.
Initially, certain subtle features may be missed ... not learned.
I have seen questions about language features, from "new" users", which correspond to answers in the documentation material. i.e. READ THE DOCS .....
My only real hassle was the inability to link the system's Xlib (X11) library with my own-built Modula-3 coded executable program. Ultimately I resorted to viewing the Modula-3 distribution's .../AMD64_LINUX/.M3EXPORTS files for the built GUI-based packages to, hopefully, learn how a Modula-3 package implements linkage with the X11 subsystem.
I found the import_sys_lib("X11") command was being used.
I, now, use this command in my own m3makefiles.
For documentation, my approach has been to create a ZIM desktop wikibook for the Modula-3 language, based on :
--> documentation in the Modula-3 distribution
--> detail learnt from Nelson's book
--> detail learnt from Harbison's book
--> internet references for Modula-3 detail
--> my own experiences porting my C++ code to Modula-3 .
This desktop wikibook has become my Modula-3 reference.
Some useful internet links for Modula-3 language info include :
https://modula3.github.io/cm3/tutorial/m3/m3_toc.html
https://modula3.github.io/cm3/help/interfaces.html
https://modula3.github.io/cm3/help/concise-bib.html
https://modula3.github.io/cm3/reference/complete/html/Modula_3_Language_definitio.html
http://www.faqs.org/faqs/Modula-3-faq/
The DEC SRC reports can be useful.
Articles related to the theme "How The Language Got Its Spots" can be useful
as they give insight to the design of Modula-3 language; the detail on generics
was very insightful.
[GARBAGE COLLECTION]
Garbage collection can be a very controversial/ideological topic for someone.
I'm a practical guy ... in general, something may either "work" or "not work" and will depend on the effort you put into design/implementation detail.
I have come across the the FUD related to garbage-collected languages but this should not scare you from exploring the garbage-collection experience; especially when reading articles on the pros of garbage collection.
Modula-3 has both "traced references" and "untraced references".
Think of "references" in Modula-3 as being analogous to "pointers" in C/C++.
"traced references" refer to memory in the "traced heap" and managed by the garbage collector.
"untraced references" refer to memory not traced by the garbage collector.
Apart from the garbage-collector role, traced/untraced references are the same.
In Modula-3 :
--> REF is used to declare a traced-reference; Re: garbage-collected memory-management
--> UNTRACED REF is used to declare an untraced-reference; Re: manual memory-management.
--> avoiding the above keywords implies a stack-based declaration, analogous to other languages (e.g.C/C++).
So, with Modula-3, you have access to both types of non-stack memory;
i.e. garbage-collected memory-management and human-based manual memory-management.
The latter is useful in case a program cannot afford the garbage-collection "cost".
Up to now, my Modula-3 demo programs did not use manual memory-management.
These programs build fast and execute fast.
My realtime, but simple, Modula-3 non-manual-memory-managed version of the OpenGL "gears" demo was executing fine/fast.
As I port concurrency patterns from C++ to Modula-3, this is where I'll be stress-testing Modula-3's garbage-collector; Re: concurrency related memory-management.
Ultimately, if required, I will use manual-memory-management for specialised portions of source code to attempt to achieve "realtime" simulation performance targets whilst the remaining code is garbage-collected.
The advantages of garbage-collection can be immense and would be foolish to not explore this memory-management paradigm, at least to determine it's potential usefulness.
For example :
"A classic unsafe runtime error is to free a data structure that is still reachable by active references (or "dangling pointers"). The error plants a time bomb that explodes later, when the storage is reused. If on the other hand the programmer fails to free records that have become unreachable, the result will be a "storage leak" and the computation space will grow without bound. Problems due to dangling pointers and storage leaks tend to persist long after other errors have been found and removed. The only sure way to avoid these problems is the automatic freeing of unreachable storage, or garbage collection." [1]
Unlike C/C++, Modula-3 is "essentially" memory-safe.
I would rather spend time with the safe Modula-3 language (even with it's safety-overhead and extra time in designing optimal use of the garbage-collector by my algorithms) rather than relying on a slightly higher performing unsafe language like C++.
If coding was only about performance then we would all be assembly language programmers.
It's about balance of programming language features.
[FINAL COMMENTS]
As in Geoff Wyant's 1994 article "Introducing Modula-3" in Linux Journal, you'll especially appreciate Modula-3 after doing alot of C++ coding.
My Linux box used for exploratory Modula-3 development is :
==> single processor; 2014 Intel i5 CPU
==> 4GB system memory
==> OS (uname -a) --> Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux .
From what I have ported to Modula-3 (from C++), I can say that the cm3 compiler works fast.
Error message syntax gets more understandable as you use the language; a section-number quoted in an error message refers to a section in "language definition".
The grass-roots (fundamental) nature of the "modular programming" paradigm within the Modula-3 language has been a big game-changer for me in terms of programming language themes.
Sure, C/C++ can attempt to simulate a file-level "module" approach but this will always be a hack.
The fundamental nature of the Modula-3 version of "modules" is so much more than what C/C++ could ever achieve because these latter languages were not designed from scratch to support a module paradigm; e.g. consider the importance of the "interface" in declaration of Modula-3's generics.
Note: I am fine when using the C language for low cognitive-load targets like producing small utilities; C was not designed to handle the human-based coding of large scale projects via relatively low cognitive-load. That is, use a tool where it has scope, and not use it outside of it's practical scope.
I have been spreading the word about Modula-3 to acquaintances.
Modula-3 made me realise the kitchen-sink-C++-experiment has existed for far too many years.
It was beneficial that the Modula/Oberon series of languages learned and partitioned themselves
from the less desirable portions of their PASCAL base, unlike C++ and it's C base.
Some may think, possibly early-stage-programmers or non-programmers, that spending so many years and effort on an initial language (C++ in my case) and then dropping it for another language implies a waste of time spent on the former language.
NO, this is wrong-thinking.
The role of a computer programming language is to translate the higher-level (abstract) representation of algorithms/ideas from our mind (brain) to a lower-level representation as computer source code (in a text file).
Any decent programming language does this translation at varying degrees of success.
I suggest the level of success is connected to "cognitive-load" implied by the translation process.
i.e.
A lower cognitive-load means simpler thinking, by the human, is required for the translation.
A higher cognitive-load means the translation is more difficult for the human.
As mentioned previously, and purposely designed/implemented by the language designers of Modula-3, Modula-3 enforces structured-coding through a relatively low cognitive-load.
My experience is that the C++ route involves a higher cognitive-load.
C++ has turned into a bloated mess.
I'd rather use all of the features of a well-designed smaller-conceptual-footprint language (Modula-3) rather than a kitchen-sink language (C++) having much/redundant conceptual detail you will never use much. Use the lightweight-core of Modula-3 to create custom concepts in your Modula-3 libraries.
I'm an applied scientist and prefer to unravel the complexity of certain favourite-to-me themes in science/mathematics whilst not expecting to be slowed down by the complexity of a computer language, hence my interest in Modula-3.
My main regret with C++ is that I spent too much time fighting the language,
implicitly thinking it was the be-all-end-all ....
[REFERENCES]
Beta Was this translation helpful? Give feedback.
All reactions