What's wrong with Object-Oriented Programming and Functional Programming - <AUTHOR> https://yinwang0.wordpress.com/2013/11/09/oop-fp/ <comment><USER3> This is a low quality article from someone who, given his qualifications, should know better.

The criticisms of functional programming languages range from trivially true (you can't be purely functional and have side effects) to incorrect (it is certainly not difficult to create a circular data structure in Haskell - it's easy given laziness).

The criticism of OOP is verging on nonsensical. Of course functions can be objects. A general definition of an object (following Cook somewhat) is something that satisfies an interface along with some form of dynamic dispatch. There is no reason why a function can't fall under that definition. The distinction between "fundamental" and "derived" isn't a technical argument, it's pseudo-philosophical junk. As several others have pointed out, the fact that Java doesn't have proper first-class functions is also utterly irrelevant. In fact, it is possible to program in a very pure OOP manner in any language with proper closures.

If the author is representative of the quality of researchers working on programming languages, it's no wonder the field seems stagnant.

<comment><USER4> > This is a low quality article from someone who, given his qualifications, > should know better.

It really depends which audience this article is targetting (Do you believe that S. Peyton Jones speaks in monads to his mother?). If this article was written in response of a talk between undergraduates in a TA session, it is perfectly acceptable, and even provides links to advanced material for the curious.

> A general definition of an object (following Cook somewhat) is something > that satisfies an interface along with some form of dynamic dispatch. There > is no reason why a function can't fall under that definition.

Yes, but why have that definition, if you already have functions as builtin types? Conversely, if there's a need for functions as builtin types, why force programmers in using that clunky alternative? That's pretty much the point made by the article: don't corner yourself in one paradigm when others might be better at some tasks.

> As several others have pointed out, the fact that Java doesn't have proper > first-class functions is also utterly irrelevant. In fact, it is possible to > program in a very pure OOP manner in any language with proper closures.

Careful, the wording is a bit lacking here imho: you join two different ideas and make it seem like the second one validates the first, while it's not the case.

> If the author is representative of the quality of researchers working on > programming languages, it's no wonder the field seems stagnant.

That shows you probably don't follow much the field. Anyway, this article doesn't fit your standard (see first point), ergo this man's whole work doesn't, ergo the whole field doesn't? That twice too much stretching from someone who isn't very careful in his own argumentation.

<comment><USER3> > It really depends which audience this article is targetting...

I disagree. Low quality articles like this are part of the reason why many undergrads are full of strongly held opinions about things they don't know much about. They think you can dismiss a huge paradigm with a glib one-liner: "functions are not objects".

> Yes, but why have that definition, if you already have functions as builtin > types?

Because we can't talk about objects without having a definition of what they are? I have no idea what point you're trying to make here. I'm just trying to be clear about my terminology.

> Careful, the wording is a bit lacking here imho: you join two different > ideas and make it seem like the second one validates the first, while it's > not the case.

Think about it a little bit and you'll see why they are actually very related. His statement about Java is meant to imply that proper higher order functions and OOP are in opposition in some way (at least I assume that's his point, it's still not clear to me because that is obviously incorrect). I am saying that proper higher order functions alone are enough for a very pure form of OOP, so there is clearly no opposition.

> That shows you probably don't follow much the field. Anyway, this article > doesn't fit your standard (see first point), ergo this man's whole work > doesn't, ergo the whole field doesn't? That twice too much stretching from > someone who isn't very careful in his own argumentation.

I'm going to ignore the digs at me and elaborate on what I meant. The author wrote an article about programming languages that was full of elementary errors, both in logic and in technical details. If he can't make a simple argument correctly, how am I supposed to have faith that his research isn't similarly full of errors? It's easy to disguise sloppy thinking in technical writing.

<comment><USER4> > I disagree. Low quality articles like this are part of the reason why many > undergrads are full of strongly held opinions about things they don't know > much about.

I doesn't happen with undergrads only (but that doesn't make the whole profession guilty of it all the time).

> They think you can dismiss a huge paradigm with a glib one-liner: "functions > are not objects".

I don't think the article dismisses any paradigm whatsoever. It dismisses the entrenchment in one paradigm at the expense of any other. That's the main point. The explanation given is perhaps a little bit careless, I can concede it.

> Think about it a little bit and you'll see why they are actually very > related.

Relation does not imply causation, which I perceived in your wording, but I might have been mistaken. Was I?

> His statement about Java is meant to imply that proper higher order > functions and OOP are in opposition in some way

I don't think he meant that, but rather that the way Java never included functions as "primitive types" was a mistake because of that need of OO purity. The Runnable interface (or any interface containing a single method) is an example of that problem (there are other reasons which may support the existence of that interface though).

> I am saying that proper higher order functions alone are enough for a very > pure form of OOP, so there is clearly no opposition.

That's debatable. I totally agree with you on the idea that FP let you implement OO. Likewise, OO let you implement closures easily (there's a duality there obviously, as in algebra vs coalgebra). However, I think that OOP (or FP) as a full fledged paradigm included in any language - and not just a library built on top of closures (or closures on top of objects) - makes a lot of sense: it let the language incorporate syntactic sugar for all the specific constructs related to OO, and it also enable the compiler to perform better code analysis (though I suspect that it should be possible with a library based implementation, but that would imply either the compiler to know about it, or it having a very flexible - plugin like - mechanism to include enhancements as libraries as well). I don't think that the latest evolution in Java to include FP is a coincidence. Many languages have already been mixing these paradigms with good success.

> I'm going to ignore the digs at me [...]

Good. Let's get that out of the way. I'm glad we're having a saner discussion.

> If he can't make a simple argument correctly, how am I supposed to have > faith that his research isn't similarly full of errors?

I understand your point better now. Initially, I was very afraid you'd be having the very same issue.

</comment></comment></comment></comment><comment><USER5> This looks like an attack to functional programming mainly. And if you follow Haskell closely I think that the guys building it are well aware that the world is actually full of side effects. But the thing is that if they push the "pure" ideology to its limits they will uncover a number of useful things along the way. And that is the whole reason to stick to it. Maybe you don't find the usefulness of monads, but that doesn't mean that there is no value of composing part of you programs in this way. Otherwise you are stuck to the same old ways of doing things.

So going with pure has its benefits for all of us, but this does not mean that we should stick with something just because. Unfortunately the answer to most of the questions in programming/software development is: it depends.

<comment><USER6> > But the thing is that if they push the "pure" ideology to its limits they > will uncover a number of useful things along the way.

For example new elegant approaches to parallelism/concurrency that would be very difficult in an impure language.

<comment><USER7> Indeed. For instance, something like

