Examples of Incorrect Abstractions in Other Languages - <AUTHOR> https://www.reddit.com/r/haskell/comments/glz389/examples_of_incorrect_abstractions_in_other/ <comment><USER3> Some of these are arguably "incorrect abstractions", but others are just design decisions that are being treated as "incorrect" because they don't follow Haskell's design sensibilities. A perfect example is the complaint about _sum_ in Python:

       >>> sum(["a", "b"], start="")
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
        TypeError: sum() can't sum strings [use ''.join(seq) instead]

I don't think this is incorrect at all! There's a very good reason to use _join_ instead of _sum_ for adding strings together: _join_ is a lot more efficient than simply adding strings together, because it will precompute the amount of space needed for the resulting string at once and then put all the strings into the buffer at once, whereas using _sum_ in the naïve way suggested would do a different append for each element. These are just different tools for different purposes!

Could you design a _sum_ that automatically looked at its argument type and deferred to _join_ for strings? Sure! And that'd be a valid design decision as well. But the specific choice Python made here is motivated and defensible: it's only "incorrect" if your personal definition of "correct" is "built with the same algebraic sensibility that Haskell's designers had," but at that point, all other languages are "incorrect" because they're not Haskell!

<comment><USER4> Special cases like this make generic code very hard to write. If I'm writing a library that needs to handle user-provided data agnostic of type and I want to do a sum operation, now I have to add checks all over the place for whatever special cases python has.

<comment><USER5> I think never have I written generic code for summing up numbers AND concatenating strings. Even the Haskell people would agree I think. So the design problem is in overloading `+` for string and list concatenation in Python in the first place.

But I guess in terms of strings let's take a moment and remember the one truly good design decision that Python devs made about strings (which isn't _usual_ for an imperative language). Strings are immutable by default.

<comment><USER6> > I think never have I written generic code for summing up numbers AND > concatenating strings. Even the Haskell people would agree I think.

Erm, Haskell people write code that can do this all the time - you write stuff in terms of generic monoid and then it just does. I can even think of a concrete case where I used those two examples: I had essentially a report that looped over a bunch of rows and accumulated something as a secondary effect, and in one client's case that was a string explaining what had happened, and in another client's case that was a count of how many things had been processed.

<comment><USER7> So you've written (of course type safe) generic code that was in principle able to achieve the same effect as described in [https://stackoverflow.com/questions/9032856/what-is-the- expl...](https://stackoverflow.com/questions/9032856/what-is-the-explanation- for-these-bizarre-javascript-behaviours-mentioned-in-the) ? ;-)

Batman!

<comment><USER8> No. He was talking about monoids. The content in the link you are talking about aren't monoids.

<comment><USER7> Do the implementation details matter if you could achieve the same result?

<comment><USER8> It's not about the implementation details. It's about that the things that are mentioned in the link make no logical sense. The addition operator allows values of different types to be added together and even worse the resulting values type isn't required to have the type of either operands.

It's not possible to write the generic code since there are basically no constraints. Generic code is all about constructs with certain invariants and use those invariants to create something new. Javascript addition basically has no invariants.

<comment><USER7> >It's not about the implementation details. It's about that the things that are mentioned in the link make no logical sense. The addition operator allows values of different types to be added together and even worse the resulting values type isn't required to have the type of either operands.

I would argue that that's not true.

JS is a "mono-typed" language and there is therefore only one type of things you can operate on and return as a result.

>It's not possible to write the generic code since there are basically no constraints. Generic code is all about constructs with certain invariants and use those invariants to create something new. Javascript addition basically has no invariants.

That's backwards to my point. I tried to point out that having generic code which can operate on (almost) arbitrary data structures mixing for example natural numbers or lists of arbitrary things will lead in the end to the same puzzling results as the "classical JS-Batman" example.

Don't get me wrong, generics are a great tool! But imho it's easy to "overstretch" their usage until a point where things become "so generic" that your functions can operate on "almost everything" but the results become as surprising as the alleged "JS insanities".

Something like the Monoid abstraction is incredibly powerful (most languages can't express such an abstraction in a sensible way even). Using such a powerful tool to abstract over some very concrete and banal things (that would be handled better separately as they're "not the same", no matter there may be a deep mathematical connection) is not a good architecture imo. If your code handling "concrete things" is written in a very generic and abstract way you won't have any "normal" tools left on your belt in case you would need to abstract over that stuff you've just written (at this point you could enter type-level programming or something that will achieve something similar but you will than end up with laughable complex code to handle in the end banal business logic).

