Oberon+ Concurrence and others

[tarkonian]

I am very happy that you continue to work in the oberon+ language. In your paper about possibilities to introduce concurrence in the language you don't cite the Vector Pascal implementation

https://sourceforge.net/projects/vectorpascalcom/

In another topic I saw your implementation of active oberon, I am using for some time the new version (2019)

https://gitlab.inf.ethz.ch/felixf/oberon

The introduction of math arrays is fantastic (they have a library called Matrix very good). The main problem is that the project is like a Frankenstein construct with outdated documentation and half implementation of modules. I saw good ideas there for a solid language, but they need to create a standalone compiler to compile to others operation systems. One think good is that , like in your oberon implementation, you don't need to write in uppercase the key words. If you begin write in normal letters the compiler will interpreted all the key words correctly.
For modula-2 you saw the modula-2 R10

https://github.com/m2sf

there is a discussion about a better implementation of coroutines. Sadly they don't have a compiler implemented (they are waiting for the creator of the new gnu modula-2 to implement also the R10 specification). Congratulation for your work.

[rochus-keller]

Thanks for the feedback. I actually never stopped working on Oberon+ (see commit log), but there are also other interesting projects, and a decent development of the Oberon+ language requires time and carefulness.

you don't cite the Vector Pascal implementation

Thanks for the hint. The goal was not a full historical treatment. I was actually mostly interested in what Wirth and Brinch Hansen were doing.

I am using for some time the new version (2019)

I'm aware of this language. It actually hasn't much to do with Active Oberon anymore. The author should have given it a different name. I spent much time analyzing different A2 releases and think that too much was added to the language and it is no longer "as simple as possible". I agree that a math array/matrix library is useful. But I would have preferred it in original Oberon (or Active Oberon) syntax. Operator overloading etc. might make code look a bit more pleasing to mathematically inclined users, but it makes the language much more complex. There are other languages already around with such features (e.g. FreePascal, C++), so I don't think it is necessary to inflate Oberon with all kinds of features. Actually FreePascal is a good example how a language looks after a decade of feature inflation.

EDIT: note that Oberon+ has an integrated, cross-platform foreign function interface with dedicated C compatible types, therefore it is possible to reuse the well established and documented mathematical C libraries.

For modula-2 you saw the modula-2 R10

Again, I just focused on what Wirth was doing, especially how he managed to integrate concurrency with as little as possible effort. Which part of Modula-2 R10 are you particularly referring to? Can you provide a link, please?

Besides that, I'm interested in getting feedback especially about my conclusions and the resulting proposal: https://github.com/oberon-lang/oberon-lang.github.io/blob/main/_posts/2023-12-25-towards-concurrency.md#elaboration-of-oberon-concurrency.

[tarkonian]

Thank you i will read the new proposal. A curiosity: do you know if exist some implementation (if possible, of course) of Oberon without a Garbage collector.

For an outside you never considered the possibility to use a modula+ instead of oberon+ as a possible modern system program? I don't work with in this area, but everyone that i talked always eliminate languages with GC immediately as candidate to use in a system program (they always said that when the program begin to became complex it is very difficult to predict the behavior of the CG).

Thank you again for your work to preserve the Wirth legacy

PS: I found a research paper about the possible problems in real world of the go concurrence implementation (pdf file)

https://songlh.github.io/paper/go-study.pdf

PS2: I don't consider freepascal a difficult language. The problem is the millions of libraries that the compiler have to understand (from the turbo pascal until delphi), but the essence of language remains simple. If you don't care about visual components (vcl library) everything is the old pascal for good or bad (i read that many concepts of object oriented added to the language comes from the work of Apple with Wirth act as consultor)

[rochus-keller]

do you know if exist some implementation (if possible, of course) of Oberon without a Garbage collector

I don't know, sorry. But it should be not difficult to modify a compiler so no garbage collector is assumed and instead a DISPOSE() built-in function is used to get rid of the memory.