[http://hackage.haskell.org/package/parallel-184.108.40.206/docs/Con...](http://hackage.haskell.org/package/parallel-126.96.36.199/docs/Control- Parallel-Strategies.html)

Would be very difficult to implement in a language that is not referentially transparent and lazy.

</comment></comment></comment><comment><USER8> From a mathematical/theoretical point of view, this is an interesting article, but I think it misses the larger point of programming language paradigms. Yes, the PL researchers have their reasons for creating languages that are object oriented, functional, procedural, imperative, declarative, logical, etc. but those are rarely, if ever, the reason that _programmers_ choose these languages.

Ultimately, the _main_ purpose of a programming language is to convey intent to _other programmers_. If calling an object a function just because it has a `__call__` method makes it easier to convey intent, then it doesn't really matter that the object is not _really_ a function. Personally, I'd be interested in any research into the ability to convey intent using these different paradigms.

<comment><USER9> In the case of natural language, I would agree with a statement similarly worded to yours above, "The main purpose of a ... language is to convey intent to other(s)". (Sorry for butchering, I promise I'm getting to a point =) )

I'm not sure I'd agree with respect to programming languages, however. These are artificial languages designed to convey a limited set of ideas, with varying degrees of abstractions over various concepts in electrical engineering and mathematics. Given this, the purpose of a programming language isn't just to communicate with others, it's also to shape how you approach problems.

Anecdotally, learning the strict functional programming paradigm is what allowed me to pass an extremely difficult technical interview recently. The emphasis on dataflow and "do what I mean, not what I say" truly changed how I thought and approached problems. Previously, my years of experience in imperative languages lead me down a road that was a bit too missing-the- forest-for-the-trees when it came time to solve a difficult, interview-style algorithmic question.

</comment></comment><comment><USER10> The author should mention Smalltalk to talk about _pure OOP_. Not mentioning Smalltalk means the author didn't really _researched_ the _pure OOP_. The author just tasted some OO style languages. I really don't understand how can the author argue about drawbacks of pure OOP with Python (which is more like procedural) or Scalar (which is more like functional).

Also in the middle of text, the author frequently mention _most OO langauges_ which is nothing related to topic - extreme, pure OO language.

Mention about Haskell is pretty agreeable, but that drawback is already published on Haskell website, and that's why Haskell support impure operations.

I don't understand how can a Ph.D person can write this poor text.

</comment><comment><USER11> This is a gross mischaracterization of functional programming and basically attacks a straw man--one that's lamentably common when talking about functional programming.

I'm going to repost a comment I wrote on the blog. It's long and really needs editing, but I hope it gets my thoughts across. I think the part about OOP is also misguided, but it's so obviously tacked on to a rant about functional programming that I just ignored it.

Haskell's "purity" is not about getting rid of side-effects but about _controlling_ side-effects. It's making side-effects _first-class citizens_ : now you can write code that talks about having or not having them!

You can still have side-effects however you want, you just have to be explicit about it. To some extent, the fact that this uses monads is incidental: all that's important is that there is _some_ IO type, _some_ ST type and so on–the fact that they all form monads is almost an implementation detail. That's why some of the most exciting Haskell features–STM, the IO manager and so on–are all about effects. Clearly, Haskell more than acknowledges effects, so the entire diatribe about ignoring the existence of side-effects is attacking a straw man.

Besides, you can't simply replace a first-class system for managing effects with static analysis, without essentially reproducing the same restrictions. How would you do something like Haskell's deterministic parallelism model or reliable STM or the very aggressive loop fusion (and general rewriting) Haskell uses? There's a reason you don't see these things done nearly as well in any other languages: all of these fall apart as soon as you introduce side- effects, so you need some way to help the programmer ensure things like this are only used safely.

And this is exactly how types like IO and ST help make code safer. Sure, _within_ an ST block, you have stateful code that's just as hard to analyze. But you can guarantee that this does not leak outside the block. Similarly, functions can rely on their inputs not doing anything untoward however they're used. This allows you to explicitly state the assumptions about your inputs: how is this a bad thing? In turn, this makes writing code that takes advantage of these properties much easier: you can ask that your inputs do not cause side-effects in a way that's self-documenting and easy to verify. Then you're free to re-evaluate your inputs or call functions however many times you want, as concurrently as you want. At the extreme, this can even be used for security purposes: see Safe Haskell.

Sure you can write pure functions in any language. And you can write side- effecting procedures in Haskell too. But the difference is that Haskell lets you be explicit about whether you want side-effects or not–it's just another part of your interface. And this is how types like IO and ST help make your code easier to think about: any code that is _not_ in a type like IO or ST can only depend on its arguments, making all the dependencies more explicit. (Note, again, how this is all independent of "monads"–it's all about effects, and the types just happen to form monads.) This does not make static analysis too much easier, but that was never the point–the goal is to make the code easier to think about, and knowing that there are no hidden state dependencies certainly does that. A static analyzer can follow data flow easily, but it requires quite a bit of thinking for the programmer to do the same!

The core motivation for managing effects à la Haskell is not "mathematical purity": it's software engineering. We want code that is easier to think about, has better guarantees and is more modular. The goal is to make code less complex by removing hidden dependencies between distant parts of your program (mutable state) and the effect of evaluation on the meaning of your program (side-effects in general). You can refactor and move around most Haskell code without worrying about breaking its surroundings because any dependencies are explicit. You can extract something into a function, consolidate multiple function calls into one or split one into multiple and generally change your code up quite a bit without worry–these actions cannot change the code's correctness because effects are managed for you.

Ultimately, functional programming like Haskell is not just normal programming with side-effects outlawed. Instead, it's a different _basis_ for programming which allows you to manage side-effects explicitly. In this light, papers like "solved problem but with monads" are entirely reasonable: they're about bringing things over to this new basis. And this goes the other way too: there's a reason why you don't see good STM, deterministic parallelism, stream fusion (and rewrite-rule optimizations in general), anything like DPH and anything like Safe Haskell in other languages.

<comment><USER12> The way Haskell manages side effects is inspired, and I don't think anyone can say that Haskell is not a beautiful and coherent language. I only dabbled in Haskell a bit so I may be wrong, but I think that the problem with the way it manages side effects is that it does so through lazy evaluation, and lazy evaluation is hard to wrap your head around.

So I think that if there is one big problem with Haskell, it is this: you say Haskell is about "software engineering". Indeed, the guarantees it provides may assist with software engineering, but those guarantees aren't free. They require programmers to think and program solely within Haskell's lambda calculus and lazy evaluation framework, which is neither the way people think nor the way computers do (the latter is important when doing performance analysis on your code). This constrained framework also takes its toll on software engineering, then. The question is, therefore, when are the guarantees provided by Haskell worth their price? I think there are cases where they certainly are, and cases where they certainly aren't.

(A tangential point: when thinking about software engineering, there are vital issues that have little to do with the choice of the language. For example, a language would have to be truly magical for me to forsake the JVM's vast ecosystem, runtime linking, and runtime profiling and monitoring capabilities – that's why I won't use GHC in my projects, but may certainly give Frege a try)

<comment><USER13> Dabbling really is not enough to show you the problems with your assumptions. You are right that there is a cost, but it is really paid once up-front by each programmer.

I could have written this same comment five months ago, before I started down the long dark tunnel of doom which is to go beyond LYAH and trying to write a real application. I think it was two months before I saw a light at the end of that tunnel - and only recently that I have really begun to feel as productive in Haskell as I previously was in Ruby. At this point, the costs you speak of are paid up and I do not incur them when I write new code. Yes the type system does impose a lot of structure and some boilerplate, but the benefits are profound. Its the sort of statement I did not really fully credit before experiencing myself, but I will say that is profoundly amazing how frequently my code works perfectly once it compiles. This is particularly true when refactoring. I remember sometimes in Ruby despairing to refactor some code because I didn't want to fix all the tests...in Haskell once my tests are compiling they are passing, and the compiler errors are usually very easy to understand and fix (after several months of head-banging frustration).

<comment><USER12> I don't doubt you, but your experience also provides little evidence. Have you done profiling and performance analysis yet? Have you tried working in a large team on a large project?

Different languages have different strengths. Some excel at quick and dirty prototyping or small projects/small teams. Others make a 50+ developer team more manageable. Some have good runtime performance, some have a shorter development time, while others have better runtime monitoring and maintenance tools. No language excels in all of these.

<comment><USER13> Certainly my experience is insufficient. I have only dabbled in profiling and performance analysis - enough to prove it can be done but that it can be time- consuming and that sometimes you may have to give up some elegance/purity in favor of performance. However the performance I get from naive code is so good (so far) that I have not yet actually had to delve into it.

I am dubious of Haskell's prospects in large teams but I was completely dubious of Haskell in general (like you) before I had experience in it. Perhaps after experience with large teams I would be more bullish on this point but I haven't had that experience so far. I am quite optimistic about the size of the problem space that a small, skilled team (say 5 developers) could solve with Haskell.

</comment></comment></comment></comment></comment><comment><USER14>
        Have you noticed how easy it is to implement circular
        data structures or random number generators in C?
        The same is not true for Haskell.

I might be wrong, but, isn't this a circular data structure (or, what they are referring to) [http://www.haskell.org/haskellwiki/Tying_the_Knot](http://www.haskell.org/haskellwiki/Tying_the_Knot) ?

        In a language like Haskell, where Lists are defined
        as Nil | Cons a (List a), creating data structures
        like cyclic or doubly linked lists seems impossible.
        However, this is not the case: laziness allows for
        such definitions, and the procedure of doing so is
        called tying the knot.

<comment><USER15> Yes.

      oneTwo = 1 : 2 : oneTwo

is a circular singly-linked list containing 1 and 2. If you wanted to change the 1 to a 4 though, you would not be able to do so without creating an entire new list. You can use Vector or Array (i.e. fixed-size containers) to make yourself a circular buffer, but the implementation will be very similar to what you would do in C.

<comment><USER16> Wow. That looks hard. I bet you stayed up all night working on that. ;-)

Seriously: sometimes things are hard because you don't know the language all that well. Consider that possibility.

<comment><USER16> Just to be clear: the advice of "consider that possibility" is intended for the author of the article. quchen clearly knows the "easy" way to do this kind of thing with Haskell.

</comment></comment></comment></comment><comment><USER17> The author states the "extreme" case of OOP is "everything is an object" and the extreme case of FP is "purity."

The problem with this analogy is that everything being an object doesn't by you much. But in Haskell, the type system helps you keep track of what's pure and what's not. So having a type system that keeps track of purity buys you something: lots of pure and extremely easy to reason about code. Non- deterministic (unpure) code is the same difficulty to reason about in any language. Isolating it from pure code just reduces the amount of code which is difficult to reason about.

</comment><comment><USER18> It looks like the author prides himself on reinventing ideas. I've read a handful of his other posts, and he's "reinvented" the Y combinator, the proof of the halting problem, and other such things. It appears that, perhaps partially by a perpetual mishap with diction and connotation, the author claims that his reinventions are original ideas, his opinions are fact, or that his insights are somehow deeper or his arguments are better.

I see this happen all the time, with myself and with others, and I think it's a common thing in mathematics (the author is in CS, so he might not get exposed to this as much as I do). I've seen undergrads finally realize that calculus makes sense and explain how much deeper their understanding is now that they've really thought about it, and I smile and nod my head. I've myself touted my own deep understanding like it's not completely trivial to somebody with years of experience.

I think this article shares that sentiment. The author has thought of on his own accord what we all consider a dead and beaten horse, and is shouting his thoughts from his proverbial mountaintop: no paradigm is perfect for every situation.

Best of luck to him for all his thoughts, but he'd better learn when and where to curb his enthusiasm if he wants others to take him seriously. For the record, this doesn't apply to his personal blog. I expect sooner or later he'll have a post talking about how Haskell's pure style is all about giving the sculpter more clay.

</comment><comment><USER19> So does the author deny the existence of any sort of domain where these paradigms would be "right"? Or are they universally "wrong"? Also, he states a view or philosophy: "everything is an object" and then he says "this is wrong because I disagree. functions are not objects". Wow. If you remove the commentary about scala and python, which is irrelevant to his philosophical thesis, then what is his argument? And why is it not a matter of just having a different definition?

</comment><comment><USER20> This article is remarkably _low on arguments_ , despite being so long. Just a few of its gems:

> OOP is wrong because of its definition of an "object", and its attempt of > trying to fit everything into it. When that goes to the extreme, you arrive > at the notion "everything is an object". But this notion is wrong, because: > > There exists things that are not objects. Functions are not objects.

This has two problems:

1\. It's factually wrong. Smalltalk functions are first-class objects.

2\. It fails to explain _why_ that would be wrong (assuming it were, you know, true).

The author does give the (poor) examples of Python and Scala, which -- in his opinion -- incorrectly call a function an object, because only the __call__ and apply are the "function objects" one is trying to define, but they were "kidnapped" and jailed into their wrapping objects. IMO, this is ontologically incorrect. The same can be said of any object's definition: if I have an object called PlaneVector, the "vector object" itself would actually be only its x and y properties, which I have kidnapped and jailed into my object.

The fact that this structure (the object I'm defining in my programming language) is _not the same_ as its counterpart in the world of ideas (i.e. the plane vector in maths) should be fairly obvious, despite using the same generic term (i.e. object) to denote both.

Behold, then, the straw man:

> Most OO languages also lack correct implementations of first-class > functions. An extreme is Java, which doesn't allow functions to be passed as > data at all. You can always wrap functions into objects and call them > "methods", but as I said, that's kidnapping. The lack of first-class > functions is the major reason why there are so many "design patterns" in > Java. Once you have first-class functions, you will need almost none of the > design patterns.

There are a lot of things wrong with Java, of course, which does not mean that they are also issue of object-oriented programming. Inheritance (sorry...) doesn't work both ways: the fact that a Lexus is prohibitively expensive doesn't mean moving vehicles are prohibitively expensive.

I have less of a problem with the author's treatment of functional programming. What he's essentially trying to argue is that:

> Simulating them [side effects] with pure functions is doomed to be > inefficient, complicated and even ugly. Have you noticed how easy it is to > implement circular data structures or random number generators in C? The > same is not true for Haskell.

IMO, this is true, but the isolation of side effects doesn't have to happen only by the ugly means he outlines next (i.e. monads) in _every_ application. A typical CRUD application the web kids like to write can be written so that the only side effects involved are in fact modifications of the database, in which case the side effects are confined to SQL.

I also think there's an ontological error in this argument. Its foundation is that FP tries to "ignore" side effects even though they are real, but the examples the author gives are several layers of abstraction below. C also woefully ignores _some_ of the side effects in the silicon (e.g. if you go low enough, calling a function with no side effects that does not even alter the state of the program will, in fact, alter the state of the underlying silicon, and quite substantially so), and I think it's reasonable to assume that we can't quite move the debate into _which_ of those should be ignored or not.

 _All_ languages abstract the silicon away, and it's not only good that they do, it's what they were built for. I honestly don't miss hardwiring relays.

<comment><USER21> >> _There are a lot of things wrong with Java, of course, which does not mean that they are also issue of object-oriented programming. Inheritance (sorry...) doesn 't work both ways: the fact that a Lexus is prohibitively expensive doesn't mean moving vehicles are prohibitively expensive._

But isn't the main point of the article that OOP just doesn't _always_ fit the problem domain, that _sometimes_ you want to model something in a way where forcing it into objects (nouns and verbs) only adds complexity without benefits?

I don't think the article condemns OOP in any way except when it becomes a religious dogma that everything needs to be an object, as it is in Java. I've written many different types of programs in various languages, and I can only agree that sometimes, OOP simply isn't what you are looking for. Think about streaming data processing for example, or something reactive like a network service. Surely some parts of the outside interface or the 'glue' between the outside interface and the actual number crunching or request processing can be modeled using OOP, but at the core, there's all kinds of processing on blocks of data or asynchronous IO going on that doesn't need objects and methods, and doesn't add to code clarity or stability in anyway (on the contrary even).

The article basically perfectly describes why I very much prefer programming in Python or C++/Objective-C over Java: they allow me to mix and match different programming paradigms for different problems.

<comment><USER22> > I don't think the article condemns OOP in any way except when it becomes a > religious dogma that everything needs to be an object, as it is in Java.

But Java _doesn 't_ make everything an object. The obvious one is that 'primitive types' aren't objects (int, bool, float, etc.), but also Java has hard-wired control structures (for, while, if, try, etc.) which aren't OO (compare to Smalltalk, for example; where "ifTrue" is a method of boolean objects, "each" is a method of collection objects and "times" is a method of number objects). Also its classes and methods aren't objects, like they are in Smalltalk, Python, etc.

I would argue that that Python's first-class classes and first-class functions/methods makes it much more 'religiously OO' than Java.

Just because all code must be in a class, doesn't mean that everything in Java is an object. I don't know why people keep saying that.

<comment><USER23> My favorite in Java are String instances, which are objects, but adding them with + is not a method call, because Strings are also primitives, sort of, hence + is in fact either eliminated (if adding two constant values) or the code gets translated to a concatenation powered by an ad-hoc StringBuilder instance. The JVM doesn't even pretend that a static method was invoked. It simply pukes some bytecode.

For example there is no interface in Java that you can use to add stuff, because from the language's point of view, adding integers is totally different from adding strings which is also totally different from adding BigIntegers, which is totally different from adding BigDecimals. Well, to be pedantic, Strings addition is in fact concatenation, as Strings are in fact Lists of Chars. I know, not fair to put them in the same bucket.

But, but, wait for it - BigDecimal and BigInteger actually do implement a Number class. But apparently Numbers in Java's vision are not even monoids, let alone rings (because duh, you also have multiplication). Let's not even mention that all real numbers have natural ordering. Like seriously, how can one get this so wrong?

Coupled with the explicit typing needed and the lack of type-classes or anything similar, it means that you simply can't write functions that operate on Numbers, as there is no such thing and you can't implement it by yourself.

People that bitch about Java being too OOP, missed a couple of lessons on their way to enlightenment.

</comment></comment></comment></comment><comment><USER24> Reminds me of this paper;

"The Interactive Nature of Computing: Refuting the Strong Church-Turing Thesis" \-- [http://cs.brown.edu/people/pw/strong- cct.pdf](http://cs.brown.edu/people/pw/strong-cct.pdf)

"The theoretical nature of computing is currently based on what we call the mathematical worldview. We discuss this worldview next, contrasting it with the interactive worldview."

<comment><USER25> The paper's author should be slapped by the any CS book contains (Theorem: IP=PSPACE)

</comment></comment><comment><USER26> This is an interesting article.

It is the first critique of functional programming I've read from someone who clearly knows their shit.

I plan to look at miniKanren more when I get the chance.

I done a fair amount of math though likely less than the author but I have a similar impression - the things that are hardest to understand aren't necessarily the best tool for every job, despite their beauty. And beautiful abstraction for its sake can be a dangerous anti-pattern as much as excess hacks and simplicity.

<comment><USER7> _It is the first critique of functional programming I 've read from someone who clearly knows their shit._

The critique is 'Haskell takes FP to an extreme and I show this is true because someone tried to implement miniKanren and needed Oleg to do it'.

That is not really a strong argument.

Also note that he isn't really arguing against functional programming, but _pure functional programming_.

 _the things that are hardest to understand aren 't necessarily the best tool for every job, despite their beauty._

Haskell in itself is a very simple language. Most functor and monad instances are also easy to understand or use. I agree that there is a tendency in the Haskell community to put abstraction on abstraction, especially when the abstraction is new. But in the end, most of the Haskell packages that became widely-used (bytestring, text, vector) are easy to understand and use.

<comment><USER27> > The critique is 'Haskell takes FP to an extreme and I show this is true > because someone tried to implement miniKanren and needed Oleg to do it'.

>That is not really a strong argument.

It's worse than that. The linked paper is about implementing minikanren _as a monad transformer_ , which is a lot trickier than just porting it over, regardless of language. It's probably a lot easier in Haskell than in Scheme though.

Furthermore, if pure FP is useless, then monad transformers are useless too. But then the argument becomes "this useless thing is really tricky to implement in Haskell, therefore Haskell is useless". The only reason you would want Oleg's minikanren to be easy to implement is if you actually want pure FP. So the argument kind of negates itself.

</comment></comment></comment><comment><USER28> I think all this blog post really highlights is that you can get a PhD without understanding OOP or functional programming.

</comment><comment><USER29> Nothing wrong with OO or pure FP. They combine very well in languages like scala. The author complains that "in Scala, functions are just objects with a method named apply" and complains also about "lack of first-class functions" in java. In fact, these languages supports clean modelisation of the algorithms using high level concepts. The target is a microprocessor that understand low-level imperative code with side-effects. If you look only at the first steps of the transformation, it may always look wrong. The distance between the code and the execution may make the program more difficult to analyse but it is a normal price for abstraction. The only thing that is wrong is that the author is looking at high level languages with a focus on low level semantic. The fact that "int" is not really an object in many languages is becoming more and more an implementation detail.

</comment><comment><USER30> This person is pursuing a PhD in Computer Science?

"If you look deep into them, monads make programs complicated and hard to write, and monad transformers are just ugly hacks."

Wow. Just... wow.

<comment><USER31> Monad transformers are ugly, ugly, ugly (though not really hacks, since they are based on sound mathematics.)

</comment></comment><comment><USER32> I think that OP mistranslates "extreme functional programming" as "we never have side effects and compose functions".

Also what exactly is "extreme functional programming"? Only using functional programming paradigms and abstract data types instead of OOP paradigms and objects? Is "extreme functional programming" not taking advantage of do notation, ST monad, etc and only programming in pure functions thereby accomplishing nothing?

I think the author should have defined what he believed to be extreme OOP and extreme FP before going on such a diatribe (on mostly FP and haskell in particular, since others don't separate side effects).

</comment><comment><USER33> Functional programming wouldn't be useful if side-effects didn't exist. So, arguing that functional programming isn't useful because:

> There exists things that are not pure. Side-effects are very real.

Is nonsensical.

</comment><comment><USER34> "The lack of first-class functions is the major reason why there are so many "design patterns" in Java. Once you have first-class functions, you will need almost none of the design patterns."

Now this is a very bold statement. I'm dying to hear more on how you can get rid of design patterns with first-class functions. Does it mean getting rid as in: sharing knowledge is not needed anymore and programming becomes art as we all head to the rapture?

<comment><USER35> FactoryFactoryFactoryClass, most of dependency injection frameworks, anonymous classes, several different one-method interfaces, (such as event handlers/observers), and probably more become unnecessary when you have first- class functions.

<comment><USER36> I am currently experimenting with Spring JavaBased config (As opposed to XML based) It seems to me that a lot of those factories are created to be able add complex behavior in the XML configuration. I almost want to say that it is XML injection what is causing such complexity.

<comment><USER35> No no no, I wasn't trying to say that Factory pattern in itself is useless, or dependency injection frameworks, or similar. These are all useful things, time-tested. However, in a language with first-class functions, all these cease to be "obscure patterns that you need a certificate to think of and design" and simply become "just another day of life". For example, you don't need to create a FactoryFactoryFactory class with appropriate functions and the whole framework around it, you simply write a function that takes the appropriate parameters and returns the appropriate object, and pass it around. Similarly, you don't need a complicated Dependency Injection framework, you just pass parameters to a functions and it gives you what you want. It's that simple. Still, occasionally some advanced IoC functionality can be useful, but much less frequently.

To see this in action, try googling "factory pattern in Python". You will find hardly any results.

</comment></comment></comment></comment><comment><USER37> Sign. Yet another discussion full of trolling pros and cons of FP vs. OO

Guys, listen to Simon Peyton Jones himself: "Haskell is useless". He's discussing stuff with Erik Meijer in this video:

[http://www.youtube.com/watch?v=iSmkqocn0oQ](http://www.youtube.com/watch?v=iSmkqocn0oQ)

<comment><USER38> His comment was of course tongue in cheek. He wouldn't spend 25 years of his life working on it if he thought it was useless.

</comment></comment><comment><USER39> If we accept the author's argument; then what is the "correct" type of language? Hybrid? A functional-OOP-CES-actor-message-passing language?

In all seriousness I do think there is definitely room for something better than what we have today. I remember a quote saying that "compilers are build for computers, not humans" and I'm starting to agree with that more and more. Our minds are primitive and OOP, functional and threading is simply asking too much of them (proof: all software has bugs). So while the author might have called out OOP and functional in particular I think programming languages as a whole are lacking.

</comment><comment><USER40> I was reminded of Anton van Straaten's "koan" on closures vs. objects with venerable master Qc Na [1] ... but I digress. This post is actually a troll post designed to re-ignite fiery discussions about which is the superior PoV - functional or oop - and I'm going to bite.

The only point I'm willing to give is the somewhat sane zen-like advise of "don't fall in love with your models".

Regarding OOP, I recall Alan Kay saying something to the effect of "OOP is not about objects. It's all about messages." which nicely points to the dualism between the two points of view.

        > There exists things that are not objects. Functions are not objects.

Well, objects are any "thing" that you can talk about, toss about in your head. Functions are certainly such "things" and count as "objects" in that sense. If we accept that "monotonic" is an adjective, i.e. an attribute of a noun, then the function described as "monotonic function" is an "object".

        > There exists things that are not pure. Side-effects are very real.

Um, how so? One notion that characterizes side-effects is irreversibility. You cannot unlaunch a rocket, for instance and so it counts as a "side effect" of the code "launch rocket". Despite that, when we look at the basic equations of quantum mechanics, they are all pure unitary! I mean, not only are they perfectly reversible, quantum "information" cannot be destroyed or even copied. So with fundamental physics we have the opposite question - how the hell do we get "side effects" out of this much purity at the core?

        > Also purely functional languages cause a huge cognitive cost.

I call _pure BS_ on this section. "Huge cognitive cost"? For whom? Wouldn't "structured programming" have placed huge cognitive costs to former "goto programmers"? It is more honest to just say "I don't understand monads, so I won't use them."

        > If you look deep into them, monads make programs complicated and hard to write

Again, "complicated" for whom and "hard" for whom? Is there some objective sense in which such declarations can be made? I, for one, have benefited greatly from learning about monads, reading monadic code and recognizing the pattern in existing code.

        > You can write pure functions in any language, but the important thing is, you should be allowed to use side-effects too.

Why? Who's to say you "should" this or "should not" that?

       > Everything starts to do harm when they are pursued to the extreme.

I'd say the exact opposite actually. Both OOP as well as the functional perspective here illuminate the programming world _only_ when taken to the extreme. Until then, folks just keep arguing about what is functional and what is oop and what isn't. Haskell and Smalltalk/Self have done this favour for us by adopting these extreme dual perspectives.

[1] [http://people.csail.mit.edu/gregs/ll1-discuss-archive- html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive- html/msg03277.html)

<comment><USER40> The Alan Kay reference is from his OOPSLA'97 talk [2], where he says that he's "apologized profusely over the last 20 years for introducing the term 'object oriented'" and suggests that the Japanese notion of "Ma" or "the unseen stuff that goes between objects" as what is important.

(edit) [3] is a quote from a communication with Kay in 2003 -

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."

[2] [https://www.youtube.com/watch?v=oKg1hTOQXoY](https://www.youtube.com/watch?v=oKg1hTOQXoY) (around 38minutes)

[3] [http://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...](http://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

</comment></comment><comment><USER41> It seems that the author has deleted the original article and posted a reply to critical comments from Haskell school: [https://yinwang0.wordpress.com/2013/11/09/oop- fp/](https://yinwang0.wordpress.com/2013/11/09/oop-fp/)

And some content of the original article was posted to: [https://yinwang0.wordpress.com/2013/11/16/pure-fp-and- monads...](https://yinwang0.wordpress.com/2013/11/16/pure-fp-and-monads/)

</comment><comment><USER42> Is there a blend between the two? I really like loops...

<comment><USER43> Let go of your loops and learn to map, flatMap, and fold! Once I really figured out how to use those effectively, I've written far few indexed for loops. I tried to explain this philosophy on a recent and unheralded SO answer: [http://stackoverflow.com/questions/19720830/is-it-safe-to- mo...](http://stackoverflow.com/questions/19720830/is-it-safe-to-modify-an- array-while-looping-it/19721042#19721042)

<comment><USER42> That looks sweet but I can't help but wonder: How are those implemented internally? It seems like it would be loops?

<comment><USER43> It depends on the language and library. You can implement them, or any loop for that matter, or any computing construct furthermore, with function application alone. This is what the lambda calculus [1] and combinatory logic [2] are all about.

In actual languages, it depends. In languages without tail-call optimization [3] (i.e. Python and JS), a loop is probably the most efficient way. But with it, it's not particularly important. In a purely functional language, loops indexed by mutable variables aren't on the table, so you have to go the recursive route.

A basic flatmap on a list is pretty easy to define without for loops in JS (although I would definitely recommend just using a library for all sorts of practical concerns):

        function flatMap(list, f) {
            if (list.length) {
                return f(list[0]).concat(flatMap(list.slice(1), f));
            } else {
                return [];
            }
        }

        flatMap([1,2,3], function (x) { return [x, x]; });
        // -> [1, 1, 2, 2, 3, 3]

[1] [http://en.wikipedia.org/wiki/Lambda_calculus](http://en.wikipedia.org/wiki/Lambda_calculus)

[2] [http://en.wikipedia.org/wiki/Combinatory_logic#Combinatory_l...](http://en.wikipedia.org/wiki/Combinatory_logic#Combinatory_logic_in_computing)

[3] [http://en.wikipedia.org/wiki/Tail_call](http://en.wikipedia.org/wiki/Tail_call)

</comment></comment></comment></comment><comment> wes-exp Though poorly articulated, I am with the author that OOP done wrong (e.g., Java) is horrible. It leads to FactoryFactoryFactory and a lot of insanity!

</comment><comment><USER44> Use the tool that is apt for the job. Programming languages and paradigms are tools. Tools are not greater than end products - period.

<comment><USER45> Part of me likes the part where he wrote "Don't fall in love with you model".

Another part of me feels like that's saying "Don't fall in love with your future spouse".

</comment></comment><comment><USER46> I don't know about you, but I find those debate a little depressing. A language will always have a certain flavour and angle to how it outputs or executes machine code. A language will always abstract thing so it can be better understood by a human brain.

There will always be a problem about orienting a language in a certain way, because there are not such thing as perfect when you design something, there are only compromises. A language orientation is a choice among many, and that will only better fit certain cases more than other.

Just be thankful to have working languages, and if you're not, just try to make one what either fit what you want, or try to have both OOP and functional features. I can't understand how people can actually criticize programming styles and language without trying to understand why such or such language is already great.

And by the way, you can't really weigh how a language is good or not, it's like benchmarking english or mandarin or spanish or french.

I'd just like to know how functionnal programming and OOP solve certain similar problems, and when it's better with one or another. Because let's be honest, programming style have nothing to do with theory, you can only judge when you have to engineer something.

</comment><comment><USER47> I thought this was going to be one of those one-word websites that said "Nothing". There's nothing wrong with either OOP or FP, only something wrong when people misapply them.

</comment><comment><USER48> This ignores the rise of effect systems, which take monadic effect-handling and place it into the realm of static analysis, where it belongs.

Disciple is the future.

</comment><comment><USER49> Just [http://www.scala-lang.org/](http://www.scala-lang.org/) and everybody's happy :)

<comment><USER43> I'm putting a lot of time and effort into mastering Scala, because I think that it's the future, paradigmatically speaking. But I think the muddled syntax and the complexity of the language may doom it. But I think it's the vanguard of the revolution. I was really psyched about Pyret ([http://www.pyret.org/](http://www.pyret.org/)) when I read about it here over the weekend, and I think it hopefully represents the future of how we program.

<comment><USER50> Come to #Scala and #Scalaz on Freenode IRC, it's a great learning resource. (REPL in the chat so you can get realtime help with code).

</comment></comment></comment><comment><USER51> Complete nonsense.

</comment><comment><USER52> This is solved long ago, without taking any extremes. In short, a language should be mostly-functional, which means when you really need to overwrite a value you just do it. In well-researched languages, such as Scheme you have set!, in CLs you have setf.

All the monadic stuff (remember, that a monad is nothing but an ADT - <USER2> Data Type) is already an extreme, because one _must_ structure the code in a certain way. However, one could write monads in Scheme, there is absolutely nothing special about them.

I think that monad madness it is of the same nature as over-engineering madness that plagues OOP - wasting of time and effort on construction of vast, meaningless class hierarchies.

On the other hand, to find a balance is the most difficult task. Scala, it seems, is close enough, but the ugliness of static typing - parametrized types polymorphism is still here. On the other hand, it avoids mutation whenever possible, uses persistent data structures and first class functions, which results in a much more reasonable and predictable, and, as a consequence, reusable and manageable code (modularity with almost no side-effects).

Yet another point is that there are literally tens of implementations of OOP features for CLs and even Schemes, which might suggest to you that OOP is just a set of conventions and rules - how to reference and dispatch methods - nothing but pointers and procedures, which are the most fundamental abstractions in CS.

The big ideas from Lisps, like everything is a reference, values have type (tags) not variables (you don't need Nothing to be a subclass of everything,) together with first-class functions without side-effects is that _good-enough_ set of features for a programming language.

The point is that so-called "best of the both words" was discovered long ago in classic Lisps and it could be loosely called a _mostly-functional language_.

<comment><USER15> You can't have monads in Scheme due to the lack of a type system. What you can have are instances of monads, but the point of using the concept of a monad is to abstract over it, and to have functions that work with any possible instance.

<comment><USER52> [http://karma-engineering.com/lab/wiki/Tutorial10](http://karma- engineering.com/lab/wiki/Tutorial10)

<comment><USER4> Genuinely wondering: does this provide type safety?

<comment><USER15> No, that would happily evaluate "(sequence_ ((display 'a) nothing))".

</comment></comment></comment></comment></comment><comment><USER53> I think that despite all mistakes that are in the article all agree that extreme OOP and extreme FP are almost equally bad and the balance between those gives the best results.</comment>


Show HN: Nerdcore minus the cringe. A (true) rap song about time estimations - <AUTHOR> https://www.youtube.com/watch?v=sh7A8UChBTI <comment><USER2> This is amazing. I love to see developers put their skills to good use and make fun of our profession. This is a needed medicine in our worlds of 100x developer magicians and downtime == emergency crisis where you skip your children's important life events. Props to whoever made this.</comment>


Why Vector Clocks are Easy - <AUTHOR> http://blog.basho.com/2010/01/29/why-vector-clocks-are-easy/ <comment><USER2> Justin (CTO of Basho) gave a phenomenal presentation (keynote worthy) at NoSQL East.

Vector clocks are easy and once he explained it in the presentation it "clicked" for me.

You can watch the whole presentation here, but if you want to get just the bit on Vector Clocks, fast forward to 28m

<https://nosqleast.com/2009/#speaker/sheehy>

But seriously, I _highly_ recommend watching the whole presentation. These guys are brilliant.

</comment><comment><USER3> Is this basically the same idea as Lamport's logical timestamps?

<comment><USER4> Lamport timestamps sync events between two systems, vector clocks extend the sync to N systems by using an array of these logical timestamps.

<comment><USER5> That's not true. Lamport clocks work across any number of nodes/processes. The figures in Lamport's paper all show examples using three processes:

[http://docs.google.com/viewer?a=v&q=cache:IJxXjuFmdHEJ:c...](http://docs.google.com/viewer?a=v&q=cache:IJxXjuFmdHEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.112.7608%26rep%3Drep1%26type%3Dpdf+vector+clock+lamport+clock&hl=en&gl=us&pid=bl&srcid=ADGEESj9G9HmsPpW6K6_8GQQ8xB- FQG2Y6NoEPNFrc_Cy7jcugKba8os_np3_7KQ2ecdS2M3cf_7VKc20VWaIqFZWpALejCa3mXf3CIcyhvvCCvL67WXK- bF45N5ewp9ODFem5R5p8aU&sig=AHIEtbQ4rf26DoHRXxGghyaByJnFtTWR2A)

<comment><USER6> Lamport's logical clocks work across multiple nodes, but they can lose information about causality.

Hence Mattern's extensions to Lamport's work, which introduce the idea of vector clocks.

</comment></comment></comment></comment><comment><USER7> Cool, it's like the data is surfing a web made of people (or inanimate actors), carrying a browsing history with it.

</comment><comment><USER8> Okay, this article made me feel stupid, given that I've been outside of a CS department for over a decade.

A brief Googling/Wiki-ing explains that they are used to solve certain concurrency problems, but without further explanation. Can somebody give me a practical, real world example of a problem this kind of strategy is supposed to help solve? I feel like I'm missing out on something...

<comment><USER9> Suppose you have a cluster of database servers in different datacenters, and somehow the connection between the datacenters go down. If you want to ensure high availability and allow your users to reach and modify the data while there is no connection, then you have to mark each modifications somehow so that later when the connection is up and the servers synchronize they are automatically able to merge most of the changes and find out conflicting cases.

That problem is solved by vector clocks and the most prominent application of them is Amazon's Dynamo system. See also eventual consistency for more information.</comment></comment>


Faster Smarter JavaScript Debugging in Firefox DevTools - <AUTHOR> https://hacks.mozilla.org/2019/05/faster-smarter-javascript-debugging-in-firefox/ <comment><USER2> You know, I've been using Firefox Dev Edition since it was Firefox Aurora (or Beta, I guess?), and it's great to hear that they are improving the dev tools! But I have to ask this in the nicest way possible: does anyone else think the tools just don't work a lot of the time?

It's something I noticed especially when they switched to React. A few examples I frequently experience:

1) Stepping through TS frequently switches back to the source JS. 2) Breakpoints don't always go away, and sometimes a page reloads with an invisible breakpoint, that stops the code, but doesn't show up in the list of breakpoints, and doesn't seem to be removable. 3) Breakpoints don't always stop at the the right place. 4) After having the tools open for a while, the tab starts freezing for multiple seconds every few seconds (GC, according to the perf tab, so it's either my code or the dev tools)

This comes from a place of love, and I'll still always use FF over Chrome, but I really have to ask if anyone else experiences the same issues, or if it's perhaps my setup/code that causes the problems?

<comment><USER3> I much prefer Firefox dev tools over chrome. The only time I use chrome is web socket stuff. Debugging css grids in Firefox (which I learned this year) is amazing.

<comment><USER4> fyi, we are picking up the websocket work this summer; so first parts might show up in 69, latest 70.

<comment><USER5> That's wonderful to hear! Websockets have definitely been a pain point for me trying to use FF dev tools in the past.

</comment></comment></comment></comment><comment><USER6> A few years ago, while working at an agency, I was using the Firefox Developer Edition to build the front-end for a website. I was presented with a very weird UI bug from the client that I could not reproduce whatsoever. It was driving me mad.

After an hour or so of frustration I realised that the bug did not occur on Chrome or Firefox "Standard" Editions and was only occuring on Firefox Developer Edition.

Now I know its not fair to make a judgement based on a single bug, too many variables at play etc but the lesson I learnt as a stressed out, time- pressured developer is not to ever ever ever use a browser that wasn't the standard version of a browser for development, the one most likely to be used by the client or end-user.

I can't recall exactly but I'm pretty sure I had a similar experience with Chrome Canary vs regular Chrome too. Although I think Canary is presented as a somewhat unreliable beta-ish version of Chrome whereas I had believed that FF Dev edition would have the same rendering engine as the equivalent FF standard, so long as they where the same version number.

In any case If I had some feedback for the team working on FF dev tools it would be to implement expand to unminifed line number on minified css and js. When I inspect an element and want to jump to a particular rule in the CSS it always expands to the first line of the file only and not whatever line that rule would be on in the uminified version of the file. Chrome does this and I find it so useful it prevents me from using FF.

<comment><USER7> Af far as understand Canarys eqvivalent is Firefox Nightly. Firefox Development Edition is not beta it is just different flavour of FF.

<comment><USER8> Firefox dev edition is based on the beta channel.

(Disclosure: I work for Mozilla)

<comment><USER6> Thanks for clarification. I was not aware at the time, perhaps my oversight or it may have not been clear on the website - was a couple years ago so I can't recall.

</comment></comment></comment></comment><comment><USER9> Firefox dev edition has been my go to lately, highly recommended if you do a lot of markup / css debugging. Being able to see outlines around elements as I hover / scan through the DOM easily doubles my speed.

<comment><USER10> I have found the CSS "changes" tab to be very useful. Just tweak the CSS and once you're satisfied you can just view a diff and use that to modify your code base [0]

[0]: [https://developer.mozilla.org/en- US/docs/Tools/Page_Inspecto...](https://developer.mozilla.org/en- US/docs/Tools/Page_Inspector/How_to/Examine_and_edit_CSS#Track_changes)

<comment><USER11> I like FF's diff format. For anyone who hasn't seen it, they give you the old code, followed by the new code:

        /* I think they also include URL info up here */
        h1 {
          /* background-color: blue; */
          background-color: grey;
        }

We (Chrome DevTools) have a Changes tab but no nice diff export like FF. [https://developers.google.com/web/updates/2018/01/devtools#c...](https://developers.google.com/web/updates/2018/01/devtools#changes)

</comment></comment></comment><comment><USER12> Inline breakpoints and human-friendly variable names are gamechangers! Looks like FF is going above and beyond Chrome devtools with this update.

<comment><USER13> Can it inspect WebSockets frames yet? I'm a Firefox user but I miss that sometimes when developing stuff.

<comment><USER14> I heard that this was going to be a GSOC project this summer, but I'm not sure if that was approved or not.

<comment><USER15> Mozilla methodology: staffs should avoid well defined works so that volunteers, interns, and students can do them.

<comment><USER16> It's not a bad strategy: just figuring out what to do can be much harder than getting it done (which can be more easily delegated). Architects (of old) made the big bucks in the days; now according to the google model they've all become senior engineers and the definition of and piecing off of work is much less formal (not to mention that it might go out to interns or the community rather the junior devs).

<comment><USER17> I can also picture it organically happening: if I were a core dev, would I focus on the issues "anyone" could pick up, or the ones that only someone as deeply invested into the code base as me would have any hope of untangling?

</comment></comment></comment></comment></comment></comment><comment><USER18> Correct me if I'm wrong, but web-socket debugging in FF isn't supported?

I ran into this last night, Chrome shows me what requests are going over websockets, FF does not.

<comment><USER10> I have always found Fiddler to be far more useful when debugging web traffic. It runs independently of applications, tabs, etc and allows for easy re- invocation of requests. And you can also test error handling easily by overriding the request and sending back an invalid response.

Fiddler is not the most user-friendly (it appears to be a bit thrown together), but it is very useful if you know how to find the right knobs.

</comment></comment><comment><USER19> Logpoints are v cool I think

[https://developer.mozilla.org/en- US/docs/Tools/Debugger/Set_...](https://developer.mozilla.org/en- US/docs/Tools/Debugger/Set_a_logpoint)

Will certainly be something I use now and again

<comment><USER20> That's sorta possible already, just use a conditional breakpoint and end it with `return false;` and it will act the same.

</comment></comment><comment><USER21> FF has had more solid console and debugging tools now for almost two years and it's one of the main reasons I switched completely from Chrome. It really is a superior, more reliable experience. And the console is light years beyond chrome. I definitely recommend it.

<comment><USER11> What makes you say that FF Console is lightyears beyond Chrome? (I write the Chrome DevTools docs)

<comment><USER21> Mainly the request/response logging. It's all in one place. I can click an xhr and it pops up right in the same window in a tabbed interface. I can see the request, response, headers, pretty json output if any. In chrome I click on an xhr, it takes me to a different tab where I have to scroll and find that request manually. I then have to switch back and forth manually if I need to go to other xhrs. Maybe this has changed in the last year? I don't know but that alone merited the switch.

</comment></comment></comment><comment><USER22> I'm really liking this recent uptick in Google/Mozilla/Opera development/rivalry lately. It's good for consumers. If only things happened more quickly...

<comment><USER23> Really? I generally see the opposite these days with everything moving to chromium (Opera, Chrome, Safari, and even Edge now all use it). Its kind of like a creepy consolidation.

I would say though Firefox does remain a strong (if the last) holdout.

<comment><USER11> FF and Safari are both shipping some great stuff that we don't have in Chrome DevTools.

Canvas debugger: [https://webkit.org/blog/8452/canvas- debugging/](https://webkit.org/blog/8452/canvas-debugging/)

Flexbox inspector: [https://developer.mozilla.org/en- US/docs/Tools/Page_Inspecto...](https://developer.mozilla.org/en- US/docs/Tools/Page_Inspector/How_to/Examine_Flexbox_layouts)

Fonts tab: [https://developer.mozilla.org/en- US/docs/Tools/Page_Inspecto...](https://developer.mozilla.org/en- US/docs/Tools/Page_Inspector/How_to/Edit_fonts)

<comment><USER24> That's got nothing to do with Chromium becoming ubiquitous as far as market share goes. Which is bad for everyone.

<comment><USER11> Sorry, given that this is a thread about DevTools I thought the conversation was scoped to DevTools. Didn't realize we were talking about browser share at large.

</comment></comment></comment></comment></comment><comment><USER25> Does hiting F2 in Firefox freeze the browser side of things (mouse position, mouse click state, css animations state, select dropdown openness state), basically everything? Or are there other tools for that? I have more problems with "debugging" CSS than javascript

</comment><comment><USER26> That is cool but I am wonder why no browser provided any HTTP request/response interception response. In 2020 we still rely on proxies which is crazy given the amount of heavily lifting browsers do these days.

<comment><USER20> It'd probably be possible to build this using service-workers or an extension.

</comment></comment><comment><USER27> I really wish Mozilla would add a way to disable CORS for local development.

</comment><comment><USER28> Great. Last time I tried Firefox dev edition a few months ago I had huge memory leaks, upwards of 2GB with a single tab after a few hours of use. It seems much better with the latest version.

</comment><comment><USER29> The best FF dev tool feature is definitely vim mode.</comment>


Xiaomi unveils the Mi 4 - <AUTHOR> http://thenextweb.com/gadgets/2014/07/22/xiaomi-unveils-new-flagship-smartphone-mi-4

<comment><USER2> What are the differences to the 1+ from OnePlus? [http://oneplus.net/](http://oneplus.net/)

Seems to be very similar hardware and price. And how can they achieve such a low price?</comment>


What should we do about Wikipedia's mature content problem? - <AUTHOR> http://larrysanger.org/2012/05/what-should-we-do-about-wikipedias-porn-problem/ <comment><USER2> You know where else kids can see pornographic images? Nearly everywhere else on the open Internet. Like this article mentions near the end, children can easily see whatever they please with a Google Image search.

So should we pour money and time into protecting young eyes? Wikimedia probably agrees with me when I think that this goal is probably impossible and thus a waste of resources.

If parents can't accept that their kids will see a lot of different things online, then they should monitor their children's online activity themselves. Shouldn't parents be the ones who do the parenting?

And last, kids are curious. What is the worst that could happen to curious children viewing porn on the Internet? I think the author of the post has a strong cultural bias against depoctions of sexuality. Wikipedia also contains many graphic depictions of violence. Isn't this much, much worse than pornography?

<comment><USER3> He doesn't disagree with you, one of his main points was that Wikipedia hosts very very disgusting porn. The fact that children can find porn if they seek it out does not mean we should be presenting it to them on a very public website like Wikipedia. Should it suddenly be ok to post nsfl images everywhere in society because anybody can find it if they really want to? Because I feel like Wikipedia doing this is a step in that direction

<comment><USER4> What's so disgusting about animated GIFs of men jerking off? Every boy is going to learn how to do that very soon. Given the abominable state of sex education in many parts of the world, I would much rather kids learned about sex on Wikipedia than on porn sites that grossly misrepresent the subject matter.

Some of the BDSM and genital mutilation stuff, to be sure, is rather disturbing. Still, those images and videos are on Wikipedia because there are articles that explain relevant topics. It's not like they will turn up when some kid searches for "boobs".

No, it's not OK to post nsfl images everywhere. But no, I don't think that means we should remove them even from places where they are appropriate. Do you want disturbing images removed from anatomy textbooks, too? Kids can easily find those books in libraries, after all.

</comment></comment></comment><comment><USER5> Truly, points to the author: he cloaked his loathing well. His concern lies somewhere between misguided and malicious.

So to the heart of this issue: What "extremely explicit" "disgusting" "pornographic" "adult content" is he referring to?

• close-up photographs of ordinary intercourse

Oh. Foundational information on a fundamental, universal behavior that propagates the human species. Yes, there's no reason "the children" should ever be allowed to define human intercourse or put it in a coherent context - best to just let them discover sex from a blinking pink banner ad.

What does this fool actually want?

</comment><comment><USER6> This is some FUD. See WikiProject Wikipedians against censorship for why most of what this guy says is nonsense, and for information on how Wikipedia already allows institutions like public schools that may require filtering of explicit content to configure it:

[http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikipedia...](http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikipedians_against_censorship)

<comment> jim-greer I don't think the filtering options you link to are realistic for public schools. They amount to configuring your browser to not show images, configure a skin which uses a blacklist of 'limited utility', or use a 3rd party proxy that gets no help from Wikipedia.

> Logged-in users can use personal cascading style sheets to display of images > selectively (explained below).

> By filtering content locally, either by configuring their web browser > (including the possibility to display no images at all), or by setting up a > proxy (such as Privoxy) (explained below).

edit: added limited blacklist option

<comment><USER7> By that logic installing and configuring all other computer systems will be equally unrealistic.

</comment></comment></comment><comment><USER8> I can't read the article because the server is down -- but people should be aware of Larry Sanger's history regarding Wikipedia: <http://en.wikipedia.org/wiki/Larry_Sanger>

<comment><USER4> tl;dr: Former philosophy professor who specializes in ethics and epistemology helped found Wikipedia, but got dissatisfied with Wikipedia's "lack of respect for expertise". He leaves Wikipedia, and ever since then, he's been highly critical of any aspect of Wikipedia that he thinks detracts from its credibility. This credibility, of course, is to be measured by traditional professional standards such as (surprise, surprise!) lack of "porn".

Nothing new there. There is a certain paradigm at the intersection of ethics and epistemology that makes it extremely difficult for people to appreciate that a repository of information can be valuable even if it does not explicitly recognize formal expertise. Adherents of this view always demand formal criteria for inclusion and exclusion, and believe that an absence of such formal criteria will inevitably lead to failure. The possibility that armchair philosophers will never be able to come up with criteria that work as well as the combined effect of a million ordinary edits never seems to cross their mind.

I could go on and on about how harmful this paradigm is (I wrote my PhD thesis on the very same topic, and yes, I'm a philosophy major) but I'll stop here because it quickly gets boring.

</comment></comment><comment><USER9> This discussion is absurd. If an institution wanted to filter Wikipedia, they could copy it en masse and just leave out the naughty bits. I don't think the license could forbid that.

The fact of the matter is that censorship is not trivial. The cost of filtering should be burdened by the censors, not the Wikimedia Foundation itself.

Edit: Jim Greer points out that Wikipedia actually does suggest using proxies for censorship, [http://en.wikipedia.org/wiki/Wikipedia:Options_to_not_see_an...](http://en.wikipedia.org/wiki/Wikipedia:Options_to_not_see_an_image#Use_a_proxy_filter)

</comment><comment><USER10> I'm not one hundred percent sure that this is a problem. Context is important. Pornographic material in Wikipedia's "NPOV" and encyclopedic context is probably not unsettling to children.

If this is a real issue, and pedagogues or parents are offended, how has Wikipedia gotten away with it this long?

<comment><USER11> I wouldn't have thought so either, but apparently there are some folks out there who are enjoying pushing the limit of exactly how _much_ pornography they can incorporate into wikipedia.

I mean, do we really need an article on the subject "Cock And Ball Torture"? I would have thought it was fairly self-explanatory. If so, does it _really_ need to be illustrated with _four_ photographs?

(You can look it up, I'm not gonna provide a link.)

I'm guessing, here, that the page exists less for the greater edification of mankind and more for the sexual jollies of that rather narrow section of humanity which happens to enjoy not only putting their genitals in "humblers", "testicle cuffs" and "parachutes", but also get off on exhibitionism.

I dunno if it's "unsettling to children", but that page is sure as hell unsettling to me.

<comment><USER12> >but apparently there are some folks out there who are enjoying pushing the limit of exactly how much pornography they can incorporate into wikipedia.

Bingo. I would even go as far as to say that wiki's have this way of attracting entire sub-cultures of contributors who enjoy sneaking such things in wherever they can shoe-horn them. (See: Tvtropes.) On the one hand I support wikipedia's position that they shouldn't censor the articles. But on the other hand I don't see limiting this subtle vandalism as censorship. It's more of quality control than anything else.

</comment></comment></comment><comment><USER13> There's no problem at all.

I created a content filtering firewall for conservative Lutheran elementary school to using Dan's Guardian and it's naughty word filter.

Problem solved in 30 minutes, and the children get to see 99% of Wikipedia, including topics like "Breast Cancer."

When we were testing the filter, we found that occasionally a topic with a slightly naughty photo may come up from time to time, but nothing you couldn't find in a National Geographic. We didn't care to filter it any more.

Want to do it yourself: Endian firewall on a VM.

</comment><comment> jim-greer I think the issue boils down to whether kids will accidentally come across porn - the author presents a very misleading example of a search result for 'male human'. When I search for that I get a high-quality porn-free page: <http://en.wikipedia.org/wiki/Male_human>.

If kids are actively looking for porn, they are going to find it. Now, it would be nice for public schools with strict white list based domain filters to be able to include Wikipedia as a safe site.

</comment><comment><USER14> It is not a problem. Let's move on.

</comment><comment><USER15> What's with the title change? There's a difference in intent between describing a "porn problem" and a "mature content" problem.

<comment><AUTHOR> Because "Wikipedia's porn problem" is a sleazy title.

</comment></comment><comment><USER16> I think a good interim solution would be to have a client-side filter, browser extension or such. Wikipedia content is very well categorized, so it's not a classical content filtering problem.

<comment><USER9> I was curious just how well the categories are exposed to clients. I didn't find any HTTP headers or HTML meta tags, but a text scan for "Category:" would do well.

</comment></comment><comment><USER17> I love the comments. I can't keep my kids from seeing porn, so let's censor Wikipedia. The logic, is just... breathtaking.

</comment><comment><USER18> Nothing. It's an encyclopedia.</comment>


Show HN: Need your feedback. - <AUTHOR>

/ This is an old post in HN (https://news.ycombinator.com/item?id=5360453), but could not get enough response, so posting again, A friend told me that 'Show HN' will help better. */
Hi All,
(http://www.mistrics.com/) I made a project that helps in documenting Academic projects and sharing them with teachers. It also provides facility to ask questions. Students needs to simply create projects, after that just create task and documents under it. Also inviting others into team and so on....
In Indian colleges this process is all manual right now. And I am trying to get this process online.
I am not getting any traction so far. Any clue what's wrong with that?
Regards, <comment><USER2> First 10 seconds impression:

The landing page seems confusing, there are at least 3/4 fonts used and the layout doesn't seem consistent, same with colours and styles, sometimes you use flat buttons, sometimes bootstrap gradient buttons.

There is not explanation of what is this for, saying collaborating and sharing nowadays is like saying that breathing.

The idea might be good but if you want people to actually use it you must give them a reason to do it and work on the design.

<comment><USER3> I second this, my first impression is definitely that the design is confusing and not attractive.

Secondly, I'm really not even sure how this site would benefit me. You need to make that clear on your landing page.

You need to sell your idea, and sell it well if you want users.

</comment></comment><comment><USER4> Get Rid of the vertical bars between Think, Share, and Collaborate. Use commas or make them separate text. The "sign up now" button should be just one font. The positioning of the about and feedback buttons is very odd and looks messy. The facebook like button should be on the same line as the other social buttons, if needed.

</comment><comment><USER5> You won't get traction without knowing who your target audience is. Incidentally that doesn't come across on the landing page, but even if you sorted that out, you'd still need to contact academics and get them to start using it.

Visit a local university and sign-up a few people to try it, then iterate on their feedback.

</comment><comment><USER6> For the clickers <http://www.mistrics.com/></comment>


Ask HN: How much equity should I ask for? - <AUTHOR> I'm not particularly  motivated by money but this feels like something I should ensure that I'm doing myself justice.
I dropped out of University after first year and took pretty much the first job I liked the sound of that would pay me to code. It's been a great year and I wouldn't trade it for the world. I was the first technical hire at the company working with an external agency. Fast forward 10-12 months, I'm now an experienced Junior Dev. I'm currently working for £18k p/a. I've been interviewing at a couple of other companies and have had been quoted £26-32k and with a hard offer of £28k.
We're about to go for a funding round with a valuation of ~£7m. My bosses have informally agreed to better the £28k offer. I really like the idea of a minor equity stake. I was thinking somewhere between 0.125% and 1%. This feels like a big range. I don't want to come off like I don't understand the value of the potential equity stake.
After the funding i'll (hypothetically anyways) be working under an experienced CTO (new hire) with a quite substantial amount of responsibility.
I really appreciate any advice HN :) <comment><USER3> Personally, I think negotiating for equity in terms of percentages is a mistake. The better way to do it is in terms of financial outcome.

You make X dollars in salary every year. You model the equity as a lump-sum bonus paid after 4 years (divide the liquid value of the options by 4, mentally applying as a deferred bonus for each vesting year).

To make that happen, you ask management for some outcome scenarios --- a "low", "medium", and "high" outcome, for instance --- that values the grant you're getting.

ie: "If we're acquired for $50MM, your options would be worth $Y". You make $X/yr, so, if the company is acquired, you'd effectively have made $X+($Y/4)/yr. Are you happy with that number? Then agree.

To dig into the low/med/high scenario, two helpful anchor numbers: first, the company's valuation at its last round (if the medium option 20x's valuation, that's, you know, worth knowing), and second (and I think more important) the multiple of trailing revenue that represents. In other words: in the "medium" outcome, how much revenue do your employers propose the company to have done in the preceding year, and what multiple does that imply for the valuation?

These are easy numbers to get your head around, implicitly capture the percentage of the company you're getting without making that the terrain you're negotiating over, and (most importantly) forces your employer to be clear about where the numbers are coming from and how the business will actually work.

The other way to do this is just to value equity at $0.

<comment><USER4> The intention of the process you outlined is good, but the process itself is flawed and highlights the pitfalls of trying to value equity at early-stage startups.

First, very few startups can accurately tell you "If we're acquired for $50MM, your options would be worth $Y." Heck, for fun, ask a founder of a typical angel or venture-backed startup how many shares it has outstanding _fully- diluted_.

If tons of startups struggle to describe what their capital structure looks like _today_ , why should prospective employees rely on them to make estimates based on what their capital structure will look like months or years from now? Dilution, liquidation preferences, the option pool, acceleration terms. There's so much that can't be predicted or controlled, so asking a company to come up with exit scenarios for specific employees is like asking a blind man to read tea leaves.

> The other way to do this is just to value equity at $0.

At most early-stage startups, this is the correct approach to dealing with equity. There are very good reasons most vested employee options are never exercised.

This doesn't mean that the OP shouldn't ask for some equity, but focusing negotiations around basis points of equity and trying to assign a future dollar amount to equity is generally a bad idea for the average employee because it opens the door for treating equity as a 1:1 (or close to 1:1) substitute for salary, which at early-stage startups it is not.

If an early-stage startup wants to offset your cash salary with equity, try this: ask for $50 to $100 worth of equity for every $1 of salary offset. How the company responds will likely tell you a lot more about its future than if you ask what it guesses 1 option will be worth 4 years from now.

<comment><USER3> _try this: ask for $50 to $100 worth of equity for every $1 of salary offset_

You take that number from their last valuation?

<comment><USER4> Of course. In the US you can't get around 409A.

As a prospective employee, if you fundamentally believe that the company's latest 409A valuation is already too rich and equity is important to you, don't join the company.

</comment></comment></comment></comment><comment><USER5> Practically speaking non-controlling non-preferred equity of a private company is worth only whatever value those higher up the food chain assign it out of goodwill. Controlling interests can structure liquidation largely however they want...e.g. they can sell to themselves at a nominal price or they can sell their stock into a round and buy a Ferrari. Hollywood accounting happens outside of Hollywood.

There's nothing to be gained by forcing your way into equity unless you are funding. You're not and recognition that there are sound business reasons for a negative response to a request for equity is not a sign of lacking sophistication.

If it's on the table take it. If it's not figuring out the business reasons why is immensely valuable.

Good luck.

<comment><USER6> Perfect response. What brudgers said is if you don't have control or preferred w/ anti dilution their commitment is minimal.

Common 5% in Q1 can be any number less than that in Q2.

</comment></comment><comment><USER7> How much of the value of the company is tied up in it's technology?

Your leverage at the moment is, if you decided to get another job, you would walk away taking all knowledge of the current system with you. Imagine you quit, and something went wrong the next day - how long would it take them to fix it?

I think your boss did you a huge favor, taking a risk on you this first year. Now you are no longer an unproved dropout, he owes you a real wage. Keep both of those in mind.

<comment><AUTHOR> I don't think I can quickly evaluate that. I would say it's less technical than a traditional tech company but still closer to that than say an eCommerce store.

> I think your boss did you a huge favor, taking a risk on you this first > year. Now you are no longer an unproved dropout, he owes you a real wage. > Keep both of those in mind.

This is exactly the lines I'm thinking of. I've been lucky enough to gain the sort of experience that puts me on the same playing field (at least in the view of employers) as my a grad.

</comment></comment><comment><USER8> Lots of people advise job hunters to be skeptical of counter-offers. For example:

[http://corcodilos.com/blog/7874/should-i-take-a-big- counter-...](http://corcodilos.com/blog/7874/should-i-take-a-big-counter- offer)

The job offers you got suggest that your current employer has been happily underpaying you by 50% of your market value.

Also, you're comparing a "hard offer of £28k" with " _informally agreed_ to better the £28k offer". Don't turn down the hard offer until you've gotten a real commitment. And you'd need to get that commitment before the £28k offer expires.

<comment><AUTHOR> It's true that it seems like I'm being underpaid - I wouldn't say they're happily doing so. We're a young start-up struggling for cash and to make ends meet. Hopefully the funding round will alleviate that to a degree.

Also thanks for the link. I hadn't thought of it like that.

From my perspective, £18k (and indeed £28k) is a lot of money. I'm 19 and I'm getting paid to code, I know it's naive but I think it's awesome. I love the people I work for/with and I love my job. I come across adults who haven't had that their entire career.

Edit: Just to follow up on the counter offer. The process of raising this round of funding has been such a whirlwind. I don't think there is anything untoward going on. I think a case of Hanlon's Razor: [http://en.wikipedia.org/wiki/Hanlon%27s_razor](http://en.wikipedia.org/wiki/Hanlon%27s_razor)

<comment><USER9> It's brilliant you are getting this experience at such a young age. It'll be absolutely invaluable when job hunting in the future. Many CS graduates come out of university in the UK ill-prepared to enter the job market and end up taking underpaid junior roles.

But 18k doesn't sound far off the salary I'd expect an inexperienced junior dev to make. Things that might get you a higher salary for this kind of role are a degree or prior experience. If you have prior working experience (even freelance) then you probably are getting a little too low.

<comment><USER10> 18k sounds low for a grad starting that's only 5k less than the minimum wage.

Around 26k would be nearer the mark for a starting grad with no experience.

<comment><USER9> He isn't a graduate though. He is a junior developer who dropped out of university after a year.

<comment><USER10> Its the rate for the Job what does a graduate certificate matter the UK isn't as fixated as some country's on credentials.

</comment></comment></comment></comment></comment></comment><comment><USER11> A lot of the comments here tells you not to get taken advantage of (financially) and how to maximise your worth etc. I don't think that's wrong per se, but I also think that may be better advise for someone a bit further in their career than you are. Where you are, I would say you should maximise for learning. That means getting to work with experienced people who are willing to teach you. By all means, make sure you get a fair salary, but make it a secondary priority when deciding what to do.

Regarding equity - Certainly ask for some amount of equity. That could never reflect bad on you as it signals a commitment to the company on your end. Keep in mind though that equity is a fairly long-term view. At 19, a 4-year vesting is eons away. There's a good chance you'll never turn those options into anything material.

</comment><comment><USER12> You ask £40k and 1.5%. What's the worst that can happen?

<comment><USER13> well the worst that can happen is that he does not get hired: no salary increase, no equity.

And this is not even the worst that can happen. I have withdrawn (let them expire) offers from people that after receiving my first offer tried to strongarm ridiculous bonuses. The reason I have withdrawn the offer is that it made me clear that the person does not understand their worth to us - <USER2> would likely be a trouble later on. I did not negotiate and just let the deadline stand.

I am tired of all these advices that make it sound as if asking excessive bonuses and money does not give off bad impressions. It actually does.

<comment><USER14> > The reason I have withdrawn the offer is that it made me clear that the > person does not understand their worth to us - hence would likely be a > trouble later on.

Or just doesn't have much experience with (salary) negotiation, which, for most roles that aren't sales or HR, isn't necessarily a problem. The people who do this for a living (employers, recruiters, etc.) are always going to know the rules and the social norms better than the ones that don't (most employees).

I don't really know what you mean by "ridiculous" in that situation, so it's hard to draw any conclusions, but I will say that most good engineers are pretty bad at negotiation skills, and IMHO withdrawing an offer is quite an extreme move.

<comment><USER13> Let me add to all this that we first did an informal negotiation with the prospective employee with a quite lengthy back and forth that led us to put those terms in writing.

But only when he had the official letter did it occur to him to ask for a larger office (it is not possible as he should have seen during the visit, travel funds (???), extra time off and more salary. It was extremely annoying.

</comment></comment></comment></comment><comment><USER15> 1% is £70K, albeit illiquid that still sounds like a lot of money. If they better your £28K salary it looks like £100K (of course salary is real and ongoing whereas equity is a single NPV). Is there a vesting schedule?

I'd say you need to think about how much you like working there, and your chances of finding something better. The market does seem pretty buoyant, could be well worth it to talk to more people.

</comment><comment><USER16> 28k outside of london is good. If they are getting funding then they are probably also scaling up, you want to get on the leading edge of that if you can. Career wise that might be worth more than equity.

Equity is a double edged sword, sure you get extra value but you are also tied to the company. When things are going great you don't want to leave and when things do sour then you cant because you just lost money and may feel a moral pressure.

28k is also a good figure as it will springboard you into all kinds of other job roles (because recruiters only look at previous salary). my salary jumps were similar in the beginning.

</comment><comment><USER10> oh one thing no one has mentioned as this is the UK - is this a HMRC approved scheme or not - might have tax implications.

<comment><USER17> ^^^^^^^^^^^^^^^^^^^^^

Really sensible comment - you need to understand whether it is an approved options scheme or not (assuming you are in the UK).

</comment></comment><comment><USER18> How many employees do they have? The less the more likely you are to negotiate a good stake. I don't think it really makes sense to apply financial calculations at this stage. You might be underestimating the amount of equity you can get.

What I'd do is keep the table open - make them hire/pay you for a month or two, then negotiate. You can probably get way more if you develop a good relationship.

EDIT:sorry, sounds like you already work there

If they're <=5 people don't be afraid to say 5 or even 10%.

</comment><comment><USER19> Ask for £35k from the existing company. Leave the discussion of equity out.</comment>


Nobody Knows the Identity of the 150 People Killed by U.S. In Somalia - <AUTHOR> https://theintercept.com/2016/03/08/nobody-knows-the-identity-of-the-150-people-killed-by-u-s-in-somalia-but-most-are-certain-they-deserved-it/ <comment><USER2> I want to vomit a little bit with sheer rage some times. America is literally rotting away since 2001. Before then, it had a few bruises and blemishes like any country does. A sad chapter here, some scandal there. But now it rots on full display for the world and I can't understand how it's citizens live with it... Then I remember they don't care. And I do my best not to care because if I kept on caring it would probably drive me to suicidal depression. And I circle back to my thoughts and realise that they don't care because they too are probably just afraid of being dead inside, it's nicer to be ignorant and happy than informed and depressed. It's just the vicious cycle of the world.

<comment><USER3> I feel the same. I wonder whether this moral sludge we live in is how the world always has been and always will be, so all the stories about moral values are just notable exceptions. How to raise children who would care for other people, for moral values when we do not? Where do we find better parents, better teachers? How do we move towards a society based on actual people instead of the _fakes of a human_ most of us are?</comment></comment>


New iPhone XS and XS Max users reporting bad WiFi and cell signal - <AUTHOR> https://www.reddit.com/r/iphone/comments/9idfu5/lets_talk_about_reception_on_the_xsxs_max/ <comment><USER2> One of the comments says:

> I don't understand why people are comparing bars. The X and XS do not > connect to the same frequencies. The XS support some that the X doesn't. > Depending on the frequency, having 1 bar may result in faster connectivity > than 4 bars in another congested frequency. And yes, phones will often > prefer connecting to cells with less signal but that are less congested than > 5 bar cells with no capacity.

I don't know enough about things to know if that's right, but it seems reasonable.

Anecdotally, I've had a XS Max since Friday and haven't noticed anything different at all, but I also haven't been away from home much over the weekend so I can't really weigh in. Still, I wouldn't be surprised if people were jumping too conclusions, but I also wouldn't be totally surprised if Apple goofed somehow (though that seems a little less likely).

</comment><comment><USER3> I've noticed that when I'm on my deck the XS WiFi signal is below 1 mbps while my iPad Pro is at 80 mbps. When I'm closer to the router both devices get roughly the same download speeds.</comment>


Office 2010 preview - <AUTHOR> http://stevenf.tumblr.com/post/101550689/office-2010-preview <comment><USER2> Considering the fact that GUI used to be MS's core competency, this is a sad state of affairs. I surprised be just how un-intuitive this looks.</comment>


Sleep-deprived brains alternate between normal activity and 'power failure' - <AUTHOR> http://www.thinkgene.com/sleep-deprived-brains-alternate-between-normal-activity-and-power-failure/

<comment><USER2> Damn, I know this sensation so well... Anyone have any advice for someone who keeps procrastinating about going to bed, even when exhausted?

<comment><USER3> I have that problem most when I am dreading the next morning. If someone is engrossed in a problem, it will still be there when you wake up.

</comment></comment><comment><USER4> That just described my last week :\</comment>