Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
bjz_
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
91.
▲
by
bjz_
8y ago
It probably could do with some examples, and better docs, but it seems like they use this to update old chunks, which is a great use of lenses. But yeah, you'd have to weigh that up against how ugly it turns out to be in Java. It'
92.
▲
by
bjz_
8y ago
Fair enough! Yeah, I've heard good things about that series.
93.
▲
by
bjz_
8y ago
Yup, lots of people are under the impression that you need to prove everything when it comes to DTs. That's not true - you can indeed push these checks to runtime, and just have the compiler make ensure you do it.
94.
▲
by
bjz_
8y ago
Don't get me wrong - CT is a super handy thing to learn, and it pops up a ton when thinking about any software, including type checkers and compilers, but the OP was specifically asking about type theory and programming language implem
95.
▲
by
bjz_
8y ago
I believe it's more just how to use a dependently typed language (my copy is still in the mail). Like the Little Schemer, it's written in the Socratic style. I think the idea is that you can do it all in your head if you want, wit
96.
▲
by
bjz_
8y ago
Note that many of those problems are being actively worked on in research, and progress is being made, albeit slowly. That said, we can still get some of the benefits of dependent types, even without all the problems being solved right now!
97.
▲
by
bjz_
8y ago
Typescript actually does have some forms of type dependency (eg. conditional types), but these things have been added in a sort of ad-hoc way, and it's unclear how sound they actually are, and they are quite limited. The book here uses
98.
▲
by
bjz_
8y ago
I hear that Practical Foundations of Programming Languages by Robert Harper[0] is highly recommended. I have Types and Programming Languages, but found it a little dry to be honest. I do use it as a reference manual in my work though. [0]:
99.
▲
by
bjz_
8y ago
They've been historically hard to implement in a way that is both efficient, sound, integrates with effectful code, promotes code reuse (like in Haskell), and has good developer UX (good error messages and IDE support). I believe we ar
100.
▲
by
bjz_
8y ago
Yeah, I agree. And when Rust removed poorly designed things, they were often replaced with alternatives that solved the problem better, so it was never felt like a pain.
101.
▲
by
bjz_
8y ago
Yeah! I also liked how escape hatches weren't looked down upon as much. They're kind of important if you want to be developing production software! It's cool to remove stuff if things are poorly designed (which Elm's nat
102.
▲
by
bjz_
8y ago
Kind of curious if anyone's played around with using incr_dom with Reason: - https://github.com/janestreet/incr_dom/ - https://www.youtube.com/watch?v=h_e5pPKI0K4 Seems like it might be tied
103.
▲
by
bjz_
8y ago
The difference in Rust's case is that whenever anything was removed it was replaced with something that was better designed. It provided escape hatches available to allow for workarounds (ie. unsafe, and a nice FFI), and to allow C lib
104.
▲
by
bjz_
8y ago
Go broke a lot of things pre-1.0. Rust did as well! Just think it's worth remembering before making comparisons like this.
105.
▲
by
bjz_
8y ago
Most other English-speaking people in the world deal with different accents reasonably often in media and their lives, the American accent most of all. I think it's more that it's easy for American's to live in a bubble, beca
106.
▲
by
bjz_
8y ago
There is work being done to bring an algebraic effects system to OCaml, but it's slow going. I think because the people pushing it have a bunch of other things on their plates too. But it would be super nice to have!
107.
▲
by
bjz_
8y ago
> No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses. Standard ML has less need for type classes because it has a much more expressive module system, but it still can be extremely tedio
108.
▲
by
bjz_
8y ago
Yeah, IIRC many years ago I added it in a document as a pattern for C APIs (I can't remember where though). Either other people were doing the same thing, or were influenced by that. Anyway, you should use `*const libc::void` these day
109.
▲
by
bjz_
8y ago
Oh lovely, will have to give this a read at some stage! I'd also be really interested in versioning, and upgrading a cluster over time, without bringing the whole thing down (like with Cloud Haskell). Would be super handy to be able to
110.
▲
by
bjz_
8y ago
Dialyzer works on success typing, which only tells you when it's certain there's a bug, but will stay silent if it's unsure. Even at the highest settings I couldn't get the same lovely iteration loop that you get in an
111.
▲
by
bjz_
8y ago
Most systems aren't really at the scale where the BEAM really excels. I'd still contend that they would be far better off with a good type system to make it easy to refactor and iterate as requirements change. Apparently Typed Akk
112.
▲
by
bjz_
8y ago
Algebraic effect systems can also do this. See Koka, Eff, Multicore OCaml, Frank, Purescript-run, freer-effects, freer-simple etc. These generally allow you to handle effects in different ways. Not sure if F#'s type system is powerful
113.
▲
by
bjz_
8y ago
In Rust and Haskell you can do: match foo() { Bar @ foo => foo.x, Baz => ..., }
114.
▲
by
bjz_
8y ago
As Haskell begins to get more and more dependently typed features this could definitely be an exciting possibility (I think there are folks already working on this).
115.
▲
by
bjz_
8y ago
Lots of folks seem to be getting drawn to actix-web, which features quite a bit up the top of these benchmarks. I've not used it, but it works on stable, is fully async, and has been met with many good reviews!
116.
▲
by
bjz_
8y ago
And many other languages before it - SML, OCaml, Haskell, Miranda, Erlang, Scala, Rust...
117.
▲
by
bjz_
8y ago
Rust will do optimisation on the layout of Option-looking data types to simplify them down to a pointer size if possible.
118.
▲
by
bjz_
9y ago
I kind of found Dialyzer disappointing from starting a project from scratch. It would miss many obvious mistakes that I expected would be caught. Very much was not a fan of this key design decision of success typing! That said, the theoreti
119.
▲
by
bjz_
9y ago
Ah, thanks for the extra info. I'm too young to have dealt with this stuff myself, so first-hand experience is always really interesting! What I have had to deal with is schemaless JSON HTTP APIs - definitely know what a pain that is!
120.
▲
by
bjz_
9y ago
Sounds pretty nice actually. I'm guessing there could be pain over time though when it came to maintaining it. Easy to add, hard to remove or change?
More ›