211–220 of 251 posts
Earlier quoted context omitted.
This is old advice :-). Use the LSP server and dune and the error displays instantly, no further setup required.
I don't get it. Is it sarcasm?
Earlier quoted context omitted.
I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.
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 spent a lot of time on Standard ML in university. OCaml was always portrayed as the engineer's alternative for real applications. I spent some time brushing up on OCaml a few years ago using Exercism.io. While OCaml is a personal "top tier" language, I'd always prefer Haskell, Rust or Scala. Type classes / traits just seem to beat a higher-order module system for me.
I learned SML/NJ and OCaml around the same time and for some reason I found SML more pleasant. I particularly liked the SML "Basis" library, it felt really well designed to me. Still, I'd pick either over Scala. Superior compilation times, cleaner syntax, less complex. Haskell also just feels excessively clever. I had hoped Rust would be "OCaml but for systems programming" and it sort of is, -- but the borrow checker…
Earlier quoted context omitted.
I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.
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 usually avoid bugs in python code by rewriting in bash (at 1-10% the size of the original python, since bash's error handling can be set to "always do the right thing" with "set euxo pipefail")
If bash is a bad fit for the rewrite, go usually works. I don't work on linear algebra software much these days. Python seems to be a good option for that.
As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…
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).
The Rust with GC proposals I've looked at all break compile time thread safety checking.
As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…
> To develop further the point about "what doesn't scale" there is also the function with unnamed arguments and currying. Not sure what you mean by unnamed arguments, but criticizing automatic currying is totally valid. > Functional programming with immutable values is a wrong pattern for programming languages. Many algorithms, almost all actually, are naturally expressed in imperative style with mutable arrays or va…
Earlier quoted context omitted.
You will have to wait for JavaScript to add it first. The whole point of Typescript and why it is so successful, is because they only add type system on top of JavaScript. Pattern matching would introduce new language constructs beyond what is required for defining types.
I think as long as they maintained it as a proper superset of javascript (i.e. all js code was valid ts code), adding a new language construct wouldn't hurt them much. see kotlin vs Java for a similar case
As for your Kotlin example, Dart's failure shown why it isn't a good approach.
Kotlin also shows what happens when the underlying platform decides to go in another direction (value types, loom, default methods on interfaces), and the amount of boilerplate that needs to be generated to pretend to be like the host language.
A language that only matters, thanks to the way Google is pushing it on Android to replace Java for anything besides system libraries.
Earlier quoted context omitted.
I don't really consider those separate things. Bounded polymorphism is parametric polymorphism, plus a type subset relationship. A quick sanity check on wikipedia is consistent with this model. BP is PP plus what's required to make it more than a toy I remember one annoyance I had with ocaml was the effective inability to use point-free style. I can't remember what limitation was behind this; do you know off the top…
> BP is PP plus what's required to make it more than a toy And in fact OCaml does have BP, as was explained earlier, just with a heavier syntax. > effective inability to use point-free style OK but point-free style is not an end in itself, it's just a means to an end (clean code), and there's certainly no universal agreement that it's the best means...explicit style is almost always easier to understand for a wide as…
Ok, I'm glad we agree on that.
> I can see how writing
Eta reduction is one example, but a great deal of code is cleanly expressed as e.g.
vecLen = sum . map (^2)
Earlier quoted context omitted.
Not "a salary", but a Jane Street salary and resume cred. Otherwise you just won't find that many takers.
I can assure you I will and in fact have found plenty of takers for my job postings with a niche language. You just need to word the postings appropriately and be willing to teach people what they don't know.
OK, I'll grant that if you have that "magic skill" then you can in fact recruit developers for niche languages.
Most companies don't, as we know, and frankly it's amazing to me how incoherent their communications are throughout their so-called hiring process.