291–300 of 322 posts
Earlier quoted context omitted.
> The next ML will be pure, with effects only via monads Which has already been proven wrong, by the way, by F#, which appeared in 2005 ("Wearing the hair shirt" was from 2003), so I think the comment is not to be taken too literally. https://www.microsoft.com/en-us/research/publication/wearing...
Did Simon Peyton-Jones work on F#?
Earlier quoted context omitted.
> You might find this a bizarre criticism but In Java, Ruby, Elixir, Rust strings are all Unicode with escape hatches for manually handling byte arrays (that could be C strings). Java's strings have noticeable misbehaviour for astral characters, and since the language is built around a single hardcoded string type, almost all Java programs inherit this. Ruby had to have a major migration to fix its string support. Ru…
Astral characters?
It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."
That's because Rob Pike never learned Haskell. Expecting to just look at it and know it because you know other languages is quite frankly silly! You don't need to be a mathematician though. Many Haskellers I've worked with either didn't go to university or went for something else. I only ever learned C before Haskell, for instance.
Earlier quoted context omitted.
That's irrelevant. OP simply said that lazy evaluation makes it harder to reason about time and space complexity. Everyone agrees with this, for goodness sake - even SPJ himself.
It is definitely not harder to reason about time. I don’t think you will find many haskellers agreeing with this.
Here is a good Stackoverflow response that expands on the point:
https://stackoverflow.com/a/12061524
I've never before seen the claim that lazy evaluation makes it harder to reason about space but not time complexity. It seems a very odd claim on the face of it, since the two are very closely interrelated. (E.g., if you are evaluating some prefix of an infinite list, then space and time are exactly correlated.)
But if that doesn't satisfy you, here is a paper that explains why time analysis is more difficult for lazy evaluation:
https://link.springer.com/content/pdf/10.1007%2F3-540-52592-...
("A major obstacle in the time-analysis of lazy languages is the problem of context sensitivity: the cost of evaluating an expression depends on the context in which it is used.")
Earlier quoted context omitted.
Correct me if I'm wrong but Clojure nudges avoiding mutable state while Haskell uses type theory to enforce it at your leisure at compilation time. Clojure seems like a great language, but it has a completely different focus. I'd say Idris is a contender instead, which is not lazy and has theory proving. Will it become popular in the wild? Of course not, Python & JavaScript or something even easier is going to eat th…
I think Clojure puts a similar amount of effort to Haskell in order to discourage mutable state: the core library makes the easy solutions the ones that use immutable data structures and pure functions, and you have relatively ergonomic escape hatches (State/ST monad, atoms/volatiles/transients) available if you need them. Haskell's compile-time checking of purity and explicit effects is obviously absent from Clojure…
I like dynamic typing when doing data science, and I like heavily enforced types when someone else dumps code in my lap.
Earlier quoted context omitted.
You really do. "Generators" are APIs, their implementations may vary, even across different CPython versions, and Stackless is not the only implementation (yet a significant one) that you should consider when talking about the differences in memory footprint. Numba, Cython, Nuitka, and a few other more exotic compilers all have their own implementations of compiled generators, and some of them allocate the required t…
Hey, I actually used to work on the numba compiler team at Continuum. I can say I don’t understand the last rant paragraph at all or why you think it’s related to my point about generators.
This is not a rant, you made a claim about generators' allocations inefficiencies compared to physical list() and tuple() allocations, I'd like to see the case where it's true.
Earlier quoted context omitted.
A sidenote: how great would it be if someday an abounded, well written, non buggy piece of code could just stand the test of time like math does? Instead we throw projects and programming languages faster than I change my wardrobe. :)
The maths of today has very little to do with the maths of 500 years ago, let alone 2500 years ago. Sure, we still have the Pythagorean theorem, but in today's modern formulation it's trivial. We still have numbers, but they are no longer something that can be totally ordered. With numbers we even turned things upside down, because we used to first try to define single numbers and only then collections of numbers. Th…
How many of the popular languages even have formal specifications to use as a reference when the next CPU architecture comes along, or the next ABI?
The tools exist but I don't see people rushing to Modula-2 for example, which has.
It does remind me a bit of this paper "Boosting Vector Calculus with the Graphical Notation" [1], but we instead have over ten thousand only partially defined ones.
But I can agree that my view of math is a bit too rosy.
Earlier quoted context omitted.
> The only members of the ML family that I'm aware of are Ocaml and the flavours of Standard ML. Only Ocaml is fit for production. F# is also a member of the ML family and is totally fit for production.
F# is the language I want to like, and would like to use in prod, but it constantly feels like the ignored step-child. The REPL is great in theory, but trying to import packages is a nightmare every time I try. Dependencies exist, but they all seem to target wide and inconsistent range of the ecosystem. Want to target dotnetcore 3.1? Good luck have fun: everything you find useful is targeting some combination of stan…
Nevertheless i would still wait another few month for things to stabilize with .net 5.
Earlier quoted context omitted.
> complexity in tooling and unnecessary tension when working with libraries Yep. I’m currently feeling this. I’m thankful I’m not a complete beginner and thankful for the Haskellers that blog their opinionated experiences. But this is such a roundabout way of learning. It’s also almost unfair to compare things to Rust’s Cargo (and Elixir’s Mix). They set the bar pretty high IMO. Haskell would be more widely used if t…
> Haskell would be more widely used if the ecosystem was more cohesive (perhaps a bit more centralized). > I’ve been enjoying Haskell enough that I’d like to help improve things. I am hatching an idea along these lines. How do I get in touch with you? Alternatively can email me at the address here if you like: http://web.jaguarpaw.co.uk/~tom/contact/