Hirrolot

10 ms·

61.
by Hirrolot 3y ago
> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? I think this tends to hold true for all complex systems past certain point. Especially web frameworks. They just tend to circumvent t
62.
by Hirrolot 3y ago
> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the t
63.
by Hirrolot 4y ago
I find the terminology that Haskell uses quite misleading for software engineering. It borrows concepts from category theory with quaint names such as a "monad", "endofunctor", "catamorphism", etc. The problem
64.
by Hirrolot 4y ago
Built-in support for closures in Golang is indeed a nice feature. In contrast, in C you would have to explicitly allocate/deallocate closures if they are passed upwards the stack [1], and pack all environmental variables in a single st
65.
by Hirrolot 4y ago
> Inevitably, you will want to do something the framework did not forecast and will come up with convoluted ways to do it anyway. I always find static site generators a kind of leaky abstraction. They eventually try to abstract nearly th
66.
How to implement dependent types in 80 lines of code(gist.github.com)
3 points by Hirrolot 4y ago|0 comments
67.
by Hirrolot 4y ago
Well yes. But this all requires additional movements on my side. On the other hand, if the tests are always ordered such that dependencies are tested first, then I won't have to deal with the approaches you've mentioned. Ideally,
68.
by Hirrolot 4y ago
I've answered it in the other comment -- because I might not know the entire module dependency graph. For example, if the code is not mine.
69.
by Hirrolot 4y ago
Even if I can have multiple failing tests, unordered testing might get tricky. For example, as I said, A depends on B, and suppose that both A and B tests are failing. If I (or really anyone else in the team) forget that A depends on B, the
70.
by Hirrolot 4y ago
I disagree that ordered tests are bad. See, I don't even have mutable state in my program -- but still have ordered tests for another reason: the ease of debugging. Say, if module A depends on module B, then B should be tested first, o
71.
by Hirrolot 4y ago
Well, your example is not a generic closure, since inside `adder`, you already have a generic type `T`; it's introduced by the `fn` keyword. If we try to do the same for a closure, we would face a type error. This issue has been discus
72.
by Hirrolot 4y ago
The example provided in the post -- yes. But I can basically demonstrate other language features that are not working with closures, such as generics -- you just can't have generic closures in the same way as you have generic functions
73.
by Hirrolot 4y ago
You can have general recursion with dependent types though. Theorem provers prohibit it because otherwise it'd render the system logically inconsistent, which is far less severe in programming than in mathematics. But I agree that a gr
74.
by Hirrolot 4y ago
That would not be a comprehensive comparison, but: - OCaml is definitely tailored for more "high-level" tasks, such as writing a programming language or a theorem prover (there are many of them in the OCaml world, and even Rust wa
75.
by Hirrolot 4y ago
I find type errors in HM typing systems can sometimes be quite obscure and misleading, due to omnipresent type inference. Writing type signatures can save you from that. For example, even if the type signature is quite "obvious",
76.
by Hirrolot 4y ago
Yeah, the main problem with dependent types being used in low-level programming is that they're now able to perform arbitrary computation. That's why I think castrated dependent types might do the trick, since if you accept only i
77.
by Hirrolot 4y ago
Your example indeed perfectly demonstrates the subtlety of closures in Rust. Now let's imagine I want to return a nested closure, e.g., `impl Fn(i32) -> impl Fn(i32) -> i32`, or something like that: fn adder(x: i32) -> i
78.
by Hirrolot 4y ago
> "fundamentally broken" and yet I've been using them with little to no friction for pretty close to a decade now. This might rather confirm my point, since engineers using a specific programming language quite often have
79.
by Hirrolot 4y ago
One important thing Rust and Haskell have in similar is the nearly complete absence of an endeavour to unify things. As more fancy type system features get added, both languages become quite complex, thus increasing the learning curve and c
80.
by Hirrolot 4y ago
HKTs in Haskell are quite castrated, too. Haskell only lets you define HKTs via data type declarations, while, in general, HKTs can be considered just functions "one level up" -- instead of operating on the term-level, they operat
81.
by Hirrolot 4y ago
Closures in Rust are fundamentally broken. See [1] for the discussion. [1] https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-...
82.
by Hirrolot 4y ago
The Rust community seems to be obsessed with the idea of re-writing every prior piece of software in Rust, to such an extent that there is a specific word for it: RIIR. This is sometimes funny, since it demonstrates the incentive to be &quo
83.
by Hirrolot 4y ago
Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.
84.
by Hirrolot 4y ago
It's strange that most of the times, they just confuse me more. I'd prefer just looking at the BNF grammar...
85.
by Hirrolot 4y ago
"Checking Dependent Types with Normalization by Evaluation: A Tutorial" [1] This one is cool too, I believe from the same author. I've read it recently and it makes pretty clear the intuition behind dependent types implementa
86.
by Hirrolot 4y ago
I'm afraid I can't answer your question. Either scenario -- a unified system or a "halfway house" -- might be the case; it depends on the intentions of people who design programming languages and the number of pretty arb
87.
by Hirrolot 4y ago
Zig is an attempt to merge metaprogramming and type system into a single, coherent unit, however not without drawbacks. Basically, in an ideal language, I see that type system permits three kinds of dependencies: - Values dependent on value
88.
x86 Opcode and Instruction Reference(ref.x86asm.net)
3 points by Hirrolot 4y ago|0 comments
89.
by Hirrolot 4y ago
I have a similar essay entitled "Why Static Languages Suffer From Complexity" [1]. I don't deal with TypeScript, so it's up to you whether the essay relates to it or not. Basically, the idea is that languages make type-l
90.
by Hirrolot 4y ago
Does it mean that languages should prohibit type-level programming (or type-valued functions), like in Idris?

More ›