use a modula+ instead of oberon+ as a possible modern system program?

Well, actually I already have C++ as a very capable system programming language ;-) I was rather curious what features of a language could be left out and still have a useful system programming language. Starting with Oberon is a good choice because it already intends to be minimal and the syntax is parser friendly. I learned Modula-2 during my first ETH study in the eighties and even had a Modula-2 job at DEC for some time. It has some good features; but for my projects during the last thirty years C++ was a better fit; and for this present project, Oberon is a better fit, because Wirth already removed all things from Modula-2 not really needed, so I don't have to. Concerning the GC, it is rather an issue for real-time applications. And Oberon has good support for static allocation; Oberon+ even supports variable-length arrays allocated on the stack. I didn't use it for microcontroller applications so far (C is the only way so far to go on these devices from my experience), but it doesn't seem impossible.

research paper about the possible problems in real world of the go concurrence implementation

Thanks for the reference, will have a look at it.

I don't consider freepascal a difficult language.

It's about as big and complex as C++98 which most people consider pretty difficult to master. I spent a lot of time with it and even had to derive a sufficiently complete grammar myself, see https://github.com/rochus-keller/FreePascal/

from the turbo pascal until delphi

That not only affects the libraries, but also the language itself is an amalgam of many different languages, not all of which nicely fit together.

[tarkonian]

Thank you and as a musician and composer (not professional) I will also look your software MusicTools.

[rochus-keller]

Welcome.

The MusicTools project is in an early stage. I'm mostly using MidiSink so far (e.g. for most of these tracks: http://rochus-keller.ch/?p=1221). What kind of music are you composing/playing?

[tarkonian]

I have 3 albums in the style of atmosphere/progressive (old Tangerine Dream, for example). In these albums all the music was composed using a synth guitar (a fender stratocaster with a gk3 pick-up with the Roland GR-55). I used the Logic pro X to record. Some examples in youtube:

https://www.youtube.com/watch?v=0Yez_SKsy4o https://www.youtube.com/watch?v=ma5zKzNNO84 https://www.youtube.com/watch?v=2a7KALKZ6s8

If you look for Wagner Utiel in the streams (Spotify, amazon, apple store, etc...) the albums are there. All are old records. Today I learned better how to record, mixer and mastering the song (the problem is that a mac-pro is very very expensive in Brasil and I have a old one). Sadly I lost the files from the last album and I don't have a way to make a new mixer-mastering. In the future I will rework these albums. Today I am working more in creating new music using only a electric guitar without synth. I am also interested in generative music using AI (because everyone use c++, maybe I will try to use modula-2 to learn more about computer music generation - with the go language I noted latency due the CG when you have more instruments playing together maybe with Oberon we will have the some problem.). As a background I studied classical guitar and piano for some years. In the university (I am a physicist) I have enrolled in some optional classes form the music departments (basic composition theory, harmonization theory, coral, etc...) I will close the comment (to not became much off-topic). If you want to discuss topics in computer music composition or music in general I will be happy to learn and study (I am only now begin to study about this topic) you can send an e-mail to

wusilva@gmail.com

Thanks.

[rochus-keller]

Great, thanks! These are cool tracks; I also listened to some others in your utube channel.

But first of all happy new year to you and your family!

And of course I couldn't hold myself back, but hijacked one of your tracks and just played along* prima vista (sorry if you don't like that); here's the result, directly live from the stereo channel, and filtered/compressed a bit with Ozone: http://rochus-keller.ch/Downloads/Wagner-Utiel-The-Awaken-plus-Rochus-Impro.mp3.

Concerning AI and algorithmic composition, there are other alternatives to C++, e.g. Python or Lua, maybe Oberon+ in future. I recently had an intense look at the Stanford CCRMA tools: https://ccrma.stanford.edu/software/, especially Common Music and sndlib, which use Scheme and a special language for algorithmic composition called SAL. Also Impromptu looks very interesting, and I yet found another great tool from Australia: https://nodalmusic.com/. I consider doing something similar in text instead in graphical form.

