skysight-inc/HackerNews huggingface dataset:
TLDR: Virtualization meets continuous delivery in the now, versus conventional systems administration in the way-back-when.

In practice, "immutability" (again poor terminology) means disposability.

15 years ago, if I wanted to update a software component on a UNIX system, I upgraded the software package and its dependencies. Now I tend to view running server instances as components. If you need to upgrade the OS or some package on the system, just replace the server with one that's updated. If you need to upgrade your own application code, create new server instances with the new code and replace the old servers with it.

Also features gems like:

(1) rolling back with immutable infrastructure to a recently previous version is cheap and easy: you just replace the new servers with servers launched from a previous image.
What's wrong with this picture? Nothing should touch production that isn't a known quantity.

(2) The way to get infrastructure right is to have a continuous knowledge relationship with system specifications (what I call promises in CFEngine language)
Silver bullet scenario without clear definition.

(3) Disposability emerges often in a society when resources seem plentiful. Eventually resources become less plentiful, and the need to handle the waste returns.
Isn't that why older, full-hardware era PFCTs like CFEngine/Puppet area losing ground to LXC and snapshot-capable filesystems?

(4) Mission critical servers running monolithic applications cannot generally be managed in this disposable manner.
Actually they can, just not by these immature tools. That's because both (a) the overly simplistic deployment methodology of older, full-hardware era PFCTs like CFEngine/Puppet provides no integrated tools for storage management; and (b) deployment speeds and therefore feedback loops are again far too slow; moreover the old-school immature "try it and see" approach is allowed, encouraged and favoured over any formalistic SOA service interoperability testing model resulting in known inter-service compatibilities that can be used to inform and rationally restrict changes to production infrastructure.
It think you have a great idea about peer review of the code. We already have contacts with coders in the online password management business. The only thing that might be a problem is the involvement of the government. Like with Lavabit, they force them to reveal there SSL master key so that they could intercept every communications. We are currently trying to figure out if we could host our server in switzerland or something.(it fixed the problem for several security company we know.) I think our product present a huge leap in privacy for email compared to google and the likes who allow free access to data. Keep that in mind. http://gizmodo.com/how-google-gives-your-information-to-the-...
> Shape can lay itself out with regards to its enclosing rectangle for example.

How so? I mean, sure, Shape can declare, say

bool is_inside(Rectangle enclosing_rect)

...but how would Shape know how to calculate that? It'd be an abstract method. All of Shape's methods would be abstract methods. Thus, a Shape is an interface: a contract an object makes with the system to say that it has a given API.
Spyware's role in domestic violence
http://stackoverflow.com/questions/4858585/why-is-ghc-so-lar...
Scientists are attempting to recreate dinosaurs by manipulating chicken DNA
I liked the Ascent of Money.
I remember having boxing and wrestling matches in the playground at school (from very young up until the age of 17 when I finished) ... things like body hits only and slaps to the head and face. As long as no-one went psycho it was pretty good to get your energy out (and since there were always other boys standing around watching if someone did go psycho they were shut down pretty quickly so no-one ever got hurt badly).
Ask HN:  Why Haskell?
I was hating on Haskell the other day. A lot of HN'ers apparently love it, because my comment was downvoted.

One of the replies said:

"I've seen experienced programmers failing at learning Haskell...the initial learning curve is very steep, and they don't see the value on climbing that wall...with Haskell, all those seemingly complex concepts come with a big reward." [1] [2]

My question is: I currently don't see the value proposition of learning Haskell. What is this great enlightenment I'm supposed to receive from studying Haskell? Can someone give me the TLDR version?

PS: If you say "functional programming", please elaborate. I know all about function pointers in C, and I've read the docs of Python's functools module [3].

[1] https://news.ycombinator.com/item?id=7478274

[2] I don't want this thread to degenerate into a favorite editor flamewar the way the other one did, so I'm leaving out the commenter's clearly preposterous claim that learning vim is worth your time.

