Executables should pin.
Libraries should depend on ranges (though they can also pin internally for development).
1,213 karma · joined October 12, 2011
mail@ianjeffries.net
Libraries should depend on ranges (though they can also pin internally for development).
+ The Stack package manager for haskell: https://docs.haskellstack.org/en/stable/README/
+ NixOS: https://nixos.org/
Note that NixOS' drive towards critical mass isn't complete yet. It has great Haskell support (especially since Stack has nix integration), but may not have as good support for your language. No point in switching OSes before the time is right.
EDIT: The right solution is the simple one. Follow RFC4180 exactly. Reject everything that doesn't match it.
Just like timezones and calendar changes, leap seconds are a display issue. While obviously very important in some circumstances there's no need to keep track of them through absolutely all of our code.
If the way you measure time takes leap seconds into account, you have no way of saying "exactly X Système international seconds from now". This is a big deal.
I use NixOS as my main OS though and it works fine.
Both are very tastefully designed (so I've heard, I haven't used Elm myself). If you're coming from something like Haskell and really value correct abstractions go with PureScript. If you need something working right now and don't plan on pushing the boundaries of the language then Elm should be fine.
EDIT: Also I like my numbers reflexive.
(Downsides: Haskell is weird (but good), you have to have Stack installed, and the first time you run the script it will take a while to download dependencies)
More resources: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md#s...
I should have said "JSON number's aren't machine numbers" (e.g. float, double, integer). But serialized, human-readable numbers are still numbers, so I was wrong.
no program can be purely functional
By this I mean that a function that takes an Int and outputs an Int will have type `Int -> Int`, and a function that takes an Int, does logging, and outputs an Int will have type `Int -> IO Int`. Both are purely functional -- they're pure transformations from an Int to some other thing. For the first function that other thing is another Int, for the second that other thing is an action that can be performed by the machine which will return an Int.
So from the perspective that matters to us a developers programs can be purely functional.
(This becomes even more useful with something like PureScript's granular effect tracking https://github.com/purescript/purescript/wiki/Differences-fr...)
That's the point.
If a genius can't make a tricky personal website without breaking things, what chance do normal people have?
Just make a normal website.
Brett Victor is awesome. If you copy his website, you're learning exactly the wrong lessons from him.
data Sign = Positive | Negative
data Digit = Zero | One ... Eight | Nine
data JSONNumber = JSONNumber
{ _sign :: Maybe Sign
, _integerPart :: [Digit]
, _fractionalPart :: Maybe [Digit]
}
Of course, users of the parsers could ask to have a number converted to a float, but that wouldn't be the default.
We're a long way from that though. At the moment I don't even feel like I can write a protocol that expected implementations to distinguish `1` and `1.0`. This should not be the case.
IMO this wasn't originally a bad thing at all. There are so many different types of numbers, with so many different behaviours (does `1` == `1.0`? Not in statistics class) that trying to work it all out in JSON would have been a fools errand. The problem is that so many JSON parsers are overly aggressive about turning JSON Numbers into something specific (usually floats) that when writing a JSON API we have to assume it will be consumed in this lowest-common-denomitor way.
By the way, I don't think that all JSON numbers are technically both integers and floats. `42` and `42.0` are clearly different according to the spec, IMO. I'd be curious to get your thoughts on this.
If we want it to be secure anyway...
You've read about the dozens on dozens of compromised exchanges?
You heard about the DAO hack?
You realize that the majority of bitcoin is mined by like a dozen people in China?
Maybe someday we'll get our act together, but right now blockchains are a recipe for FUD and centralization.
(I say this as someone who thinks bitcoin is cool. For instance, the traditional financial system makes it unnecessarily hard to send money overseas, a need bitcoin can fill well. But secure? No.)
(Do be aware of pastejacking though, but this is not nearly an important enough issue for a wall of shame)
EDIT: We can all learn something from the readability of that page though. One zoom and it's better than 90% of the websites I've seen. Text -- it works.
I was in Chattanooga from 2013-15 and have nothing but good things to say about their team. Most notably they ran a functional programming meetup that covered pretty advanced topics but was still inclusive to beginners. I'll remember the encouragement I got there for a long time.
If anybody who cares about the Chattanooga tech scene reads this: do your best to keep the OpenTable team intact. A lot of the programming community's enthusiasm is either directly coming from or being encouraged by them.
DISCLAIMER?: I was in Chattanooga a couple weeks ago and they gave me a bunch of useful, free advice on my current project. This isn't really a disclaimer though because IMO it just reflects even better on them.
It's up there with bash
bash is the world's default shell for a reason
At the same time I think it's important to note that the entropy analogy is just an analogy. Software is not actually subject to the laws of entropy (at least no more than a book or a poem is). Sure, often we want to change programs for various reasons -- that's not entropy.
Most fields have to deal with actual entropy -- the fact that we don't should be super exciting. See chubot's adject comment for just some of the things this makes possible.
This is similar advice to "always have your castle ready to withstand a siege". Both are excellent pieces of advice -- for 2010s software/the medieval ages respectively. But the advice is not timeless, once we get/got our crap together it stops making sense.
Software decays because we don't track all its inputs. Once we do it will no longer decay, when run in environment X it will give output Y, every time. There's already movement on this front with http://nixos.org and imitators -- I expect massive improvements on that front in our lifetimes.
Of course, you still need an x86-64 computer or whatever. I doubt they'll stop making them any time soon though=)
Imagine you want to implement a vacation-booking service
as part of an enterprise system. The first step is to
remove any reference to computers or modern technology.
This will allow you to concentrate on the business
objectives of the service, without getting sidetracked by
technological considerations. In other words, it enables
you to separate the “what” from the “how.”
(But yeah, compared to languages that were designed over years obviously it's incredibly bad.)
To quote Eich (from here[1]):
" Ten days to implement the lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler. I had help only for jsdate.c, from Ken Smith of Netscape (who, per our over-optimistic agreement, cloned java.util.Date -- Y2K bugs and all! Gosling...).
Sorry, not enough time for me to analyze tail position (using an attribute grammar approach: http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_...). Ten days without much sleep to build JS from scratch, "make it look like Java" (I made it look like C), and smuggle in its saving graces: first class functions (closures came later but were part of the plan), Self-ish prototypes (one per instance, not many as in Self).
I'll do better in the next life. "
[1] Edit: jwz.org intercepts HN links. See mjgoeke's comment.