*EDIT: since it might not be obvious: I play all four instruments - bass, drums, e-piano and guitar - at once and live, playing the bass with my left hand and the drums with my feet. Here is a video which demonstrates this (I'm the guy on the left side).

[tarkonian]

Thank you and happy new year. I listened to some of your music (in your home page) and I like your improvisations (the guitar sounds are very good, I have to fight to obtain good guitar sound with logic). To be a multi-instrumentist is a plus in my book. The songs that I recorded were more a proof of concept that I could make a sound like Tangerine, Dream, Jean-Michael Jarre, etc.. only with a synth guitar without a keyboard set (than without many octaves like a piano to work). Then the songs are much "dense" and don't have space for improvisations like your work.

In general I don´t like lisp style programming (scheme, racket, etc..). I Love functional languages (and in my opinion this is a mistake from prof. Wirth to give emphasis to the Object Oriented paradigm (OO) and nothing for the functional). All the new languages abandoned the OO (rust, go, swift, etc...). I read that the creator of the theory of OO considered that all the implementations in C++, Java, etc.. have nothing with his idea of OO and are all horrible. Like he said if you want to use a banana you have to use all the forest, the gorilla and everything together. If you never work, give a look in the F# language (it is one of more easy to use languages). The library FSound is very simple to use

GitHub - albertp007/FSound: F# sound processing library https://github.com/albertp007/FSound

Python popularity comes from the wonderful libraries related to the language (and not the merits of the language per si). The language is very easy to use in many domains (I have python books for General Relativity, Quantum mechanics, electromagnetism, discrete mathematics, music generation, opengl, games, etc...) This is a big plus for the language. Maybe a mistake of prof. Wirth and the older generation (in my opinion of course) is that in the past only a few researchers had access to a computer and they had to build everything (hardware, software, libraries). Today I had many students that don't care about the language and also don't have time and/or proficiency to create a library. They want to use libraries (python and modern c++ with stl). Matlab, Maple, Mathematica are other examples. I have colleagues that hate computers but learned to use the R language because of the excellent statistical libraries (and the language is not easy). To create a library or make adaptation of libraries from different languages is necessary to have a deep knowledge of the languages, and today outside the computer scientist or computer engineer I don't believe many people have this knowledge (I certainly don't have) or time to learn. I believe that 90% of people that would use your language (oberon+) will never have a knowledge of the language to create complex libraries. If they don't have a set of basic libraries like the Go language have (basic html, image, math, etc...) they will give up and use another language. I really like your approach for oberon+ (for personal taste I like more the rust type notation (i32, i64, f64, etc..) instead of int32, longreal, etc..., but in general is a excellent implementation and I like to use. If a had your talent to language design and compiler construction I would probably create a frankenstein language that mix pascal, with elements of oberon+ and some A2 (math arrays and native parallel programming). I am curious about the Mojo language because it will maintain the python simplicit for the common users and for the advanced user there will be a hardware independent low level programming capacity (including parallel and gpu programming with the same language construction). Will be a Rust (security and without Garbage Collection) with python simplicity. The main creator (Chris Lattner) certainly had knowledge (he created the LLVM, Clang, Swift language and the implementation of TensorFlow for Google) and had a company to work for him. Lets see if the great expectation is not the mother of deception. In pascal there is a propose (like implemented in modern fortran) to add the world PURE to define a pure function

Pure functions - Free Pascal wiki https://wiki.lazarus.freepascal.org/Pure_functions

(in fortran if you write pure function the compiler knows that the function is pure.) I don't know if in the Wirth languages it is possible to create a difference where the world function indicates to compiler a pure function (like sine function) and a procedure a more general function with side effects (like a random function, print function, etc.). In parallel programming this is fundamental, because one of the big errors that occurs is when in some process the same variable acquires different values in different channels.

