Classes Considered Harmful [pdf] - <AUTHOR> http://web.cecs.pdx.edu/~black/publications/ClassesHarmful.pdf <comment><USER4> Having used C++, Java, C#, Python, Ruby, NewtonScript, Dylan, Scheme, and various other languages "in anger" I can say that in general I agree with the author's frustrations. My favorite (as in most flexible, least boilerplate) approaches to object-oriented programming have been:

\- NewtonScript's frames with prototype inheritance. Allows "objects" to consist of very small data structures that point to ROM objects and only use RAM for slots that actually vary, using copy-on-write. The actual implementation had some issues and of course that platform is dead, but the concept was great.

\- Dylan's adaptation of generic functions, with multiple inheritance. There are classes but they don't have methods "inside" them. The class hierarchy describes the dispatch for the generic functions. Allows some really nice styles of programming (dispatching on multiple parameters) that are perhaps possible but absolutely hideous in C++.

\- Qt's method. The use of a separate preprocessor step and generated code for dispatch was a hack to get around limitations of C++, but although you don't want to look too closely at that generated code if you value your sanity, at a practical level it works pretty well.

In summary, I'd just add that it is a deep and abiding shame of my industry that people wind up in silos learning one model of object-oriented programming and never consider other models that are different and can be cleaner and far simpler to think about.

<comment><USER5> In addition to Dylan, Julia also allows multiple dispatch via generic functions.

I have found this approach to multiple dispatch leads to code that's much easier to reason about and maintain. My use case is a tensor library where the tensors have a single interface but various storage backend types, which 'interact' with each other. It doesn't make sense to define these interactions through methods belonging to only one class or the other.

<comment><USER6> Also R via the S4 OOP system, which was directly inspired by Dylan

</comment></comment></comment><comment><USER7> I like this kind of critical papers but I cannot agree with the author in this case. I have studied this problem quite deeply while working on concept- oriented programming and concept-oriented data model ([http://conceptoriented.org/](http://conceptoriented.org/)) for many years by also trying to minimize the number of basic constructs. Yet, my conclusion is that classes are actually needed.

There are several major reasons for that. One of them is that we actually need two different relations: 1) membership relation, and 2) inheritance (or inclusion in more general case). Unfortunately, we cannot reduce them to one relation. If we do (in prototype-based languages) then normally we will still distinguish the role of this one relation depending on the context.

Mathematically, we have the membership relation '∈' between an element and a set, and we have the subset relation '⊆'. Just as we need both of them, we need both class instances and classes. In other words, if somebody argues that classes are not needed, then it is analogous to the statement that sets are not needed and it is enough to have only membership relation among elements. It is possible to develop such a theory but then we will get an alternative mathematics. Or we will implicitly treat some elements as sets.

<comment><USER8> _we actually need two different relations: 1) membership relation, and 2) inheritance (or inclusion in more general case)._

No. You don't _need_ OO at all, let alone bolt-on conceptual baggage like this.

 _The notion of object oriented programming is completely misunderstood. It 's not about objects and classes, it's all about messages._ \- Alan Kay[0]

[0] From my fortune clone @ [https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

<comment><USER9> Message passing only takes you so far. As soon as you want to start reasoning you will structure your messages into groups and now you're back to what looks suspiciously like classes.

I'm not arguing for one or the other but that extreme late-binding as espoused in much of the smalltalk way of doing OO only takes you so far. Static reasoning about program structure is helpful and just message passing alone does not give you enough structure to do that.

</comment></comment></comment><comment><USER10> The practical usefulness of classes in C++ comes not from an "object- orientedness" that they supposedly give the language. It comes from the fact that they are merely a _mechanism_ that can be used to create abstract data types, thereby providing a better encapsulation, and do many other things, rather than a _policy_ saying that every object must be an instance of a class. So, one has to be careful when talking about classes, because they may effectively mean different things in different programming languages, even though on the surface they may look similar or appear to serve the same purpose.

<comment><USER11> Classes tightly couple functions on types with the type declaration itself. It's often not even clear in which class certain methods belong.

Better to separate data types from functions on data types the way it's done in functional languages, and if you still want object-oriented programming, you can support it like Ada does, or as syntactic sugar over the ordinary call syntax like some functional languages do.

<comment><USER12> Better why?

<comment><USER13> Superior composability with simpler semantics and sounder type systems.

Class hierarchies are inherently unfriendly to strong, sound type systems. Interface composition isn't.

Composing interfaces is clean and straightforward. Composing classes isn't, and you run into things like the diamond problem.

<comment><USER14> Classes do not imply inheritance. Classes are a means of defining an interface, albeit a heavy one.

The statement that it is better to separate data and behavior is far from self-evident IMO, and I would be very interested to understand why this is such a deeply held belief. Seriously, why?

<comment><USER15> It's not always true, by any stretch of the imagination. Closures couple data and behavior and most (though not all) functional programmers consider closures to be pretty central to FP. I'd add that closures are hard to use in that way without allocating, which is why I think one potentially reasonable argument against coupling data and behavior is performance-driven, but that's a more subtle argument that ignores compiler performance (and there are times where you lose more from all the extra code taking up your icache than you gain in speed due to not allocating; plus, as C++ and Rust demonstrate, you can have closures without allocation if you're willing to heavily restrict them).

<comment><USER13> > Closures couple data and behavior

The use of closures in functional programming is an implementation detail, not a fundamental aspect of the underlying theory, and closures only "couple" data and behavior in the very literal sense that it is a function that happens to point to some data under the hood, not in the syntactic or semantic sense we're referring to when we say that OOP classes couple behavior and data.

A closure in a pure language can't couple to data any more than a lambda expression without free variables (from the programmer's perspective), because they can have the exact same type and semantics.

In other words, there's no semantic difference between "f = \x . x + 2" and "f = let y = 2 in \x . x + y" even though the latter is a closure in the absence of inlining.

<comment><USER15> Purity seems to be totally orthogonal to this question, to me. I'm referring to the ability to return thunks from within called functions, such that the data are totally encapsulated in the closure (are not passed in explicitly and cannot be retrieved manually). That seems to be coupling data and behavior to me, since you can't run the function without the data it was coupled with at construction time. Whether that's fundamental or not is, of course, a subjective question, but I have a hard time thinking of a language that bills itself as functional that doesn't provide that capability natively (Rust and C++ make it difficult, but neither really bill themselves as functional).

<comment><USER13> > Purity seems to be totally orthogonal to this question, to me.

Ah, well there's the confusion. A language with semantically impure closures emphatically _does not_ reproduce the semantics of the lambda calculus unless you restrict yourself to only pure, immutable variables. But if you reproduce the lambda calculus, there's no need for closures as we know them. It's just an implementation that happens to work well. You could supercompile the lambda-abstraction at the application site and avoid having a closure. It's just not a good idea.

But I agree, in a language with mutable variable capture, you can reproduce the semantics of OOP by providing a bundle of functions closed over mutable references to the "object" data.

> a language that bills itself as functional that doesn't provide that > capability natively

I'm not sure exactly what capability you're referring to. Could you clarify a little bit?

<comment><USER15> I'm referring to "information hiding" by providing a function that uses currying in order to close over data that cannot be accessed from the caller. For example:

        (* foo.ml *)
        let bar =
          let foo = lambda x . lambda y .
            if y == 0 then { getFoo : lambda z . 0 }
            else { getFoo : lambda z . (x * z - x + z) / y }
            end
          in foo 3

        (* bar.ml *)

        include foo.ml

        let y = bar 5
        bar.getFoo(4)