[3] http://docs.python.org/3/library/functools.html
First, investment pours into companies with users and revenue.

The next stage it's companies with users but no revenue.

The final stage is companies with no revenue and no users.

It's the Minsky-moment updated for the internet age. (first people take out loans they can afford to pay back; then loans where they can only afford to pay the interest; then finally people start taking out loans where they can afford neither the interest nor the principal payments)
Do you know of any library that generates multiple GETs without some blatant warning in the documentation? I would guess that even though it might be allowed in the RFC it poses no problem in practice.
A Spot-On Parody of Every Brand Video Ever
Isn't he mostly complaining about lack of encapsulation? So what if you do encapsulate your data? That's totally possible in most programming languages, and it's even possible in javascript if you drop prototype inheritance. You can use closures to encapsulate your data.
Whenever people criticize the market valuations, shouldn't Laissez Faire advocates say, "the market is always right?" There is something they don't know.
Class inheritance should be about the data not the behavior. If you're looking for "IS-A" inheritance, you should look at: what parameters does the class require on construction. If your implementation isn't fundamentally based around the same construction parameters, then it shouldn't be a derived class.

For example: HTTPResponseHandler IS-A TCPResponseHandler because its primary role requires a TCP socket on construction. The only inherited methods should be management of the data from construction.

Problems with this only arise when people use subclass to gain the interface but not the data. You should never need to do this and it's a problem with using classes instead of interfaces for your parameter declarations – it's not a problem with class inheritance.
I think there may be some confusion about what a space leak in Haskell is.

When you apply a function f to a, that is not actually evaluated. Rather, a "thunk" is created that will evaluate `f a` only when that value is actually needed.

If, in your program, you never need anything, or don't "force" your function calls and data structures ("pretend" to need something) in intermediary stages, then the thunks may take up a non-trivial amount of memory. This is not a memory leak in the traditional sense, just temporarily increased memory usage.

It is very easy to (pre-emptively) handle most space leaks in Haskell, but you do need to know how they arise.

There are two very simply rules you can follow that take care of the vast majority of space leaks:

1. Make data fields strict unless you actually want them to be lazy, i.e. instead of:

data Foo = Foo
{ bar :: String
, baz :: Int
}

write

data Foo = Foo
{ bar :: !String
, baz :: !Int
}

2. When you write recursive functions that depend on values which are not forced (e.g. pattern matched against) in each function call, use either `seq`/$! or bangpatterns to make sure the value is evaluated (to HNF) rather than building up excessive thunks. For example, instead of:

acceptLoop :: Socket -> Int -> IO ()
acceptLoop sock connNum = do
econn <- accept sock
_ <- case econn of
Left err -> printf "Error accepting connection %d: %s" connNum err
Right conn -> forkIO $ runConn conn
acceptLoop sock (connNum+1)

write either

acceptLoop :: Socket -> Int -> IO ()
acceptLoop sock !connNum = do
econn <- accept sock
_ <- case econn of
Left err -> printf "Error accepting connection %d: %s" connNum err
Right conn -> forkIO $ runConn conn
acceptLoop sock (connNum+1)

or

acceptLoop :: Socket -> Int -> IO ()
acceptLoop sock connNum = do
econn <- accept sock
_ <- case econn of
Left err -> printf "Error accepting connection %d: %s" connNum err
Right conn -> forkIO $ runConn conn
acceptLoop sock $! connNum+1

to make sure that connNum is always just a single value rather than a series of unevaluated thunks. That way you won't get a space leak if you rarely have problems accepting new connections.
How Dropbox Knows When You’re Sharing Copyrighted Stuff Without Actually Looking
no I want people driving cars around in circles for fun! and ghost ridin the whip. Oakland is dripping with creativity even in high crime areas.
Thanks JL for sharing and helping him! Hopefully this time investment in HN and Y-Combinator has led to lots of ideas for his coming writing.
>Could I reproduce this patented system without ever reading the patent just by looking at the results of it