Thanks again for your work and I will continue to listen to your compositions. We can maintain contact through this email.

Wagner.

PS: What do you think about ALGOL68?

Em seg., 1 de jan. de 2024 às 16:15, Rochus Keller @.***> escreveu:

Great, thanks! These are cool tracks; I also listened to some others in your utube channel.

But first of all happy new year to you and your family!

And of course I couldn't hold myself back, but hijacked one of your tracks and just played along prima vista (sorry if you don't like that); here's the result, directly live from the stereo channel, and filtered/compressed a bit with Ozone: http://rochus-keller.ch/Downloads/Wagner-Utiel-The-Awaken-plus-Rochus-Impro.mp3 .

Concerning AI and algorithmic composition, there are other alternatives to C++, e.g. Python or Lua, maybe Oberon+ in future. I recently had an intense look at the Stanford CCRMA tools: https://ccrma.stanford.edu/software/, especially Common Music and sndlib, which use Scheme and a special language for algorithmic composition called SAL. Also Impromptu looks very interesting. And I found a great tool from Australia: https://nodalmusic.com/. I consider doing something similar in text instead in graphical form.

— Reply to this email directly, view it on GitHub https://github.com/rochus-keller/Oberon/issues/42#issuecomment-1873445346, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB5ZKOMHHA575PWBXPJ5KYTYMMDOLAVCNFSM6AAAAABBHRD7UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGQ2DKMZUGY . You are receiving this because you modified the open/close state.Message ID: @.***>

[rochus-keller]

