3 ms·
I didn't say that the "Go way" was bad; just that there are few similarities. Certain things you can do in Oberon you cannot do in Go and vice versa. Personally
by Rochus 4y ago
I didn't say that the "Go way" was bad; just that there are few similarities. Certain things you can do in Oberon you cannot do in Go and vice versa. Personally I prefer Oberon+ over both Go and previous Oberons; if I didn't need to maintain backward compatibility with Oberon/-2/-07 I would remove type inclusion from Oberon+ and require explicit casts like Go; Wirth also removed type inclusion from Oberon-07, but he (unfortunately) also removed all numeric types but INTEGER, REAL and BYTE (but left some unfortunate implicit casts).
- pjmlp 4y agoFrom that point of view yes, I do agree. Although I still think Active Oberon is the best descendant from original Oberon, I am not a fan of the minimalist design Wirth persued afterwards. In any case, Oberon's best days are behind it, hence why I would rather see some Go inspired approach to those ideas, even if I am not a big fan of Go's design.
- Rochus 4y ago> In any case, Oberon's best days are behind it Maybe if you insist that parallel processing is part of the language (which you likely do if you prefer Active Oberon). Personally I think this can be well delegated to libraries to keep the language simple. Oberon+ doesn't use dedicated syntax even for exception handling; also "green" or regular threads, and channels and the like can well be covered by libraries or FFI. I'm neither a fan of Go's design, but with the ongoing work on Oberon+ I'm confident that its best days are yet to come.
- pjmlp 4y agoThe whole point of Oberon was the Smalltalk like experience, or to be more precise Mesa/Cedar like experience. So to offer a bare bones language in 2022 without an OS that is at least at the same level of Blue Bottle, let alone what consumers expect from a modern OS is really not attainable. It remains a nice language to look at as language nerd, and at the end of the day, pick something else when delivering software into production with the expectations that Swift, C#, Kotlin and so on can fulfill.
- vitiral 4y agoI don't think I have the breadth of your knowledge, so I would really love any thoughts you had on the language/OS I'm creating, github.com/civboot/fngi. It's partly inspired from Oberon (although I started it without knowing about Oberon), but I'm still working my way through the book and language as I develop my own. I'm sure it's going to a decade+ project to have something valuable, but I'm hungry for any feedback I can get at this early stage.
- Rochus 4y ago> The whole point of Oberon was the Smalltalk ... Mesa/Cedar like experience. That's not even true if you mean the Oberon OS. The idea - as described in the referenced HOPL paper - was the focus on the essentials of a language, which from my point of view is still a very valid goal, as you can see by just looking at the success of Go. Swift, C#, Kotlin are at the other extreme of the spectrum, not too far away from modern C++ or Ada, where the language designers seem to want to integrate everything that anyone could ever want. That makes about as much sense as everyone today thinking they have to drive an SUV, and leave the bicycles or other economical means of transport as "a nice thing to look at" for the "transportation nerds".