This reasoning is deeply flawed. There is a tendency for something to seem "easy" or "obvious" after the fact, but this is ignoring all the insight, effort, and risk it took to find that initial successful path to the solution to begin with. Take a look at the Occulus Rift for example. Two years ago no one cared about VR. Today there are a handful of companies that claim to have a headset on par or better than the Rift. What changed? The Rift proved that it was viable, and now its relatively easy to follow their path to a successful product. Just because a solution is obvious after the fact, does not mean its creation was equally as obvious.

>Patents don't exist to protect ideas, they are supposed to protect unique and novel implementations of inventions, not ideas.

An apple lawyer could easily say that the "idea" here was unlocking of the phone, while the implementation/invention was the "slide to unlock" functionality. Neither is more right than the other.

Edit: would be an interesting experiment to have public downvotes
You certainly do seem restless and confident, but it seems to me the qualifications you list (PHP, Python, js, html/css) put you still near the bottom of a very long ladder. If you feel you're exceptional, then prove it. What have you written that's exceptional? What projects have you contributed to?
Yes. That's snooping. They're actively looking at what I store with them.
i never understood the sentiment, that people are afraid that their tool of choice becomes "mainstream" popular

i think people argue a lot about which language is better, because programming languages need to be popular

they need to be popular, because this is the best guanranty they will have lots of good quality libraries

and a bad language with good libraries trumps a good language with no libraries

if haskell becomes "ruby" popular, and haskell i believe is actually one of the more popular functional languages, you will only benefit
"Deserve" is a framing that wraps together a moral claim with what is intended to be a purely utilitarian calculus (whether a class of patent "promote[s] the Progress of Science and useful Arts"). As soon as you start framing things in terms of who "deserves" what, the side who can generate greater pathos wins.
Hi, Stephan from the Ethereum project here.

I must say that seeing that link taken down was surprising, since Ethereum is at its core a programming paradigm for decentralized applications + a distribution mechanism.

In fact, the only 'thing' Ethereum borrows from bitcoin/altcoins is the implementation of decentralized consensus at scale, which we believe is applicable not just to currencies, but also the law, entrepreneurship, governance and many other fields.

If people here would like to help us improving our messaging, feel free to post here!! We're really appreciative for any advice, straight from the horse's mouth :)
Advocating for abolishing software patents is saying that software is a special case. This is not obviously so (the 'software is math' argument is weak), and so any argument one puts forward for abolishing software patents likely applies to many other areas. It is obvious there is a problem with the quality of software patents being issued. It is not obvious that software patents in general should be abolished. After all, is it not possible to have an invention that is largely or completely software?
The article makes no mention of quantitative easing. I think that has a bit of an effect of the stock market I general, not just tech IPOs.

So, I don't think this market is anything like 1999, this is very different.
@wyclif Thanks for letting me know. I added this box last week. I used a jQuery plugin called Tweetable that grabs tweets without authentication from www.getmytweets.co.uk. I noticed that this is very slow. Over summer break, I plan to write my own Twitter API wrapper for unauthenticated requests that is fast enough to cover my blog's needs.
I used to lump "Work Smarter, Not Harder" in with the gigantic category of information I classed as "self help bullshit".

It is, however, very good advice. The truth is that it's relatively easy to exchange your time for money, what's very difficult is to set up a system which makes money without taking up all your time.

I would say it's far more worthwhile to learn how to do that, even when the numbers (ie. actual money being made) are small, because it creates the freedom to experiment with other, more ambitious projects.

Also, if you're in the habit of "working hard" you may not realise that you're wasting your (finite) time and (finite) energy on something that has little chance of succeeding.

I liken "work smart not hard" to not buying the biggest house you can possibly buy based on how much you can borrow. If you are constantly "mortgaged to the hilt" in terms of your time and energy expenditure you are setting yourself up to make bad decisions and miss opportunities when something that is genuinely worth all that time and effort comes along.

