vmchale

55 ms·

631.
by vmchale 8y ago
> Laziness can make it harder for some to reason about performance as an example. Lots of people are fond of pointing this out, but very few are actually able to reason about performance of lazy data structures.
632.
by vmchale 8y ago
> complicates debugging and performance reasoning Lots of people say this, very few understand what it actually means and how to do the analyses. > Laziness is, in my opinion, the wrong default. Unfortunately, GHC is still the only co
633.
by vmchale 8y ago
> I like it's stripped-down feature set How could the absence of sum types possibly be a good thing?
634.
by vmchale 8y ago
Pretty expensive, to be honest. Facebook snatches up most of the "engineers" and blockchain companies hire a lot of the academic community. That being said, if you have the money, Haskell developers will absolutely follow - and in
635.
by vmchale 8y ago
> You miss a lot of the advantages of FP unless you go all-in on it like Haskell does. I'm not familiar with F# but Scala at least has a far inferior compiler (compared to GHC). There are a lot of functional techniques that simply d
636.
by vmchale 8y ago
I'm not familiar with F# but from what I understand it lacks support for laziness, unlike GHC.
637.
by vmchale 8y ago
Haskell's type inference (and type system) are leagues ahead of Java.
638.
by vmchale 8y ago
> the bottom line: it's just not that great for newbies. since most people are going to be newbies at it, i could not recommend it at all. sometimes i think the language even goes over my head, and I'm supposed to be a pretty s
639.
by vmchale 8y ago
> I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome. ATS is far closer and indeed compiles to C. Rust's
640.
by vmchale 8y ago
> some inexplicable reason C also has a quite decent reputation if you think like this, you will never replace C... > Using C outside a kernel or existing C project today is professional negligence. or embedded development lol
641.
by vmchale 8y ago
ATS is in a better state than Zig/Jai lol
642.
by vmchale 8y ago
> You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice. Ironi
643.
by vmchale 8y ago
Agreed. Comparing compiler pipelines is a poor way to judge how your code will perform in practice, and it's even not that useful for compiler authors, where optimizations that matter in practice are not the same.
644.
by vmchale 8y ago
step 1: hook it up to a car
645.
by vmchale 8y ago
Haskell is call-by-need so you get guarantees you wouldn't otherwise. It's not the same as memoization but it gives you what you want in any case.
646.
by vmchale 8y ago
> I do not think that the naive recursive Fibonacci is a useful benchmark in any way though, it's a way too pessimized implementation. probably, but I would still like to see more benchmarks that use recursion. It's a fundament
647.
by vmchale 8y ago
They pay like 2x more than competitors that aren't big tech companies.
648.
by vmchale 8y ago
> Haskell being the exception due to the absence of quick and dirty mutability I don't think that's "getting in your way" so much as asking you learn pure, immutable data structures. Which is good even aside concerns
649.
by vmchale 8y ago
> Real hardware is imperative. Wrong. > So practical languages took the good idea out of OOP for convenient syntax sugars. Also wrong, unless by "syntactic sugars" you mean "nontrivial compiler rewrites" > Funct
650.
by vmchale 8y ago
> Static typing imposes limitations (kind of like government), where to begin
651.
by vmchale 8y ago
> so all functional code is arguably syntactic sugar No. "Syntatic sugar" implies that it is relatively trivial 1-1 translation that could in principle go backwards. Functional programming has many, many more optimizations and
652.
by vmchale 8y ago
> show how spreadsheets and functional programming are equivalent They are not in fact equivalent, unless the functional programming you're doing is trivial.
653.
by vmchale 8y ago
Eh, aside from embedded development binary size isn't really a problem. And at this point, having experience with ATS + Rust, the fact that the memory-management model is still wonky is kind of disappointing.
654.
by vmchale 8y ago
> ELF golf actually turns out to be important in embedded work
655.
by vmchale 8y ago
Haskell actually has a reasonably functional way of approaching things like I/O (in part due to laziness), so that you can e.g. parallelize I/O actions by passing them to a `parallel` function.
656.
by vmchale 8y ago
> It seems to me like monads must be the logical conclusion to this style of programming, or else you wind up with a mess (or just abandoning this technique.) Monads are nice, but there's a lot of work on algebraic effects/effe
657.
by vmchale 8y ago
> This says a lot about how little the industry cares about software quality. You'd think a bunch of people who make a living out of automating tasks would happily use tools that automate the checking of an importnt source of bugs.
658.
by vmchale 8y ago
> As it turns out, their strategy of extending an existing language to make it safer worked great, while brand new languages that are safer than Typescript are now miles behind it in terms of adoption Did it? Adoption seems to me to be a
659.
by vmchale 8y ago
> I agree the solution is not perfect and ideally I would nuke the language out of orbit. > But that approach will never win the hearts of UNIXy kernel devs I don't think this is fair. The Linux kernel contains (as of writing) 17
660.
by vmchale 8y ago
It's not safe though. ATS/Rust are.

More ›