221–230 of 251 posts
Forgive this tangential question, but does anyone know of a practically-oriented tutorial for implementing an ML-style language? Any format is fine, as are books.
There's "Modern Compiler Implementation in ML" which has a section on making the example language Tiger a pure functional language. I don't have "Compiling with Continuations" but that might be even more appropriate.
Also, I love your handle :P
P.S.: are you referring to the paper entitled “the essence of compiling with continuations”, or something else?
Earlier quoted context omitted.
I don't think I've ever seen anyone seriously argue against the claim that strong typing systems at least prevent many types of bugs. Now people may think that they are more productive in a language with weak types but that's a different consideration.
I think the big win is actually immutable data and pure functions. It just so happens that strong typing tends to come along with these things (e.g. Haskell, OCaml)
Earlier quoted context omitted.
There's "Modern Compiler Implementation in ML" which has a section on making the example language Tiger a pure functional language. I don't have "Compiling with Continuations" but that might be even more appropriate.
Brilliant! Much appreciated, thank you. Also, I love your handle :P P.S.: are you referring to the paper entitled “the essence of compiling with continuations”, or something else?
Earlier quoted context omitted.
I'm sure there's some element of subjectivity, but at a minimum there's something to be said for "unfamiliar to the overwhelming majority of programmers". I think it's also very likely that OCaml's incredibly terse syntax (and terse naming conventions) is objectively difficult to understand from a "how the human visual/symbolic processing pipeline works" perspective, but I don't have the data to back that up (I also…
Thing is, if OCaml is terse and weird syntactically (and I would agree), then so is Rust. Especially once you have to spell out signatures.
Earlier quoted context omitted.
I generally agree, and I'm hoping that Gleam fits the bill for "Rust with garbage collector" (also, when I say this, people leap to OCaml, but OCaml introduces a bunch of problems which aren't present in Rust: cryptic syntax, lower quality build tooling, unbounded type inference, competing "standard" libraries, a fairly toxic community, etc).
How does gleam handle thread safety and asynchrony? Rust leans heavily on the borrow checker for that. The Rust with GC proposals I've looked at all break compile time thread safety checking.
Earlier quoted context omitted.
I don't get it. Is it sarcasm?
No. You don't need this anymore. > You can use -annot or -bin-annot when compiling and the Tuareg function caml-types-show-type in Emacs will be your best friend. Just open OCaml program in some editor with LSP(Vim, NeoVim, VS Code, Emacs) and it will instantly show you the error.
I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…
Forgive my ignorance, I'd would like an example of the "functional" (hehe) benefits of automatic currying
---
One benefit is that functions are more reusable. Functions with more arguments can be partially applied and used where applicable.
For instance, if you wanted to increment the values in a list you might do something like this in python:
map(lambda x: x + 1, [1,2,3])
map((+ 1), [1,2,3])
Additionally, you can think of currying as a form of dependency injection.
For example, if you wanted to inject a database client and a logger before running a query you might do something like this:
def queryer(db, logger):
def _q(query):
logger.info("before query")
results = db.fetch(query)
logger.info("after query")
return results
return _q
rows = queryer(db, logger)(query)
queryer db logger query =
logger.info("before query")
results = db.fetch(query)
logger.info("after query")
results
rows = queryer db logger query
rows = (queryer db) logger query
rows = ((queryer db) logger) query
---
I hope this makes sense and I wish I could preview my comment to see if it was formatted reasonably!
Earlier quoted context omitted.
I program primarily in (untyped) Python (which, I get is technically strongly typed but people don't think in technical terms) these days, and I almost never experience type errors. I guess I could attribute this to a couple things: - I'm very specific about when I use None - I'm a big fan of named function arguments - I like to think my naming of things is pretty good, as are my conventions for parameters - I try to…
I’ve similarly developed my own habits. But why spend our effort into developing habits, when we can address the problems across people --- junior and senior --- automatically with a type system.
Earlier quoted context omitted.
And pretty much only them. Perhaps some day we'll learn how little the programming language matters for anything beyond coding.
Ever used AWS EC2? Docker Desktop? OCaml code is driving some of the lower-level performance-sensitive parts. That's a gajillion instances running globally.