Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
catnaroek
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
297 ms
·
2071.
▲
by
catnaroek
13y ago
dang, ninja'd me
2072.
▲
by
catnaroek
13y ago
Types themselves are not proofs. In particular, the proposition associated to a type might be a blatant lie - you simply should be unable to find a term for that type. Also, the notion of blame in a contract maps directly to the type chec
2073.
▲
by
catnaroek
13y ago
And their core, types and contracts are the same thing: logical propositions asserting properties of a program that have to be enforced somehow. The difference is the method of enforcement: types are enforced via static analysis and contrac
2074.
▲
by
catnaroek
13y ago
LASER's homepage ( http://carboni.ca/projects/p/laser ) for some reason does not load in my browser. http://downforeveryoneorjustme.com/http://carboni.ca/project... Judging the
2075.
▲
by
catnaroek
13y ago
If you are developing a system meant to be stable and run for an indefinite period of time, static analysis imposes less computational overhead. You pay the price of static analysis only once. You pay the price of runtime checks every time
2076.
▲
by
catnaroek
13y ago
My understanding of simplicity is that it can be nailed down to a few universal principles: 1. Facilitating local reasoning : I do not want to read the whole program to understand what a single line of code may or may not do. 2. Compart
2077.
▲
by
catnaroek
13y ago
Runtime tests always cause a performance penalty. (And they do not prevent you from writing buggy programs! They just make the runtime environment yell at you if a bug is found.) If you want to guarantee that a property holds for all the el
2078.
▲
by
catnaroek
13y ago
Ease of use. Which is not the same thing as simplicity.
2079.
▲
by
catnaroek
13y ago
Learning a new programming language is an intellectual, exploratory endeavor, even if it might result in adopting that language for future programming projects. Writing software professionally is a pragmatic engineering job constrained by n
2080.
▲
by
catnaroek
13y ago
In my experience, jumping straight to writing code results, if anything, in a huge mess. For anything more complex than proof of concept programs for specific language or library features, this quickly becomes unmanageable. I have obtained
2081.
▲
by
catnaroek
13y ago
> "The types of your nodes probably don't have much to do with any algorithms you may be writing." Which is precisely why he wants generic types. > "Consider your algorithms as functions which act on an interface.&
2082.
▲
by
catnaroek
13y ago
That way you can delude yourself into thinking you are productive, because you are writing code immediately. However, productivity is not to be measured by the number of lines of code; rather, by 1. the amount of actual functionality implem
2083.
▲
by
catnaroek
13y ago
Fanbois hate it when someone points at the flaws in their favorite language. I still cannot comprehend why. As much as I like Haskell and Standard ML, if someone pointed out their flaws (Haskell: lame module system, needing arcane hacks to
2084.
▲
by
catnaroek
13y ago
In many ways, Carlsen reminds me of my two favorite champions: Like Capablanca, he plays the opening and the middlegame "naturally", seemingly just following "common sense" positional principles - sure, backed by calcula
2085.
▲
by
catnaroek
13y ago
One problem with that idiomatic Scala code is that all inherited traits have to be declared in the same place, making the definition conceptually "too loaded". (Scala's implicits allow for something more flexible, akin to Has
2086.
▲
by
catnaroek
13y ago
Rust's polymorphism system is somewhat limited compared to, say, (GHC) Haskell. But, to the best of my knowledge, it is the best among languages aiming at mainstream.
2087.
▲
by
catnaroek
13y ago
That suggests a problem with subtyping (or, rather, with inheritance as construct for implementing subtyping), not with generics. Parametric polymorphism is a most natural notion.
2088.
▲
by
catnaroek
13y ago
Taken from the article: > "Strongly typed (with dyamic casting)" > "while Go is statically typed, it has a strong system for dynamic casting and reflection". This is not even wrong. The whole point to using types
2089.
▲
by
catnaroek
13y ago
Or learning how to write code you can trust without testing it.
2090.
▲
by
catnaroek
13y ago
Yaaaaaaaaaaaawn. There are much better reasons not to learn Rails: http://www.yesodweb.com/
2091.
▲
by
catnaroek
13y ago
To a certain extent, the analogy is fair: Go's design is much simpler (in the sense of "bare bones") than Rust's, just like C's design is much simpler than C++'s. But this comes at the price of leaving many com