Thanks. The solo guitar is the Ample Sound LP plugin (https://www.amplesound.net/en/pro-pd.asp?id=1) since 2021 (before it was a Yamaha Motif sound).

It's interesting that you like functional programming, but not Scheme. I think Scheme is quite a good fit for algorithmic composition. It's also e.g. used in Impromptu for live coding.

Wirth added a very minimal form of OO to Oberon, actually only inheritance, even without method dispatch. If you have a look at the original Oberon system, inheritance is mostly used für messages, and polymorphism is done via message handlers and forwarding the message records around the system. Oberon-2 had bound procedures and method dispatch, but was largely ignored by Wirth.

I read that the creator of the theory of OO considered that all the implementations [..] have nothing with his idea of OO

I'm only aware of one theory of OO, written by Cardelli (https://link.springer.com/book/10.1007/978-1-4419-8598-9). You probably mean Alan Kay, who was a manager at Xerox Parc in the seventies, and the inventor of the Smalltalk-72 concept. OO itself was invented in Norway (https://ethw.org/Milestones:Object-Oriented_Programming,_1961-1967). Kay neither liked the later Smalltalk versions, which were closer to Simula than to Smalltalk-72. Ironically the way Wirth does OO comes pretty close to Kay's definition. Personally I think OO is just one of many useful tools. F# is an interesting language. I spend some time with OCaml and ML, but in my daily business I prefer more general purpose languages.

Concerning Python I agree that the focus has shifted to one-stop solutions in the last twenty years, and there is little concern about resources. I'm rather from the old guard and prefer lean solutions, which don't fill up my system with a ton of stuff behind the scenes just to print "hello world". The Mojo language looks like an interesting alternative to CPython, and let's hope the speed-up is much more than what we see e.g. in PyPy. I spent a lot of time with LLVM, but unfortunately it has become very unwieldy in size and performance, which finally pushed me to look for other solutions.

What do you think about ALGOL68?

It's a very interesting language with a lot of interesting ideas, but unfortunately with a very user-unfriendly specification. The language itself I consider mostly relevant today for historical reasons.

[tarkonian]

I don't like the prefix notation (polish notation) of lisp and derivatives. Lisp is probably one of the most powerful, if not the most powerful, languages in existence (it is possible to program everything you can imagine without a fight with the language). I like Haskell, Ocaml e F# (in reality it is Ocaml for .Net). The first Rust compiler was created using the Ocaml language. Many aspects of Rust came from OCaml. In some sense Rust can be considered the only "functional language" without Garbage Collector. This is more about taste than good or bad language, but for me the prefix notation is easy to read in small expressions, but in complex mathematical equations it becomes a mess. In the books:

Structure and Interpretation of... by Sussman, Gerald Jay (amazon.com) https://www.amazon.com/Structure-Interpretation-Classical-Mechanics-Press/dp/0262028964?ref_=ast_author_dp&dib=eyJ2IjoiMSJ9.rtaII6L1H4Pr4uZv-U0pVr6oYQmmCRlvbSr_qD9IWx8Lq-w6_dE_d70kqATfamRptmnU_VeFQQpqi5Z4Iwtp6AwStEf-crYB3iEMcIdBQRSuJ3Xa53bt-ce2Fo04KBZ5eGED45dJBIPia5-NvWQBEzAszx1UBR_BdE6ULw8zUVIcNPwyyeSV-qxxap4Xa2IV.wkXCEyBmZlQyvZ7ix-pQQlBrXOIiYpHid6izXm_PX-I&dib_tag=AUTHOR Functional Differential Geometry (Mit... by Sussman, Gerald Jay (amazon.com) https://www.amazon.com/Functional-Differential-Geometry-MIT-Press/dp/0262019345/ref=pd_sim_d_sccl_2_1/143-4687144-7286651?pd_rd_w=mLdvF&content-id=amzn1.sym.95c9984b-e881-4eb8-9a85-bd9add50dfd7&pf_rd_p=95c9984b-e881-4eb8-9a85-bd9add50dfd7&pf_rd_r=9K5V467EM7RXYE08FDR7&pd_rd_wg=iML6t&pd_rd_r=a246b103-0965-477a-9747-31f138b19913&pd_rd_i=0262019345&psc=1

The author had to create hundreds of functions only to write the equations of the books (and many continue to be difficult to read). I work with computation physics and I like the language to be rigorous and very explicit in all its elements. For example I like the way of rust:

let a:i32 = 12; let mut b:f64 = 3.14;

The type is explicit and reading I know if a variable é mutable or not. Because of this, I like the Wirth languages. In Haskell and F# you can use the types explicit in OCaml no. This is a no for me. In rust if you write

s:= 2 * cos(pi);

The compiler will emit an error because 2 is an integer and Pi a cos(pi) a float (f32 or f64). Another bonus for me is the namespace. In Pascal or Ada and Rust if I use: import math (in rust every function in the std can be called without some prefix) I can write

sin(pi/2.0), sqrt(2), etc...

I hate to need to write

Math.sin(pi/2), etc...

np.math(pi/2) like in python

In my opinion if you are using only the standard library you don't need to qualify the method. It is a bad language design. 3rd party libraries ok. If you want to use a cosine from other library and not the standard:

import MyMath as mm or from MyMath import Trig as mm

mm.cos(pi/2)

From the discussion in discord the Mojo language is much more than CPython or PyPy. In the site they talk about

Modular Docs - Mojo🔥 FAQ https://docs.modular.com/mojo/faq.html

The language can be used in parallel program, GPU,etc... without some special notation. The language can be faster than c or c++ because its architecture is built over MLIR and can be more optimized than c or c++.

I am looking for the plug-in you recommended. I bought the FL Studio for windows (from what I read it was created in pascal) and I will use it for some days to verify the quality. I have to buy a new mac to use the logic again.

Thanks

Em ter., 2 de jan. de 2024 às 12:30, Rochus Keller @.***> escreveu:

Thanks. The solo guitar is the Ample Sound LP plugin ( https://www.amplesound.net/en/pro-pd.asp?id=1) since 2021 (before it was a Yamaha Motif sound).

It's interesting that you like functional programming, but not Scheme. I think Scheme is quite a good fit for algorithmic composition. It's also e.g. used in Impromptu for live coding.

Wirth added a very minimal form of OO to Oberon, actually only inheritance, even without method dispatch. If you have a look at the original Oberon system, inheritance is mostly used für messages, and polymorphism is done via message handlers and forwarding the message records around the system. Oberon-2 had bound procedures and method dispatch, but was largely ignored by Wirth.

I read that the creator of the theory of OO considered that all the implementations [..] have nothing with his idea of OO

I'm only aware of one theory of OO, written by Cardelli ( https://link.springer.com/book/10.1007/978-1-4419-8598-9). You probably mean Alan Kay, who was a manager at Xerox Parc in the seventies, and the inventor of the Smalltalk-72 concept. OO itself was invented in Norway ( https://ethw.org/Milestones:Object-Oriented_Programming,_1961-1967). Kay neither liked the later Smalltalk versions, which were closer to Simula than to Smalltalk-72. Ironically the way Wirth does OO comes pretty close to Kay's definition. Personally I think OO is just one of many useful tools. F# is an interesting language. I spend some time with OCaml and ML, but in my daily business I prefer more general purpose languages.

Concerning Python I agree that the focus has shifted to one-stop solutions in the last twenty years, and there is little concern about resources. I'm rather from the old guard and prefer lean solutions, which don't fill up your system with a ton of stuff behind the scenes just to print "hello world". The Mojo language looks like an interesting alternative to CPython, and let's hope the speed-up is much more than what we see e.g. in PyPy. I spent a lot of time with LLVM, but unfortunately it has become very unwieldy in size and performance, which finally pushed me to look for other solutions.

What do you think about ALGOL68?

It's a very interesting language with a lot of interesting ideas, but unfortunately with a very user-unfriendly specification. The language itself I consider mostly relevant today for historical reasons.

— Reply to this email directly, view it on GitHub https://github.com/rochus-keller/Oberon/issues/42#issuecomment-1874174955, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB5ZKOIQEXLFJZTHWALS67TYMQRZFAVCNFSM6AAAAABBHRD7UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUGE3TIOJVGU . You are receiving this because you modified the open/close state.Message ID: @.***>

[rochus-keller]

Ok, I see, thanks. I agree that Lisp is not really suitable for mathematical formalisms, as they are common in physics. My statement referred more to algorithmic composition. But I'm afraid that you won't find a particularly suitable language for this purpose in Oberon+ either. Have you also checked Julia?

The compiler will emit an error because 2 is an integer and Pi a cos(pi) a float (f32 or f64).

I don't find the implicit conversions in Oberon optimal either; I would also rather rely on type incompatibility between integer and real, but I would also like to be backwards compatible.

the Mojo language is much more than CPython or PyPy

But their main selling point is that Mojo can be used as a drop-in replacement of Python; for the other features there are already good solutions, even with Python syntax (but not fully compatible).

[tarkonian]

I believe that lisp like syntax can be used in computational physics without problem. When I think in lisp (scheme, racket) I see them as fantastic for symbolic computation. In general functional languages are not good for number cruncher programs. All of them need the Garbage Collector because of the data immutability. They need to create multiple copies of the same dada and in a program where you have operations with matrices with thousands of elements it is a problem. Julia language is very good. They use a cool idea to define blocks (useful for pascal like languages in my opinion). You have:

function ... end for ... end if ... end etc... There is no Begin or point-virgula. Also the language has a macro in the lisp style (a never used). The problems with Julia are

• Marketing sold that the language as is easy like python (correct) and fast as c/c++ (false you need to work much to obtain this)
• it is not compiled to result in a exe or equivalent
• like c++ there is a hell package dependence (some package need different versions of other packages)
• compilation time is very slow
• sometime the Garbage Collector becomes crazy and your memory disappear very fast
• the so called multiple dispatch can sucks in parallel programming
• many packages (like in rust) are v0.2 or v.0.5, i.e. are unstable and immature. For scientific work this can be a serious problem if you need validation of your results.

Of course the people in julia know very well c/c++ and fortran and they can program very efficiently, but for the target public that they are trying to sell the language this is not true. It is much easier for a newbie to write an efficient program in fortran than in julia. The differential equations package of julia is probably the state of art in the field.

For the mojo I believe that the python syntax can attract some users (and will be fully compatible because is a superset of python and not a subset), but the main goal of the language is to be fast, efficient and hardware independent. It is the only language that can run in a cluster of GPU without the use of special keyworks or different syntax. In this aspect the language is very different for all the existing languages in the market. You can use the program to run in a cluster of CPUs, or a cluster of GPUs or some specialized hardware accelerator without modification. And in some cases fast them c or c++ (of course in some tests is 35.000 faster then python). From the discussions I read that the language is build from the ground with parallelization of arrays, vectors and many structures (I believe this is a similar idea used in the A2 oberon 2019 and the necessity to rewrite the type system). But the language is in version 0.6 and we will have to wait to verify if the promises will be fulfilled.

Your language Oberon+ can be used without problem in scientific computation (of course there is the problem of libraries). I really like your implementation, and more important for me is that you are trying to create a better oberon version adding features with research and not only because is cool (like the modern c++). Many people in the Oberon community live in the past believing that the language is perfect and the last 30 years of research means nothing. Like everything in life it is important to be critical. Prof Wirth was a good research but this is no mean that he was perfect and his ideas are the only correct. As a scientist I don´t like the cult of personality around him or other person.

Thank you

Em ter., 2 de jan. de 2024 às 15:37, Rochus Keller @.***> escreveu:

Ok, I see, thanks. I can agree that Lisp is not really suitable for mathematical formalisms, as they are common in physics. My statement referred more to algorithmic composition. But I'm afraid that you won't find a particularly suitable language for this purpose in Oberon+ either. Have you also checked Julia?

The compiler will emit an error because 2 is an integer and Pi a cos(pi) a float (f32 or f64).

I don't find the implicit conversions in Oberon optimal either; I would also rather rely on type incompatibility between integer and real, but I would also like to be backwards compatible.

the Mojo language is much more than CPython or PyPy

But their main selling point is that Mojo can be used as a drop-in replacement of Python; for the other features there are already good solutions, even with Python syntax (but not fully compatible).

— Reply to this email directly, view it on GitHub https://github.com/rochus-keller/Oberon/issues/42#issuecomment-1874399874, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB5ZKOMZMALHC34LLKWR673YMRHVLAVCNFSM6AAAAABBHRD7UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUGM4TSOBXGQ . You are receiving this because you modified the open/close state.Message ID: @.***>

[rochus-keller]

Interesting, thanks. You seem to have much experience with a lot of different technologies.

Many people in the Oberon community live in the past believing that the language is perfect and the last 30 years of research means nothing. Like everything in life it is important to be critical. Prof Wirth was a good research but this is no mean that he was perfect and his ideas are the only correct. As a scientist I don´t like the cult of personality around him or other person.

That brings it to the point ;-)

[deviantbit]

tarkonian commented:

In general functional languages are not good for number cruncher programs. All of them need the Garbage Collector because of the data immutability. They need to create multiple copies of the same dada and in a program where you have operations with matrices with thousands of elements it is a problem.

This is not true. First, Not all functional languages use a GC. Second, if you're copying data you're programming wrong. This is a "you" problem.

rochus-keller commented:

I agree that Lisp is not really suitable for mathematical formalisms, as they are common in physics.

This is not true. Lisp has been used in many scientific applications. CERN uses Lisp in many of their applications. I won't get into my uses.

This entire conversation I've been watching has been interesting to watch.

[rochus-keller]

This is not true. Lisp has been used in many scientific applications. CERN uses Lisp in many of their applications. I won't get into my uses.

The point was not, that it cannot be done, but that it is much effort to write and difficult to read. It can obviously be done, no question. tarkonian even referenced Sussman's books which demonstrate it. But the argument was, that it requires "hundreds of functions only to write the equations of the books (and many continue to be difficult to read)", which is obviously the case. There are languages much better suited to represent mathematical formulas so they better resemble how mathematicians or physicists would write them. But Oberon+ is not one of them, and I have no intentions so far to do so.

[tarkonian]

Hi deviantbit

You wrote

"this is not true. First, Not all functional languages use a GC. Second, if you're copying data you're programming wrong. This is a "you" problem."

Can you cite one pure function language without CG?

There is an old discussion about this here

haskell - Why do functional programming languages require garbage collection? - Stack Overflow https://stackoverflow.com/questions/39440412/why-do-functional-programming-languages-require-garbage-collection

There is a study of new models of memory management here

Department of Computer Science and Technology – Technical reports: UCAM-CL-TR-908 https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.html

It is near impossible to create a pure functional language without CG. Maybe you don´t program using functional language, but the essence of FL is that all data is immutable. If you create an array (or other data) and want to alter it, you need to create a copy of the array, manipulate this copy to obtain the result desired and after this free the memory of this copy (Garbage collector). A solution obtain para OCaml in the library

OCaml Scientific Computing Tutorials https://ocaml.xyz/

was using an imperative paradigm for the parts with matrix, vector and arrays operations. OCaml is a multi-paradigm language and not purely functional.

About the use of Lisp in CERN, of course they use lisp, but also use python, perl, etc... We are talking about number cruncher programs and not scripts (or macros) to access data to be manipulated with a c++ or fortran program. If you are talking about this recent paper

[2312.13295v1] A functional scripting interface to an object oriented C++ library (arxiv.org) https://arxiv.org/abs/2312.13295v1

where they use clojure (a lisp type language) as script. This has nothing to do with the discussion between me and rochus-keller.

I don't know if the rise of the Java language made prof. Wirth changed his mind (because I read an article from him against the use of GC in a system program). I know that after Java everyone wants object oriented language and Garbage Collector (Ada introduce OO, in c++ was a discussion to GC as optional feature, etc...) The problem is that with the introduction of GC in Oberon (conservative GC) the language was born dead for system program. I never hear someone talk about the possibility to use Oberon (modula-2 yes) in a system. In many situations you can use GC languages without problem, but when the flux of data is intense you begin to have problems.

Thanks

Em qua., 3 de jan. de 2024 às 07:00, Rochus Keller @.***> escreveu:

This is not true. Lisp has been used in many scientific applications. CERN uses Lisp in many of their applications. I won't get into my uses.

The point was not, that it cannot be done, but that it is much effort to write and difficult to read. It can obviously be done, no question. tarkonian even referenced Sussman's books which demonstrate it. But the argument was, that it "hundreds of functions only to write the equations of the books (and many continue to be difficult to read)", which is obviously the case. There are languages much better suited to represent mathematical formulas so they better resemble how mathematicians or physicists would write them.

— Reply to this email directly, view it on GitHub https://github.com/rochus-keller/Oberon/issues/42#issuecomment-1875109390, or unsubscribe https://github.com/notifications/unsubscribe-auth/BB5ZKOKNFVH4U6JRX2E23NLYMUT2BAVCNFSM6AAAAABBHRD7UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVGEYDSMZZGA . You are receiving this because you modified the open/close state.Message ID: @.***>

[rochus-keller]

PS: I found a research paper about the possible problems in real world of the go concurrence implementation (pdf file) https://songlh.github.io/paper/go-study.pdf

Meanwhile I studied the paper and more and considered the insights in the updated proposal. I added a discussion where you can post your feedback if you want: https://github.com/rochus-keller/Oberon/discussions/45