You should never run any system at "full capacity" for very long.
I mean, I agree such examples exist. I don't think this is yet a truly good example, though. The real advantage to existential types like this are in creation of multiple variants---again I recommend reading Jeremy Gibbons' paper.

But, for completeness, here's how you could write your type

{-# LANGUAGE ExistentialQuantification #-}
data Test = forall i o . Test i (i -> o) (o -> o -> Bool) o

Although, note, this is exactly equivalent to `Bool`, although in two ways—if we knew the comparator function was commutative then there'd be just one way to convert to `Bool`.

testBool :: Test -> Bool
testBool (Test i fun cmp o) = cmp (fun i) o

testBool' :: Test -> Bool
testBool' (Test i fun cmp o) = cmp o (fun i)

But in either case there are no other ways to "observe" the existentially quantified types since we've forgotten absolutely everything besides `Bool`. More likely we would want to also, say, show the input.

data Test = forall i o . (Eq o, Show i) =>
Test i (i -> o) o

and this type is now equal to `(String, Bool)`.

testOff :: Test -> (String, Bool)
testOff (Test i fun o) = (show i, fun i == o)

So, in general, if you're using existential types you really want to either be using multiple variants or when you have such a combination of observables that it's not worth expressing them all directly.
You still have to convince the town residents to pony up the money or see it as a good idea.
Both his essays and this site pretty much reshaped my whole view on programming, economics and entrepreneurship, and I know some other people who can say the same thing, so I'd like here to thank you and your husband for all the hard, good work. You created tremendous amounts of value for the world. I do strongly hope PG has some more essays coming ;).
During the 90s internet stocks were doubling or tripling in a matter of days. That isn't happening now. This market is very frothy but this most certainly isn't 99. That said, the market can go anywhere. The market could be topping right now and on it's way to DOW 5000, or it could be taking a break then go merrily on it's way to DOW 35,000. It doesn't matter what Schiff says, it doesn't matter what the cheerleaders say. The market will do its own thing.
Qatar accused of working 1,200 people to death for 2022 World Cup
When I was in elementary school, much of the playground was built out of old car, truck, and tractor tires. There were conventional swings and slides, but there was also a tractor-tire tower to defend, a couple of car-tire geodesic-sphere-like structures, and other such wonders but the jewel was TireTown, a fortress built out of tires with tire bridges connecting to two smaller structures. TireTown was easily two meters high, and an agile kid could easily climb onto the roof and slide down one of the provided poles.

All of this was done with materials to hand, not safety-certified foam and plastic, although many of the tires were glued fast together for greater structural support. Nobody batted an eyelash. Nobody complained. This was the 1980s, which I still think of as being not that long ago, but compared to today we had it much better off. Just to be certain, and doubtful that something as wonderful as TireTown would be permitted by today's standards, I checked the satellite images of my old elementary school.

All the tire structures -- completely gone. And the playground area seems a lot smaller than I remembered it...
Most of my lingering injuries are the result of an attempt to get exercise.

I broke my pinky finger playing softball, and it never healed right.

I hurt my knee learning to dance.
Games on the big board are irrelevant compared to the intelligence service of a nation state ripping your life appart because they want your access credentials to do some industrial espionage.

Because this is what this is. A nation state coming down with all his power on some of us worthless pawns because we work in otherwise harmless infrastructure businesses. How is that being compensated for by the abstract benefits of an allegiance in "the war of the systems" or some other bullshit.
> still uses directed non-cyclic graphs for classification (eg, single inheritance) shows just how powerful single inheritance really is

Perhaps I'm missing something, but I think the article makes the point that single inheritance results in a tree structure, not a DAG. That aside, I feel it's unfortunate that he chose to illustrate his point by way of analogy, as it seems some of the arguments here are refuting the analogy and not his original point.

My personal experience has been that as software grows in complexity, isa relationships tend to fall apart. Generally this is because although they have some characteristics in common, they only have SOME characteristics in common. Further, the more the tree grows in breadth, the fewer the shared characteristics there are. Over time, this overlap becomes so small as to utterly rob the isa relationship of meaning. Saying X is a Y simply means that (generally for historical reasons) you chose to emphasise the commonality of X and Y over the equally valid relationship that X is a Z. Oh and often an A and a B.

I say grows in breadth because, with inheritance, having a tree grow in depth suggests specialisation in each branch WITHOUT behaviour shared between some (but not all) nodes in different branches of the tree. In practice I've found this happens so infrequently as to barely worthy of consideration.

>> when you see these kinds of errors it probably means that you're classifying things incorrectly

I accept that this may be entirely true. However, I have seen significant resources (time, mental effort, etc) dedicated to discovering the correct classification - although that presupposes that there is a correct classification, so perhaps I should say more useful classification - of a class hierarchy in a project, and have not been able to find something adequate. Whether this was due to our stupidity, or whether this is because there is indeed no clear way to express the relationship in hierarchical terms, the fact remains that it made inheritance an unsuitable way for us to model our problem domain.

> Often you can fix an IS-A by simply refactoring your graph

Your use of the word suggests to the reader that this is an easy undertaking. In practice I have found this is often note the case. Saying that we CAN refactor the inheritance tree doesn't mean that it is simple to do, and I posit that by the time you have learnt enough about your domain to recognise you have modelled it incorrectly, the hierarchy is of such complexity that this is generally a very difficult undertaking. Again, I'm not arguing against refactoring, but rather that refactoring inheritance hierarchies is often difficult.

I think ericHosick (above/below?) says it best:

> In the real world, people can build out classification systems and easily add in edge cases when we find new ways things can be classified. In software, that could lead to a complete change in the software architecture.

My experiences are obviously anecdotal, but since I find that I - and many other software developers whom I talk to - struggle to make domain modelling using class hierarchies work, his argument that is inherently flawed rings true.
Thanks for sharing Ghost. I did not know about it till now. It looks pretty neat, especially since it runs on my favorite stack: Node.js and Handlebars :)
We're talking about values, but I think these are ultimately empirical questions about which system performs better under certain constraints.

