4 ms·

"Upgrading" Modula-3 is an interesting idea, but I wonder how much you'd have to tweak for it to be worth the effort. I suspect that adding a new chrome would e

"Upgrading" Modula-3 is an interesting idea, but I wonder how much you'd have to tweak for it to be worth the effort. I suspect that adding a new chrome would end up as something awfully like Go. Go, in my opinion, is currently the best distillation of the Wirth progression of languages that we have. The Go authors (one of whom worked on Oberon-2 at Wirth's ETH Zürich) took a lot of inspiration from Wirth, and Go is in many ways a reactionary language as a result: A simple, strict type system; easy to parse (Wirth's languages all famously fit on a single screen of EBNF grammar, not sure if Go is quite that small); design choices favouring the pragmatic over the theoretical (ignoring the last 30 years of type theory), reasonably performant, etc. I'm not sure there's that much left in the original well. Modula-3 did have a "safe" construct, but it seems a bit naive today (nowhere near Rust's advanced, complicated safety features). Explicitly choosing between GC/non-GC seems like something compiler writers should be able to automatically optimize. Modula-3 did have generics, of course.

nickpsecurity 10y ago
I think it could be a bit better if it got close to Ada's safety features without their unusability. I was considering adding a borrow checker, ref counting, and Go-style GC to it for various use cases. Idea being people could choose along spectrum from quick prototyping with reasonable performance to hard work for safety without GC. Add Design-by-Contract support from Eiffel with SPARK-like static analysis on modules simple enough to allow it. Complex modules could be analyzed easier than C since it's a Wirth-style language. Port either Rust's or SCOOP's concurrency model so it's safe-by-default. Maybe a few things from functional programming for decoupling of modules without getting too much overhead. I don't think it has to be Go language or have nothing we've learned from type theory while being easy to use. Just has to have a base as easy to use as Go with options to bring you closer to Ada, Eiffel, or Rust in safety + performance. Plus macros maybe with compiler being LISP on inside for ultra-easy transforms like Julia did. :) The combination should be quite advantageous where baseline of safety & maintenance is achieved at Go speeds with effort of rest increasing other attributes. That was my brainstorm on it anyway. It's all up for debate outside the part where it would be easier to learn & compile than Rust or Ada. Their strategies are intrinsically complex vs a Wirth language with some upgrades.
- lobster_johnson 10y ago
  I think a language like that could be great if you managed to synthesize all the good parts into a modern whole. I always liked the very pragmatic mechanism, in Wirth's languages and in Ada, of attaching constraints to data types; for example, defining a type as an integer of range 1..9. On the one hand, from a type-theoretical viewpoint, it's completely cheating — the mechanism is hardwired into the language, there's no real underlying system or symmetry to it, unlike a proof-based language such as Idris or Agda. On the other, it's awfully pragmatic.

nickpsecurity 10y ago

I think it could be a bit better if it got close to Ada's safety features without their unusability. I was considering adding a borrow checker, ref counting, and Go-style GC to it for various use cases. Idea being people could choose along spectrum from quick prototyping with reasonable performance to hard work for safety without GC. Add Design-by-Contract support from Eiffel with SPARK-like static analysis on modules simple enough to allow it. Complex modules could be analyzed easier than C since it's a Wirth-style language. Port either Rust's or SCOOP's concurrency model so it's safe-by-default. Maybe a few things from functional programming for decoupling of modules without getting too much overhead. I don't think it has to be Go language or have nothing we've learned from type theory while being easy to use. Just has to have a base as easy to use as Go with options to bring you closer to Ada, Eiffel, or Rust in safety + performance. Plus macros maybe with compiler being LISP on inside for ultra-easy transforms like Julia did. :) The combination should be quite advantageous where baseline of safety & maintenance is achieved at Go speeds with effort of rest increasing other attributes. That was my brainstorm on it anyway. It's all up for debate outside the part where it would be easier to learn & compile than Rust or Ada. Their strategies are intrinsically complex vs a Wirth language with some upgrades.

lobster_johnson 10y ago
I think a language like that could be great if you managed to synthesize all the good parts into a modern whole. I always liked the very pragmatic mechanism, in Wirth's languages and in Ada, of attaching constraints to data types; for example, defining a type as an integer of range 1..9. On the one hand, from a type-theoretical viewpoint, it's completely cheating — the mechanism is hardwired into the language, there's no real underlying system or symmetry to it, unlike a proof-based language such as Idris or Agda. On the other, it's awfully pragmatic.