You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
About 2 months ago I finished porting my ~ 20 year old {linear algebra, VRML, 3D graphics, etc.) library code-base from C++ to Modula-3.
A worthwhile experience and served as a good test for the cm3 compiler.
The compiler performed admirably and that whole library code-base compiles, from Modula-3 source-code to binary libraries, in a bit over 2 minutes on my 2014 Intel-i5 CPU box (Linux Debian OS).
Very impressive.
A C++ "build world"-like route for that code-base takes much longer.
Due to Modula-3 language enforcing more proper design/structure in source-code than the C++ language, some of my C++ code required redesign prior to translation to M3. This was not a major hassle and served to highlight the unstructured mess that is the C++ language which conveniently, but foolishly, lets a possibly-impatient programmer write badly designed code.
In parallel with the above porting has been porting of the BGFX (https://github.com/bkaradzic/bgfx ) cross-API rendering library to M3.
BGFX is C++ based, but also offers a C-language API.
Currently been using :
M3's EXTERNAL pragma
bgfx's C-API
custom C code (embedded in my Modula-3 BgfxPkg package)
as basis of this port.
I have successfully built a Modula-3 ported bgfx demo.
I am investigating the practicality of doing a source-port of BGFX code tp M3. i.e.:
limit M3's EXTERNAL pragma to system detail like render (e.g. OpenGL) calls, whilst BGFX-implemented detail is ported to M3
replacing BGFX's thread-code with M3 thread code.
After nearly a year of M3 coding since that "28 March 2024" post, the detail in that post is still applicable except for one thing. Back then I mentioned my own custom-developed Modula-3 software development environment consisting of {bash language, fltk-dialog program, C-code script (executed by Tiny-C-Compiler), AWK script).
That environment has served me well during my M3 coding sessions. However, with time comes extra ideas and enhancing the code for that environment (more specifically the AWK code) is not very practical since the AWK language is not well suited to be used like a "full blown" programming language. AWK's a good utility for text processing but I pushed the role of AWK too much outside it's "sweet spot".
Hence, I am currently reimplementing my Modula-3 software development environment using the Icon programming language; see https://www2.cs.arizona.edu/icon/ .
The Icon programming language is very well-suited for development of tools.
I can now replace the four programming language paradigms {bash language, fltk-dialog program, C-code script, AWK script} used in my M3 tool with a single programming language paradigm being the Icon programming language. This reduces cognitive load in a massive way and provides a good platform for maintenance and expansion of my M3 tools.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Greetings.
Just some info since the time I wrote my previous Modula-3 (M3) post
"FROM C++ TO MODULA-3 ... (28 March 2024) ".
About 2 months ago I finished porting my ~ 20 year old {linear algebra, VRML, 3D graphics, etc.) library code-base from C++ to Modula-3.
A worthwhile experience and served as a good test for the cm3 compiler.
The compiler performed admirably and that whole library code-base compiles, from Modula-3 source-code to binary libraries, in a bit over 2 minutes on my 2014 Intel-i5 CPU box (Linux Debian OS).
Very impressive.
A C++ "build world"-like route for that code-base takes much longer.
Due to Modula-3 language enforcing more proper design/structure in source-code than the C++ language, some of my C++ code required redesign prior to translation to M3. This was not a major hassle and served to highlight the unstructured mess that is the C++ language which conveniently, but foolishly, lets a possibly-impatient programmer write badly designed code.
In parallel with the above porting has been porting of the BGFX (https://github.com/bkaradzic/bgfx ) cross-API rendering library to M3.
BGFX is C++ based, but also offers a C-language API.
Currently been using :
as basis of this port.
I have successfully built a Modula-3 ported bgfx demo.
I am investigating the practicality of doing a source-port of BGFX code tp M3. i.e.:
After nearly a year of M3 coding since that "28 March 2024" post, the detail in that post is still applicable except for one thing. Back then I mentioned my own custom-developed Modula-3 software development environment consisting of {bash language, fltk-dialog program, C-code script (executed by Tiny-C-Compiler), AWK script).
That environment has served me well during my M3 coding sessions. However, with time comes extra ideas and enhancing the code for that environment (more specifically the AWK code) is not very practical since the AWK language is not well suited to be used like a "full blown" programming language. AWK's a good utility for text processing but I pushed the role of AWK too much outside it's "sweet spot".
Hence, I am currently reimplementing my Modula-3 software development environment using the Icon programming language; see https://www2.cs.arizona.edu/icon/ .
The Icon programming language is very well-suited for development of tools.
I can now replace the four programming language paradigms {bash language, fltk-dialog program, C-code script, AWK script} used in my M3 tool with a single programming language paradigm being the Icon programming language. This reduces cognitive load in a massive way and provides a good platform for maintenance and expansion of my M3 tools.
Beta Was this translation helpful? Give feedback.
All reactions