I think these empirical questions can be resolved prior to implementation, by modeling the incentive structure of employees operating under traditional payment schemes, and employees operating under coupling transactions under Strangecoin, and then running simulations of the two models. I suspect traditional currencies will perform well under certain assumptions, but also that Strangecoin will perform well under similar assumptions, and may even outperform traditional currencies.

In particular, I suspect that an employee with a coupled Scoin transaction with a business will have a closer relationship with that business, partly because the transaction has direct consequences on every other transaction the user engages in, and (by extension) has a closer association with that employee's identity than another business offering only a weekly paycheck.

Businesses spend lots of money cultivating employee cultures so that they identify with the business, and these aspects of the culture can be more influential on employee motivation and job satisfaction than financial compensation. Strangecoin builds these relationships directly into the transaction, so we might expect it to have similar consequences.

But as I said, I think these are empirical questions that can only be solved from the armchair if that armchair is in front of a computer model simulation.
One of My Most Frequent Pieces of Advice: Be Politely Persistent
Disclaimer: graphite co-maintainer here. This is own of my favorite graphite dashboards. This one and giraffe are two of the nicest
I've never seen any explanation from Rich on the subject, but semantically speaking, vectors used in syntactic constructs are almost universally meant to denote binding forms. Let-bindings, loop-bindings, function parameters and the like all use vectors in the context of binding symbols to values.

I find that, having gotten used to the mental shortcut "square brackets == binding", the distinction makes it easier to read the "shape" of code from a very high level and get a general understanding of its meaning at a glance. YMMV.
Isn't that what a traditional co-op is?