pka

23 ms·

181.
by pka 10y ago
> And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them. This is definitely true. The firmware on your phone is probably
182.
by pka 10y ago
Instead of abstractly arguing over "writing generic code", here are some concrete examples I came up with when running down a random Haskell file: * Thing.map :: (a -> b) -> Thing a -> Thing b instead of deriving Functor
183.
by pka 10y ago
It's only because Elm is basic Haskell minus a lot of stuff. So basically if you know Haskell you already know Elm (so you need the 15 minutes to get up to speed wrt ports and subscriptions or whatever), but at the same time miss the s
184.
by pka 10y ago
You seem to miss the point. Elm is particularly easy to pick up for people coming from Haskell. Maybe not in 15 seconds, but 15 minutes is a totally reasonable estimate. The author can without doubt write a large project in Elm. His compl
185.
by pka 10y ago
PureScript!
186.
by pka 10y ago
Yep, there are several. [0] https://github.com/paf31/purescript-thermite [1] https://github.com/alexmingoia/purescript-pux [2] https://github.com/slamdata/purescript-halogen
187.
by pka 10y ago
And what if those beliefs are "fuck democracy"?
188.
by pka 10y ago
So is Rich Hickey self-taught (I don't know)? I think the "before college" comment is mostly meant as "self taught" rather than literally "before the age of 18".
189.
by pka 10y ago
iirc they scrapped that in favor of virtual-dom a long time ago.
190.
by pka 10y ago
Well, Clojure/ClojureScript?
191.
by pka 10y ago
Yes, it can, although I can't say how usable those bindings are. [0] https://github.com/arthur-xavier/purescript-react-native [1] https://github.com/hoodunit/purescript-react-native
192.
by pka 10y ago
Elm's type systems is really constrained compared to PureScript's. It's great for people coming from JavaScript, but not so much for those coming from Haskell. Also, you still need FFI in Elm. elm-lang/virtual-dom is bas
193.
by pka 10y ago
> What you are doing is claiming types into and out of functions decide if they are functioning correctly. This is not the case at all. When I say proof, I mean it in the mathematical sense. The Curry–Howard isomorphism [0] formalizes th
194.
by pka 10y ago
> This is wrong because it depends on the language. The behavior depends on the implementation but if you are meant to return the first character in the string and the string has no characters then you should return an empty string if pr
195.
by pka 10y ago
I'm thinking a lot of the complexity of writing a compiler stems from the usage of inappropriate tools. I.e. I would rather kill myself than write a lexer in C (without yacc / bison), but using parser combinators it's a rathe
196.
by pka 10y ago
Well, an F to C converter is not a terribly interesting case, because it would be trivial to implement. When you think about it, how would you test this in your favourite language of choice? By computing the expected value by using the sam
197.
by pka 10y ago
> Also, you know as well as I do that you don't need to test every input, only a representative subset if you use unit tests and use a fuzzing testing library. The thing is that you can never be sure that you chose a "represent
198.
by pka 10y ago
Exactly :) And a proof that the spec is correct. But without formal verification both your spec and the implementation may be incorrect.
199.
by pka 10y ago
- Unit testing: Provide every test case possible Even if your program only takes a 32 bit integer as an input you'd have to provide 4294967296 test cases. Most programs' inputs are a bit larger than that. - Pure Fu
200.
by pka 10y ago
The sibling comment points out property based testing (see QuickCheck), which is a good idea in any language. And yes - you don't need to write that many unit tests (but still some) when using a type system, because you can encode a lo
201.
by pka 10y ago
Yes, record accessors being partial functions is a big problem. One way to deal with this is to not use fields at all together with algebraic data types (i.e. when you have more than one constructor), just pattern match. When you have some
202.
by pka 10y ago
While I disagree (static typing is much more than catching type conversion errors), my point was that it makes experimentation and design exploration much easier and faster. Without types, you'd need mock data for even the simplest of
203.
by pka 10y ago
I'm not an expert on type systems, but I don't think it would add that much in your case. You might get more out of it if you wanted by using phantom types, which is just a way to differentiate among structurally identical types,
204.
by pka 10y ago
Agreed. My comment wasn't aimed that much at Haskell in particular (even if it's my language of choice), but rather the idea of using structure/types for fast experimentation, rather than just a REPL. Also, using a type check
205.
by pka 10y ago
Static languages, in particular Haskell, PureScript, etc, are unparalleled when it comes to fast prototyping or design space exploration. The compiler can show you whether your idea even makes sense before writing big chunks of business c
206.
by pka 10y ago
I just really hope I’m not wasting my time. I think this is very easy verify: just climb down the abstraction ladder and try to solve some particular problem without those abstractions. If you then find yourself yearning for monads, macro
207.
by pka 10y ago
On the contrary, it's about reducing complexity. You don't have to worry about mixins, classes, prototypes, inhertiance. Just plain old functions. Can't get simpler than that.
208.
by pka 10y ago
Higher order functions are not such a complicated concept. Just a function passed to a function. You use functions, right?
209.
by pka 10y ago
No no, just higher order functions. They don't have join and return.
210.
by pka 10y ago
I'm not qualified enough to comment on the possibility of strong AI, but one thing to consider is that natural intelligences don't launch the missiles only because they are afraid of the resulting total annihilation, of death basi

More ›