[https://en.wikipedia.org/wiki/Rule_of_least_power](https://en.wikipedia.org/wiki/Rule_of_least_power)

<comment><USER8> > JS is a "mono-typed" language and there is therefore only one type of things > you can operate on and return as a result.

Javascript has a type system that is enforced at run-time.

> That's backwards to my point. I tried to point out that having generic code > which can operate on (almost) arbitrary data structures mixing for example > natural numbers or lists of arbitrary things will lead in the end to the > same puzzling results as the "classical JS-Batman" example.

I don't agree. The entire point of the link you posted was the insanity of the semantic of the addition operations in Javascript. Monoids are very simple and well defined. The javascript insanity would need pages upon pages of explanations because basically everything is a special case. In contrast monoids can be fully explained in a two sentences.

<comment><USER7> >> JS is a "mono-typed" language and there is therefore only one type of things you can operate on and return as a result.

>Javascript has a type system that is enforced at run-time.

Nobody questions that JS has "runtime type-checks". But that's irrelevant to my point. I've referenced of course this here:

[https://existentialtype.wordpress.com/2011/03/19/dynamic- lan...](https://existentialtype.wordpress.com/2011/03/19/dynamic-languages- are-static-languages/)

>Monoids are very simple and well defined.

Sure. Just define an instance for a type that models a JS runtime-object, let's see what happens… ;-)

But I see, my point is still not explained well: What I'm trying to say is that using abstractions that are so powerful that the resulting code can operate on (almost) arbitrary "unrelated" things using that code will lead to the same _kind_ of puzzling outcomes as "JS Watman".

(And like I said, a deep mathematical relation doesn't make things "related" in a practical sense automatically. For example when it comes to "correct" domain modeling of business cases where you _explicitly_ want to treat different parts of your system separately; as this results in a less "entangled" architecture. Gluing together parts that are unrelated through clever code on the other hands side creates maintenance hell where everything depends on everything, but you can't even see what depends on what as everything is generic; that's the opposite of good software engineering, imho. To throw a few phrases: "Divide and conquer!" "Use the right tool for the job!" "Use the least powerful tool that gets the job done well!").

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Fun trivia, the promise absorption thing was dismissed when it was brought up, with the argument that the "ship had already sailed on that" and that the arguments for supporting promises of promises were too academic (in the detractors' words, it was "fantasy land").

Which then resulted in the creation of a specification called fantasy-land[1] as a form of mockery towards the "incorrect abstractions are fine" attitude. The goal of this spec is to standardize on functional algebra nomenclature in JS.

[1] [https://github.com/fantasyland/fantasy- land](https://github.com/fantasyland/fantasy-land)

<comment><USER10> lol, I knew fantasy-land, but I didn't know the story, thanks!

I have to admit, when I read stuff by hardcore FP proponents like in that Reddit thread, I also feel the urge to call it fantasy land.

</comment></comment><comment><USER11> This is a thread from r/haskell. I think a fair summary of the contents is "things Haskell people dislike about other languages."

<comment><USER12> To me it looks like someone who wants to compile a list of arguments they can refer to when they are having an argument about programming languages

</comment></comment><comment><USER13> > And yet, for a long time, it lacked a function analogous to < _> , which is > strange when considered from a "folds are Applicative" perspective.

Man. I enjoyed hacking around with Haskell back in the day, but I found it to be a write only language with forms like <_> making me stop and stare too often.

Also, after maybe 15 years of working in statically typed languages, I also decided that ultimately, I prefer dynamically typed languages. Still have yet to use my favorite (Clojure) in production, though.

<comment><USER14> > Also, after maybe 15 years of working in statically typed languages, I also > decided that ultimately, I prefer dynamically typed languages. Still have > yet to use my favorite (Clojure) in production, though.

I like to have types when I need types. If I want to write a numeric value in a json output I'm creating that will be consumed by some other system, I want that thing to represent exactly that and spit an error if I ever try to assign something else, such as a string. But more than that, it should be easy to define my own types. I need to be able to say, "this number is not just any number, this is actually a temperature measurement in Celsius" or "this is talking about screen coordinates, not world coordinates". And then only be able to send that to the correct functions – or treat as a normal number if I'm doing basic math.

But most of the time, most people don't care about types. We want to say "do this operation across all elements of this array". If I trust whatever lower level function that added the properly typed elements in the first place, now I can focus on manipulating them. Glue code is very amenable to dynamic types.

Haskell has a very rich type system (maybe too rich?), but it also allows you to say that function receives an A and returns [A]. What's A? If you don't care, you don't care. That's beautiful. And the compiler can even inference some of it for you.

Now, if the only thing I have is a poor type system(like Java), then just give me primitives and a struct.

<comment><USER15> You want F#.

> If I want to write a numeric value in a json output I'm creating that will > be consumed by some other system, I want that thing to represent exactly > that and spit an error if I ever try to assign something else, such as a > string

[https://fsharpforfunandprofit.com/posts/serializating- your-d...](https://fsharpforfunandprofit.com/posts/serializating-your-domain- model/)

> I need to be able to say, "this number is not just any number, this is > actually a temperature measurement in Celsius"

[https://docs.microsoft.com/en-us/dotnet/fsharp/language- refe...](https://docs.microsoft.com/en-us/dotnet/fsharp/language- reference/units-of-measure)

</comment></comment></comment><comment><USER16> I occasionally find myself interested in learning Haskell, wondering why I haven't done so yet. So I go out and find an introductory tutorial, which is without fail written with exactly the sort of smug self-satisfaction that this thread is written. And I immediately lose interest.

Maybe the Haskell community is genuinely peopled by the most brilliant minds ever to grace the planet, and the rest of us are out here farming shit. I'll never know, because I'd rather struggle for a lifetime through poorly- implemented languages than have to turn every time I have a problem to a community completely unable to process the idea that they might be wrong.

<comment><USER17> > So I go out and find an introductory tutorial, which is without fail written > with exactly the sort of smug self-satisfaction that this thread is written. > And I immediately lose interest.

I think reading that tone into a tutorial, or from this thread, says more about you than the community.

And even if they were smug, consider the possibility that maybe they have good reason. Would you never buy a Tesla because Elon Musk smugly claims his cars are the best on the market?

> I'll never know, because I'd rather struggle for a lifetime through poorly- > implemented languages than have to turn every time I have a problem to a > community completely unable to process the idea that they might be wrong.

Cut off your hand to spite your face? Your choice of course, but from my experience as a non-Haskeller, the community is perfectly welcoming and willing to explain details to beginners.

Also, if the Haskell "community" never thought they were wrong, they would never disagree. That's clearly not the case if you perused any mailing list or thread.

<comment><USER16> TFA:

> which really should have implemented a well-known concept (Monoid, Monad, > Alternative, whatever), but they fell short because they (probably) didn't > know the concept

If that's not smug self-satisfaction, I don't know what is. No consideration that there were reasons they implemented their system in a different way. Suggestion that it was done due to ill-education on their part. I reread it carefully after your accusation. I don't want to too readily assume the worst in people. I am extremely comfortable with the accusation I laid on that thread.

But to your other point, I don't consider the possibility that they have good reason for their smugness. I don't find it implausible (as I said, albeit sarcastically), I just find smugness entirely orthogonal to correctness. There are brilliant smug people, but flat-earthers are also among the more smug people I've encountered.

If I lived in a world with only ten languages, I might agree I was punishing myself more than them. But I will never learn every language, tool, technique or skill I want to, so why would I ever start here?

<comment><USER17> > If that's not smug self-satisfaction, I don't know what is. No consideration > that there were reasons they implemented their system in a different way.

Of course there was consideration. The history surrounding this is well documented. People familiar with the relevant concepts raised the problems with the JS Promise API early on, but were dismissed.

Which is also beside the point, because generalizing from N=1 is silly. If I'm being generous, you pointed out one smug Haskeller, where you claimed that the entire community was smug.

> If I lived in a world with only ten languages, I might agree I was punishing > myself more than them. But I will never learn every language, tool, > technique or skill I want to, so why would I ever start here?

Allow me to rephrase with an analogy to illustrate: I can easily solve 90% of my problems perfectly well with just integers, reals and complex numbers, so why would I ever learn general vector or matrix math?

Certainly that's your perogative, but I hope you'll agree that you're ignoring a powerful tool that would subsume all of your previous understanding of these abstractions, and which would let you solve those same problems, and more, _better_.

</comment></comment></comment></comment><comment><USER18> I think that classes (in the school of OOP coming from C++ and Java) are incorrect abstractions. Here incorrect is in the eye of the beholder, but I would argue that tying the three fundamental principles of OOP (encapsulation, inheritance, polymorphism) into one abstraction leads to more problems than it solves.

In particular in Haskell, these things are separated into modules (encapsulation mechanism), abstract data types (inheritance mechanism) and type classes (polymorphism mechanism). But other modern languages have this separation as well, and it is cleaner.

Consider for example a common Java exam question, should you use interface or abstract class? This is a completely artificial problem that doesn't occur in languages that separate these abstractions orthogonally. Also another common exam question, access control (private, public, protected) is more complicated due to lack of the separation of encapsulation and inheritance principles.

Another example is Java is arguably much less readable than it could be because organizing all the code as classes makes code more difficult to follow (especially without IDE it's insanity of directories) - you don't know which classes are just utility types or simple functions and which actually contain the meat of the code. A properly organized module is much more pleasant to work with.

<comment><USER11> In Java, it is perfectly acceptable to have either a file containing the primary public class and any number of private utility and implementation classes, or just have a non-instantiatable enclosing class that works as a module and a bunch of interfaces, classes, and enums within it. Consumers then can then refer to them either by their Class.SubClass name or the shorter SubClass name.

<comment><USER18> OK, thanks! I didn't realize it is possible, I haven't seen code that uses this technique.

<comment><USER19> Typically nested classes in Java make it harder to follow what each class does, where it ends and starts. The files then tend to become too big and at worst end up cross referencing each others privates too much. At least, that is my experience with code that uses nested classes all the time and - I am slowly refactoring it to split classes into separate files.

</comment></comment></comment></comment><comment><USER20> Don't forget about Go:

        func Open(name string) (file *File, err error)

Your basic Optional/Maybe monad would have worked better here.

There is a lot of evidence supporting the fact that Rob Pike and company when inventing Go were not aware of Sum types indicating that this special Tuple return type (that can never be reused anywhere and must be pattern matched immediately after it returns) was created because of lack of knowledge and not as a design choice.

See this thread as evidence: [https://news.ycombinator.com/item?id=6821389](https://news.ycombinator.com/item?id=6821389)

<comment><USER21> Where did you learn (or, more generally, where do people learn) about those Sum types?

The Wikipedia page for "Sum type" redirects to "Tagged union", implying those are synonyms; do you agree with that?

Sadly, that Wikipedia page only seems to refer to pages specific to some programming languages.

Could you maybe recommend an introductory book about type theory, preferably with an orientation to how it can be applied to language design? EDIT: or maybe a programming language theory book? To be honest, I am mainly interested in imperative languages, basically how could a better Go have been made.

<comment><USER22> Types and Programming Languages[0] by Benjamin C. Pierce is a good introduction to type theory and programming languages.

[0] [https://www.cis.upenn.edu/~bcpierce/tapl/](https://www.cis.upenn.edu/~bcpierce/tapl/)

</comment></comment></comment><comment><USER23> My favourite example, because I've been working with it recently, is the nunjucks templating language. It has three or four different ways of almost- but-not-quite implementing functions. It has dynamic scoping (hello, 1960s!) But my favourite feature is its recursive for-loops. These are truly majestic. I would not believe someone could implement a language so broken if I had not witnessed it.

</comment><comment><USER24> Good link: [https://old.reddit.com/r/haskell/comments/glz389/examples_of...](https://old.reddit.com/r/haskell/comments/glz389/examples_of_incorrect_abstractions_in_other/)

</comment><comment><USER25> This reminds me stdout's fine tune: My language is better than your language. It captures a lot of what this thread is about.

</comment><comment><USER26> I never understood the complaint about generators. Languages can have both light-weight laziness (like generators) and more heavy abstractions (like scheme's srfi-41). The overhead of generators in, say, JavaScript is minimal. If you want odd lazy lists, generators is a great thing to use to build it. Generators and streams (as in scheme's SRFI 41) are not mutually exclusive.

</comment><comment><USER27> If Unicode were a monad, Haskell would have gotten String right.

</comment><comment><USER28> Null and exceptions. (in Haskell, Maybe and Try/Either)

<comment><USER29> Nothing beats pattern matching on Maybe for exception or null handling, or variations of such (Rust's Option). It's just so clean syntactically.

<comment><USER30> I'd argue that nullable type with refinements as in flow for example beats Maybe most of the time. You can't make it simpler (one letter ? overhead) without special unwrapping constructs (refinements) just normal code with same guarantees.

<comment><USER6> Refinement typing is too complicated IME. Haskell guarantees that you can always pull out an expression into a function without changing anything, and vice versa, whereas with refinement types you can extract a function and find your code no longer compiles.

</comment></comment></comment></comment><comment><USER31> I was thinking just yesterday while casting an int32 to a uint64 that theres no guarantee the int32 wasn't negative beyond my knowledge that the code was only ever incrementing it, and how most languages (that I have worked with at least) allow dangerous casting without enforcing any sort of error handling on the given operations.

I think this would fall into this category.

<comment><USER32> You should definitely have a go at rust where this conversion would have to be done explicitly via `try_from` [0] which may fail.

[0]: [https://doc.rust- lang.org/beta/std/convert/trait.TryFrom.htm...](https://doc.rust- lang.org/beta/std/convert/trait.TryFrom.html)

</comment></comment><comment><USER33> This classic contains a lot of them: [https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

</comment><comment><USER34> It's threads like this that remind me how little I know...

<comment><USER35> A lot of Haskell jargon is just simple everyday concepts dressed up with complicated neologisms.

<comment><USER36> Could you give an example?

<comment><USER37> Monad. It's just a very generic container. You can put things into it (unit/pure/return/bind) and you can do things within it (flatmap). Sometimes it's an effect or control flow container (Try, Future, Result, Either, Maybe, Option), sometimes it's just a List.

And then there's cata (catamorphism), which is the generic reduce/fold/accumulate/aggregate.

And then there's bifunctor, which is the general Either, Result, or List[(A,B)] thingie.

These concepts are very useful, but usually typed FP code nowadays are full of compromises in the name of typing. Typed FP code is constrained by what the type system allows.

This eventually boils down to everything becoming for-comprehensions / do- notations. Which is fine after you get the hang of it. But it's very easy to run into real world problems that require "hacks" or inelegant solutions, or forces the correct solution, which is very time consuming.

<comment><USER36> Monad has a specific set of mathematical rules, though, which have important properties which make them well-suited for some very specific tasks, including defining the semantics of programming languages.

I'm not aware of any "simple everyday concept", or anything in any mainstream programming language, that comes close to being equivalent to what monads are. You can find examples of specific monads being used (and misused) in many ordinary programs, because of their deep connection to programming language design, but they're never explicitly identified as such, partly because most languages can't conveniently make use of an abstraction like that.

Similarly, there's more to catamorphisms than what you describe. What you described is essentially what the generic mathematical concept of a catamorphism looks like in a specific context, but that's like saying that the term "vehicle" is just the simple everyday concept of a bicycle dressed up with a complicated neologism.

Something similar goes for bifunctor. `Either` is an example of a bifunctor, but it's also an example of a functor. Conflating the generic concept with specific instances will mislead you.

The point about this terminology, and the concepts it represents, is that it classifies these abstractions with precise rules, allowing the commonality across many different abstractions to be identified and exploited in well- defined, rigorous ways.

You don't find that in mainstream programming languages or the literature about them. The closest you'll come is things like object-oriented collection class hierarchies - Collection / List / Set / OrderedSet etc. That kind of classification is analogous to the sort of terms we're discussing, but is nowhere near as well-factored or mathematically rigorous.

> This eventually boils down to everything becoming for-comprehensions / do- > notations.

What language are you thinking of? Sounds like Scala maybe. Unfortunately I think Scala was a mistake from the point of view of introducing functional programming to a wider audience. The object/functional mixture results in a kind of worst of both worlds that doesn't show off the benefits of either to best effect.

> usually typed FP code nowadays are full of compromises in the name of > typing.

> But it's very easy to run into real world problems that require "hacks" or > inelegant solutions, or forces the correct solution, which is very time > consuming.

Perhaps you've had this experience from experimenting with functional languages, but it's not my experience from actually using languages like Haskell and OCaml in real projects for many years. I'm also very experienced with many mainstream languages - Java/Javascript/C/C++/Python etc. - and I find functional languages to be models of elegance by comparison. Statically debugging code by designing the types well ("make illegal states unrepresentable") is a huge timesaver when it comes to avoiding bugs and making significant changes to large codebases easier.

There's a lot of research on extending the power of type systems, which it seems like you may be thinking of, but for most ordinary purposes, you don't need to worry about that.

<comment><USER37> Of course, Haskell is right, the jargon is precise. That doesn't mean underlying concepts are not what everyday programmers use. The jargon has given proper names to the general concepts, it reified them, made them first- class citizens.

I'm not saying they are not useful. (On the contrary, they are invaluable for high level discussions about certain aspects of programming, including control flow, data structures, and programming techniques.)

Every async/await implementation is basically a monad with fancy syntax.

> Conflating the generic concept with specific instances will mislead you.

Yeah, agreed, no questions there. I'm just saying that the vast majority of programmers are nowhere near prudent enough to appreciate the strength of a correct/lawful system, plus they usually have other powerful concepts in their heads (after all there are many C programs that are sort of correct but not easily written with standard, total, and sound types, plus the required assumptions are not expressed in the source code). Also, another angle I think might help to convey what I'm trying to say is to look at how much jargon is needed to explain things like for-comprehensions execute the monad steps in sequence, but if you use mapN and an applicative then you can execute independent steps in paralell. Whereas it's just "race the futures" (or Promise.all, or whatever) in common programming parlance.

> Perhaps you've had this experience from experimenting with functional > languages [...] > What language are you thinking of? Sounds like Scala > maybe.

Yes, I don't know Haskell, I have a few years of Scala with some Scalaz experience. And maybe you're familiar with mypy and TypeScript, and it's obvious how problematic is to build the bridge between existing semantics and a correct/sound type system. (And of course, it's very much impossible, because you either have soundness or not, and so TS is unsound to be useful, and mypy is useless unless you rewrite many things.)

> [...] and I find functional languages to be models of elegance by comparison

I haven'got the hang of any pure functional language (yet?). I like to think it's not because of lack of trying. I see where concepts can be useful (eg. how TS and Rust would benefit from HKT, and how many people are waiting for a more expressive type system to create better abstractions, better libraries, better APIs), but to me all Haskell code looks like something like a dadaist poem with strange symbols sprinkled here and there.

(Eg I'm looking at the sample app for miso [https://github.com/dmjio/miso#sample- application](https://github.com/dmjio/miso#sample-application) and I have no idea what is what, no idea about shapes, what's <#, what's >>, why div_ and button_ have underscores after them, why div_ takes an empty list, what's {..}? And sure, most of these can be found, but still a lot harder than even the most damned FactoryFactoryBean in Java.

And sure, I appreciate that lenses and the Transition interface helps with stuff, but that's simply a very small incremental ergonomic enhancment compared to what I wish.

Similarly, when I look at servant's documentation I wonder how come a such powerful language, but to model 'GET /user/:userid' it can't - or doesn't - use /user/:userid, but "user" :> Capture "userid" Integer. The type is nice, and whatever :> is, I'm sure that's nice too, but I'm not finding the elegance that TSed has - [https://github.com/TypedProject/tsed#create-your-first- contr...](https://github.com/TypedProject/tsed#create-your-first-controller) )

So, all in all, I'm just a lazy party-pooper when it comes to Haskell (or FP in general). And mostly just because the pain of debugging TypeScript and the myriad "any"-s everywhere still seems the lesser one than trying to grok the the cryptic symbols.

<comment><USER36> > I'm just saying that the vast majority of programmers are nowhere near > prudent enough to appreciate the strength of a correct/lawful system

That seems like a failure of education. Imagine if we put up with bridges that collapsed because "most engineers are nowhere near prudent enough..."

People use what they were taught to use. Programming languages form part of that teaching. Bad programming languages teach people bad habits.

> after all there are many C programs that are sort of correct but not easily > written with standard, total, and sound types

For example? I suspect there's a kind of all-or-nothing mentality behind this. I would bet you can easily write the sort of programs you're thinking of in a good functional language, if you don't get hung up on perfection. It would still be a significant improvement. There are many examples of this - <USER2> comes to mind, which you can compare to i3 which is written in C.

It seems to me that most of what you're saying boils down to simple unfamiliarity. I would suggest that you're suffering from a kind of inverse expert blindness. You discount the amount of learning that went into your ability to understand a phrase like "race the futures," and this leads you to reject systems that are different enough that you can't easily apply that existing expertise to.

Your difficulties in reading miso code without, apparently, consulting _any_ documentation is a little silly, I'm afraid. What programming language, that is significantly different from the ones you already know, allow you to read its code without any background knowledge?

If you're actually working with the language, there are easy ways to answer all the questions you're asking. Short of _gasp_ reading the docs, you can query the functions or operators you're interested in at the ghci prompt. For example:

        > :t div_
        div_ :: [Attribute action] -> [View action] -> View action

This helpfully points out that the first argument to `div` is a list of Attributes. If there are no attributes, that list would be empty.

That wasn't so hard!

You could also read the docs: [https://hackage.haskell.org/package/miso-18.104.22.168/docs/Miso-H...](https://hackage.haskell.org/package/miso-220.127.116.11/docs/Miso- Html-Element.html#v:div_)

Or look it up in Hoogle: [https://hoogle.haskell.org/?=&hoogle=div_%20package%3Amiso](https://hoogle.haskell.org/?=&hoogle=div_%20package%3Amiso)

> Similarly, when I look at servant's documentation I wonder how come a such > powerful language, but to model 'GET /user/:userid' it can't - or doesn't - > use /user/:userid, but "user" :> Capture "userid" Integer

It's expressing the route in the language rather than in an untyped string. :> is just the operator servant defines to separate route components. But here (and in some of your other observations) you seem to be conflating a decision that the servant authors made, with the language itself.

> So, all in all, I'm just a lazy ...

That's your choice. You should just know that your critiques are off the mark - they're the stories you're telling yourself to justify not having to learn.

<comment><USER37> Thanks for responding! I really wasn't hoping you'd think my rambling is worth responding to.

> Imagine if we put up with bridges that collapsed because "most engineers are > nowhere near prudent enough..."

Most developers don't develop nuclear reactor control software.

And I'm saying this, not because your statement about education is wrong, but because there's a cost-benefit analysis going on, and traditionally correctness was too expensive. This is due to insufficient tools, a very strange mindset ("That seems like a failure of education."), plus the path- dependence of the real world (the whole history of computer programming somehow led to a lot more close-to-the-metal imperative code and programming languages than "here are the correct abstractions and let's see how far can we go with them" ones). Also, as far as I know we need dependent types to be able to easily model a lot of invariants that would help with many kinds of programming errors. (Of course validating safely composable components would go a long way - like that project targeting some subset of Rust, but that's basically what static analysis is. And there's a whole industry that tries to bolt-on this kind of correctness verification after the code has been written.)

...

All in all, I'm simply pointing out that the Haskell ecosystem is still not exactly approachable. You say it's because education, and people's choices, and other reasons. (Which is tautologically true.) But that doesn't help much. In my experience programmers get better when tools get better, and it makes sense to learn them, when it gives them sufficient value. (Correctness, productivity, ergonomics, performance, hipness and whatnot, and all of that on a reasonable time-horizon.)

This whole comment thread started out from talking about jargon, and about the value of having mathematically exact, precise (correct) concepts as definitions used for everyday programming, and my observation is that programmers and programming as an occupation don't have the need/want for such high level concepts and correctness, and on top of that, even if everyone wants better programming tools, somehow the obvious answer isn't rewrite it in Haskell. Maybe the gap is [stil] too big [in the average case]. Maybe the very strong static typing, and pure FP (and the basically necessary immutability) and jargon, and unfamiliarity is still too constraining, too "expensive" to learn and use.</comment></comment></comment></comment></comment></comment></comment></comment>


Practical Neural Networks with Keras: Classifying Yelp Reviews - <AUTHOR> http://www.developintelligence.com/blog/2017/06/practical-neural-networks-keras-classifying-yelp-reviews/ <comment><AUTHOR> Author here - Obviously there are a bunch of Keras text classification tutorials out there already, but I tried to take a more practical focus here than what I usually see.

* I use real data instead of the preprocessed IMDB dataset. This makes it easier to adapt to your own text as all the preprocessing code is included

* I explicitly shows how to reuse classifier on new data (most posts I see stop after getting a test set accuracy)

* I explain each piece of code in detail to make it easier to adapt to your own needs instead of treating it as sa black box (corrections welcome, I'm still learning too).

Feedback appreciated!</comment>


Nokia discloses their patents on VP8/WebM - <AUTHOR> https://datatracker.ietf.org/ipr/2035/

<comment><AUTHOR> A little while ago, Google reached an agreement with MPEG-LA where MPEG-LA would stop claiming that its members had patents that covered VP8, so it seemed that VP8 was patent-clean after all.

However, the IETF is currently trying working on the WebRTC effort for standardizing Skype-style audio and video conferencing via web-browsers. They have already standardised the Opus audio codec for audio-conferencing, and now they're trying to find a suitable video-codec. VP8 was the obvious choice, but now Nokia (who is _not_ a member of the MPEG-LA, and so is not covered by MPEG-LA's agreement with Google) has come forward with a list of patents they hold, which they claim cover VP8.

I don't know much about these patents, I don't know whether they do or don't cover VP8, but it's big list with patent-numbers in it, which is far more concrete evidence than MPEG-LA was ever able to muster.

<comment><USER2> I find it interesting, that if they are not part of MPEG-LA, somehow these patents apply to VP8, but don't apply in any way to H264? Does that mean that most commercial MPEG-LA licensees also do separate deals with Nokia, or that by sheer coincidence, this boatload of patents manages to cover VP8 but does not intersect H264? It smells kind of funny, like there's an alternate motive besides looking for royalties.

<comment><USER3> MPEG-LA doesn't claim to have all possible H.264 patents in their patent pool. Nokia has an FRAND obligation for H.264, so it's obligated to license on fair, reasonable and non-discriminatory terms, but it has chosen not to be part of the pool.

MPEG-LA did not claim to have all possible VP8 patents either.

Note that MPEG-LA is basically a group that sets up convenient one-stop licensing, there's no such thing as being a "member" per se. You can be part of any of their patent pools, or not, if you believe you have essential IP.

<comment><USER2> No they did not claim to have all the patents, nor do I expect Google made this assumption (there's a never ending list!), but the timing is very curious. What does Nokia really want out of this if they are not interested in licensing under any circumstances?

This is not the first time Nokia did this. IIRC, they also threatened Ogg when it was being proposed as the mandatory codec for the <video> element.

Certain companies that have large installed bases of H264 hardware certainly have a vested interested in seeing H264 as the mandatory WebRTC codec.

<comment><USER4> Has any party actually proposed h.264 being made mandatory to implement for WebRTC?

<comment><USER5> Yes, Nokia, Cisco, Apple, Microsoft, Ericcson, RIM, France Telecom/Orange, Qualcomm.

[http://datatracker.ietf.org/doc/draft-dbenham-webrtc- videomt...](http://datatracker.ietf.org/doc/draft-dbenham-webrtc-videomti/)

IETF's royalty-free commitment isn't as strong as W3C's so unlike the HTML5 codec were they were just filibustering alternatives, they are actually arguing for H.264 to be MTI. But the VP8 camp is strong enough to at least prevent that, even if not strong enough to prevail as MTI itself.

There's some overlap with the groups that didn't want Opus made MTI as well (one of them submitted a patent against it too).

</comment></comment></comment></comment></comment></comment><comment><USER2> From the ietf mailing list: "The declaration says that Nokia is not prepared to license the listed patents for RFC 6386 under any terms."

Deja Vu: <http://boingboing.net/2007/12/09/nokia-to-w3c-ogg-is.html>

Things that make you go hmmm.

</comment><comment><USER6> Is it too far fetched to wonder if Nokia is fighting on behalf of MS? In the end Nokias CEO comes from MS, Nokia is very dependant on MS nowadays and MS has a strong interest in H264, is a member of MPEG-LA and earns money from every H264 license?

All that software patent bullshit needs to stop, already, it's sickening!! It's the <video> tag discussion all over again. Why can't we have royalty- free, free-for-all codecs in an OPEN worldwide standard?! Because stupid companies like Nokia, MS or Apple are NOT acting on behalf of the users but on behalf of their own income.

And don't start with "but h264 has so much better quality!" No normal person could tell the difference between a proper vp8 encoded FullHD youtube video and a h264 one, it's not like there are glaring differences!

<comment><USER7> >> _And don't start with "but h264 has so much better quality!" No normal person could tell the difference between a proper vp8 encoded FullHD youtube video and a h264 one, it's not like there are glaring differences!_

The glaring difference is in the ubiquitous hardware encoder/decoder support, which in itself is more than enough reason to prefer H264 anywhere. I'd be really happy if everyone should finally stop beating the dead horse that is VP8, because as it stands it never served any other purpose than channeling unfounded bias against H264 because it is not 'free' enough for some people to comprehend, even though neither industry nor consumers have ever made a big problem out of this. A bit like no-one ever bothered to complain about the fact that there are millions of other technologies in widespread use that aren't royalty-free. The fear-mongering and FUD about MPEG-LA as if they are some kind of extortionist codec mafia really has been mind-boggling from day 1.

<comment><USER6> There will never be an alternative the way it is today. One of the reasons the MPEG-LA exists is to prevent and supress competition, don't you think? The whole concept is bullshit.

I tell you how i see it: In a world without MPEG-LA (even without h264) there would still be good video codecs. There are plenty out there (e.g. VP8, VP9, Dirac and what not). They were created like many other codecs and standards and still they can exist, there is no need for the MPEG-LA! The only purpose the MPEG-LA has is to prevent competition (and thus prevent choice for the endconsumer, for me!) from entering the market. And even without the MPEG-LA and the licensing model (and the obvious patent trolling behaviour in the past) there is enough money to make for codec implementations and content creators. Why can't it be that way, that we have a "free" codec (as i've said, there are alternatives) without the licensing and yet we can still have a whole industry around them. Hardware chips could support a free codec and h264. The W3C could recommend a free codec for HTML5 video and webrtc. Software companies that write encoding/decoding software could even earn more money (no fees) and would thrive on competition and not rely on suppression/patent trolling. I think that everyone (meaning the customer!) would win, if the MPEG-LA (and other patent trolls) would be shut down, you'll have a hard time to convince me otherwise.

I couldn't care less about the "hardware decoder/encoder support" argument, because it's a symptom of all that MPEG-LA crap, not a reason. Everything the MPEG-LA works for is to make sure there will only be that one video codec. They will also make sure that only H265 will get enough hardware support (see, 2 codecs in one chip, is this even possible you say!?).. And on it goes, it's a kind of monopoly and one that knows how to play the game and keep earning money.

The point that there are "other technologies in widespread use that aren't royalty-free." is not an argument, it's just a sad fact. In general there are alternatives available and in general i don't see such a patent abusing behaviour in other areas.

<comment><USER3> Keep in mind that MPEG (which defines codecs) and MPEG-LA (which gives you one-stop shopping for some of the patent licnses) are completely separate entities.

MPEG-LA even arranges patent licensing for some codecs not developed by MPEG, such as SMPTE VC-1.

They may have a vested interest in the royalty-bearing license regime but not necessarily in supporting any given codec family.

</comment></comment></comment></comment><comment><USER8> "Unwilling to Commit to the Provisions of a), b), or c) Above" refers to the following from the IETF's template for patent disclosures and licensing declarations[1]

a) ___ No License Required for Implementers

b) ___ Royalty-Free, Reasonable, and Non-Discriminatory License to All Implementers

c) ___ Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee

[1] <http://tools.ietf.org/html/rfc3905>

</comment><comment><USER9> This seems to be a commendable action (even if it is forced by the standards body) to me - come forward with what patents you have publicly and then it can be resolved.

Contrast to Microsoft who claims mysterious patents on Android and refuses to disclose what they are purposefully to create and aura of FUD and prevent any resolution. With these patents in the open, Google can work around them, license them or dispute their infringement directly.

<comment><USER10> All patents are by definition, publicly viewable. But you may be right in that figuring out which patents are associated with which technologies can be hard when companies have thousands of them.

One would think that Google would on average be better at searching through a large database of patents than any other company, though.

<comment><USER11> Most of the patents in question probably read more like "method to send video over a network" than technical documents. _Everyone_ in the space has some. What they are disclosing is which ones they intend to make a nuisance over.

</comment></comment></comment><comment><USER12> Another example of how patents harm innovation and in particular open-source software: years of video codec innovation by Google and On2 are now being pirated by Nokia using these patent threats. Note that many of the countries where they claim to have been granted patents do not, in theory, allow software patents at all.

<comment><USER4> VP8 was developed as patented proprietary technology by On2, and the only innovation since Google purchased the company has been picking a container format.

It might be solid gold in every other respect, but it's not a very good example of open source innovation or of patents harming innovation.

<comment><USER12> Indeed, but On2's patents on what they invented are not shielding Google from the expropriation of their work by Nokia, using other patents. It seems to me that, while patents are perhaps intended to secure your ownership of your invention, in this case they are calling On2's ownership of On2's invention into question, and the patents On2 filed are not helping at all. If patent offices had simply rejected all the related patent applications out of hand, Google would now be in a much better position.

<comment><USER5> That's one of the mental traps of the term "Intellectual Property", it doesn't protect what you own, it only allows you to stop other people from doing things (and therefor charge them in order to get your permision). But other people can use the same mechanism to stop you doing things with your own "property". That's why the asymmetric warfare of patent trolls works so well, they don't actually do anything you can interfere with via your IP.

<comment><USER12> To put it another way, patents work to prevent innovation, but they don't work to protect innovation.

</comment></comment></comment></comment></comment><comment><USER13> I wonder if Google will be able to use its own patents on VP8 to pressure Nokia into a deal. As I understand it, Nokia lost its license when it sued HTC in Germany over VP8 technology[1], since the WebM licensing terms say:

 _If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross- claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed._ [2]

Of course Google only gets leverage from their VP8 patents to the extent that VP8 is used...

[1] [http://www.ietf.org/mail- archive/web/rtcweb/current/msg06704...](http://www.ietf.org/mail- archive/web/rtcweb/current/msg06704.html)

[2] <http://www.webmproject.org/license/additional/>

<comment><USER14> As long as the Qualcomm application processors don't support hardware based VP8 decoding, Nokia probably won't care.

The day that mainstream application processor vendors support hardware based VP8 decoding, this will change.

</comment></comment><comment><USER15> It seems we have some very strong forces who will do everything they can do to prevent an open, standards-based and DRM-free video-protocol to become part of the internet.

We should shun them absolutely in every way we can.

Anyone who supports WebDRM: Boycott.

Anyone who patent-trolls: Boycott.

</comment><comment><USER16> This is what happens when a company stops having anything relevant to contribute and just becomes a bag'o'patents.

<comment><USER17> >stops having anything relevant to contribute

You mean like Lumia Phones, Nokia Maps, Nokia Free Music...

I love their apps and hardware but I do however disagree with their stance on enforcing unnecessary patents!

<comment><USER18> Nokia's still little more than a blip on the smartphone radar. Their alliance with Microsoft was an effort to save their smartphone division, and it's affecting other areas of their business. First they laid off the entire Qt team, now they're attacking open standards. It's like SCO all over again.

<comment><USER19> SCO worked out pretty well for Microsoft the first time. Years of distraction from a dead company, they got to pay off David Boise in return for his dropping the anti-trust case, and nobody successfully followed the money trail back to Microsoft in any way that mattered.

Why wouldn't they try to do it again?

<comment><USER18> _Why wouldn't they try to do it again?_

Indeed, but it still makes me wish I were born on Mars or something.

</comment></comment></comment></comment></comment><comment><USER20> A Nokia spokesman is quoted in this article: [http://www.fosspatents.com/2013/03/nokia-comments-on- vp8-pat...](http://www.fosspatents.com/2013/03/nokia-comments-on- vp8-patent.html)

as stating

"Nokia believes that open and collaborative efforts for standardization are in the best interests of consumers, innovators and the industry as a whole. We are now witnessing one company attempting to force the adoption of its proprietary technology, which offers no advantages over existing, widely deployed standards such as H.264 and infringes Nokia's intellectual property. As a result, we have taken the unusual step of declaring to the Internet Engineering Task Force that we are not prepared to license any Nokia patents which may be needed to implement its RFC6386 specification for VP8, or for derivative codecs."

So their position is that since VP8 does not offer any technical or licensing advantages over H.264 (Nokia being at least one company that owns or claims to own patents on it), they're going to use their patents to prevent Google from promoting VP8. At this point, I don't see why any reasonable person would still want to use H.264 over VP8.

<comment><USER2> In other words, this isn't really about innovation or "theft of ip", but suppressing competition, more evidence of the abuse of the patent system.

As to why a reasonable person would want to not use H.264? It's simple. Organizations like Mozilla cannot ship software with IP encumbered codecs. WebRTC doesn't say that you cannot use H.264, it allows you to negotiate the codec, this debate over what is the minimum fallback codec that everyone has to support.

Given that Microsoft/Skype/Nokia have been against the IETF WebRTC proposal, you can gather for very good business reasons. A non-IP encumbered spec widely deployed would be a threat to Skype/Cisco/Nokia et al who have commercial video conferencing stuff, it would commoditize the market for video chat and make it a trivial matter.

The established players only have to gain by delaying an open spec. I think even if H264 were used over VP8, there Microsoft and others would find other reasons to stop it.

<comment><USER20> Well, I guess it looks like they're suppresing competition, but if Nokia's correct that they own patents on VP8, then VP8 is patent encumbered and promoting it just creates fragmentation. This argument seems kind of tautological if Nokia's the only company with patents on VP8 that Google does not have a license to, but otherwise it seems reasonable. They could offer to license their VP8 patents at the same cost they offer their H.264 patents at, but instead they're choosing not to license them at all. What other motive would they have for "suppressing competition" if they could charge the same to license their patents either way?

<comment><USER2> Realistically, everything is patent encumbered. It's probably impossible to write anything that has more than 1,000 lines of code that isn't. That's not a good argument for defeating a spec, it's a good argument for opposing patent trolling and reforming the patent system.

Clearly, Nokia, which used to be a leader in the mobile market, is on is on a downhill slide and like Kodak was with film, and is turning to their patent portfolio to slow down the slide into the abyss. This is typical in the industry, when companies start losing marketshare to competition, they start getting litigious.

For example, they are suing HTC over a 1995 patent on "tethering". Really? The entire internet going back to the 80s is about tethering. I used to tether my Amiga off of a PC via a null-modem cable to get internet access. This is a pretty offensive patent, in the "disgusting" sense. Apple similarly sued poor old HTC over a 90s patent on using regular expressions to detect phone numbers in a page and make them clickable.

Legal or not, the whole idea of "ownership" of this kind is deeply disturbing to me. The new generation of entrepreneurs have to contend with an environment that was far more litigious than it was in the dawn of personal computing, and often the very same players who benefited early on by lack of trolls, are now some of the biggest.

The only glimmer of light for me is that by the time my son is old enough to make his way in the world, most of this crap will have expired.

</comment></comment></comment></comment><comment><USER21> Links to US, European and Canadian patents [http://mdpaste.appspot.com/p/agdtZHBhc3Rlcg0LEgVQYXN0ZRjJoxY...](http://mdpaste.appspot.com/p/agdtZHBhc3Rlcg0LEgVQYXN0ZRjJoxYM)

</comment><comment><USER22> Google just killed Reader. How long before it will kill VP8?

<comment><USER23> Oh this is just getting silly now.

"How long before it will kills x?" is becoming the new "What ever happened to 'Don't Be Evil'?".

A lazy incantation trotted out by people who haven't really thought out whether it applies to the situation under discussion in any sensible way.</comment></comment>


Dreamliner spells out "787" & Boeing logo over US during test flight - <AUTHOR> http://flightaware.com/live/flight/BOE236/history/20120209/2100Z/KBFI/KBFI <comment><USER2> Similar attempts:

Gulfstream V: [http://flightaware.com/live/flight/GLF17/history/20070206/15...](http://flightaware.com/live/flight/GLF17/history/20070206/1538Z/KATW/KATW)

Cessna Logo: [http://flightaware.com/live/flight/N750CX/history/20080307/1...](http://flightaware.com/live/flight/N750CX/history/20080307/1745Z/KICT/KICT)

Boeing 747: [http://flightaware.com/live/flight/BOE523/history/20110802/1...](http://flightaware.com/live/flight/BOE523/history/20110802/1330Z/KPAE/KPAE)

Also, a thread from one of the pilots: [http://flightaware.com/squawks/view/1/7_days/popular/24611/B...](http://flightaware.com/squawks/view/1/7_days/popular/24611/BOE236_787_performing_a_787_with_a_logo#36259)

Interestingly, this required a lot of work on our side to pull this off. Since the route field on flights plans expects short input and this flight's route is dramatically longer, it caused an FAA system to split the flight arbitrarily into different legs.

(Disclaimer: I work for FlightAware)

<comment><USER3> I'd just like to say: Thanks for running such an awesome site!

I use FlightAware to hack airlines by trying to locate the incoming flight that is to be my outgoing plane. Any plane landing ~60 minutes before my departure whose make and model matches my flight is a suspect. I can usually predict whether or not we'll have an on-time departure long before announcements are made.

<comment><USER2> On some flights, we actually know what the corresponding inbound flight is. If we know, we show a small "track incoming flight" link and consider it in our delay prediction algorithms.

</comment></comment></comment><comment><USER4> I actually posted this about 16 hours ago (<http://news.ycombinator.com/item?id=3574619>) and I point this out because it's always fascinating to me when the "right" time to post something on different sites is.

For example, I believe days start at 8pm PST on Flickr (can anyone correct me if I'm mistaken) and there's a power-user perspective that will wait to post things so that they can get a leg up on the "interestingness" algorithm.

Anyhow, this post makes me smile even the second time around.

<comment><AUTHOR> (doh, wrote a long reply with thoughts a few hours ago from Hacker News Beta mobile app and it didn't post...fail)

sorry man, it was just the link I got. I'm all for first poster credit and respect, just sometimes same content can be generated from multiple links etc and stuff gets messed up. Annoying but you know how it goes.

On the time of posting thing...I know someone created a site to determine the optimal posting time for HN.... I have never used it tho! It's just naturally there'll be hotspots in the day based on simply where the majority of HN readers are from and the waves of social network activity.

Anyways, a good link indeed. A fun Friday afternoon share -- Great that the FlightAware guys are watching this and contributing too.

<comment><AUTHOR> ah, the 'tool' for optimal HN Pickup. Still interesting when you look at it. <http://hnpickup.appspot.com/>

Also, re: titles -- yeah, descriptive titles always -- I try to do that, since I appreciate it when others do

</comment></comment></comment><comment><USER5> The test pilots are basically told what part of the world and for how long they have to fly; when they turn in a plan like this basically for the sake of cuteness, that's a lot of work picking waypoints.

This pleases me.

</comment><comment><USER6> There were some others:

[https://flightaware.com/live/flight/GLF17/history/20070206/1...](https://flightaware.com/live/flight/GLF17/history/20070206/1538Z/KATW/KATW) [http://flightaware.com/live/flight/N750CX/history/20080307/1...](http://flightaware.com/live/flight/N750CX/history/20080307/1745Z/KICT/KICT) [http://flightaware.com/live/flight/BOE523/history/20110802/1...](http://flightaware.com/live/flight/BOE523/history/20110802/1330Z/KPAE/KPAE)

</comment><comment><USER7> Question for people with more aviation knowledge than me: Don't games like this make life hard for air traffic controllers? 35000' is right in the middle of normal airspace; isn't it much easier if planes are flying along standard routes between airports?

<comment><USER8> This flight got up to 42,000 feet if you look at the elevation graph. I didn't know planes flew that high.

<comment><USER9> <[http://www.messybeast.com/dragonqueen/cockpit- chatter.htm...](http://www.messybeast.com/dragonqueen/cockpit-chatter.htm>); (Flight level is x10000, so FL600 is 60,000 feet)

SR-71 Blackbird was crossing the control-zone of London Control. Evidently the controller didn't know the service ceiling of this aircraft is around 30,000 metres (yes metres, not feet!). There are so many variations on this item that the original event has evidently become part of aviation folklore or joke- lore.

Pilot: "Radar, Good Day, Airforce Blackbird, request FL 600(!)"

Controller (amused): "Sir, if you can reach, you are cleared FL 600"

Pilot: "US Air Force Blackbird, leaving FL 800, descending Level 600..."

<comment><USER10> So many good stories about that bird.

One of my favorites:

[https://groups.google.com/forum/?fromgroups#!topic/rec.aviat...](https://groups.google.com/forum/?fromgroups#!topic/rec.aviation.stories/ueI6JKeEomo)

"There were a lot of things we couldn't do in an SR-71, but we were the fastest guys on the block and loved reminding our fellow aviators of this fact. People often asked us if, because of this fact, it was fun to fly the jet. Fun would not be the first word I would use to describe flying this plane. Intense, maybe. Even cerebral. But there was one day in our Sled experience when we would have to say that it was pure fun to be the fastest guys out there, at least for a moment. ..."

</comment></comment></comment></comment><comment><USER11> Reminds me of the 'biggest drawing in the world' viral image that went around a while back, which later turned out to be a hoax: <http://www.wired.com/gadgetlab/2008/05/artist-says-he/>

Pretty cool that someone actually did it though!

</comment><comment><USER12> A 19 hour flight? How was this even possible without running out of fuel?

<comment><USER13> Newark - Singapore (Singapore Airlines Flight 20) is regularly scheduled for 18hrs and 50mins.

Wikipedia has a good list of long, regularly scheduled, non-stop flights: [http://en.wikipedia.org/wiki/Non- stop_flight#Currently_sched...](http://en.wikipedia.org/wiki/Non- stop_flight#Currently_scheduled_.28top_30.2C_by_distance.29)

EDIT: Flight is SQ21, not SQ20

<comment><USER14> 19 hours on a plane must be quite a sufferfest. I do Europe->Oregon every year or two and 12 hours is already agonizingly slow. About the time you're thoroughly sick of the movies, reading, drinking or anything else, you realize you still have another 4 hours to go.

<comment><USER15> When Quantas had a San Francisco -> Sydney non-stop it was 14+ hrs. It was the longest flight I had been on up to that point. Fortunately I was in business class and could stretch out, but I remember watching two movies, taking an 8hr "nap", and then STILL having another 2hrs of flying to do. A looooooooooooong way to go.

<comment><USER16> Business class is a lifesaver for long-haul flights. I can't sleep unless I can (mostly) lie down; noise and motion aren't a problem, but I need a seat that reclines if the flight is going to cross more than four or so time zones.

Economy seats for most airlines have something like an incredibly generous 5" of seat travel, which is why I've caught up on all the movies that I didn't watch when I was younger.

Oh, and if I start reading (which includes hacking), I get motion sick. It's hell.

I'm genuinely envious of people that can sit and work in economy. It would be fantastic to be able to get some hacking in...

</comment></comment></comment></comment></comment><comment><USER17> Can't wait for the green-team to have their arms up about wasting fuel to do this (even though it's a scheduled test flight)

<comment><USER18> It's great to see them do something interesting while they're already in the air burning time/fuel on the new engine testing. The test flight would have occurred for the same duration regardless of the path. They needed a flight that was about 19 hours long for extended operation certification purposes.

<comment><USER19> 19 hours and _not over water_ which constrains them quite a bit. If they're going to run laps around the continental United States, why not make it fun?

<comment><USER20> Even with multi-engine they can't run over water for the certification?

<comment><USER21> It's a test flight, so you want to keep near some sort of airport in case something goes wrong. So yeah, you could duck over the ocean, but you really don't want to be flying in areas that could be problematic for too long in an untested plane.

</comment></comment></comment></comment></comment><comment><USER22> and here I was hoping they were stunt flying it.

</comment><comment><USER23> I can't wait to fly in one of these. The wings bow like crazy, can't wait to see them out the huge windows.

</comment><comment><USER24> WTF? Completely unreadable.

</comment><comment><USER25> This seems like a waste of fuel for a stupid publicity stunt. Airplanes dump so much carbon dioxide into the atmosphere.

<comment><USER26> They were going to be in the air for 19 hours as a test flight anyways. Who cares what the path looks like?

There's being environmentally conscious, and then there's being a green freak.

<comment><USER25> That's true, I was being a "green freak."</comment></comment></comment>


Ring 0 of fire: Does Riot Games' new anti-cheat measure go too far? - <AUTHOR> https://arstechnica.com/gaming/2020/04/ring-0-of-fire-does-riot-games-new-anti-cheat-measure-go-too-far/ <comment><USER2> It's important to know that Riot Games is 100% owned by Tencent, making it a Chinese company.

This doesn't even mean a grand conspiracy is required. They have an office in Shanghai, so it's trivial for the CCP to persuade a couple employees and leverage this as a kernel level backdoor into hundreds of millions of western PCs.

If you think this is unfounded speculation, remember US intelligence was accusing Karspersky with distributing malware for Russian state backed cyber operations just a number of years ago...

Or the recent BGP hijackings on US ranges that are transparently obvious by China Telecom.

</comment><comment><USER3> > "This isn't giving us any surveillance capability we didn't already have," > Riot noted in its blog post (using language that isn't exactly comforting on > its own). "If we cared about grandma's secret recipe for the perfect > Christmas casserole, we'd find no issue in obtaining it strictly from user- > mode and then selling it to The Food Network."

So not only are they injecting kernel level code and running it from boot, but they're being flippant about the level of control this gives them and downplaying the security implications here.

This gives me serious pause, because I have work on my gaming machine too, some of which is confidential client information, and confidential personal information as well. It's getting to the stage that games, a distraction, can't be trusted to be on the same machine as anything else.

<comment><USER4> > _It 's getting to the stage that games, a distraction, can't be trusted to > be on the same machine as anything else._

The iOS/macOS sandbox, for games purchased through the App Store/Apple Arcade, provides some degree of reassurance.

<comment><USER3> Unfortunately the continuing spat between Apple and Nvidia, and the lack of games available, make the Mac a path less travelled for gamers.

Which is a shame, I'd love to use it for more, but it's poorly supported.

<comment><USER4> I've been gaming on a Mac for years. There are many Windows-only games, but I don't really miss that operating system. Between native Mac ports and the Nintendo Switch/3DS, my gaming needs are well covered. When there's something I really badly want to try on Windows, I fire up CrossOver, Parallels, or Boot Camp, in that order.

Right now the GPU in my 2019 16" MBP (5300M) seems to be good enough for everything I want to play, and the 5500M is said to be even better. Of course the problem remains optimization for macOS which most ported games don't have.

Apple Arcade is actually a ray of hope, even for core gamers. There's some good stuff on it, give it a try.

Right now I'm going to remove anything Riot-related I find on my macOS installation.

</comment></comment></comment></comment><comment><USER5> For those who don't know, Riot Games recently released a closed beta of Valorant, their new game with this anti-cheat. Valorant is a direct competitor to Valve's CS:GO, borrowing it's core loop and even some of its weapons.

It's interesting to compare the two approaches to anti-cheat that the two companies are taking here:

* Valve use VAC, an unobstrusive memory scanner in user-space with an emphasis on never having false positives.

* Valve use machine learning on game replays to detect obvious aim-bots and spin-bots

* Valve enlists the community via the "Overwatch" program to review game recordings and spot cheaters.

* Valve supports CS:GO on Linux.

* Leveraging your Steam history, Valve creates a "Trust Factor" score for every player and keeps trusted players together.

* Riot uses ring-0 scanners.

* Riot will not allow you to run Valorant in a VM.

* Riot will ban specific hardware if a cheat is detected. Beware when buying 2nd hand motherboards!

* Riot does not allow you to host your own Valorant servers (this makes hack-vs-hack servers, which some people enjoy, impossible)

I think that in the long run Valve's approach, particularly with Trust Factor, will be proven the better of the two.

[https://www.youtube.com/watch?v=ObhK8lUfIlc](https://www.youtube.com/watch?v=ObhK8lUfIlc)

</comment><comment><USER6> [https://news.ycombinator.com/item?id=22855600](https://news.ycombinator.com/item?id=22855600)

[https://news.ycombinator.com/item?id=22230168](https://news.ycombinator.com/item?id=22230168)

[https://news.ycombinator.com/item?id=22870975](https://news.ycombinator.com/item?id=22870975)

</comment><comment><USER7> Apparently, the anti-cheat system is also blocking VMs from running the game [https://twitter.com/RiotSupport/status/1248402073269309441](https://twitter.com/RiotSupport/status/1248402073269309441)

<comment><USER8> I wonder if this also prevents running the game if you have Hyper-V or Hyper-V based technologies (Windows Defender protection, Container support, WSL2) installed. That would be a real bummer - because you can't game on your dev- computer then.

</comment></comment><comment><USER9> Its a rootkit. Hopefully microsoft pushes an update to remove it like they have done for other malware like this in the past.

</comment><comment><USER10> Some cheats are using PCIe FPGA boards to get access to game memory totally outside of the OS. The boards are controlled from a separate computer.

<comment><USER6> Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

You needn't use your real name, of course, but for HN to be a community, users need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. [https://hn.algolia.com/?query=by:dang%20community%20identity...](https://hn.algolia.com/?query=by:dang%20community%20identity&sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0)

</comment></comment><comment><USER11> The wonderful world of games running on your PC.

Recently I tried to get Dirt Rally 2.0 to run on my Linux gaming machine. Apparently, according to ProtonDB [0], the solution to get it to work is installing a fully trusted root-certificate from Codemasters on your system (not only in the Wine/Proton environment) [1].

In case you don't know, this means Codemasters can now man-in-the-middle every https connection from your computer. This is insane imho.

I tried to comment on that thread but they need full system information before you can post anything on ProtonDB.

[0]: [https://www.protondb.com/app/690790](https://www.protondb.com/app/690790)

[1]: [https://gist.github.com/PeXArtZ/020931f0182cafe84c623b5584da...](https://gist.github.com/PeXArtZ/020931f0182cafe84c623b5584da6f9a)

</comment><comment><USER12> I have a problem with it, even ignoring the Chinese influence or any direct spyware/vulnerability issues.

If it's seen as a good idea then soon everyone will want to do it and our computers will suddenly be back in the hellscape of 00's browsers. I don't want to know what my computer will be doing when 10 companies' kits are actively competing with each other, the OS, anti-virus etc.

</comment><comment><USER13> You know what they say about the cloud.

There is no cloud, it's simply somebody else's computer.

Welcome to the next level where even your personal computers is somebody else's.

</comment><comment><USER14> Isn't it trivial to defeat this type of AC? Grant your program SeDebugPrivelege and open a handle to the AC process. Inject away. NOOP any memory scanning routines.

<comment><USER15> The... ring0 process?

<comment><USER14> That's a good point. It will be a bit harder, but not entirely impossible. Position independent code/memory layout will complicate any attempts to modify the AC.

</comment></comment></comment><comment><USER16> How does that work with having say 2 copies of the same OS (Win) on the same computer? On 2 separate drives? If I have the game on one does the kernel access affects both or just one? Obviously I'm not an expert but I actually want to give a game a try but I'd not install just on its own as is. Apart from buying an other PC or waiting an eventual console release I wonder what else can be done

<comment><USER17> You can only have one running at once, so presumably the game simply won't run if it's kernel-level countermeasures aren't in place.</comment></comment>


Web graphics/designs - <AUTHOR>

Hello fam,as at late December I overviewed an interesting content that sprite my interest about "where graphics designers and webdevelopers get there images from"..Didn't save d URL,wouldn't mind should I get that content back please...Thanks a lot. <comment><USER2> maybe [https://news.ycombinator.com/item?id=7046263](https://news.ycombinator.com/item?id=7046263) ?</comment>


Show HN: Uplisting – a property management tool for Airbnb hosts - <AUTHOR> http://www.uplisting.io/ <comment><AUTHOR> Just launched. We're offering 6 months free for early adopters. Any and all feedback is appreciated. Thanks folks!</comment>