It sure seems to me that bar is hiding the 3 from bar.ml (and there are much more complicated examples where foo.ml really can't get at the captured type, for instance), and at the same time it's capturing the value of 5. The function getFoo on bar is bound to it (the record type can desugar to more curried lambdas, if necessary, it's just tedious and this illustrates my point better).

None of this seems to have anything to do with mutation, to me, though it certainly seems to have both information hiding and binding logic and data. The fact that it can be compiled not to use closures (using whole-program compilation) is immaterial; the same is true for the same program specified with objects in mutable languages (SML has both mutation and closures, and MLton does exactly that).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> There seems to be a common fixation on objects "modeling the real world" with the counter argument for classes being that they don't model the real world. True, there isn't a physical chair class in real life(philosophically, there aren't even chairs), but there is a common abstract _idea_ of what would describe the function and attributes of a chair. Granted, it differs a little from person to person, but objects themselves are all different in some way. As far as I can tell, in most OO languages, there's no reason why classes _must_ use inheritance, though I am certainly willing to be schooled in that regard.

<comment><USER17> > As far as I can tell, in most OO languages, there's no reason why classes > must use inheritance, though I am certainly willing to be schooled in that > regard.

That there is no precise definition of what a class is and isn't, and that the traditional notion of a class conflates several independent concepts, is precisely the big criticism! To my mind "traditional classes" means inheritance, and recent languages without inheritance (Rust or Go) have tended to not use the term "class".

<comment><AUTHOR> Forgive my ignorance. What do Rust and Go call their data structures that are analogous to classes?

<comment><USER18> There really isn't a direct analog in Rust. The best approximation in Rust is actually a combination of constructs in the language: structs and traits.

Structs are almost exactly like the C-objects of the same name: they define layout in memory for a data structure with discrete types as fields, and there are various packing options available. However in addition to this a struct- specific implementation can exist which defines static and instance based methods. As there is no inheritance in Rust, a struct's "impl" is unique to itself.

Polymorphism is implemented via the traits system. A trait defines a set of methods that objects meant to have said trait must implement (unless a default implementation for a given method in the trait exists). Any struct can have an implementation for a given trait, so these can be considered a (rough) analog to abstract base classes/interfaces (e.g. C++ classes that are either pure virtual or have virtual functions with default implementations).

<comment><USER19> You say traits are a rough analogue for C++ base classes with virtual methods. What are the fundamental differences?

<comment><USER18> I'm not familiar enough with the internals of how Rust handles v-tables and the like in light of its other features to answer that competently.

In practice, one defines an interface in C++ by having a (hopefully) stateless class with pure virtual method declarations, and then classes derived from this class must implement these methods (in order to instantiate them anyway). In Rust one defines a data structure (either a struct or enum) and then, separately, writes the "impl" for it for a trait.

<comment><USER20> The big difference is that when you have a trait object in Rust, it's a double pointer: a pointer to the vtable, and a pointer to the data. In C++, in my understanding, you'd have a single pointer to both the vtable and data laid out next to each other.

<comment><USER19> So rust traits are effectively/functionally abstract classes with restricted functionality and a different implementation?

<comment><USER20> Sort of. The closest thing in C++ would be concepts. That is, even using traits in this way is the minority case; they're more usually used for monomorphized, statically dispatched code.

But, given the case where you want dynamic dispatch, then in a sense, they are, yes.

<comment><USER19> Right. I suppose in Rust you generally use variants and pattern matching when dynamic dispatching is required.

<comment><USER20> You could, but that requires that you know all of the variants ahead of time. The advantage of trait objects is that you don't have to.

It really just depends on what exactly you're trying to do.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Most eye-opening moment in my software engineering class was when the professor asked, of four core OO features (don't recall the precise list now), which was superfluous.

The answer, of course, was inheritance, and once the question was asked it wasn't hard to see how much better life could be without it. I've been on an anti-inheritance kick ever since.

Now I see how much better life can be without OO entirely, but that's a different discussion.

<comment><USER22> I think that inheritance can have a place. It makes a lot of sense when writing //small variations// on an otherwise rich inner class. Small variations might include layering on a different input or output mechanism, or possibly handling 'extra' data that the object stores but previously did not modify.

<comment><USER23> You can achieve the same with composition or parametrisation. Both of which are the _only_ tools in a functional language.

<comment><USER24> You can achieve the same in any Turing complete language.

However, composition and parametrization require up-front design and are usually only viable for large-ish variations.

As the parent said, inheritance handles the case of _refinement_ , that is, _programming by difference_ , which composition and parametrization handle with difficulty (if planned for) or not at all (if not planned for).

The bad rap inheritance gets is that it is often misused in places where composition or parametrization were appropriate. But that's just the old "it hurts when I poke myself in the eye with a sharp stick": don't do that.

[http://www.metaobject.com/papers/Diplomarbeit.pdf](http://www.metaobject.com/papers/Diplomarbeit.pdf)

</comment></comment></comment></comment><comment><USER25> The biggest problem with classes is that they conflate two different concepts in a way that limits reusability.

When you have classes, you have subclassing, and subclassing means two different things at the same time. First, subclasses are the subtyping operation. If you want type B to be a subtype of A, B must subclass A. Second, they provide code reuse via inheritance.

Each of those things is useful, but there's no reason to tie them together. In fact, modern best practices in OO say to favor interfaces and delegation over subclassing, and that's precisely because it separates those two concerns.

As far as I can tell, this is what the paper was getting at - <USER2> delegation of implementation from subtyping. Since this is already what OO best practices suggest, why is it controversial?

</comment><comment><USER26> Although he spends quite some time on exploring the alternatives, the only reason the author specifically states where classes are harmful is _because they are premature optimization_. That's it?

I guess "Classes considered a PITA" just didn't make a good title.

<comment><USER27> He delegates to his other paper with "A long discussion of the issues can be found in my submission to MASPEGHI 2013 [1]". That paper can be found here:

[http://www.cs.jyu.fi/maspeghi2013/papers.html](http://www.cs.jyu.fi/maspeghi2013/papers.html)

specifically:

[http://www.cs.jyu.fi/maspeghi2013/p17-black.pdf](http://www.cs.jyu.fi/maspeghi2013/p17-black.pdf)

</comment></comment><comment><USER28> For what it's worth, the footer reads, "Submission to NOOL / 2015/10/12".

NOOL seems to stand for "New Object-Oriented Languages", a workshop of the ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH).

[http://2016.splashcon.org/home](http://2016.splashcon.org/home)

[http://2016.splashcon.org/track/nool2016](http://2016.splashcon.org/track/nool2016)

<comment><USER29> And the paper does appear in the program of NOOL 2015(!), so it has been accepted.

[http://2015.splashcon.org/track/nool2015#program](http://2015.splashcon.org/track/nool2015#program)

</comment></comment><comment><USER30> At least in the cases of C# and Java, classes and interfaces recapitulate a weak form of ML-style functional programming rather an impoverished version of Smalltalk-style object-oriented programming: "Inheritance" from a class corresponds to logical disjunction (and hence is equivalent to a sum type) and "implementation" of an interfaces corresponds to logical conjunction (and hence corresponds to product types). The visitor pattern is a verbose form of pattern matching.

You can recover the strong form of ML-style FP (albeit without the nice type inference) if you limit inheritance to abstract classes (thus, all classes are sealed/final or abstract), mark all fields as readonly/final, and use interfaces for destructuring (which addresses problems 1,2 and 3 under the "Alternatives" section).

As an aside, one of the big issues with "classical" OOP is that it enjoins the programmer to create phenomena using logic (i.e. wizardry) rather than of using math to model a system (i.e. science and engineering). Among other problems, this leads to designs that break symmetry (e.g. if modeling a bucket brigade, the perspective of many humans passing by a single bucket should be just as valid and available as the "natural" perspective of many buckets passing by a single human). Of course, appeals to symmetry is question begging, and I don't have time to litigate that here, but it sure seems like symmetry is key to building scalable systems (where scalability means not just number of users, but also things like number of edits to a codebase).

In summary: Classical OOP seems to require that you either have a prior (well- designed and debugged) model against which you can program, or really, really good taste.

</comment><comment><USER31> Link to _The Treaty of Orlando_ : [http://web.media.mit.edu/~lieber/Publications/Treaty-of- Orla...](http://web.media.mit.edu/~lieber/Publications/Treaty-of-Orlando- Chapter.pdf)

</comment><comment><USER32> "I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - <USER3> start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work."

A. Stepanov ([http://www.stlport.org/resources/StepanovUSA.html](http://www.stlport.org/resources/StepanovUSA.html))

<comment><USER33> I think this is more based on the early methodology advice for developing OO software. But the methodology is independent of the constructs (though often limited by it).

In practice these days often the most effective way when developing OO code is working the "proofs" till you have a set of classes.

Also, some people go for very FP inspired OO code.

<comment><USER32> Those are clearly exceptions to the rule, though. You can write sort of Haskell in any language, OOP is still bullshit.

</comment></comment></comment><comment><USER34> The premise is the introduction is wrong.

"so before we have written a single program in our language, before we know whether shared behaviour will be important in the applications that will be written in it"

read the POODR book, or watch this

[https://youtu.be/OMPfEXIlTVE?list=PL5s3t9kPeAN6aDxaSywIbeFJO...](https://youtu.be/OMPfEXIlTVE?list=PL5s3t9kPeAN6aDxaSywIbeFJOCfm7ixpi)

it explains how shared behavior works without code duplication and why people tend to mess it up.

</comment><comment><USER35> Not a single line of code in the entire paper. Without that I have little or no idea what the author is talking about.

</comment><comment><USER36> I write most of my code in Python. I think that's give me a leg to stand on when it comes to discussing OOP.

I find that classes, if nothing else, are a fantastic way to namespace data and methods that operate on said data. For instance, if I have a chair object, I could use a class to describe the chair. I could store the materials it's made out of, the height of the seat, whether it is an office chair, a barstool, or something else. I could also write methods that can say, price the chair based on data about the chair.

In this particular case, I wouldn't subclass the chair at all. There's no point. Every time I need a chair, I would just create a new instance of Chair. That's why chair is an object. It's a self contained thing that I can pass around and pull data out of or mutate.

I don't really use deep inheritance at all in my code. I think the deepest I've ever subclassed something is once. I find inheritance to be useful if I need to be able to create multiple objects that deal with very different things, but perform similar operations on them. A good example of this is Django class based views(it's own controversial topic). I created my own resource class to use for handling API specific requests. The methods of pulling filters out of the query string and serializing database objects are exactly the same for every single request, but the objects that these classes operate on are vastly different. Therefore, I need to specify a serialization schema for each database object type, but I don't necessarily need to rewrite the function that does the serialization. I use my Resource class in order to more easily re-use these generic methods.

Just my two cents.

</comment><comment><USER37> I can buy a language without classes if it gives me these things:

* Interfaces

* Records

* Abstract data types

* All the above should use foo.bar() syntax

Classes provide those things, which is good, but also provide implementation inheritance, which is bad.

<comment><USER38> >> but also provide implementation inheritance, which is bad.

Inheritance isn't bad.

Abusing inheritance is bad.

For the record, you can also abuse composition, polymorphism, operator overloading, free functions, interfaces, records, and abstract data types. I've abused them all and seen them abused as well.

Inheritance is just another tool. Like all tools, we are expected to use them wisely.

<comment><USER37> Do you know any situations where implementation inheritance is the best tool?

<comment><USER22> I mentioned one such example about 6 hours before your post.

As the other reply stated, when you mostly want to keep the base class but over-ride a small specific subset of what it does.

E.G.

The base class uses class member functions to do save/load records from a store.

You want to implement a variant of that class which instead works well with a database engine you like.

You can then derive a class and define JUST the storage and recall functions, and inherit everything else.

<comment><USER37> Interfaces are a better tool for that case IMO. One small utility interface (save/load) and two implementations would be easier to test in isolation and wouldn't suffer from the fragile base class problem.

</comment></comment></comment></comment></comment><comment><USER39> Funny how when the author finally arrives at the point where he intends to go from "unnecessary" to "bad", he has little more to say than "there is no space to repeat it here".

</comment><comment><USER40> I like Factors ([http://factorcode.org/](http://factorcode.org/)) approach to classes. In that language, a class is a category and not a "mold" from which objects are created. E.g, I can say the following:

        33 number?
        t
        33 integer?
        t
        integer number class<=
        t
        number object class<=
        t

The last two lines demonstrates a little of the class algebra possible. It says that if an object is an instance of the integer class, then it also an instance of the number class and of the object class. That is, the set of objects that are integers is a subset of the set of objects that are numbers which is a subset of all objects.

I can add new classes which refines categories of existing objects:

        PREDICATE: positive < number 0 > ;
        PREDICATE: prime-number < integer prime? ;
        17 positive?
        t
        17 prime-number?
        t
        13.4 positive?
        t

Note that both real and integer values can be "positive" which means that "positive" isn't a strict subset of either class. That kind of refinement isn't possible in most oo languages.

</comment><comment><USER41> Hilarious how he blatantly ignores the existence of C++. He talks about Smalltalk, Java, Grace, Emerald, Pharo... but no C++!

<comment><USER42> Many academics love to ignore it.

</comment></comment><comment><USER43> Even in OO languages (such as Java and C#) people are routinely advised to favor composition over inheritance whenever given half a chance. Classes definitely smell (or rather reek) of the infamous 90s that inflicted such atrocities on humanity as the Rational Rose "products" and the UML "methodologies". It also goes to show why the "typescript" Microsoft strategy is ill thought. Unless of course it's simply (as I think it is) the Mother of all Embrace Extend Extinguish strategies in which case it is very cleverly thought. Sadly ECMAScript has also jumped on the OO bandwagon by offering "classes" syntactic sugar but at least it is left to the developer to use it or not, whereas in the Microsoft-land of "typescript" you get classes rammed down your throat.

</comment><comment><USER7> > "classes do not "model the real world""

Classes are supposed to model sets (of objects), that is, instances represent real objects and classes represent real sets of objects. So the question is whether sets are as real as the members they consist of. For example, if a set of chairs is a reality that we can comprehend and want to represent in the system.

Yet, I think the problem is that we are probably not happy how classes model sets in OOP. They actually do not - and it is a major problem. (Classes in OOP are mostly templates for instantiating objects.) Also, we are not happy with how inheritance works and it also limits possible benefits of classes. But it is not a reason to say that classes per se are harmful. I would say that they are not as good as they could be :(

</comment><comment><USER44> Amount of boilerplate one needs to implement "good" OO design is just horrendous. For example, in C++, previously we had rule of 3. Now its rule of 5! Just having a virtual abstract interface means almost half dozen lines of boilerplate! Even in managed languages such as C# or Java, it would require significant effort to create, say, read-only version of collection given a read-write collection. One of the goal for language design should be to eliminate all these forced boiler plate. It is definitely the time for new paradigm in language design. However I'm not sure how the "delegates" would solve this which is proposed alternative in this paper.

<comment><USER45> I believe Objective C's @property declarations brings some level of what you describe to C/C++. They generate the boilerplate for you.

E.g., @property (readonly) NSString* myName;

</comment></comment><comment><USER46> What is the point of these types of arguments and opinions if they don't have any evidence to back them? I don't give a shit if it's functional or object- oriented or procedural or whatever comes next. I just want a language that is proven, via empirical evidence and reproducibility, to solve my particular use case better than any others.

And, given all the use cases I have, I'd be amazed if one class of language can do it all. I'm guessing it's impossible.

It's way better for my engineering team to know how to use a bunch of different specialized tools, and how to use them together, than to focus on one type of tool.

</comment><comment><USER47> IMO language should be designed to be more effective, simpler or powerful, not to avoid programers to miss use them. All the "rules" about not using goto for example are legitimate but people forget that sometimes using goto could be a good practice in some languages. A semantic is just a tool you can miss used it`s programer issue not a language/semantic issue. OOP is a way to program among other we can argue that it's harder than another or easier but we can't say it's good or bad, it depend on how you use it and hwo effective you are using it.

<comment><USER48> An adage I use is you should know all the rules so you know when and which to break.

<comment><USER49> The problem is that this requires rules to not actually be rules, but strong recommendations. Compilers are good at rules, less so with strong recommendations, which end up in static analysis tooling.

<comment><USER48> The compiler is fine with using GOTO, it's people that are not.

</comment></comment></comment></comment><comment><USER50> I feel like I just read a lot of opinions by one frustrated dude without a real sense of _why_ classes are bad (or even really why they frustrated him so much). Am I missing something?

<comment><USER51> No. You are right. Everything can be bad or good depending on how you use it.

</comment></comment><comment><USER33> so, the argument is it's harmful because it's a premature optimization? the evidence being simply alternatives to classes? It seems like the paper doesn't present a good case for why classes are harmful. Seems the whole premise if flawed based on a glib quote from Knuth

Premature optimization ( if that is what classes are ) doesn't mean the optimization is harmful. It could actually be really good.

The quote means, when you find some evil, and track it back, you'd find premature optimization. You can also find awesome code, track it back, and also find premature optimization.

So, you need to prove classes are evil, and then track it back to premature optimization. This paper fails to do that and therefore fails to make the case for harm

</comment><comment><USER52> Paper neglects to discuss CLOS approach: generic functions instead of methods, etc.

The claim that classes don't do object creation because some operator like "new" actually does that is jaw-droppingly stupid.

</comment><comment><USER34> The premise is wrong, read the POODR book.

</comment><comment><USER19> The paper was a good read. I was kind of dreading it'd be another tired rehash of attacking straw men from someone who thinks having used Java or C++ makes them expert on OOP.

In the early history of smalltalk Alan Kay talks about how he was never entirely satisfied with inheritance, and having inheritance in the language (quoting in full, hard to link to):

 _A word about inheritance. Simula-I had neither classes as objects nor inheritance. Simula-67 added the latter as a generalization to the ALGOL-60 <block> structure. This was a great idea. But it did have some drawbacks: minor ones like name clashes in multiple threaded lists (no one uses threaded lists anymore), and major ones like rigidity in the extended type structures, need to qualify types, only a single path of inheritance, and difficulty in adapting to an interactive development system with incremental compiling and other needs for instant changes. Then there were a host of problems that were really outside the scope of Simula's goals: having to do with various kinds of modeling and inferencing that were of interest in the world of artificial intelligence. For example, not all useful questions could be answered by following a static chain. Some of them required a kind of "inheritance" or "inferencing" through dynamically bound "parts" (i.e. instance variables). Multiple inheritance also looked important but the corresponding possible clashes between methods of the same name in different superclasses looked difficult to handle, and so forth.

On the other hand, since things can be done with a dynamic language that are difficult with a statically compiled one, I just decided to leave inheritance out as a feature in Smalltalk-72, knowing that we could simulate it back using Smalltalk's LISPlike flexibility. The biggest contributor to these AI ideas was Larry Tesler who used what is now called "slot inheritance" extensively in his various versions of early desktop publishing systems. Nowadays, this would be called a "delegation-style" inheritance scheme [Liberman 84]. Danny Bobrow and Terry Winograd during this period were designing a "frame-based" AI language called KRL which was "object-oriented" and I believe was influenced by early Smalltalk. It had a kind of multiple inheritance—called perspectives—which permitted an object to play multiple roles in a very clean way. Many of these ideas a few years later went into PIE, an interesting extension of Smalltalk to networks and higher level descriptions by Ira Goldstein and Bobrow [Goldstein & Bobrow 1980].

By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in its semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction. I was not completely thrilled with it because it seemed that we needed a better theory about inheritance entirely (and still do). For example, inheritance and instancing (which is a kind of inheritance) muddles both pragmatics (such as factoring code to save space) and semantics (used for way too many tasks such as: specialization, generalization, speciation, etc.) Alan Borning employed a multiple inheritance scheme in Thinglab [Borning 1977] which was implemented in Smalltalk-76. But no comprehensive and clean multiple inheritance scheme appeared that was compelling enough to surmount Dan's original Simula-like design._

<comment><USER52> _I was kind of dreading it 'd be another tired rehash of attacking straw men from someone who thinks having used Java or C++ makes them expert on OOP._

It squarely looks like that to me. I'm not fooled by the transparent ruse of dropping a few names like Smalltalk to appear informed.

</comment></comment><comment><USER53> The meme is becoming lame.

Talentless developers who fight and argue are the only real hazard in the world of programming.

Mature trends and languages have attracted decades of developers good and bad, and because they're widely used, they have the misfortune of also providing a home to the largest corpus of terrible code.

Mark my words: in a generation, functional programming will accumulate just as much garbage, inadequately programmed by just as many careless and/or passive- aggressive developers desperately clinging to their jobs throughout the next wave of whatever becomes the next Steve Ballmer stack ranking code review process.

It doesn't matter how many words or ideas you throw at this circumstance. Terrible developers will still manage to commit garbage.

Life finds a way.

<comment><USER54> I feel this counter meme (programming languages/language features/paradigms aren't bad, developers are) also get's thrown around a lot, but I don't understand the argument.

Are all languages really equally good? Is C really no more productive than assembly? Is Swift really no more productive than Objective-C? For many higher level applications is Java really no more productive than C? Doesn't using something higher level like Python make certain kinds of tasks easier than the same task in Java?

Since the inception of programming languages, there has been continuous improvement of the existing languages as well creation of new languages, both of which have introduced new paradigms and features to programming. These new features and paradigms often replace older features and paradigms. Not everything works, but much of the time the new features and paradigms have made writing and maintaining good programs much easier.

Unless you believe our current tools are already completely optimal, it seems only natural to try to improve upon them.

So is your argument that programming languages in a generation will be equal productive/un-productive as what we have now? That seems too pessimistic to me. I think our tools will be much better, just as I feel our tools now are better than they were in 2000 or 1990.

If the argument is that functional programming is not an improvement, that's fine, how do you see languages improving? What's the direction they should take?

<comment><USER53> Turing tarpits aside, people speak very highly of C, just as they may do the same for assembly, but depending on context.

Languages fill a niche, and outside of their area of utility it's easy to notice weaknesses.

But arguments in favor of functions are similar to those in favor of objects. They both joust for the award of being adept at doing more with less code, in terms of mythical-man-month project scalability.

I've experienced that problem with huge OOP code trees, and I still don't foresee Pure Functional programming supplying a cure for that problem. Maybe I'm just not one of the lucky ones yet. I don't know.

But when I read Pure Functional code, even though it's tighter, with less boiler plate, it doesn't feel like honest improvement. It's like Coke or Pepsi, McDonalds or Burger King.

OOP might yeild thousands of source files and hundreds of lines per some files, but if a Pure Functional project does the same thing with fewer lines of code in fewer files, it's still doing the same thing.

So in a decade you'll probably find the same complaints, in the same places, but at least people will have different hair styles.

</comment></comment></comment><comment><USER55> Computer science gets a lot of papers with arguments for a certain way of doing things.

Very few with controlled experiments to find out if a way of doing things is better than another.

Every time I mention this, people say that it is hard to do such experiments. Yes, it is hard to actually know things. while it is very easy to make plausible arguments, for almost anything.

<comment><USER56> Just challenge the promoter to rewrite a c++ base program in their new favorite method, paradigm.

For example, the author of this paper can try to rewrite the google chrome browser - a huge C++ project in the "non-Harmful" way.

<comment><USER57> Rewriting is not very likely.

A new development could use a new paradigm. Same applies to goto vs structured programming, plain procedures vs classes and OOP-style method dispatch, etc.

</comment></comment></comment><comment><USER58> The E programming language, and its newer relatives like Monte, lack classes; instead, objects are defined by object literals and the extends keyword performs object composition by delegation.

<comment><USER59> You mean it's prototypal, like Self, IO, Javascript?

<comment><USER60> No, it's similar to creating an object this way in ES6:

        function makeVector(x, y) {
            return {
                norm: () => Math.sqrt(x*x + y*y),
                // ... more methods ...
            };
        }

but frozen so that consumers can't change it except by calling a method.

It's odd how this is the 'obvious' way to generalize lambda expressions from functions to objects, yet it's rare to see this style, and you always have to clarify that you're not talking about prototypes. (IIRC Emerald, mentioned in the paper, also works something like this.)</comment></comment></comment>


Type 'Merry Christmas' in Google Search - <AUTHOR> https://www.google.com/search?sourceid=chrome&ie=UTF-8&q=Merry+Christmas

<comment><USER2> ugh...</comment>


Ask HN: Becoming an independent technical consultant - <AUTHOR>

I'm trying to work out a different income stream for myself. I'm getting older, and would really like something more appropriate for me as I'm dragged kicking and screaming into old age (I'm 46 - so, not too late to be doing this).
I mostly work for large organizations, but I don't want to spend the rest of my life doing that.
Over the years, I've been contracted by small and medium sized companies as a technical consultant. They are usually friends of friends, or someone I worked with in the past. Including time for paperwork, they typically last about two weeks. It pays well, so it doesn't need to be constant, just steady. As it is, this comes up about once a year.
Feedback I've received has revealed some advantages:
- one point of contact, they always talk to the same person
 - low to no sales pressure, since I don't have a product line to push
 - much less expensive than a full consulting firm, because I have little overhead
 - deliver solutions appropriate to the business. No tech for the sake of tech.
I'm getting ready to do the meetups, technical and business. Before I begin stumbling around, could I get some ideas of what small and medium, preferably technical, businesses might be looking for? What are other benefits? What's a good approach for initiating conversations - the "elevator pitch"? Are there other places I could look?
For what it's worth, I ran a small hosting company for a few years, but got out when everything started consolidating. I'm comfortable with the paperwork, taxes, etc. I'm terrible at marketing, and that's where I'd like your help.
I don't want this to be about me. I think there are others that would be interested.
Thank you. <comment><USER2> I've worked and talked with various dev/IT consultants over the years, and the advice I've gotten boils down to this: specialize in a niche or product. Don't just be a web development consultant, for example. Be a web development consultant with a focus on X.

That X can be anything. Things like Wordpress or Joomla, or product companies like SAP, MS CRM, verticals like finance/banking or energy, or even your own open source project on GitHub.

<comment><AUTHOR> That makes sense, thank you.

</comment></comment><comment><USER3> The same question came up just a little while ago: [https://news.ycombinator.com/item?id=9836376](https://news.ycombinator.com/item?id=9836376)

Check out those threads and start digging. Patio11 is a good person to read up on.

<comment><AUTHOR> I missed that one - thanks!</comment></comment>


Congress passes cellphone unlocking legislation - <AUTHOR> http://www.washingtonpost.com/blogs/the-switch/wp/2014/07/25/congress-passes-cellphone-unlocking-legislation/

<comment><USER2> It is no "quirk" of the DMCA that you cannot remove software locks. It was the entire point of the DMCA. Anyone who has read the text knows that.

<comment><AUTHOR> The point of §1201 of the DMCA was to prevent piracy by preventing circumvention of DRM. It wasn't meant to be used to lock down cell phones. So in some ways, it is a quirk. In other ways not.</comment></comment>


Show HN: my first Saas app in alpha: gethirely.com - <AUTHOR>

I am almost ready to launch my first Saas app, inspired by HN. Its called Hirely, it's for hiring.
It's trying to make hiring a good team a little easier by centralizing positions, candidates, resumes, comments in easy-to-use app. For the overall interaction it's (clearly) inspired on Gmail.
You can have a look at some screenshots here (and sign up for the alpha): http://gethirely.com/
The competition is mainly http://www.theresumator.com/, which is clearly a more mature product right now (although I do dislike their overall UI experience).
If you want to try it out sooner, just contact me at petervandijck at gmail
Thanks for the inspiration HN. Now I hope I can make it through the valley of Prototype-Almost-Finished to the mountain of App-That-Actually-Helps-Users. <comment><AUTHOR> Clicky: <http://gethirely.com/>

</comment><comment><USER2> looks good (similar to an earlier idea I had last year).

<comment><AUTHOR> Thanks :) Any suggestions for features, marketing, etc.?

<comment><USER2> I'd suggest focusing on one industry or subindustry - retail, realty, accounting, etc - and market and focus on their specific needs.</comment></comment></comment>


Ask HN: Is it ok to start a Delaware Corp solely to accept payments? - <AUTHOR> Recently, I've seen several posts on HN* about how to start a US Company, get an EIN, an US bank account from abroad.
I have no intention to move to or work in the US. However, a US company and bank account would be very useful to accept creditcards worldwide, especially with new services like Stripe.com.
From my home country, it is very difficult to get a proper merchant account / payment gateway / business bank account etc. Now I could start a Delaware Corporation, signup for a merchant account / Stripe / whatever, and start accepting international payments.
The Delaware corporation's only purpose would be to accept payments. All real work would be done within my company in my home country. The Delaware Corporation would essentially be the sole reseller of my SAAS app.
Now what are the legal / tax implications of doing so?
Can I charge the US company the same amount it makes on (re)selling a monthly subscription? This would mean the US company would never make a loss or a profit. It would just be a front-end to my company in my home country, which is where I pay taxes.
Is this legal? Or should the US company charge something? EG 1% per transaction?
Are there other (legal) implications of doing this?
* http://myeverwrite.com/opening-a-delaware-corporation-an-incorporation-guide-for-foreigners/ http://blog.freshdesk.com/how-to-incorporate-a-us-corporation-from-outs <comment><USER2> I would look into LLC's based on what your describing. Maybe even an LLP. However I have a slight suspicion if your from a country that it is hard to set up the accounts you described you will likely expose yourself to a lot of liabilities and legal problems in your country. Also I think you will also cause a serious tax headache on your part.

Maybe look and see if there are companies in the US that provide a "corporate shell" and take care of taxes, etc and then pay you as a contractor... Only an idea. Not even sure if this could work or is even legal.

<comment><AUTHOR> Thanks for you reply.

I'm not trying to evade taxes or get into legal trouble. It just looks like it is easier to start (and maintain) a US company and get a Stripe.com account, than it is to get a merchant account and a payment gateway over here.

Because the US company is simply reselling the subscriptions, every sale will be passed through to my company here, so I don't really see any tax headaches.

I am simply wondering if it is legal to use a US company for this.

<comment><USER2> I believe people use corporate shells all the time for things similar to what you are describing. However don't take my word on that But you will still need to pay corporate taxes here in America. Good Luck!

</comment></comment></comment><comment><USER3> Instead of creating a c-corp in US and debating how much profit to leave in US just create a US LLC owned by your home country corp. Thus the profit just passes to your home country corp and you will pay tax on it in your home country.

Also with this setup you can pay all your US expenses (hosting, advertisement etc) out of your US LLC. I am not a lawyer or CPA so discuss this suggestion with a experienced professional

<comment><AUTHOR> I think you're referring to the same setup as rprasad was talking about in his comment (<http://news.ycombinator.com/item?id=3055493>).

(If I'm correct) When a US company pays dividend to it's non US parent company, the US charges a withholding tax of 30%. This can be less if there's a tax treaty between the two countries.

</comment></comment><comment><USER4> Let's say you successfully create a Delaware corporation. It exists. It has a US tax ID number. It has a bank account. It has a merchant account. All of the stuff you want to do business. In other words, stipulate complete success in achieving your business objective.

Here is what the tax part of your plan will look like:

1\. Money comes into your corporation via the merchant account.

2\. After paying expenses, you have money left over inside your Delaware corporation.

3\. That -- to the U.S. government -- is taxable income.

Crap. So you have to pay U.S. tax on the money flowing through the merchant account? You don't want to do that. How do you get the money out of that Delaware corporation?

A. Dividend. No good. First you pay corporate income tax on your profits in the Delaware corporation. Then you pay a dividend to the shareholder--you. The default U.S. rule is that the Delaware corporation has to withhold 30% of the dividend payment it makes to you. There are sometimes ways around this.

B. Loan to you. No good. First you pay corporate income tax on your profits in the Delaware corporation. Then you loan it to yourself. Only marginally better because at least you don't have the 30% withholding tax on the dividend. But you have to pay the loan back, with interest. And the interest payment back to the Delaware corporation is taxable income to the Delaware corporation on which it has to pay income tax.

C. Tax-deductible expense. Aha. Now we're getting somewhere. The Delaware corporation has a business expense that it pays. This reduces its taxable income, thus reducing tax. E.g., $1,000 of profit in the corporation, and you perform services for the corporation and the corporation pays you a consulting fee of $950. Hey presto! New net profit is $1,000 - $950 = $50 profit in the Delaware corporation. Tax liability is next to zero. Yay.

Item C is where the fun and games are. This is called transfer pricing in the tax geek world. (Yes, in fact I do own the domain name taxgeek.com and I can't figure out what to do with it.) In order to do this successfully you have to navigate through complex tax rules to avoid tax withholding on that $950 you paid yourself (analogous to the 30% withholding on that dividend). You have to navigate through the transfer pricing rules generally.

It's awesomely hard. And expensive. The reason is simple: you're trying to drain taxable profits out of a high tax country, thus depriving the U.S. government of money. They are quick to call "Bullshit" on these types of plans. So you have to do it right. And many, many other countries have their own transfer pricing rules.

When you said "Can I charge the US company the same amount it makes on (re)selling a monthly subscription?" you were really talking about something that looks like transfer pricing.

Related party transactions. Meh. Hard. That's what we are talking about and they get looked at by the government. A lot.

Advice: set up the Delaware corporation so it buys your product, marks it up, and resells it. Leave a little profit on the table in the USA and pay tax on it. As long as you are a small potato floating in the great crockpot of life, you are probably going to be OK. :-)

Further advice. You MUST prevent the USA from thinking that you (from wherever you live) are doing business directly in the USA. This is variously called a "permanent establishment" (in treaty lingo) or other similar ideas.

Further advice. The accounting and tax return work for this is going to chew up a lot of your profits. If you get a cheap quotation for tax return work, run like hell. People who are competent in international tax work are rare, therefore expensive. And the price of incompetence is usually big financial penalties from the government -- like $10,000 at a time for not filing the correct documents.

That is why I tell people to concentrate on running their business correctly and not to get clever to save taxes in the international area. Set up as simple a structure as possible to eliminate as many possibilities for error as you can. Like they say in AA, if you don't take the first drink you don't get drunk. If you don't set up that extra-fancy tax-saving device, you can't fuck it up and get hit with a penalty.

<comment><AUTHOR> That's a great reply. Thank you. Maybe you could save comments like these and put them on taxgeek.com :-).

I'm not trying to evade taxes. I'm European, and I pay taxes here. Still, even in Europe getting a Merchant Account is difficult. I'm simply looking at this because the cost (money/time) of starting and maintaining a Delaware Company might be less than the cost of setting up a Merchant Account over here.

Without US company:

1\. Europe company sells subscription for 20/month

2a. Taxable income in Europe

2b. No taxable income in the US

With US company:

1\. Sell subscription through a US company for $20/month

2\. US company receives $18 (Merchant Account keeps 2)

3\. US Company buys subscription at Europe company for $18

4a. Taxable income in Europe

4b. No taxable income in the US

Am I really "draining taxable income" if in the other scenario there wouldn't be any US taxable income either??

Is this what you recommend:

1\. Sell subscription through a US company for $20/month

2\. US company receives $18 (Merchant Account keeps 2)

3\. US Company buys subscription at Europe company for $17

4\. Profit of $1 per subscription per month

5\. Business expenses (including accounting & tax return)

6a. (eg) 5% of total revenues is now taxable income in US

6b. (eg) 95% of total revenues is taxable income in Europe

Of course I would need a good accountant, but things still look pretty simple to me... The only thing I need to calculate business income / expenses is how many subscriptions were active during a month. Please do understand the cost (time/money) of getting a Merchant Account over here. I like to keep things simple too, and it might just be the US route is simpler.

<comment><USER4> Until your revenues are huge I think your idea is fine. Keep as simple as possible. Leave a bit of profit in the Delaware company. Keep your paperwork straight.

This is pragmatism, pure and simple:

\- you are making sales (yay)

\- if you get audited the challenge will be on the basis of the price that your European company gets from the Delaware company. The worst case outcome probably isn't too bad.

\- Unless you are making tens of millions, your Delaware corporation will be a tiny taxpayer among all of the corporations in the USA. Low profile. Clean paperwork. Don't attract attention etc. :-)

\- one last thing. Look at the treaty between your country and the USA. Sometimes there are odd little things you can use to pull business profits out of the USA easily and without tax. Or less tax anyway.

If you don't make a sale you don't have a tax problem. So first make a sale.

</comment></comment></comment><comment><USER5> Seems like you already know this, but speak to a professional even if it costs a little bit. You don't want your company closed down, clients stripped, and you at the top of some U.S tax fraud list.

Best of luck

EDIT: Looks like Mr. Hodgen IS a professional. That's why we love HN!

</comment><comment><USER6> Dividend withholding depends on your home country, so the actual amount that the company would be required to withhold is between 0% and 30% (inclusive).

Really, the best idea if you want to do something like this would involve two companies: a foreign (non-US) parent company that does the actual business operations, and a domestic US company that solely handles US-based payment processing. Dividends from the US company to the parent company can be exempt from withholding (i.e, exempt from US double-taxation), depending on the home country of the foreign company. This sort of structure avoids much of the transfer pricing mess mentioned above, _and_ the self-employment taxes that consultant fees would incur.

Jibjab, you should talk to a tax lawyer or tax professional to help you structure your business and business activities to minimize your overall financial costs (taxes, operating expenses, and otherwise). The money you spend on business planning will pay for itself. I am a tax lawyer, as is Mr. Hodgen. I believe Mr. Hodgen is located in Pasadena, California. My office is in Century City (Los Angeles, California), but my firm has offices worldwide.

 _Circular 230 Notice: Pursuant to US law, the above communication is not intended to be actionable tax advice. It is intended as general information for speaking to a lawyer or other tax professional about the issues related to your specific circumstances._

<comment><AUTHOR> Thank you for your answer.

I understand I have to talk to a professional. Asking on a place like HN however, allow me to be better prepared when I eventually do so.</comment></comment>


The harm done by tests of significance (2003) [pdf] - <AUTHOR> http://andrewgelman.com/wp-content/uploads/2014/12/1154-The-Harm-done-by-tests-of-significance.pdf

<comment><USER2> I found this paper a couple years back when I was writing about statistical errors. I love the right turn on red example -- an everyday situation where bad statistics leads to extra deaths every year. (Somewhere on the order of 10-100, I think.)

The problem, turning "not statistically significant" into "there is no difference," happens all the time in just about every field of science. Often you see people report "three studies found that this medicine work, but two found that it didn't" and conclude that the evidence is contradictory and can't be trusted. But if you look at the effect sizes, you see the five studies found nearly the same answers -- its just two of them didn't quite cross the threshold for significance.

I wish I had a way of teaching statistical thinking more clearly than standard intro classes. It's so weird and counter-intuitive that very few people get it right. I've given it a shot by writing a book ([http://www.statisticsdonewrong.com/](http://www.statisticsdonewrong.com/)) but there's a lot more to be done.

<comment><USER3> >But if you look at the effect sizes, you see the five studies found nearly the same answers -- its just two of them didn't quite cross the threshold for significance.

This is why I wish meta-analysis was introduced much earlier than it is in statistics education. There are sensible ways of combining the information from the five studies, weighting them according to their sample size (provided the studies are similar in design and cohorts). =)

</comment></comment><comment><USER4> Deirdre McCloskey (an economist) has an entire book devoted to this[1]. Her article here: [http://www.deirdremccloskey.com/docs/jsm.pdf](http://www.deirdremccloskey.com/docs/jsm.pdf) covers the main argument in the book. One important point she makes is that not all fields misuse p-values and statistical significance. In physics significance is almost always used appropriately, while in social sciences (including economics) statistical significance is often conflated with actual significance.

[1]: [http://www.amazon.com/The-Cult-Statistical-Significance- Econ...](http://www.amazon.com/The-Cult-Statistical-Significance- Economics/dp/0472050079)

<comment><USER5> That difference is likely because reality won't believe you if you state the significance wrong, but people will.

</comment></comment><comment><USER6> The single paragraph in the postscript of this paper (part 6) is actually really important. It's very common for people who are using statistical testing in applied settings to entirely forget about type II error (and correspondingly, the power of the test), and so when they see a p-value that isn't significant at a certain level (say 5%), then they just assume that the null hypothesis is true.

Of course, this is not correct, and all we can really say is that the test did not reject the null, given the size (type I error rate) and power (type II error rate) of the test. It's entirely possible that the null should be rejected, but the test is just not very good (i.e. it might have the correct size, but very poor power).

So given some complex and eccentric real-world data, how can we figure out what the power of a given test might be in practice? If you have some idea of what the data generating process might look like then one option is to do some simulations. This enables you to see what the size and power properties of your test are by empirically measuring the type I and type II error rates.

</comment><comment><USER7> People often have trouble applying statistical methods correctly, and perhaps often can manipulate statistics to tell a given story. And indeed, P=0.03 on its own is meaningless without an understanding of how a study is set up and a plausible hypothesis.

But inferential statistics is grounded in sound theory, and used correctly and with appropriate assumptions is a powerful tool to reason about data. Without it, how are you supposed to reason about (for example) study results? Appeal to intuition?

It seems to me that significance tests are not all-powerful, or foolproof, but are still a very valuable tool.

<comment><USER8> > Without [inferential statistics], how are you supposed to reason about (for > example) study results? Appeal to intuition?

The alternative, which the author of the linked article mentions, but doesn't really emphasize, is to report a best estimate of whatever effect you are trying to measure, along with some measure of uncertainty in that estimate.

For example, instead of "we failed to find significant evidence that right turn on red increases the expected number of fatalities," you say "our best estimate of the expected increase in fatalities due to right turn on red is 200 +/\- 210."

This approach puts the most relevant information front and center, and it seems to me, encourages better intuitive reasoning. It's what engineers and most of the hard sciences do most of the time.

You do also need to say something about the meaning of your uncertainty estimate (e.g. it's 1 sigma, or 2 sigma, or 95%), or alternatively, there needs to be an understood convention for your field.

<comment><USER7> Is the method you described not another form of inferential statistics? (Definitely not hypothesis testing however).

It seems that this is a combination of several techniques:

1\. First, we either explicitly or implicity choose a model to relate deaths and RTOR laws (perhaps a linear relationship, i.e. [deaths w/ RTOR] = a*[deaths w/o RTOR]).

2\. Then we perform point estimation to estimate the parameter "a".

3\. Then we compute a confidence interval.

With respect to the RTOR example in the paper, it seems to me that it WOULD be incorrect to reject the null hypothesis that the change in crash numbers arises from random chance for ANY INDIVIDUAL STUDY. In this case it seems that you must figure out a way to transfer information between studies to establish this idea of "statistical significance." Perhaps a survey of studies or usage of bayesian techniques would have resolved the difficulty.

</comment></comment></comment><comment><USER9> Related to this might be the decision of a psychology journal to remove p-values from published articles: [http://www.nature.com/news/psychology- journal-bans-p-values-...](http://www.nature.com/news/psychology-journal-bans- p-values-1.17001)

Even though p-hacking is bad, I'm not sure whether banning p-values is good or bad. The real question is what will be used to replace the p-values.</comment>


How $5 can wipe out your traffic - <AUTHOR> http://www.reachdigital.in/destroy-competition-5-covert-fiverr-services-taking-small-businesses/

<comment><USER2> i have a sleazy friend that hires people from overseas on fiver to drive him to the top of local search results and drive the competition to the bottom.

It's easy and it fits in with his personality! He truly makes $$$$$ sitting at home. He should make a Pay for Seminar</comment>


Samsung Launches First Tizen Phone And It Is A Beast - <AUTHOR> http://www.forbes.com/sites/gordonkelly/2014/06/02/samsung-launches-first-tizen-phone-and-it-is-a-beast/ <comment><USER2> 1\. Samsung is launching the phone in Russia and not a major market like China, US, South Korea or even Europe.

2\. The processor isn't an Exynos, but a Snapdragon. That means that they don't know what volumes to expect and are hedging their bets.

3\. Tizen itself is interesting but until a few months back support for ARM was very much second class.</comment>


Show HN: Paralign – A Smart Journal That Finds Patterns Within Your Thoughts - <AUTHOR> http://paralign.me/ <comment><USER2> Your landing page have ZERO information about the app. I don't count the "app store" buttons. And the diary tab just looked like clickbait articles - so I closed that instantly.

The app itself, and the content in the app store (text+screenshots), actually looks kinda neat. Just use that.

I guess it just looked like "tinder for thoughts" now when I look back at it, is it?

And seriously, 18 pages of "X ways to do Y" and "Why X is blah (and how to X it!)". It really feels like spam.

</comment><comment><USER3> I can't download it on Android.

<comment><USER4> What was the problem?</comment></comment>


Virtual Goods Start Bringing Real Paydays - <AUTHOR> http://www.nytimes.com/2009/11/07/technology/internet/07virtual.html

<comment><USER2> Virtual goods to me feel like a scam and I doubt that will ever change.

I feel the same way about ringtones, wallpapers, telephone applications that have no utility and so on.

I'm probably old fashioned, but I think if someone pays they really should get something in return for it.

Not the ability to 'dress up their avatar' or something silly like that.

The most bizarre case ever to be brought to court I think was one in which someone stole someone elses virtual goods.

<comment><USER3> A lot of people do feel that they are getting something in return. That $2.99 ringtone does something for some people.

<comment><USER2> Yes, I realize that, it just doesn't 'work' for me.

I would contrast that with my grandparents (long since deceased) who would consider paying for software just as silly because I'm not getting anything 'tangible' in return.

It is probably just an age thing :)

<comment><USER4> Probably, with virtual goods you're basically paying for someone's time (and perhaps skill at that aspect of the game). Not very different from most monetary exchanges in real life.

</comment></comment></comment></comment><comment><USER5> I think part of the stigma of buying online goods stem from the 'fantasy' games where people think they originated from. That had more to do with generalizations about fantasy gamers more than any real concrete reasons. A trade is fair as long as both parties feel they gained from it and has nothing to do with whether there is anything physical or tangible involved or the marginal cost.

</comment><comment><USER6> This is kind of funny actually. They gave a sentence midway down indirectly referencing the TC drama, and the rest is the Times giving the industry the same praise its used to. Don't call it a recovery!</comment>


Bad copyright rules killed Hadfield's Space Oddity - <AUTHOR> http://www.ottawacitizen.com/entertainment/copyright+rules+killed+Hadfield+Space+Oddity/9842445/story.html

<comment><USER2> Although I'll miss Hadfield's rendition, I'm a lot more worried about zombie copyright than copyright being exercised by living artists on work they created. (Create, in this case, when the artists was significantly less well- off than Chris Hadfield.)

Get angry about Sherlock Holmes and Donald Duck first.</comment>


Warren Buffet on Bitcoin (p.24) - d-k http://fm.cnbc.com/applications/cnbc.com/resources/editorialfiles/2014/03/03/2014-03-03%20Ask%20WarrenBuffett%20complete%20transcript.pdf

<comment><AUTHOR> It's one or two sentences.

BECKY: _You know, I 've been meaning to ask you your opinion about bitcoin. What do you think of it?_

BUFFETT: _It 's not a currency. I mean, you know, it does not meet the test of a currency. I wouldn't be surprised if it's not around in ten or 20 years._</comment>


Slowloris.pl HTTP DoS - Linux iptables workaround (sort of) - <AUTHOR> http://pastebin.com/d1fb3386b

<comment><AUTHOR> rules provided by 'l3u' (not me)

Of course this does not prevent dDoS and is not a solution of the problem. but it seems to stop lonely script kids for some minutes while migrating to immune httpds/proxies.</comment>


Mind the Gap (2004) - <AUTHOR> http://www.paulgraham.com/gap.html <comment><USER3> The whole argument centers around the notion that people are, compensated for wealth creation. But it seems like some of the most highly compensated professions (short sellers, personal injury attorneys, the people who created and promoted default mortgage swaps, etc.) have absolutely nothing to do with the generation of wealth. In the case of short sellers, they actually profit off of the destruction of wealth. Furthermore, among those of us that create wealth, we are not 'fairly' compensated, not in the sense that he attacks, but in the sense that those of us who create the most wealth are very often not compensated the most. Consider engineers that invent new technologies, but the patents are owned by the companies. Consider the company that has the superior product for the superior price, but cannot compete with the advertising of the already existing gigantic corporation. Consider the gigantic corporation that lobbies to change regulations to their own benefit at the price of competition. If the market simply rewarded wealth creation, Graham would have a much stronger arguments, but the list of behaviors it rewards is an awful lot longer, and contains an awful lot more unsavory actions, than he seems to acknowledge or consider.

<comment><USER4> Short sellers acts as signalers to the market that there is probably danger in the stock.

They're not destructive as so much telling informations via price mechanism.

<comment><USER3> In theory, that's what they do. In practice they are credited with utterly destroying several companies that might have been able to survive otherwise. No one knows for sure if they would have made it, but they had absolutely no chance to survive with short sellers in the mix. The stock market often encourages a herd mentality which isn't necessarily based on reality (e.g. the dot com bubble of the mid-90's). Short sellers have a way of sending that herd mentality into overdrive.

<comment><USER5> If your company is on solid footing, it shouldn't matter if your stock price is zero (that'd be great, actually; you could buy back your whole company). Your argument is functionally equivalent to saying that any number of unfunded and dead startups _could_ have made it if only they'd gotten a $5M Series A round. They didn't because investors didn't think it was a good bet. Public companies that need cash infusions to survive face the same situation -- they are at the mercy of their _prospective_ investors. There is nothing wrong with this.

<comment><USER6> Many of your best employees will quickly leave the company if its stock price falls to zero.

</comment></comment></comment></comment></comment><comment><USER7> There are a lot of flaws with Paul's thinking here. First, most money is handed down, and then there's the lucky. Those bright sparks who earned their fortune may be on the covers of magazines, but they represent a paltry portion (1%?) of the total.

Second, the wealthy are very good at keep their wealth for their families, those who are like them, those who went to the same school, etc.

The worse the disparity in income, the worse the economic mobility and the worse society is as a whole. It creates huge problems that are well documented and easy to see if you simply travel.

I understand Paul's point: driving technology creates wealth, and so it should be rewarded. Great. But if you peel off the fads and leave those technologies that really create wealth, you'll find Europe contributes just as well. In Europe, however, you don't trip over the homeless and crazy as you do in San Francisco. I'm an American entrepreneur; I choose to live in Europe.

<comment><USER8> I think you may be responding to what you think I said, rather than what I actually said.

Can you give an example of a sentence or passage in the original that you feel is false?

<comment><USER5> Unrelated to the criticisms above...

Having not reread this essay for a few years, I'd forgotten what a wonderful piece this was. Your exploration of the common fallacies that lead people astray is particularly clearheaded and well supported.

However, you might want to reconsider the way you lumped, in passing, speculators together with thieves -- implying that neither create value. Thieves clearly destroy value, whereas speculators add information to markets. They create value in a very abstract way that is difficult to recognize, but is nonetheless there. A speculator that accurately foresees a shortage of grain in 6 months and therefore buys grain futures provides a service to society (by raising the future price of grain over the spot price, causing people to warehouse grain, which will take grain off the spot market, pushing up the spot price, moderating present demand for grain, and preventing an acute shortage).

<comment><USER9> Technically, thieves redistribute value, they don't destroy it. Speculators, on the other hand, _can_ destroy capital by making bad investments. They can also just get lucky by investing in a rising economy.(thereby not contributing any information of value)

<comment><USER5> In the real world, thieves destroy wealth in the process of redistributing. They break windows, they cause people to hire security guards, and their actions make people feel vulnerable and insecure -- all wealth-destroying. The redistribution isn't zero-cost to the thief either. The gas used by the thief to get to his target is destroyed wealth.

Thieves also redistribute goods in such ways as to lower their value. Let's say a biotech company pays $20k for a microscope. A thief steals the microscope and pawns it to someone for $20 who just thinks the microscope looks cool. Wealth has been destroyed through the misallocation of resources caused by the improper redistribution.

As for speculators destroying wealth by making bad investments: yes, they can, but they lose money when they do so, which is a self-correcting process. The CEO of a company can also destroy wealth by misallocating resources.

As for speculators getting lucky: yes, they can do that as well, but random chance tends not to be sustainable (a random strategy will lose on average after transaction fees), causing a self-correction that tends towards mitigating noise. Anyway, if they are lucky and right, they've still added valuable correct information, just as a company that randomly happens onto a successful product still created value.

As for speculators getting lucky by investing in a rising market: if the market rise is supported by fundamentals, then the speculators are still adding value by allocating resources towards worthwhile enterprises. What's the difference at that point between speculators and investors? If the rising market isn't supported by fundamental wealth creation (e.g. the central bank is printing money), there will be a correction, and the (long) speculators will lose money.

Don't get too tied up on the word _information_. Market processes allocate scarce resources in such a way as to maximize total wealth and wealth creation (as best as can be done with the information available). Sometimes correct speculation aids that process indirectly by sending price signals. Other times correct speculation adds value by directly allocating resources where they can best be used (investing money in a startup, or in a pool of companies, or in bonds, for example).

</comment></comment></comment></comment></comment><comment><USER10> I agree with the _basic_ thesis - you can earn lots of money, and deserve it.

But the essay as a whole suffers from assumptions that the market is pretty efficient. It's really hard to believe that the market as a whole is anywhere near efficient, particularly the CEO market. Was the CEO of Bear Stearns or Lehman Brothers worth the salary they got?

(I think it's easy to point at a lot of likely reasons for distortions in the upper tiers of the salary scale, but I think that distracts from the point - <USER2> good number of CEO salaries were empirically demonstrated to be poor investments.)

<comment><USER5> A good part of market efficiency is the simple mechanism it provides to punish those who make wealth-destroying choices. Markets can't guarantee perfect decision-making (what can?), but _free_ markets can provide that people who make poor choices suffer losses.

<comment><USER10> I don't understand your comment. If you mean a Platonic Free Market, maybe. In the real world, the CEOs weren't penalized for their wealth-destroying choices, and the boards weren't penalized. Sure, they lost their jobs, but perhaps they never should have had those jobs to begin with. They got to keep the money that they didn't earn. And that market is about as close to a free market as you'll see in the real world.

<comment><USER5> The investors lost money. They put their trust in bad (or simply imperfect or misguided) CEOs and careless boards. In the future, perhaps they will be more careful in their selection of managers. If not, they will continue to lose money. That's part of the market process.

The CEOs got to keep their money because the _investors_ made poor choices; the investors could have negotiated a clawback in the compensation packages, for example. But in some sense, you might even say that the CEOs gave the investors exactly what they wanted. If the investors had wanted a more conservative corporate strategy, they could have always pulled their money out and invested in Berkshire Hathaway, or they could have uprooted management. Management set out on a strategy that didn't turn out well, but they weren't hiding anything from their investors.

It gets a little blurry at high levels, but remember that at the end of the day, the CEO is just an employee. The owners are ultimately responsible for the company.

</comment></comment></comment></comment><comment><USER11> I agree with only some of the points in this essay. I think that the assumption of efficiency is overstretched. I think that the demonstration that wealth is created is overstretched.

The reaction between these imperfections (people who have become very rich by participating in imperfect markets) creates a hole. It is this hole that people react to. Even if markets were perfect, wealth creation is not often dependant to factor that people can control. A factory worker in Japan is more productive then one in Burma for reasons completely outside his sphere of influence. Similarly a 8th century peasant's wealth was generated by him from the land. But, the great variations in wealth of peasants probably had more to do with how much & how good the land was then how hard or how skilfully they worked. Wealth generation does not mean a meritocracy.

On the other hand, wealth _is_ something that is created. That _is_ something not enough people grasp. This essay actually got me thinking at the very start in the comment about children.

 _Likewise, it doesn't occur to most kids that wealth is something that has to be generated. It seems to be something that flows from parents._

That is something that many parents would react to. "Children need to be taught the value of money. They need to learn that money must be earned." They then set up chores or encourage kids to work and _earn_ money. This is to set them straight. That is a fundamental mistake. It leaves out wealth generation. It encourage them to think that they are _entitled_ to their _share_ if...

</comment><comment><USER12> "It's absolute poverty you want to avoid, not relative poverty"

seems empirically not to be true; see all the medical research about the health hazards of relative poverty, eg: <http://www.yesmagazine.org/issues/health-care-for-all/1509>

not to mention Veblen.

It would be better and simpler if people only cared about absolute wealth, but to quote some essay I read recently, "of course people want the wrong things. It seems odd to be surprised by that."

</comment><comment><AUTHOR> I know this is quite old, but I would very much like to see an HN discussion about its contents.

<comment><USER13> Try raising some questions.

</comment></comment><comment><USER14> _A 747 pilot doesn't make 40 times as much as a checkout clerk because he is a warlord who somehow holds her in thrall. His skills are simply much more valuable._

The amazing thing is the difference is at most an order of magnitude less than that.</comment>


New federal rules blamed in disappearance of Kindle erotica titles - <AUTHOR> https://techcrunch.com/2018/03/29/new-federal-rules-blamed-in-disappearance-of-kindle-erotica-titles/ <comment><USER2> We certainly wouldn't want to permit the trafficking of underage words! Seriously, this is an ugly, puritanical step back for a country that makes quite the show of free speech. If nothing else, censoring books should be a great big red flag for anyone wondering about the impact of FOSTA. Unless the book is a kidnapping manual, this is worrisome.</comment>


Show HN: RemoteML – Job Directory for Remote Machine Learning Positions - <AUTHOR> https://remoteml.com/ <comment><USER2> With so many remote job boards, some of them could do more to be useful to target customers (people looking for jobs, not companies posting them) by not simply being "remote job board for X, Y or Z", rather focus on the facets of what makes working remote actually work.

Time zones, for example. A lot of remote jobs are with companies that only consider remote work to be work done from your home and only if in the same city as their office, and during the same hours. While this technically shouldn't matter, it greatly limits the success and talent pool available when you don't consider all the available time zones and cities which are great for remote workers.

Additionally, I've found working remote for companies that don't have a remote first culture to feel more like grunt in the corner that is ignored than part of a team and as an experienced professional with values and insights to contribute to the team. While that might seem like a great deal on paper — lower on costs — it works out terribly in the long run with ROI.

Working with a completely distributed team (no HQ) on the other hand is the best job I've had in 10 years, both in terms of culture, team dynamics, subject matter, salary, location, work environment, etc etc.

<comment><AUTHOR> I am European and something that bothers me a lot are companies that are hiring remotely, but then ask me to relocate or are US-only. That's why I added a category on every RemoteML job post: Anywhere, Remote US and Remote near HQ

<comment><USER3> Unfortunately that's a reality. This happens to me a lot. Remote work JUST for US citizens. The irony is that most of those companies pay attention to not discriminate people (minorities, sex orientation, disabilities and other things) but they discriminate those that don't have USA passport :-(

</comment></comment></comment><comment><USER4> This should include compensation ranges.

<comment><AUTHOR> Good point. Will add in the future!

</comment></comment><comment><USER5> I had made a job board for machine learning as well. [https://mljobslist.com/](https://mljobslist.com/)

Posting a job is free also, unless you want it featured.

I'm glad to see more competition.

<comment><USER6> Your site on mobile has a few issues:

1) the typing thing you're doing continuously shifts the page when I'm scrolling through, regardless how far past I am from it. Really annoying.

2) The fonts don't seem to scale well to smaller screens (weird word wrapping)

I'm on an iPhone 5s.

</comment></comment><comment><USER7> i resent the fact that machine learning has taken over the ML acronym. :(

<comment><USER8> What other meaning did it displace?

<comment><USER9> Likely they're referring to ML, the programming language [https://en.wikipedia.org/wiki/ML_%28programming_language%29](https://en.wikipedia.org/wiki/ML_%28programming_language%29)

<comment><USER10> I'm curious, did people ever actually refer to those languages as ML? I've taken classes in Standard ML ("SML") and OCaml and I don't think we ever called them just "ML" besides acknowledging in the intro that ML the official family of languages that those dialects fall under.

<comment><USER11> I generally view ML as a family of languages, generally consisting of algebraic data types, pattern matching, first class functions, currying, idiomatically functional.. Members are Standard ML, Ocaml, F#, Elm, Haskell, and to a lesser degree Rust.

</comment></comment></comment></comment></comment><comment><USER12> Thank you for posting this. Not many ML jobs around other than Jane Street and Facebook.

</comment><comment><USER13> This looks like a cash-grab

<comment><USER14> Everything starts small. Give it a chance.

<comment><AUTHOR> Thanks :)</comment></comment></comment>


Surviving In The Era Of Free - <AUTHOR> http://fitfriendapp.tumblr.com/post/63374043209/surviving-in-the-era-of-free

<comment><AUTHOR> It's our company blog, but I didn't hold back in calling out the problems</comment>


The HTML 5 DTD project - <AUTHOR> http://www.html5dtd.org/faq/

<comment><USER2> >I use Emacs+PSGML to write HTML. I can't without a DTD.

This seems like a failing of Emacs+PSGML rather than HTML5 lack of DTD.

Or rather why are you using an SGML tool to write a language not based on SGML? (from wikipedia "The HTML5 syntax is no longer based on SGML")

<comment><AUTHOR> AFAIK the PSGML mode is also the favourite one to use for XML editing.

<comment><USER3> nah, your best bet's definitely nXML - <http://www.thaiopensource.com/nxml- mode/>

<comment><USER4> ...using <http://www.thaiopensource.com/relaxng/trang.html> for DTD -> RelaxNG conversion, I agree.</comment></comment></comment></comment>


Freelance Freedom #41 - <AUTHOR> http://freelanceswitch.com/freelance-freedom/freelance-freedom-41/

<comment><USER2> From the comments: "Oh I'm thinking about getting into web design. There's lots of money in it and I have this program called coverpage or something which makes it really simple, I wont need to do anything."

What's worrying is that he could become professional. The ability to read HTML is becoming less significant.</comment>


Secret debugger discovered in AMD CPUs - <AUTHOR> http://www.theregister.co.uk/2010/11/15/amd_secret_debugger/ <comment><USER2> There are comments on the previous submissions of this story:

<http://news.ycombinator.com/item?id=1897522>

<http://news.ycombinator.com/item?id=1897583>

</comment><comment><USER3> Wonder if there is any significance to 9C5A203A.

<comment><USER4> It's a secret value that puts AMD processors into an undocumented debug mode.

[http://www.techeye.net/security/hackable-debug-mode-found- in...](http://www.techeye.net/security/hackable-debug-mode-found-in-amd-cpus)</comment></comment>


Self language still alive - new release for Linux, Mac - <AUTHOR> http://blog.selflanguage.org/2010/07/16/self-4-4-released/

<comment><USER2> This is very very very cool, If i recall my pl research lore correctly, self even ~ 15 years ago had runtime/compiler tech that was at least par with 10 year old java.

Also, its an objects all the way down language, so its quite pretty! (in terms of uniformity of semantics/syntax!)

[added edit] I believe that the documents to substantiate this can be found at <http://selflanguage.org/documentation/published/> and I suspect that part of the reason for self's comparative advantage is that by having the core language be so uniform, every control/date structure and abstraction immediately benefits from any improvement in the runtime or optimization techniques (as is the case with scheme and to a moderate extent haskell as well).

</comment><comment><USER3> Wow, I didn't think Self was still alive.

Ole Agesen's PHD (about the Self type inference) was the best reference I used for my Master's thesis.

</comment><comment><USER4> Didn't some of the Self research get used in the JVM?

<comment><USER5> It did indeed. I can't find a great link for it though.

Sun put a good amount of work into the self vm which along with strongtalk, got rolled into the java vm.

<comment><USER6> David Unger gave a great talk recently on this: <http://www.youtube.com/watch?v=3ka4KY7TMTU> (recorded at Stanford, but it's a reprise of his acceptance speech on receiving the Dahl-Nygaard award from memory)

He has a role-call at the end of what the people involved in the self project went on to do afterwards, and it's staggering: some of the engineers of the original Google architecture, what became Hotspot as you say, Lars Bak (of Chrome V8) as someone else has pointed out... just an amazing list.</comment></comment></comment>


Need a developer for an iPhone app project - <AUTHOR>

A friend of mine is interested in hiring an iPhone app developer or team to produce a niche application, so I figured I'd put it out to the HN community.  He's looking for someone who has already published to the app store, knows the ropes, etc.  Any interest? <comment><USER2> I am currently a college student majoring in computer science, and I have written very simple iPhone apps. I am looking to learn/develop more intensive apps, and if I could be part of a development team would be great experience. I probably wouldn't be too much help because of my level of skill, but I could do the "bitch" work of the project. I am just looking for experience. Tell me if you are interested. Thank you.

<comment><AUTHOR> Thanks for your interest, but he indicated he's looking for an established developer or agency.</comment></comment>