[HN Gopher] Some memories of Niklaus Wirth
___________________________________________________________________
Some memories of Niklaus Wirth
Author : gautamcgoel
Score : 187 points
Date : 2024-01-14 21:08 UTC (3 days ago)
(HTM) web link (odersky.github.io)
(TXT) w3m dump (odersky.github.io)
| moomin wrote:
| Modula-3 (not designed by Wirth, but tangentially mentioned in
| the article) was a practical disaster. Phenomenally verbose, and
| with a type system implementation that could easily confuse a
| complex class with an int.
|
| It also had go-like structural interfaces, if that floats your
| boat. Pretty much everyone I knew hated working with it.
| pjmlp wrote:
| I liked it, have almost all published books, and enjoy that
| Swift, Java and C# have taken several ideas from it, even
| better now that AOT is finally part of the whole package
| instead of commercial offerings.
|
| D as well, but nowadays they are fighting with a dwellig
| community.
| kragen wrote:
| 'fighting with a dwellig community'? i thought i spoke
| english but maybe i was wrong
| cjohnson318 wrote:
| I think it's a "dwindling" community.
| pjmlp wrote:
| Not everyone is a native English speaker on the Internet,
| what a surprise.
| kragen wrote:
| i thought i was, but this sentence is too advanced for me
| panzagl wrote:
| Dwellig you know, where the bandersnatch is
| santiagobasulto wrote:
| For the unaware: Odersky himself is a "modern day Wirth". Amazing
| language designer. He's responsible for generics in Java and the
| Scala language.
| nickpeterson wrote:
| It's interesting that odersky helped put generics in Java and
| also made Scala. Don Syme helped put generics in .net, and then
| made F#. It feels like two people on a very similar trajectory.
| mjburgess wrote:
| The question, "how do we make functional languages popular,
| (useful?) in the enterprise?" was a question in the air for,
| i'd, say decades. The 00s answer was to create a merger
| between enterprise langs (Java, C# etc.) and functional langs
| in a new language.
|
| The net result, as we know now, was to push those langs to
| adopt functional features -- rather than to shift to others.
|
| I suspect the question for the niche programming community,
| of the next decade, will be "how do we make effect systems
| popular?" or some such thing.
|
| Or, "how do we make AOT metaprogramming popular?" etc. (cf.,
| jai, zig... carbon, circle, ...)
|
| I suspect if a post-C++ new-wave gets popular, with
| structural typing and ct metaprogramming, we might see the
| same in C# quite easily
| pjmlp wrote:
| You already get them with code generators and Rosylin, but
| it is a bit painful to use.
| SideburnsOfDoom wrote:
| There is also a new compiler feature, "interceptors" that
| swaps in calls at compile-time.
| https://learn.microsoft.com/en-us/dotnet/csharp/whats-
| new/cs...
|
| This looks very hard to use well, but that's because
| "it's not for you" to use directly in app code, rather
| it's a low-level building block for such AOT and code
| generation patterns and toolkits.
| pjmlp wrote:
| I hate it, as it is a bad approach to what should have
| been a proper AOP framework like PostSharp or Microsoft
| Fakes.
|
| Instead we will end with a special cased mini framework,
| designed to override reflection code for the purposes of
| AOT code generation.
|
| Something that AOT toolchains for Java have solved much
| better with agents, PGO and config files.
|
| From my point of view, it is neither a good approach to
| sort that out, nor a good AOP alternative.
| santiagobasulto wrote:
| I didn't know Syme helped with generics in .net. Very
| interesting indeed.
|
| I think it makes sense for these people to create their own
| "perfect" languages. I'm not aware of C#, but I know (or
| knew) Java very well. And Generics always was a half-baked
| option for a broken language.
|
| From a purists' perspective, in Java "everything is an
| object", except ints or floats, but we have Integer or
| BigInt, but then we have `null`, but then... if Integer
| extends from Number, does that mean that a List<Integer>
| extends from List<Number>? Nobody knows...
|
| Those things are what I feel Odersky wanted to solve and
| couldn't with Java, so he went "Bender Style".
| throwaway89988 wrote:
| Sorry, but Odersky is nothing like Wirth.
|
| Scala failed hard because it is kitchen sink of every half
| baked feature someone wanted to write a PhD thesis about. The
| graphs of the interdependencies of the standard library are an
| excellent example of a totally insane design, the Scala data
| structures have been at least an order of magnitude slower than
| the JVM native ones. Don't get me started about the tooling,
| which is too slow for any real world projects. (The only ones I
| regularly see to use Emacs are Scala developers, because
| opening projects in an IDE like IDEA could take up to 30 min on
| high end workstations.)
|
| Wirth valued clean design, speed and simplicity. Odersky wants
| to compete with C++ for complexity. As the article stated, for
| Wirth a feature would have to pay for itself regarding
| complexity, speed and usability. If someone can demonstrate how
| Scalas features came to pay for themselves, I would appreciate
| a pointer.
|
| Finally... generics in Java are a shit show, thanks to type
| erasure. Fair enough, Odersky was probably forced for this
| implementation, thanks to backwards compatibility, still,
| nothing to be proud of.
| bombcar wrote:
| This all sounds right to me - scala needs first class support
| for what it is doing in the JVM itself - which it doesn't
| have. Trying to ASM scala is a pain.
| kagakuninja wrote:
| Type erasure is an interesting discussion, because functional
| programmers love type erasure. Consider the function:
| def foo[T](t: T): T
|
| If the function is truly generic, then we know nothing about
| the implementation details of T. The only meaningful
| implementation of foo is identity: def
| foo[T](t: T): T = t
|
| From a FP perspective, T should be erased, and the programmer
| should not cheat and use reflection. The type signature
| should tell you much about what the function does.
|
| I've used Scala professionally for the last 8 years. The
| tooling is fine, assuming you avoid exotic libraries like
| Shapeless. Compile times are fast enough that I don't think
| about it much, using IntelliJ incremental compilation. A full
| recompile of a micro service might take 30 seconds, whatever
| it is is not a big deal IMO.
|
| > opening projects in an IDE like IDEA could take up to 30
| min on high end workstations
|
| This is insanely wrong. Maybe you are operating on
| experiences from 10 years ago? I have a new M2 MacBook Pro,
| and opening projects is quite fast. The first time you do it,
| it will resolve the SBT dependencies and index files. That
| can be done in the background, and is probably less than a
| minute for a typical project. Even my previous laptop could
| open projects quickly despite being 3 years old.
|
| > the Scala data structures have been at least an order of
| magnitude slower than the JVM native ones
|
| They are slower, but not an order of magnitude slower.
| Perhaps you are remembering the infamous email from the
| Yammer CTO that got leaked, but that was a long time ago, and
| the compiler and libraries have improved greatly since then.
|
| But yes, in performance critical code, you can just switch to
| an imperative style and use Java collections.
|
| I don't have time to explain the benefits of Scala features,
| but I'll just point out that other than implicits, many ML
| inspired features of Scala have made their way into modern
| languages, including Java, C#, Rust and Swift. Scala didn't
| invent those ideas, but repackaged them in a novel way.
| geodel wrote:
| So modern day Wirth is quite different from antiquity Wirth.
| Java generics are quite complex they have multi hundred pages
| books to explain it all. Scala a really clever language,
| perfect for 1 line code doing 50 line equivalent of Java code.
| Slow compile times and immature tooling is another important
| feature of Scala.
| kagakuninja wrote:
| Current Scala compile times really aren't that bad. Yeah, Go
| will be 10x faster, but then you have to use Go...
|
| For a typical micro service, I never think about compile
| time, thanks to incremental compilation. Even a full compile
| is not bad. Tooling is also fine, although Scala 3 set things
| back. IntelliJ now supports Scala 3 adequately.
| geodel wrote:
| Well, its like one can always tolerate shortcomings when
| they like something/someone. Reasons can always be added
| later for liking something but rarely other way around.
| jll29 wrote:
| There was a language called Pizza that Odersky wrote while in
| Karlsruhe (before moving to EPFL Lausanne), and that became
| part of "standard" (not as in ISO, but as it SUN-approved) Java
| as "generics".
|
| https://en.wikipedia.org/wiki/Pizza_(programming_language)
| https://www.reddit.com/r/scala/comments/8c7h8f/history_the_p...
| jll29 wrote:
| Beautiful semi-obituary + personal impact report.
|
| Odersky has done very impressive work (I only recently learned
| about his work on TurboModula-2 - cool!), but his work is not
| focused on simplicity as Wirth's was - I wonder if he tried hard
| to adopt Wirth's simplicity mantra or not (given how he praises
| it in the article)?
|
| Scala's type system is quite complicated, for instance, and the
| notion of "object-functional" itself, as a hybrid concept, lacks
| simplicity.
| zokier wrote:
| Yeah, I too found the praise for Wirthian ideals funny in the
| context of Scala. But on the other hand I believe Scala 3 did
| clean up lot of things, so maybe there is still something
| there?
| pohl wrote:
| Interoperating with Java was a requirement. That immediately
| takes simplicity off the table if the goal is to bring FP to
| the JVM.
| macintux wrote:
| Admittedly this is from a distance, having only toyed a bit
| with each, but Clojure always seemed much simpler than Scala.
| pohl wrote:
| That follows from Clojure being dynamically typed, though.
| Different design constraints lead to different results.
| bigbillheck wrote:
| Why's that?
| switchbak wrote:
| Types interop on a VM that wasn't designed for a more
| complex one like Scala has.
|
| Collections interop between Java<->Scala. Scala's
| (immutable/mutable) collections are not built on the Java
| ones, and they provide helpers to translate between the
| two.
|
| Calling conventions, name mangling, Java to Scala issues,
| etc.
| Nullabillity wrote:
| Scala has accumulated a lot of cruft on its own over the years
| and it hasn't always succeeded, but at the same time I'd say
| that a core value has always seemed to be trying to unify
| Java's weird special cases ("why does every class member have
| to support being static, instead of just supporting first-class
| singletons?", "why are primitive types not part of the type
| hierarchy?", "why null?", or even "why are some type
| conversions hard-coded in the compiler?").
| n_plus_1_acc wrote:
| They cleaned up a lot of warts (like implicits) with scala 3
| _a_a_a_ wrote:
| I don't think implicit's were a wart, and AFAIK in Scala 3
| implicits effectively still exist but with a different
| syntax (but not touched it for a while, so may be wrong)
| agrounds wrote:
| Scala 2's implicits have been a source of great pain in
| many Scala codebases at many different organizations.
| They are too powerful. The situation is comparable to
| languages that depend on gotos instead of structured
| control flow elements (for/while loops, if statements,
| function/subroutine calls).
|
| I can't speak for Scala 3 as I haven't used it at all. If
| they've limited the power of implicits to a few more
| structures usages it would be a great benefit to the
| language.
| _a_a_a_ wrote:
| Too powerful? Or just ab/mis-used?
| sideeffffect wrote:
| In Scala 3, implicits live on under a different name.
| They're called _given_s. But they're reduced to just one
| use case: propagating a context through (and deriving one
| given form others). And Type Classes are subsumed under
| this use case.
|
| The other use cases have been essentially removed:
|
| * Extension methods are now its own feature, relying on
| completely different mechanism * Automatic conversions
| have been severely curbed and de-emphasized, although
| they are still there, but much more explicit
| bombcar wrote:
| All I know about scala is it takes aeons to compile scala
| Minecraft mods, and few people know how to fix them.
| sideeffffect wrote:
| > [Odersky's] work is not focused on simplicity as Wirth's was
| - I wonder if he tried hard to adopt Wirth's simplicity mantra
| or not
|
| I would beg to differ. I think he's very much aiming at
| simplicity. Btw, the essence of Scala really is simple. Take
| for example DOT (Dependent Object Types is the theoretical
| calculus Scala is based on), it is simple
|
| https://www.scala-lang.org/blog/2016/02/03/essence-of-scala....
|
| as video https://www.youtube.com/watch?v=bZEWNKzhBoU
|
| Or take his emphasis on simplicity in practical software
| engineering:
| https://www.youtube.com/watch?v=-qf8yteuxPs&pp=ygUObWFydGluI...
|
| Than there is the question of practical concerns with Scala,
| like fitting onto the JVM, interoperability with Java,
| superficial features for programmer comfort (or lack thereof)
| and the tendency of some people to use the most powerful
| features for the simplest of problems that inevitably lead to
| messy codebases. And that certainly makes things complicated.
|
| > the notion of "object-functional" itself, as a hybrid
| concept, lacks simplicity
|
| I think this is misunderstanding about what Scala is all about.
| Scala is not supposed to be 50% functional and 50% object-
| oriented. It's supposed to be both 100% functional and 100%
| object-oriented (aka having powerful module system) _at the
| same time_. It's supposed to be a concrete proof that this
| dichotomy (FP vs OOP) is false and you can have both in the
| same language with the same features.
|
| This is contrary to other languages which may have support for
| FP and OOP but have _separate_ support for each, like SML,
| OCaml or F#. Scala is in this tradition, but different, it
| supports FP and OOP with one set of features. And from this
| point of view it is _simpler_. Whether people find it _easy_ is
| another question.
| jll29 wrote:
| > It's supposed to be both 100% functional and 100% object-
| oriented (aka having powerful module system) _at the same
| time_.
|
| That is well said, and I agree.
|
| And it certainly is an acomplishment, it's even in some way
| elegant, but I would not call it "simple". Simple is a
| compiler book in less than 100 pages that _also_ includes the
| full source code of a compiler that can compile itself, or a
| language the syntax graphs of which fit on a single paper
| page of ordinary size.
|
| Odersky saw that to make impact, you need to interact with an
| existing, large library ecosystem instead of "build it all
| yourself", so I'd say he is a realist-pragmatist whereas
| Wirth was a practicising (self-made) idealist-minimalist.
|
| I think I will get out my old MODULA-2 book in honour of
| Wirth again and play with GNU Modula-2 a bit, let's see how
| that feels after 24 years of C++/Java/Python in-between.
| mjburgess wrote:
| I remember having just left a scala event I was running in a cab,
| and seeing Martin on a london bridge with a gaggle of guys
| following him. I wasnt aware he was the student of Nikalus Wirth
| -- but it makes a lot of sense.
|
| It's a shame though, that Wirth's philosophy was, imv, ditched
| from 90s-00s (where we get: python, js, ruby, ...scala).
|
| It seems now language design is rediscovering Wirth and his
| techniques (see, eg., google's carbon which iirc, seeks to be
| ast-free single-pass).
| 7thaccount wrote:
| Everything is a balance. Can you have the power of Python in a
| Wirth-like language? Pascal compiles fast into executables that
| are easy to distribute. Python is extremely flexible and easy
| to use for a wide array of problems, but is a packaging
| nightmare. Languages like C are blazing fast and easy to
| distribute, but require a lot of code to do what I can do in a
| few lines of Python.
|
| I haven't used Swift, but hear it may be a bit of a compromise
| in that it compiles (albeit not in a single pass I don't think)
| and using it is not that much more verbose than Python. I know
| Nim and Crystal are similar attempts, but Nim doesn't seem as
| easy to use to me.
| mjburgess wrote:
| The jai, zig, etc. approach is compile-time metaprogramming;
| make the compiler available to program, make the build system
| plugging into the compiler.
|
| Then I think you can do it. The compile-time is "a Wirth" and
| the runtime is "a Wirth".
|
| You get 95% the benefits of a python, since 95% of the
| dynamics you want are actually just static transformations of
| the program.
| 7thaccount wrote:
| I don't see how you can get 95% of the benefits of Python
| by programming in Zig. When I looked into Zig, it was like
| coding in C. Not as many built-in data structures and you
| have to manually manage memory and all that. Zig seems like
| an attempt for a better C.
| cwzwarich wrote:
| > (see, eg., google's carbon which iirc, seeks to be ast-free
| single-pass)
|
| Carbon's (mostly hypothetical) frontend is actually 3 passes:
| lexing, parsing, and a semantic analysis pass, each with
| separate IRs. One of their arguments is actually that they are
| more efficient as separate passes operating on packed data
| structures rather than e.g. a parser that calls into a lexer
| for each individual token. In a way, this is a claim that
| Wirth's approach is inherently inefficient on contemporary CPU
| microarchitectures.
| mjburgess wrote:
| Hmm, i read it as "wirthing" each layer. since, iirc, the IR
| representation of each pass is in fact, basically, just a
| linear array of ints.
|
| So you have linear scans on top of linear scans.
| norir wrote:
| There is something deeply attractive about writing an ast-free
| single pass compiler. It's a great exercise to write a compiler
| that targets a scripting language like lua or js in a single
| pass. I think though that there are significant advantages to
| having an ast and multiple compilation passes, particularly on
| present day computers that have effectively unlimited memory
| for the purpose of compiling a single source file.
|
| Multiple passes allows you to break down the problem into
| separate orthogonal components. To support the same
| functionality in a single pass, you have to jam an enormous
| amount of functionality into one place which can make it very
| difficult to see the forest of the trees as well as introduce
| unintended coupling. It also is difficult to implement certain
| recursive features in a single pass (though this could be
| considered an advantage depending on how powerful you intend
| the language to be).
|
| Ideally, a compiler can also provide apis that will expose the
| ast at different phases. It is somewhat sad to me that tree-
| sitter has emerged as an LCD solution for syntax highlighting
| and semantic analysis. If a compiler could export e.g. a json
| representation of the ast after parsing, that could be used for
| syntax highlighting rather than tree-sitter.
| playingalong wrote:
| I learned programming mostly with Wirth's Pascal quite a few
| years ago. Now I am employed in a company whose primary language
| for backend is Odersky's Scala.
|
| I have fond memories of the former and greatly enjoy the latter.
|
| It's only now that I learn Odersky was Wirth's student. It
| clicks.
| playingalong wrote:
| It'd be interesting what was the other five PhD students did. I
| kind of guess most of them being successful, not necessarily in
| the domain of programming language design.
| throw_pm23 wrote:
| It's easy to check, they seem to have done well:
| https://www.genealogy.math.ndsu.nodak.edu/id.php?id=61847&fC...
___________________________________________________________________
(page generated 2024-01-17 23:00 UTC)