[HN Gopher] Four Lectures on Standard ML (1989) [pdf]
___________________________________________________________________
Four Lectures on Standard ML (1989) [pdf]
Author : swatson741
Score : 84 points
Date : 2023-09-04 20:48 UTC (1 days ago)
(HTM) web link (www.cs.tufts.edu)
(TXT) w3m dump (www.cs.tufts.edu)
| qwerty456127 wrote:
| It's so refreshing when the ML acronym is used for its original
| meaning rather than for the AI hype.
| ribosometronome wrote:
| milliliter?
| Jtsummers wrote:
| With a capital-M ML would be megaliter, not milliliter.
| Milliliter would be mL (or ml).
| roflmaostc wrote:
| I wish more programmers would take an intense course on
| functional programming.
|
| I learnt so much in my OCaml classes and really enjoyed
| programming with it.
| qwerty456127 wrote:
| Why use OCaml when we have F#?
| pjmlp wrote:
| Its owner doesn't really know where to drive it to.
|
| However in general, any would do.
| qwerty456127 wrote:
| Do you mean the F# Software Foundation consisting of 1831
| members?
| pjmlp wrote:
| I mean Microsoft.
|
| Quite curious what those 1831 members would do, if
| Microsoft decides to play a VB6/VB.NET (both now in
| maintenance) on F#.
| qwerty456127 wrote:
| Does Microsoft care about F# at all? Wasn't it a short-
| lived experiment of the 2000th creative era which just
| happened to attract enough persistent community interest
| to avoid being archived?
| pjmlp wrote:
| It cares enough to ship it on VS, and still pay salaries
| that keep it going.
|
| I expect it to fade into oblivion the day Microsoft
| decides to drop it.
|
| Those foundation members will hardly keep it relevant,
| once it becomes yet another third party language on .NET
| ecosystem.
| bunderbunder wrote:
| As others have hinted at, F# and OCaml are really not
| interchangeable languages. They handle lots of things in
| very, very different ways. Even the difference in runtime
| makes a big difference. You could very similarly have asked,
| "Why use Objective-C when we have Java?"
| qwerty456127 wrote:
| I would rather ask why use Java (for reasons other than the
| large legacy code base and the job market) when we have
| Scala (which doesn't even force you to program functionally
| and can be used as "a better Java" if you want, it can be
| used to write really weird code but doesn't have to).
| bunderbunder wrote:
| Having spent some time using both in a professional
| context, I would actually choose Java over Scala. And I
| say that as someone who cut their teeth on functional
| programming and still tends to prefer it over OOP.
|
| The problem with Scala is that good, maintainable code is
| defined more by how many language features you have the
| discipline to avoid using than it is by how many you do.
| And that makes it more difficult to keep a large Scala
| codebase maintainable on a team with varying levels of
| experience. Freely mixing ad-hoc and subtype polymorphism
| (that is, type classes and subclasses), for example, is a
| very short, very slippery slope to a situation where the
| best way to figure out how the code works is to already
| know how the code works.
| weatherlight wrote:
| Scala, The Walmart of language paradigms.
| toastal wrote:
| Relying on Microsoft's .NET is not what a lot of us would
| want to do, especially when it comes to libre software.
| qwerty456127 wrote:
| To me .Net seems the most powerful thing to make a
| relatively esoteric language practically useful in the real
| life. Compiling to .Net gives a really solid ground for
| free. Compiling to JavaScript is a great option but the
| JavaScript landscape seems way less stable and this way
| harder to support.
| toastal wrote:
| But you have to rely on Mono or .NET Core for Linux which
| isn't something many want to put on their servers or
| desktops.
| Verdex wrote:
| Perhaps they want to have access to some features that ocaml
| has that F# does not. Like:
|
| * gadts
|
| * first class anonymous modules
|
| * functors (module level functors)
|
| * polymorphic variants
|
| * row polymorphism
|
| * effect handlers
|
| Although, I must confess, I haven't exactly kept up to speed
| on F# development. Perhaps F# has added some of these
| features recently?
| bunderbunder wrote:
| I haven't used F# in a couple years now, but the longtime
| position of the maintainers has been that F# will not and
| should not adopt many features along those lines because
| they interact poorly with the .NET type system.
|
| It's not a perfect comparison, but, having spent some time
| dealing with all the unusual and surprising ways that some
| Scala language features interact with Java's type system, I
| tend to agree with the F# community on that point.
| qwerty456127 wrote:
| Sincere thanks! This is exactly what I meant to ask!
| roflmaostc wrote:
| It doesn't matter which functional language you use, any will
| do its educational purpose.
|
| But as for other languages, there is pros and cons for each
| of them. I never tried F#, only Haskell and OCaml.
| qwerty456127 wrote:
| Sure. I'm just curious what do people who are into
| functional programming actually think. I've taken a look at
| F# and other MLs and F# seemed the best althoigh not this
| simply - another ML (I can't easily recall which one) had
| some interesting features F# lacked. So I hunt for curious
| thoughts people may have on this when they MLs are
| discussed. I personally have little interest in academic
| computer science but do have strong interest in using cool
| programming languages to write concise reliable code.
| Functional languages really shine at saving a solo
| developer's time as most of the bugs are caught during
| compile time, verbosity generally is lower and readability
| generally is higher.
| bunderbunder wrote:
| I did Advent of Code in SML a couple years ago. It was an
| interesting experience. I don't think I've ever previously
| experienced such a vast disconnect between the quality of the
| core language, and the lack of functionality in the standard
| library.
|
| I think that it could have easily been my favorite dialect of ML
| if its standard library hadn't been so anemic even by 1990s
| standards. As it is, though, my AoC solutions tended to take a
| large effort, not because the problems were difficult to solve in
| the language, but because I ended up having to build up so many
| of my own algorithms and data structures. Fortunately, doing that
| in in SML is a genuine joy. But it still, sadly, renders the
| language irrelevant for just about any practical purpose
| nowadays.
| shpongled wrote:
| I had the exact same experience - I did some of AoC in SML,
| fell in love with the core language, and even hacked on a toy
| SML compiler (didn't get too far).
|
| It really is a wonderful language held back by a lack of good
| tooling and ecosystem, and well, users.
| csb6 wrote:
| SML/NJ has a standard library [0] beyond Basis with a lot of
| useful functionality, e.g. sets, queues, hash maps, red-black
| trees, sorting functions, regex.
|
| [0] https://www.smlnj.org/doc/smlnj-lib
| roblh wrote:
| This website looks hilariously mangled on mobile. Which at
| first I kind of expected, until it said at the bottom it was
| updated in 2022.
| weatherlight wrote:
| i concur with this assessment. I did the wonderful course,
| "Programming Languages, Part A" by The University of
| Washington. Part "A" of the course teaches Functional
| Programming and uses Standard ML as a vehicle to teach it's
| semantics.
|
| I completely fell in love with the language, but I concur that
| the tooling is almost non-existent and the error messages that
| bubble up, leaves much to be desired.
| avg_dev wrote:
| i took that course. it was a whole lot of fun. i still have
| yet to take parts B and C.
| shrubble wrote:
| Is that the case, even with the 'BASIS' library?
| Munksgaard wrote:
| Yes. The Basis library does not live up to today's standards.
| Which is of course no surprise, given that it hasn't changed
| since the 90s.
| ratmice wrote:
| While it is true that things don't move fast, there have
| been proposals to it which have seen some adoption
| (thinking MONO_BUFFER was implemented by smlnj has compat
| in mlton). And I recall a proposal from polyml subsequently
| was implemented in smlnj. I don't know if there actually is
| a process in place to actually decide to accept proposals
| into the basis.
|
| One of the things I like about the basis library is it's
| principled stance that if it doesn't require compiler
| support, host operating system support, is more efficiently
| implementable by the compiler than would be with an
| external library, or has clear proven utility it belongs in
| a separate library. This barrier for inclusion is to me at
| least undoubtedly good.
|
| Personally I would split things apart further (kicking host
| OS support to a separate library from the basis, as I am
| inclined towards non-posix hosts where most of the API
| requiring host support isn't implementable). And kicking
| out any optional types/modules to separate libraries (where
| said library is then optional).
|
| So while it is about as minimal a standard library as
| exists, (for my purposes at least) it sometimes feels like
| it contains too much. Given there is no language level
| support for things like conditional compilation of anything
| optional within the basis. These tend to be my gripes with
| the basis... not "it needs more things".
| bunderbunder wrote:
| Agreed.
|
| Though, also, maybe don't go too far with kicking things
| out into individual separate libraries. Last year I did
| AoC in Scheme, and there the annoyance was figuring out
| exactly which of the approximately nine kajillion SRFI
| packages I needed to import to get different bits of
| functionality. A smaller number of more tightly
| integrated libraries that are allowed to evolve over time
| would have been more pragmatic.
| ratmice wrote:
| Yeah, excessive modularity can be just as bad as any
| monolith. I'd tend towards sticking to a few libraries
| with well defined boundaries like target OS, or perhaps
| one for native cpu architecture word sizes and the like.
| But that still leaves some optional oddities like IntInf
| without an obvious destination.
___________________________________________________________________
(page generated 2023-09-06 20:01 UTC)