With React 16.8, React Hooks are available in a stable release - <AUTHOR> https://reactjs.org/blog/2019/02/06/react-v16.8.0.html <comment><USER2> Hooks seem to be a drastic change in how we're going to write React components in the future. I'm quite satisfied with the current way of writing components which is to me is very explicit (with no magic). With Hooks React is taking a different direction from their original motto of explicit design patterns. From the looks of it, Hooks seems like a counter-intuitive design pattern but traditionally that's how most of the JS concepts were before they went mainstream.

I'm going to wait and see for some production success stories become giving it serious thought.

<comment><USER3> In case you're curious, I recently wrote up a deep dive on React from first principles that includes Hooks.

[https://overreacted.io/react-as-a-ui-runtime/](https://overreacted.io/react- as-a-ui-runtime/)

Personally I don't see them as being either "magic" or "implicit". You might find my post helpful for conceptualizing how they fit into the picture.

(Warning: it _is_ a longread. But it also explains 90% of React on a single page.)

<comment><USER2> what a coincidence I just finished reading this article yesterday (and even Tweeted about it [https://twitter.com/BilalBudhani/status/1092784595756556294](https://twitter.com/BilalBudhani/status/1092784595756556294)).

TBH, After reading the article I'm definitely putting effort to understand the thought process behind this change. Thank for writing up such a detailed & informative explanation on concepts in React.

</comment></comment></comment><comment><USER4> Are hooks being accepted as a good design by the community?

It seems to me that the lack of a parameter explicitly indicating the component and the reliance on hook ordering to match them across calls of the component function make them a bad design, but I might very well wrong and would be happy to be convinced otherwise.

<comment><USER3> While HN wasn't convinced last time I posted this, here's a few posts or sections that explain the static call order thing:

[https://overreacted.io/why-do-hooks-rely-on-call- order/](https://overreacted.io/why-do-hooks-rely-on-call-order/)

[https://overreacted.io/react-as-a-ui-runtime/#static-use- ord...](https://overreacted.io/react-as-a-ui-runtime/#static-use-order)

[https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...](https://github.com/reactjs/rfcs/pull/68#issuecomment-439314884) (Persistent Call Index section)

Hope this helps, happy to answer questions. We've been using Hooks for several months at FB and haven't seen confusion caused by the call order reliance.

(Note Hooks don't rely on _specific_ call order but just on it being _static_ between renders. Which is pretty easy to understand and reasonably enforce in practice.)

<comment><USER5> One thing that looks 'magical' is how does the setWhatever function lets React know that state has changed and has to re-render? Is there any info/writeup on this anywhere?

<comment><USER3> Pretty much the same way as this.setState in a class does.

React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to.

I think this explanation is quite accessible:

[https://medium.com/@ryardley/react-hooks-not-magic-just- arra...](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays- cd4f1857236e)

<comment><USER6> > React knows which component is rendering at any point in time — so it knows > which component useState() call corresponds to.

Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked.

With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of the shared react module, `useState` is not passed into the component, and I don't have to reference the component itself at any point while using hooks. The new sets of rules you have to follow to make things line up correctly play a part, as well.

Of course that may be how `this.setState()` does it anyways - you know better than I do, obviously. Maybe the usage of `this.setState()` made me feel confident in something I didn't actually understand under the hood. But at least for me, that's why `useState()` feels a bit magical at first glance compared to `this.setState()`. Not _too_ magical, and not enough to scare me away from using hooks, but still a bit.

<comment><USER3> Yeah I totally get that.

Conceptually Hooks are modeled as "algebraic effects" feature from languages like Eff and Koka. Those are essentially like resumable exceptions.

With that conceptual model, `useState` is like a `throw` that goes back into React "up the stack", and then goes back into your code.

Of course that's not how it works for perf and other reasons (there's no resumable exceptions in JS). But this may help the conceptual model around how we know which component it is.

</comment></comment></comment></comment></comment></comment><comment><USER7> Everyone is calling this "magic" yet under the hood it's the same "magic" behind a react component class setState function. It's literally the same thing, but lets you pass these functions to descendents. It essentially decouples that "feature" from being tied to the class component. That's just excellent.

</comment><comment><USER8> I've read a lot about hooks, the reasoning all makes sense but I'm still not fully getting it at an intuitive level. Like I get that it means you can write functional versions of class based components, an example of a complex class component that has been converted to a function with hooks would be good. The counter example really leaves a lot to the imagination.

The examples in [https://usehooks.com/](https://usehooks.com/) aren't convincing me for some reason, but maybe that's just my lack of familiarity with the syntax so it feels more magic. Lifecycle methods like componentDidUpdate are super easy to reason about at first.

<comment><USER3> A major point of Hooks is that they're composable — unlike lifecycle methods.

You can separate different reusable pieces of logic into Hooks, and then combine them or pass values between them. You can even call the same Hook more than once.

I've wrote about new possibilities they unlock here:

[https://medium.com/@dan_abramov/making-sense-of-react- hooks-...](https://medium.com/@dan_abramov/making-sense-of-react-hooks- fdbde8803889)

Hope this helps.

<comment><USER9> But why does Hooks need to be implemented on top of functions and not classes? The way I see it is that Hooks today implements two distinct things: (1) a composable way to handle lifecycle and (2) a custom way to store state. Why can't we have the composable hooks available on React.Component like this?

        class Foo extends React.Component {
           constructor(props) {
             super(props)

             this.useEffect(…);
             this.useState(…);

             // or maybe even a top-level API:
             useState(this, …);
           }
        }

<comment><USER3> How would you pass values between them?

Note Hooks execute on every render. That's their whole point.

I explain this here: [https://overreacted.io/why-do-hooks-rely-on-call- order/#flaw...](https://overreacted.io/why-do-hooks-rely-on-call- order/#flaw-7-cant-pass-values-between-hooks)

<comment><USER9> [https://codesandbox.io/s/5vvm68k6qp](https://codesandbox.io/s/5vvm68k6qp). The custom effects would take functions instead of values and then `useEffect` will be executed by the component. There's certainly some issues in this implementation with regard to how to handle nested state changes, but I think that can be worked out.

</comment></comment></comment></comment></comment><comment><USER10> I don't get it. I thought the main appeal of functions were that they were stateless so you had immutability. We already have classes if we want state, so why is this an improvement? Functions have slightly less overhead maybe? But then why didn't the React team just work on making classes have less overhead? It seems sort of "extra".

<comment><USER11> Not specific to React, but with CommonJS modules you can use module scope instead of global scope to get private methods and variables, which the function can access via the closure.

        var foo = 1;
        var bar = x => x++;
        module.exports = function baz() { return bar(foo) }

I find this much more simple then classes. I even consider it an anti-pattern to make a class for something this simple.

<comment> crooked-v That gets you a single instance, but the whole point of React components is that you can use them lots of time and each will do its own instance of the thing.

</comment></comment></comment><comment><USER12> Based on the consistent supply of comments sharing hesitation/confusion whenever hooks are talked about, I'm curious. Is this a normal reaction to a new thing that ends up being a very good idea? Are there past examples of this? I can't quite tell if it's a sign that something's off or if this is just normal.

<comment><USER13> Well, when React first came out no one was convinced by it. It took more than 2 years, I guess, before everybody suddenly got convinced and started claiming it was the best thing and so on.

<comment><USER14> I was not convinced either, Code and UI together!. If you ask me now there is nothing better then reactjs out there. I would not hesitate to change if there was something better.

</comment></comment></comment><comment><USER15> Now we can finally have completely clean data loaders:

Create a data loader hook that loads your data in a one-shot effect (you pass it the identities array), and which returns either a valid view (an error or loading view) and no data, or no view and valid data of type T. Then you can just do:

        const loader = useDataLoader(async () => {
          const a = await getDataA();
          const b = await getDataB(a);
          return b.data;
        });

        return loader.view || <MyView data={loader.data} />

I've been using this for a few months and it's amazingly clean compared to render-props. I hope this gets pulled into the React standard library.

<comment> basil-rash This also ties in very cleanly with graphQL:

      import gql from 'graphql-tag';
      import { useQuery } from 'react-apollo-hooks';

      const GET_DOGS = gql`
      {
        dogs {
          id
          breed
        }
      }`;

      const Dogs = () => {
        const { data, error } = useQuery(GET_DOGS);
        if (error) return `Error! ${error.message}`;

        return (

            {data.dogs.map(dog => (

{dog.breed}

            ))}

        );
      };

[https://github.com/trojanowski/react-apollo- hooks](https://github.com/trojanowski/react-apollo-hooks)

</comment></comment><comment><USER13> Hooks is awesome! I love hooks! They make everything so simpler. There are less names, less bloat, less stuff to remember.

Contrary to what others have been saying, I think hooks is much more explicit than the current class-based components.

</comment><comment><USER16> Never a boring day being a frontend developer. Looking forward to add hooks to my React project. The next frontier would probably be functional strongly typed languages, like Reason or some variation on Elm?

<comment><USER17> A variation on Elm? Why not just Elm?

<comment><USER18> Well, he said "the next frontier". Probably implies that Elm didn't catch on, and means "what will the next major framework/paradigm/fad will be post- React".

<comment><USER19> I honestly don't think that there will be another framework that'll overtake react anytime soon. It's not about there being a better framework, just that we finally have something that's "good enough".

<comment><USER20> True. I used ExtJS and Ember for years and React just operates on another level.

<comment><USER21> I would say the same for Elm architecture and type system that guarantees no runtime exceptions. There is nothing similar in frontend languages and frameworks.

<comment><USER20> I think Elm is pretty cool too.

But last time I looked, the JavaScript integration did feel quite a bit more cumbersome than with Reason.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Something that I really like about React is that it is easy to reason about the state of each component, with functions there was no state, with classes, you can see everything that touches the state there in your class.

I am not sure how having various functions (hooks) that trigger state changes and so re-rendering is going to pan-out in practice.

Here comes _setInterval_ and _counter_ packages, no I don't believe I can simply avoid using them, everyone depended on _leftpad_ , indirectly.

<comment><USER23> There is a blogpost from dan abramov about using setInterval with hooks: [https://overreacted.io/making-setinterval-declarative- with-r...](https://overreacted.io/making-setinterval-declarative-with-react- hooks/)

</comment></comment><comment><USER24> Looking forward to updating my current project later today. The mess of HOCs, local state, context and props flying around have kept me busy looking for alternative frameworks in the past few years; without those it might actually start being consistently enjoyable.

</comment><comment><USER25> This is exciting, and at the same time I wish this came out before writing thousands of lines of code on my React app...

I can see the possibilities this brings, and they're much better than the mess of props, local state, redux, and HoCs that we have. But the refactoring needed is just insane.

Has anyone gone through something like this and has any tips?

<comment><USER3> We're not refactoring anything at FB and don't recommend you to either!

We mostly use Hooks in new code.

<comment><USER25> Sounds good! Absolutely didn't expect getting a reply from you on this :)

I'll use them in a couple new features and see how nice and tidy I can make things look, then think about how we'll continue going forward.

Still have a bunch of componentWillReceiveProps that need attention as well...!

</comment></comment></comment><comment><USER26> Do hooks work well with TypeScript? e.g. types will catch errors for you and you don't need to use "any"

<comment><USER27> Sure, the "magic" bit of hooks that people are talking about doesn't really affect their type signature

See eg, setState: `function useState<S>(initialState: S | (() => S)): [S, Dispatch<SetStateAction<S>>];`

from: [https://github.com/DefinitelyTyped/DefinitelyTyped/blob/ab08...](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/ab0806bfb5b2ad74dccacd4780be688e96d2ea5a/types/react/index.d.ts#L809)

</comment></comment><comment><USER28> One thing I can't figure out in hooks vs recompose is how to use them and avoid props drilling or even just basic wiring. One of the most glorious things about recompose is that the props are drilled/wired for you automatically. This turns out to be huge for me. I had so much tedious props drilling code that just went away with recompose. Anyone have any insight?

<comment><USER29> Use the Context API introduced in 16.3: [https://reactjs.org/docs/context.html](https://reactjs.org/docs/context.html)

This is the same API that or anything that "teleports" state around your tree uses internally.

<comment><USER28> Fun approach! But I don't think that's it? Just not the same kind of zero- effort awesomeness right? Also uses the context API for something it's not intended for.

<comment><USER29> I'm not sure what you mean — the context API is specifically for moving data around the component tree without prop drilling. What are you talking about with regard to recompose?

<comment><USER28> I guess I just mean wiring. Recompose eliminates the need to do any wiring at all. You compose up your component, and then you have access to all those props without having wired them! The last thing I want to do is get the context API involved.

</comment></comment></comment></comment></comment><comment><USER30> Slightly off-topic, but has any of those who dislike hooks for the added magic seen Svelte.js version 3? It is ridden with magic. Top-level variables in the


Most useful eclipse keyboard shortcuts - <AUTHOR> http://theshyam.com/2009/07/eclipse-productivity-shortcuts/

<comment><USER2> Good list. I posted a comment there, and am copy-pasting the same here -

Ctrl + L – Brings up a dialog for a line number to navigate to

Ctrl + Shift + L – Brings up a popup of shortcuts (Handy especially when new to learning the shortcuts)

Ctrl + Shift + Up/Down – Moves the caret to the previous or next method.

[Edited to only mention some shortcuts not on the page, but those that I find handy]

</comment><comment> brown9-2 The article mention Ctrl+Shift+R to Open a Resource, but Ctrl+Shift+T is just as nice - restricts the search to Types (i.e. classes).

</comment><comment><USER3> My favorite is Alt-F4 to close Eclipse, and then Enter to spawn an IDE that isn't terrible.</comment>


Bottlr: Chatroulette for SMS iPhone App - <AUTHOR> http://itunes.apple.com/us/app/bottlr/id346251089?mt=8

<comment><USER2> Ha! I was just talking to someone the other day about an idea like this.

It's a great idea - my little sister sends a ridiculous number of texts a month (as do all of her friends). As far as they're concerned email, facebook and twitter are all for "old" people.

<comment><USER3> _As far as they're concerned email, facebook and twitter are all for "old" people._

She's well informed. Technically, Twitter and FaceBook are for over-18s only and e-mail hasn't proven portable enough to appeal to most youngsters. In ChatRoulette's case, that's _certainly_ a good thing, with perverts only a click or two away in most cases :-)</comment></comment>


Chrome 69, "Clear browsing data" – "Cookies and other data" keeps local storage - <AUTHOR> https://twitter.com/ctavan/status/1044285835133300736 <comment><USER2> The good news just keep on coming in without end, do they? Yeah, I just noticed this too while clearing my cookies. You have to manually delete all of that stuff if you want it gone, which (in my opinion) is a major usability flaw.

</comment><comment><AUTHOR> Hah - I now see that the main discussion is over here:

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

Oh well, never mind.

<comment><USER2> Not quite. There seem to be two problems:

The one everyone cares about, that google keeps its own cookies

and the one you mentioned, that it also keeps local storage (not only that of google)</comment></comment>


Deadtech: Kodachrome Goes the Way of the Great Auk - <AUTHOR> http://www.readwriteweb.com/archives/kodachrome_goes_deadtech.php?sms_ss=hackernews&at_xt=4d1d05b243a95ac9%2C0 <comment><USER2> The last pictures taken on the last roll of Kodachrome ever manufactured: [[http://stevemccurry.wordpress.com/2010/12/30/the-end-of- an-e...](http://stevemccurry.wordpress.com/2010/12/30/the-end-of-an- era-1935-to-2010/\]\(http://stevemccurry.wordpress.com/2010/12/30/the-end-of- an-era-1935-to-2010/\))

McCurry is the photographer who shot the National Geographic Afghan girl cover (using Kodachrome), they gave him the last roll.</comment>


Japan to start 4K TV broadcast in July 2014 - <AUTHOR> http://www.reuters.com/article/2013/01/27/us-japan-hdtv-idUSBRE90Q02520130127

<comment><USER2> I hope that non-corrupt telcos from other countries keep raising the bar on services and quality to make it more apparent how badly we are getting screwed in North America.</comment>


Learn to Code in 3 Months—or Less - <AUTHOR> http://www.thedailymuse.com/tech/learn-to-code-in-3-months-or-less/

<comment><USER2> This should be rebranded "Learn to produce Average Code in 3 months or how to make the real programmers on your team miserable".

I mean seriously, it's one thing to have some cute blog summarize trendy tutorials in one place, but to have it appear on the front page of HN is disappointing to say the least. I honestly expected to open the comment and see people bashing this.

In 3 months, with serious dedication (assuming no background in science), you will at best be able to run a CRUD-app prototype on your laptop, you have no feel of "real world" problem, let alone do more "serious" (as in go beyond generating a couple of forms with your web framework) programming. (Yay! you learned to type in ... a Unix command!)

The crazy thing is that I thought this was already settled 15 years ago, when Amazon started selling books a la "teach yourself programming in 2 hours (and be insanely rich for the rest of your life!)".

Don't trust me, I'm a young old-fart. Take this guy's word instead. I bet HE knows a thing or two about programming. <http://norvig.com/21-days.html>

<comment><USER3> I don't understand this attitude. Would you feel the same way if someone put up an ad saying "learn to drive in 3 months"?

A couple of years back I went to one of those "driving camps". It was enough to land me a driver's license in Sweden, which has comparatively high standards. Did I become race driver? No. A professional driver then? No. Do I know all the parts of my engine? No. I can drive my car from point A to B relatively safely and I know how to check the oil, but that's pretty much it.

You have to start somewhere. A lot of people aren't getting exposed to programming in a useful way - compared to say, driving, counting, reading and writing - and this is a good way of starting out. What's the problem with that? If you are starting a delivery business, perhaps it would be useful if you delivered the packages yourself rather than hiring a professional truck driver.

As for the reason of this being on the front page of HN: One thing to keep in mind is the fact that it, along with a gazillion other articles on the same subject, represents a change in availability of education in our industry. That and link-bait for the Zuckerbergians.

<comment><USER2> Because filling the road with half-accomplished drivers is a pain in the derriere. The average driver is already annoyed and tense on the road, I can only imagine professional drivers get very frustrated by poor driving when they're outside the tracks. (On a side note, driving is much more vital than programming, so the analogy stops here. You _should_ have the right to drive, even at a non-professional level. Can the same be said of programming?)

Just like less-than-average drivers will annoy the pros, the less-than-average programmer will limit the field. If you look at my original comment, I clearly mentioned: "How to make the real programmer on your team miserable". If the less-than-average programmer sits in his parents basement working on his own racoon-loving social network using the most mind numbing technologies, that's okay. But as soon as he interacts with others, he will inevitably cripple the advances of the field. Think of what happens each time a standard comittee reaches the conclusion: "It's a great idea, but too complex for people to grasp".

I know I sound very elitist, and I wish I wasn't. The truth is programming is hard. Very, very hard. Sure you can use your favorite framework to generate an html form and read DB fields, but this is not programming. Dijkstra has written extensively about the subject, calling programming "one of the most difficult branches of applied mathematics" or saying about BASIC (whose usage then is very analogous to the subject at hand now) "the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery". EWD was an extremist, he argued that CS students should focus on symbol manipulations, prohibiting them to manipulate computers for the first few years, focusing on an abstract formal language instead. He criticized universities for "[lacking] the courage to teach hard science" and their "infantilization" of the "radically new" idea that is computer science.

I won't go as far. If what he suggests is an extreme, a website promising you to learn code in 3 months is the opposite extreme. A 4 year CS degree, a couple of open source projects and the _deliberative practice_ Norvig talked about should be a good moderate middle-ground.

In short, do I encourage people to start programming? Of course I do, it's the most fun I've ever had in my life. Do I agree that three months worth of learning and couple of RoR pre-fabricated functions is enough to say they learned how to "code"? Absolutely not.

</comment></comment></comment><comment><USER4> The first cohort (Spring) of <http://DevBootcamp.com> graduated a month ago. It was an ultra successful class, we had some amazing teachers, mentors and fellow students (I was one of them). I've just checked the current statistics and 14 of the 17 students looking for jobs have now had offers. I think at least 5 have accepted an offer and started working so far.

Average salaries are around (but slightly less) than San Francisco junior industry averages.

This is after an 8 week course. These programs work.

Disclaimer: I now work for DevBootcamp.

<comment><USER5> > Average salaries are around (but slightly less) than San Francisco junior > industry averages.

What's the industry average? (Sorry, I'm from Oz so don't know.)

<comment><USER6> I don't know about "junior developers", but the average starting salary for a fresh BS from my public university (based on a voluntary exit survey, so there may be some upward bias) is around $80.5k.

This is particularly pertinent because the vast majority of the students here end up working in the Bay Area.

</comment></comment></comment><comment><USER7> We need to start making a distinction between computer science grads and web application developers.

Nobody really believes that you can learn everything you would on a CS degree in 3 months. But with awesome frameworks like RoR, jQuery, JMVC and Codeigniter, a wealth of online knowledge and big communities it's now possible to achieve an awful lot without any formal CS education.

I think that's the point they are trying to make.

<comment><USER8> I think you just offended a lot of people with CS degrees that call themselves web application developers or do that kind of stuff.

</comment></comment><comment><USER9> I am always surprised when reading posts like this one. Studying a subject is boring, one learns fastest through real world practice/experience.

Whenever someone asks me how to pick up programming I give them the following advice.

1\. Think of something cool you want to build. Scratch your own itch. Presume everything is possible.

2\. Find out what reading material is required by your local universities for an introductory software engineering class. Find one that has a 200-300 page _reader_ , written by the professor that teaches the course. Go to the university, buy reader. It's cheap, max 20$, and extremely dense. Do all exercises.

3\. Find a cool web framework. Program.

Before you realize it, you'll have developed something pretty cool.

</comment><comment><USER10> I think the title is silly. You don't learn to code in 3 months. You learn the keywords and semantic of the language. This has nothing to do with being a software developer and producing good and valuable products. This attitude is the reason why out of 100 resume I get on my desk I might find 1 or 2 good developers. Then you read about "developers" complaining they are only being paid 1,500 EUR in Europe. You know why? Because. They. Suck!

</comment><comment><USER11> A 3 month intensive course is not a substitute for a multi year computer science degree.

Both are valuable in their own way but the comparison is just rediculous.

<comment><USER12> I disagree.

A computer science degree means you've spent 4 years learning computer science, it doesn't mean you know anything about software development. In fact, at a university with a good CS program, it almost certainly guarantees you know nothing about software development: UC Berkeley's CS program has a single optional elective on the subject of software engineering.

Now, there is a high correlation between computer science aptitude and software engineering aptitude, but I wonder if it's just because we've conflated the two because the field is so young. I believe that one can be taught without the other, and that's what we're seeing with these academies.

Consider: on one side, you have someone who spent 720 hours over the course of four years learning Delaunay triangulation and LALR recursive descent parsing, but has never written or architected a greenfield application from scratch.

On the other, you have someone who spent 300 hours over eight weeks building applications, being exposed to good industry practices, learning how to deploy systems, how to use source control, how to use an IDE. Maybe afterwards, they could spend two weeks covering fundamental theory.

Let's be honest, when I go out to interview I do the same thing anyway.

As an employer, the latter would be more immediately useful to me. So you're right, the comparison is ridiculous, and an intense course is not a substitute for a multi-year degree. But stop and ask yourself: is a CS degree the right criteria for admission into the industry in the first place?

<comment><USER11> You seem to disagree with a point I am not making. I'm saying that they are both valuable (maybe CS grads who want to work as Software Engineers should take such classes), but not equivalent.

There are values to an academically rigorous (CS) education that are unrealted to Software Engineering. Simply being aware of CS fundamentals is not equivalent.

There are many eng jobs outside of Startup land where a deep knowledge of CS is far more valuable than how to write and deploy a full stack web app.

<comment><USER13> I'm actually agreeing with you and disagreeing with chriszf. I suppose I should have called that out specifically. My comment was mainly to counter argue what I've seen as undervaluing a CS Degree. (Sorry for the confusion).

<comment><USER11> My bad, I replied to the wrong parent. I meant to reply to chriszf's point that you also disagreed with.

</comment></comment></comment></comment></comment><comment><USER5> Interesting link. What would be nice would be some kind of comparison of different offerings (e.g. the online Codeacademy-style stuff) by either an experienced developer or a novice to see how they stack up against each other in terms of usefulness.

<comment><USER14> Code Avengers <http://codeavengers.com> is a free interactive online tutorial that will teach you Javascript. My brother created it and I think its the funnest and most effective way to learn.

</comment></comment><comment><USER15> I find these 'Learn to code in [any time period]' things tiring. You can learn to code in one day if you want, but that doesn't make you a good or knowledgeable coder. And some people will never be able to code in a logic manner, even after 3 years. The time period is hardly related to this, as is confirmed by lots of research.

<comment><USER12> Fair enough, but it's interesting to note that a person with little-to-no CS background can be made to resemble, in all respects, a junior-to-mid level engineer in such a short time. It suggests that the industry notion that a CS degree is needed to be a good engineer needs to be challenged. Why it exists at all baffles me, when some of the best software engineers around are mostly home-grown: John Carmack, Shawn Fanning, Ken Silverman, Bram Cohen, etc.

<comment><USER2> Because the industry is so much more than throwing preformated auto-generated web forms at a database. There are things far more serious than your average "Facebook meets Fitocracy for lumberjacks" ideas...

If Carmack and others managed to do great without a formal degree good for them. But they're outstanding people and are more the exception than the rule. If you're as talented as these guys, fine let your skills speak for themselves. But assuming every person following this 3 month "program" will now call themselves a programmer is something completely different.

</comment></comment></comment><comment><USER14> Code Avengers <http://codeavengers.com> is a free interactive online tutorial that will help you get started on Javascript. There is obviously much much more but this will help beginners learn basic skills.</comment>


Startups have officially run out of names - <AUTHOR> https://techcrunch.com/2017/07/18/turning-it-off-and-on-again <comment><USER2> i love all the apps with the -ly endings! ~s</comment>


Show HN: Trends – A GitHub trending PWA - <AUTHOR> Over the past few weeks I've been working on a small application to view trending repos on GitHub. I built the PWA[1] with React, Next.js and GraphQL .. but what's interesting is the application is only using React server side, meaning the client side javascript is only a few lines code adding some event listeners and registering a service worker for offline capability. This helped me achieve a perfect google chrome performance audit
I learned a ton working on it and would love to talk about it if anyone has any questions!
Application Link: https://trends.now.sh
Source code on Github: https://github.com/hanford/trends
[1]: https://developers.google.com/web/progressive-web-apps/ <comment><USER2> I'm super intrigued by the client-side/server-side rendering question. When I discovered single page apps I thought I'd seen the future - servers were just things that hosted web services, and all the presentation was a bundled, minimized blob served up by a static CDN. So simple, so clean, such clear separation of concerns. But now I'm seeing reports of faster first page rendering with React server than React client, and here I'm seeing a clearly very smart person articulating a completely different class of benefit of server-side rendering. Clearly I shouldn't be walking away from old style server side rendering so casually. My question is how do you think about that choice, now that we have the freedom to go either direction?

<comment><AUTHOR> It's certainly interesting. This kind of development has gone full circle where the methodologies are back to where it was years ago.

The issues that really large JS bundles can cause are really hard to solve (bloated sizes, but also parse time of the bundles). There are a lot of tools to help mitigate those like code splitting, but it's really challenging once things get big.

When I wanted to achieve a 100 in my chrome performance audit, I simply couldn't include React.

I think React adds a tremendous amount of value from the ecosystem, the constant improvements and updates .. and the mindset that developers have when building out react applications. (component model, etc)

I think for any really large application with lots of client side interactions or async data / data management, my solution would become unwieldy.

But for smaller applications that maybe don't need to do as much, (in the above case we're simply registering some event listeners to submit a form) or landing pages or the like .. the above solution would work very well.

</comment></comment><comment><USER3> The page load speed is seriously impressive, congrats!

There's something weird going on with the styling of the dropdowns, though: [https://i.imgur.com/WQ3m52X.gif](https://i.imgur.com/WQ3m52X.gif)

I'm on Windows 10 & Chrome

<comment><AUTHOR> just rolled out a fix for this on firefox for mac, i don't have a windows computer to test the fix on...

if you do a hard refresh this issue may be resolved! ¯\\_(ツ)_/¯

<comment><USER4> Dropdown arrow still does not show in Windows 10 with Chrome v. 68.0.3440.75 [1]

Same with Microsoft Edge 42.17134.1.0

Works OK on Firefox 61.0.1 (64-bit) [2]

[1] [https://imgur.com/a/e9pw5Ii](https://imgur.com/a/e9pw5Ii) [2] [https://screenshots.firefox.com/iv6SFyfw29zh91WG/trends.now....](https://screenshots.firefox.com/iv6SFyfw29zh91WG/trends.now.sh)

</comment></comment></comment><comment> david-cako Related question:

Does anyone know of a solution to the jank on firefox (perhaps others) when you have a hover scale effect? I figure animating all dimensions and text size instead of scale may do the trick, but that's a pain.

I'd even be okay with indefinitely deferring the re-render at the end of the animation if possible.

</comment><comment><USER5> Horrifying to see my stupid side (joke) project manipulated the star rankings. [https://www.gitstarred.com/](https://www.gitstarred.com/). I guess it doesn't take many stars to do that.

</comment><comment><USER6> I like to check the trending repos once a day, but Github keeps moving the link to it, this is fantastic. While I am sure others will be asking to add more languages, could there be a feature to check multiple languages at once with the language displayed with the repo? It is annoying on Github to have to check both Javascript and Typescript for similar trending projects.

A simple vertical list would also be nice, but that is personal preference.

</comment><comment><USER7> I did the same but with a PureScript frontend [https://madnight.github.io/grendy/](https://madnight.github.io/grendy/) and a Haskell backend [https://github.com/madnight/grendel](https://github.com/madnight/grendel)

</comment><comment><USER8> No text on IE mobile.

[https://i.imgur.com/Naqr8Xg.jpg](https://i.imgur.com/Naqr8Xg.jpg)

I know nobody supports IE mobile but I thought id report it. It's a shame because I was looking for exactly this app, and it seems to work otherwise

<comment><USER9> [https://en.wikipedia.org/wiki/Internet_Explorer_Mobile](https://en.wikipedia.org/wiki/Internet_Explorer_Mobile)

> Internet Explorer Mobile is a discontinued mobile browser

Why _should_ anyone support a discontinued browser?

<comment><USER8> Discontinued doesn't mean out of use. But I get your point. Maybe it doesn't work on ie7 either. I should just "get with the times" and move to android or iOS. But we're taking about text not rendering correctly on a PWA that otherwise works well. I don't see the harm in reporting it because maybe its one tiny change the author needs to make in order for it to be usable.

</comment></comment></comment><comment><USER10> Changing the width or zooming in and out changes the number of columns (nice!), but the max seems to be 4. Is that a hard limit? Seems like a responsive UI should respect wider screens in landscape. Nice work, btw.

<comment><AUTHOR> yeah I added a hard limit based on a relatively arbitrary max-width of 1400px.

I got all of the responsiveness for free using CSS grid! Definitely recommend checking it out if you haven't yet

Figured something like this would be a little overwhelming [https://imgur.com/nx3hISb](https://imgur.com/nx3hISb)

<comment><USER11> That is, indeed, overwhelming. Ha

</comment></comment></comment><comment><USER12> Never used next, looks interesting. So with this setup, the browser doesn't do any work, all pages are loaded as if they were static, and rendered server side?

<comment><AUTHOR> Correct!

The way that is achieved is pretty neat, Next.js has a <Document />[1] component that you can extend. This Document is essentially your application shell that is used when server side rendering.

Here is the trends Document component[2] where you can see I'm simply omitting `NextScripts` which ends up being the frontend bundle with react + application code

[1] [https://github.com/zeit/next.js#custom- document](https://github.com/zeit/next.js#custom-document)

[2] [https://github.com/hanford/trends/blob/master/pages/_documen...](https://github.com/hanford/trends/blob/master/pages/_document.js#L6)

<comment><USER2> I'd seen references to next before this but never really dug in deep enough to get a sense of whether it was worthwhile. Thanks for giving it enough context to show how cool and accessible next is.

</comment></comment></comment><comment><USER13> This site is lightning fast. Just how it should be!

</comment><comment><USER14> Select options are white on white background in Firefox. And it would be nicer, if changing language and time wouldn't reload whole page.

<comment><AUTHOR> hmm, thanks for mentioning the select options .. should be an easy fix.

As for the page reloading I agree, but this exercise was specifically to make an application with the absolute minimum amount of client side code.

HTMl5 Forms do the job pretty well! :)

</comment></comment><comment><USER15> Cool. Just curious if this is supposed to be just an exercise or does it have information that's not on github's own trending page?

<comment><AUTHOR> I'm using the search API, so unlikely anything different than Github's trending stuff that is already there.

The UI is a little better though ;)

</comment></comment><comment><USER16> I notice that it lets you sort by language. Does the underlying data let you get at trends in relative language popularity?

<comment><AUTHOR> If I understand correctly you could build something like that but I'm not currently persisting any data from github which is something I'd need to add first.

I'm simply getting this data from Github and then caching the rendered result on the cloudflare CDN layer, the rendered page data in memory in node, and additionally the GraphQL query in memory

</comment></comment><comment><USER17> Nice work, but I would put more effort in supporting Firefox rather than Chrome.</comment>


Ask HN: Were we cyber attacked today? - <AUTHOR>

I hate to sound like a conspiracy wingnut, but it seems unlikely that there were major outages at NYSE, United Airlines, and the WSJ all on the same day and it's merely a coincidence.
The media are referring to this as "computer glitches." I mean what, three different guys at three different data centers each tripped over a cable and it took each of them several hours to figure out how to plug it back in?
Maybe three different companies each committed buggy code in the past 24 hours -- code so bad that took their systems completely offline-- and they all forgot how to use git revert? <comment><USER2> Perhaps Hanlon's razor applies here: "Never attribute to malice that which is adequately explained by stupidity."

</comment><comment><USER3> Seen statistically, three "major players" still aren't all that much...

If the White House, Facebook, electricity companies and AT&T had gone down as well, then maybe we could start talking ;-)

</comment><comment><USER4> Unlikely? Maybe, but is it more likely that some entity that could attack such important infrastructure would attempt to steal something, or just destroy?

The only way I could see this could make you money is if you hedged against the markets and wanted to take everything down to benefit you, and that is superman villain level stuff.

</comment><comment><USER5> It is possible that the outages weren't unrelated but also weren't malicious. For example, all three companies use the same vendor who's services failed.

I do think it is still more likely that they were 3 unrelated problem's with their systems.

<comment><USER6> > It is possible that the outages weren't unrelated but also weren't > malicious. For example, all three companies use the same vendor who's > services failed.

That is my operating theory based on some throwaway "insider" in the NYSE thread who claimed (without supporting evidence) that "multiple US citizens in multiple US cities" worked together to fix the internal IT issue involving the NYSE issue. Cisco? Or network provider?

Perhaps there was a 0day discovered that affected UAL (or someone else) and the prioritization favored the airline and financial industries first. Hence the secrecy to let them get things in order before the larger market is informed.

Or, it could simply be that two industries that rely heavily on public trust around their network security have a standard operating procedure to pull the plug more readily when they get caught off guard with some kind of 0day or mundane attack. There was someone on here the other day talking about how banks never publicize small losses due to attack against them for similar PR reasons. But other systems are too big to fail.

<comment><USER6> Of course, with the emerging revelation that this was just an internal software/interface screwup during a pilot, I guess my speculation was wrong.

Not sure why the insider wouldn't have just said "it was a software upgrade issue" instead of saying "trust me, it's nothing", though.

</comment></comment></comment><comment> vezzy-fnord Why do you assume they use Git?

</comment><comment><USER7> > and they all forgot how to use git revert?

Implying they use any form of VCS at all...

The Knightmare fiasco might serve as a useful datapoint for re-calibrating your expectations:

[http://dougseven.com/2014/04/17/knightmare-a-devops- cautiona...](http://dougseven.com/2014/04/17/knightmare-a-devops-cautionary- tale/)

> I hate to sound like a conspiracy wingnut, but it seems unlikely that there > were major outages at NYSE, United Airlines, and the WSJ all on the same day > and it's merely a coincidence.

My expectations are calibrated at roughly "this is noteworthy?" Taking the long view of things, it seems unlikely it's taken this long for there to be three major outages on the same day. Well, rather, there have been - one wee little "yet another OpenSSL security vulnerability" and half the internet catches on fire, it seems. Or Michael Jackson dies and the full internet catches on fire. (EDIT: Or an AWS region goes down and you make a drinking game out of what popular websites are down because of it.)

Or, even ignoring mass issues like that - I suspect it's likely there _have_ been "three major outages on the same day" before - and we simply didn't notice. I wasn't aware of the United Airlines outage, for example. I didn't notice this. I had to have it called to my attention.

> and they all forgot how to use git revert?

This also ignores the fact that git revert is insufficient for something as simple as an SQL schema change if you don't want to lose data. Rolling back your blog's comments is one thing - they were mostly spam anyways. Rolling back financial transactions is entirely another (breach of contract? Fraud?)

It's entirely possible to generate rollback scripts which handle this, of course. These aren't necessarily faster to execute than it is to fix the actual problem, however, if you've got a sufficiently large database. Murphy's law means you'll hit some edge case, your rollback will fail, and now you're trying to untangle yet another layer of things gone wrong.

(EDIT: Hell, rereading about Knightmare, they tried to rollback. They succeeded, but that just made things worse in the process!)

> Were we cyber attacked today?

Nothing to suggest it was one so far, IMO. Although I'll certainly grant that a "computer glitches" hand-wave isn't a terribly strong indication it wasn't one, either. "Cyber attacks" (what does that term mean to you, exactly, I wonder?) are common enough I wouldn't find it too terribly surprising, though. I can predict my rough reaction: "I guess they were wrong about that."</comment>


Smartwatch running Android - i'mWatch - <AUTHOR> http://www.imwatch.it/

<comment><USER2> Complete vaporware and fiction. They don't have photos of anything that's real and not a mockup.</comment>


Things Every Graphic Design Student Should Know - <AUTHOR> http://www.jamiewieck.com/visual-essays/the-50-things-every-graphic-design-student-should-know

<comment><USER2> The basic ones are so basic they don't belong on the list, and the rest are all 'true'... Until they aren't.

There are exceptions to almost every non-basic thing on that list. Your exact position and circumstance will dictate all of that. They're probably a decent default, but they're hardly 'things you should know' and more 'guidelines to success, but take them with a grain of salt'.

<comment><USER3> I think that there needs to be, both for the developer and the designer, an understanding that rules are made to be broken.

Knowing or learning when and how to break them might be beyond the scope of any number of tweet sized aphorisms

Lists like this make me want to try and find a huge set of software engineering "bumper stickers" my dad sent me 15 years ago, containing dubious gems like...

pi seconds is a nano-century Never debug standing up (predates standing desk fad) Some projects can only be accomplished with fewer than 10 or greater than 100 people, but by no number in-between

</comment></comment><comment><USER4> Sadly I disagree about the unpaid internship (even though its something i would never do to anyone else) — having the right name on a resume can get you off to a good start.

</comment><comment><USER5> "It takes more energy to start than it does to stop. This is true for physics, your career, and that idea you need to work on."

This is not true for physics.

</comment><comment><USER3> Many of these apply to developers, all of them are worth thinking about if you get the opportunity to work with designers

</comment><comment><USER6> Great stuff, going to share this with the interns on Monday.

</comment><comment><USER7> #51 Learn to code.</comment>


Clean People Feel Morally Superior - <AUTHOR> http://www.wired.com/wiredscience/2010/08/clean-people-feel-morally-superior/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+wiredscience+%28Blog+-+Wired+Science%29#ixzz0xpejSPwN <comment><USER2> The same is true for nicely dressed people.

I bought my first suit last week and walked around downtown feeling all smug - I wasn't even trying to feel smug and yet when you're the best dressed in the room it goes right to your head.

Lame...

<comment><USER3> You described it in very negative terms, but I don't think it's necessarily that way. Humans are social creatures, and can't help it but judge someone they have no other information about based on the clothes.

If you're happy because you're dressed well, it doesn't have to mean you're "smug" - taking care of your looks shows that you care about other people's quality of interaction with you - everybody would rather interact with a person dressed nicely as opposed to if the same person dressed like a bum.

Also, there's something to be said about a confidence boost that you get knowing you're looking well kept. Most geeks will happily ignore all these points, but I think that's a mistake.

<comment><USER2> I agree that dressing nicely is a good way to communicate that you're serious about interacting with others.

You certainly don't want to come across as unprofessional and it's important to show others that you're putting forth your best effort (including appearance) for the work at hand.

</comment></comment></comment><comment><USER4> On a slightly related note I used to maintain highly manicured gardens for people in wealthy neighborhoods. A lot of these people were anal-retentive WASP's that scowled from their high perch as they surveyed a neighbors over- grown garden. They especially liked my leaf-blower because I could get all their hard surfaces perfectly clean. Many of them would also not hesitate to let me know I missed blowing a few pine needles. That job started to make me neurotic after a few years.

<comment><USER5> What's interesting is that it isn't a new phenomenon; Veblen wrote about our strange lawn-care fetishism in The Theory of the Leisure Class in 1899.

<comment><USER6> Sayed Kotb also commented on it after his visit to the United States in the 1940s, considering it a vulgar preoccupation.

For all his many faults, I feel he was on to something there.

</comment></comment></comment><comment><USER7> Interesting, if not relevant, tangent: Modern LDS missionaries are expected to bathe daily, without fail, when they are abroad proselytizing. I have heard anecdotal accounts of this causing some friction with their hosts due to the custom of daily bathing being wasteful/abnormal and/or a hardship on the local water supply.

This article makes me wonder if this psychological effect has been known by various religious groups for quite some time. From old-school Judeo-Christian "laws of cleanliness" to the more modern LDS church, keeping clean may be about self-righteousness more than sanitation.

Very interesting experiments, nonetheless.

</comment><comment><USER8> I believe the title should read "Clean Undergrads at Northwestern University Feel Morally Superior." FTA: "Some 58 undergrads were invited to a lab filled with spotless new equipment." I don't think this sample has any remote chance of being representative of the "People" population.

The "clean" and "dirty" passages used in the follow up studies employ very strong positive and negative words, respectively, and no control group seems to have been used to compare how people make moral judgments after reading very positive or very negative passages irrespective of cleanliness.

This is not even pop science it's trash science. It's dirty, but reading it makes me feel more morally superior, not less, contrary to the conclusion of the "study."

</comment><comment><USER9> Well it is easier to get away with being a jerk when you don't smell like B.O.

The first experiment is clearly suspect. I strikes me as equally like the people who washed their hands held themselves, and society, to a higher standard than those who didn't and thus where harsher in theory judgments.

In the later two, I'd like to see if the result differed greatly by having students read passages about how smart/stupid they were or how attractive/ugly they were.

</comment><comment><USER10> This makes self-righteous dreadlocked Marxist-toting hippie activists all the more puzzling.

<comment><USER11> As a self-righteous slob, let me be the first to say that clean people don't have a monopoly on smugness.

<comment><USER12> Honest, self critical slobs, that are able to view themselves from others' point of view, and still make a conscious choice to be slobs are alright in my book.

</comment></comment></comment><comment><USER13> If this really is true, might there be an in-built evolutionary aspect? That people who have an inbuilt tendency towards cleanliness have less chance of contracting disease?

All those religious texts and 'cleanliness is next to Godliness' - surely it can't just be a modern phenomonen? Even baptism - the act of dunking onesself in a river - must be considered cleaning for the purposes of being superior?

Note I don't expect this to be taken seriously and I'm no theological expert, but there is a talking point why cleaning pops up so frequently in religious texts of all persuasions. There surely is an element of life instruction in religious texts that drop below the moral level (do not lie) and into the physical level (clean yourself)

<comment><USER14> In Polish you literaly have "clean or dirty conscience", Bible also tells much about cleaning sbd's sins.

I'd like to see if this is about language (people primmed with concept being close to each other in language skew their judgements), or is this universal link between ethic and hygiene.

Maybe being clean is universaly considered good thing, but there are other more arbitrary associations that could be checked - for example in Polish "prawy" means "right" and also "good". Probably there are some cultures where it's the left that is associated with high ethic standards.

These 2 cultures should skew their moral judgaments to opposite directions when primmed with either "right" or "left".

<comment><USER13> Clean conscience is also a common English phrase, though, 'dirty conscience' isn't - but people would understand what you meant.

</comment></comment></comment><comment><USER15> Tbh, I'm not so sure about the accuracy of this study (and of 'experimental' social psychology in general - though that's another issue altogether)...but I guess I always new those tidy, short-haired bastards were uptight.

</comment><comment><USER16> Well maybe they are. Why bother with peoples feeling's about _x_ before bothering about _x_ itself.

"Clean people commit less crimes." Not unthinkable.

<comment><USER11> I'll grant you that it's not unthinkable. But I think it's highly unlikely that there's any kind of non-spurrious correlation between cleanliness and crime.

<comment><USER17> I find it just as plausible as the idea here that it makes you more morally judgemental of others. If it makes you more judgemental of others, it might well make you more judgemental of yourself.

I don't know if we can necessarily cut street crime by handing out free showers to bums and thugs. Might be worth a try.

</comment></comment></comment><comment><USER18> Couldn't this be an expectation issue? Washing their hands signaled to the subjects that they were in a more "proper" social environment. To fit in, they may have judged the social issues more harshly.

</comment><comment><USER19> Cleanliness is just a form of purity, which key value of morality.

Jonathan Haidt's work in this regard is fascinating.

</comment><comment><USER20> On the theme of the difficulty of making definite judgement with social- scientific experiment, I would say it's hard to separate out rather a specific state/behavior like "cleanness". Whether it is induced or normally occurring, it goes with a lot of broad social tendencies.

In the first phase of the experiment, it's possible that asking people to do some other ritual-type behavior might or might not have had the same effect.

In the second phase, having people read "I am good/bad" or "I make correct/incorrect" decisions again might or might not have had the same effect.

Move over, while reading about cleanness and cleaning yourself seems like a way to do this separating out, this approach relies, at the very least, on the assumption that imagining something is comparable to experiencing it.

<comment><USER11> You're correct in assuming that it's difficult to extract correct conclusions from a psychology experiment, just like with any other science. Moreso with psychology than other fields though because humans are complex beings.

But logically speaking, how do you make psychology beneficial to society without making a few assumptions? Math, for instance, is nothing _but_ a set of rules built on top of assumptions. Yes, we can point out all the potential edge-cases all day. But that won't put our society any closer to understanding the human psyche than when we started.

Of course as an alternative, you could just accept the team's conclusions: "Acts of cleanliness have not only the potential to shift our moral pendulum to a more virtuous self, but also license harsher moral judgment of others." To me, that seems like a valid conclusion to draw based on the research. Would you not agree?

<comment><USER21> >You're correct in assuming that it's difficult to extract correct conclusions from a psychology experiment, just like with any other science.

In psychology it is much much more difficult to tease out "correct" conclusions than in, for example, physics. This is a result of 1) the complicated nature of human behavior, which is not subject to (in comparison) simple mathematical formula; and 2) the unethical nature of trying to measure the effects of bizarre environments on children in order to analyze development.

This is what you said right afterwards, of course.

But the fuzzy sciences face challenges that naturally make them less rigorous in the scope of their conclusions.</comment></comment></comment>


Where Gravity Is Weak and Naked Singularities Are Verboten - <AUTHOR> https://www.quantamagazine.org/where-gravity-is-weak-and-naked-singularities-are-verboten-20170620/ <comment><AUTHOR> "Naked singularities could exist in a pretend 4-D universe called "anti-de Sitter" (AdS) space whose space-time geometry is shaped like a tin can."

Can anyone further explain the space-time geometry?</comment>


Compiling my own SPARC CPU inside a cheap FPGA - <AUTHOR> https://www.thanassis.space/myowncpu.html <comment><USER2> For those interested in hacking in this:

The Pano G2 FPGA is a monster, but prices on eBay have gone up a lot. My cheapest buy was 25 of them for $85 (including shipping!). They now go for around 1 for $30 if you're lucky... or $200+ for many.

The Pano G1 (with VGA instead of DVI) is cheaper but has a much smaller FPGA, though still large by hobby standards.

The benefit of the G1 is that all interfaces are working now, including DRAM, USB, Ethernet.

Last week, Skip Hansen got a full CP/M system running on one: [https://github.com/skiphansen/pano_z80](https://github.com/skiphansen/pano_z80)

USB on the G2 is hard. A bunch of people have tried and failed.

<comment><USER3> I never was a fan of the Zilog Z80 (its instruction set reminded me too much of the idiotic intel 80x86 family), but seeing someone running the Control Program for Microcomputers on a whopping 25 MHz Z80 is incredibly cool... just imagine what kind of scene demos could be coded on this monster for the next demo party...

I wonder if it would be possible to retrofit an MMU onto a Z80 design and port a real UNIX to it? 25 or even 50 or even a 75 MHz UNIX server on a Z80 processor, that'd be a nice perversion...

<comment><USER4> > [the Z80's] instruction set reminded me too much of the idiotic intel 80x86 > family

That is because the z80 was a (mostly) binary compatible superset of the 8080 instruction set, and the 8086 (while not binary compatible) was intentionally modeled after the 8080 such that there was a program that could take an 8080 program and do the 1:1 instruction mapping from 8080 to 8086 and get a working 8086 program.

> I wonder if it would be possible to retrofit an MMU onto a Z80 design

Zilog made a number of Z80 follow-on CPUs, and some have MMUs. It is amazing how far they took the instruction set; the Z80380 could run Z80 code as-is, but it also extended instructions to support 32b operations and had a mode with a flat 32b linear address space. I don't recall ever hearing any consumer product using it though.

<comment><USER5> Z80380 user's manual, for those interested: [https://www.manualslib.com/manual/1237352/Zilog-Z80380.html](https://www.manualslib.com/manual/1237352/Zilog-Z80380.html)

</comment></comment></comment></comment><comment><USER6> For a complete SPARCstation 5 implementation able to run SunOS, Solaris, BSD, Linux or NeXTstep, see [http://temlib.org/](http://temlib.org/) \- this fits on a Spartan6 XC6SLX45T FPGA, so you should be able to get it to work on the larger Spartan 6 FPGAs (if you can manage to build a working memory controller...).

It seems that the Panos are only available on eBay US, any idea where to get them in Europe without all the shipping and tax hassle?

<comment><USER7> That's one way to get a computer where you're actually sure what runs on it.

<comment><USER8> You have to trust the FPGA, its toolchain, and any peripheral hardware and firmware with priveleged access.

<comment><USER7> That's true in a technical way but it is false in a practical one. An effective attack using compromised FPGAs or toolchains would be super hard to carry out undetected because of the decree of scrutiny the output would receive, besides, the attack itself would have to make substantial assumptions about the way the FPGA would be wired into the resulting circuit. I'm not saying it can't be done but it would extremely hard to carry out and I'm not aware of any such attacks ever being discovered in the wild.

> any peripheral hardware and firmware with priveleged access.

That would be a more feasible vector. But it all still will be _much_ more secure than your average computer with a BMC.

<comment><USER8> "An effective attack using compromised FPGAs or toolchains would be super hard to carry out undetected because of the decree of scrutiny the output would receive"

FOSS vulnerabilities countered the many eyeballs argument a long time ago. There's even fewer people who know how to review hardware for flaws. I'm assuming it would be a targeted attack by default. That raises the bar. However, they could also leave a trigger that looks like a hardware flaw in the I/O interface. Intel has basically been doing that subversion with their ME flaws for some time now. Then, the only targeted part is just how to aim what's already there.

"That would be a more feasible vector. But it all still will be much more secure than your average computer with a BMC. "

True. Especially if you use an architecture like crash-safe.org or Cambrige's CHERI. I already advocate secure CPU's on FPGA's with dumb-as-allowed hardware if one can't get actual silicon. Also lets you throw in extra reliability features, too.

</comment></comment></comment></comment></comment><comment><USER9> Great article, I hope it helps motivate more people to give hardware design a try.

 _the truth is that most of the HW designers I know are editing inside their Vendor-provided IDEs._

Maybe true for FPGA designers, but not for ASIC designers in my experience.

 _Another crazy difference I experienced was that builds are NOT deterministic_

Yes, hardware generation (synthesis, but mostly optimizations, placement and routing) are not deterministic. SW people are starting to experience that phenomenon with ML as well: you don't fully control what you get, but it works.

<comment><USER10> With HW generation given the same HDL and tools you should be able to get reproducible builds if you provide the same seed at the very least.

<comment><USER2> In theory, you should. In practice, don't count on it.

</comment></comment></comment><comment> ur-whale This article is the perfect summary of everything that's wrong with the existing HW development toolchains for FPGAs.

The best bit is the windows-only version of the Xillinx gooware that in fact installs a Linux virtual box on windows to finally get to run the tools it needs.

Oh, and yeah : there's a lame protection in there that checks it's running on a specific virtual box with a specific MAC address.

Amazing (not in a good way).

</comment><comment><USER11> > Alas, I am told by my friends that DDR controllers are no joke; they are not > the playground of bored SW engineers.

No, they definitely aren't funny. I've worked with FPGAs and DDR controllers at college and their can be a big PITA. Even with DDR controller libraries you can still run into all sorts of timing issues.

<comment> ur-whale When a SWE really starts to understand how complex a modern DDR controller is at the silicon level, two things happen:

1\. You start to wonder how very, very far your code runs from the theoretical capabilities of the hardware and you start experiencing existential doubts.

2\. You are overcome by a deep and immense feeling of gratitude towards whomever managed to force all that complexity to remain hidden underneath the simple memory abstraction your rely on to write day to day code.

<comment><USER7> I try really hard to not go down that particular rabbit hole as it will always end up being 100% sure that software can't possibly work reliably or even at all. The degree to which we assume that our hardware is able to move stuff from point 'a' to point 'b' at a couple of billion times per second is scary.

<comment><USER8> Although I don't _know_ hardware, I read lots of stuff about developing it to get a better idea. Among the more interesting reads were slides about each process shrink along with challenges they brought. Especially from beginning of Deep Sub-Micron toward 28nm.

The impression I got, esp by 28nm, is the hardware is inherently broken in quite a few ways. They have to correct the masks with algorithms, they do image recognition on circuits to spot patterns that act up, extra latches, variance across the chip/wafer, aging effects... list goes on. Miracle they even work at all.

These things are also why I only trust old nodes for security. Sort of.

</comment></comment></comment></comment><comment><USER12> This article brings up an interesting question...

What other cheap hardware products contain FPGA's that are potentially user accessible?

I started a new message chain for this:

Ask HN: What other cheap hardware products contain FPGA's?

[https://news.ycombinator.com/edit?id=21305355](https://news.ycombinator.com/edit?id=21305355)

</comment><comment><USER5> On a side-note of pedantry, we really need to stop using the term ' _compiling_ ' in the context of FPGAs and HDLs. To 'compile' is to assemble a dossier of documents and/or fill in forms - this is why Grace Hopper called her automatic code generation contraption a 'compiler': because, quite appropriately, it took the description of actions to be undertaken by the machine and fleshed them out in a ritualistic fashion in lower-level instructions.

HDLs and FPGAs have very different principles and objectives. The best term is ' _instantiate_ ', because one creates an instance of a given hardware description upon the substrate of gates provided by the array.

I'm sure I'll be told I'm nit-picking, but those who do so would probably recoil in horror at the _faux pas_ of some n00b saying a browser "compiles HTML" and tell them the correct term is ' _render_ ', and they'd be right.

Please, let's be careful and deliberate about the terms we use, can we please?

<comment><USER13> I think you're not quite incorrect but your nitpicking isn't so much clarifying as redefining terms.

Lowering HDLs into logic that can be flushed onto LUTs does involve an intermediate compilation step, even though it does also involve placing/relocating/routing elements on the FPGA, ultimately producing a file to be flushed to the chip.

One could argue that 'compiling' is often conflated with 'linking' in producing application binaries, and in fact 'linking' also involves positioning/relocating elements in some fashion.

'compiling' is suitable and conceptually compatible enough that it clarifies rather than confuses.

<comment><USER5> It's precisely this notion of ' _lowering_ ', as you call it, that preoccupies me. If unchecked, the idea that all forms of 'lowering' through abstraction layers is a form of 'compilation' (of sorts) will become the norm, and we'll no longer have a unique term for what _compilation proper_ actually means. And you're entirely right in noting that nowadays 'compiling' has come to encompass and conflate the conceptually very distinct steps of compilation, linking, and assembly... a process I'm more comfortable with collectively referring to as 'building'.

It's entirely possible that I might've (accidentally) redefined one or more meanings, and if I have, I apologise. It's almost four in the morning and insomnia prevents me from sleeping but doesn't necessarily maintain me at full alertness (tomorrow/today will be hell).

</comment></comment></comment><comment><USER14> Another design to target at one of these boxes could be Milkymist [1], uses the lm32 CPU and various peripheral cores.

[1] [https://github.com/m-labs/milkymist](https://github.com/m-labs/milkymist)

</comment><comment><USER3> This is awesome!!! (Ultra)SPARC CPU's are a joy to code for in assembler, and modern T3, T4 and T5's are number crunching monsters.

How about synthesizing the GPL-licensed OpenSPARC T2 now?

[https://www.oracle.com/technetwork/systems/opensparc/openspa...](https://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html#t2-to- use)

I'd love to have SmartOS backported on a FPGA-based, OpenSPARC T2, 19" 1U rack mountable server someday. Free hardware and software all the way.

<comment><USER15> > This is awesome!!! (Ultra)SPARC CPU's are a joy to code for in assembler,

Dr Jack Whitham disagrees:

> [https://www.jwhitham.org/2016/02/risc-instruction-sets-i- > hav...](https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known- > and.html)

<comment><USER16> Of course that anyone is free to disagree for any reason, but after having written assembly for about 10 architectures, including several compilers, I definitely prefer SPARC to anything else. The current SPARC V9 ISA spec is about 1/10 of the arm64 ISA (I wrote compilers for both). The instruction encoding is so simple I can assemble in my head.

There are some spectacularly annoying things like the stack bias, but those are easy to hide in the assembler (and those are problems with the System V ABI, not SPARC, embedded ABIs ignore them).

<comment><USER17> Can you elaborate on "stack bias"? What are your thoughts about register windows? I am open mindedly curious as to why you prefer that assembly? Also, what SPARC hardware are you running?

<comment><USER16> On SPARC V9 the stack and frame pointers don't point to the top of stack, they point 2047 bytes (0x7ff) away from it. SPARC has 13-bit signed immediates, and much of that range would be wasted if the stack and frame pointers pointed to the top of the stack. Having a stack bias allows more of the immediate range to be utilized at the cost of the assembly (and runtimes) having to keep track of the stack bias.

The offset is chosen odd as to trivially identify 64-bit code in things like register window overflow trap handlers[2].

When I say I prefer some assembly vs. some other assembly, I speak from the perspective of a kernel/compiler writer. Realistically you will never use assembly to write general purpose code. You either target it from a compiler (in which case it better be easier to target), or write some specialized runtime/driver code, in which case it would better have easy to understand semantics and behavior. If you were to write general purpose code in assembly, say write assembly instead of C, an orthogonal CISC architecture would be way easier to write code for. But nobody does that anymore. People only use assembly when they have to (or target it from a compiler) and for that particular case the features of the ISA that matter most are quite different than what a general purpose programmer would want.

SPARC really excels for me because of how easy it is to target and how easy it is for me understand when I am writing runtime code.

I have various SPARC hardware, the most interesting (and the one eventually used for the Go port) being a single-digit serial number S7-2 system[3]

[1] [https://docs.oracle.com/cd/E18752_01/html/816-5138/advanced-...](https://docs.oracle.com/cd/E18752_01/html/816-5138/advanced-2.html)

[2] [http://src.illumos.org/source/xref/illumos- gate/usr/src/uts/...](http://src.illumos.org/source/xref/illumos- gate/usr/src/uts/sun4v/ml/trap_table.s#597)

[3] [https://www.oracle.com/servers/sparc/s7-2/](https://www.oracle.com/servers/sparc/s7-2/)

<comment><USER3> I grew up around cracking and the software piracy scene on the Commodore64 and Amiga so I write UltraSPARC assembler for fun (and profit, since I've always been able to utilize my knowledge and insights when landing job gigs). Does pouet.net tell you anything?

50% of servers in my basement data center are SPARC based.

</comment></comment></comment></comment></comment></comment><comment><USER18> Hmm, yeah, that does look affordable. Lots of ads on ebay.

"Lot of 25 Pano Logic Thin / Zero Desktop Client Black w/ Power Supply

Buy now: US $170.00"

I wonder what the thinking was that lead Pano Logic to put expensive FPGAs inside these units, instead of some more typical cheap ARM SoC?

Edit: Ah, they operated in 2006-2012. I guess that was just before the rise of the very cheap/fast SoCs.

<comment><USER19> Exactly. These are far far away from cheap FPGAs, Spartan 6 chips are just old, but not cheap. When thinking about cheap FPGAs I imagine these cheap things from Lattice for interface bridging.

Cheap ARM SoCs were on ARM's roadmap back then. Cortex A9 was huge innovation these days.

<comment><USER18> I guess they were thinking they'd be using very expensive FPGAs in the the first VC-funded iterations, and then move on to something cheaper. But they never got there...

[https://www.bizjournals.com/sanjose/blog/2012/11/pano- logic-...](https://www.bizjournals.com/sanjose/blog/2012/11/pano-logic-shuts- down-leaving.html)

"... the company had doubled or tripled its revenue every year since 2008, when it had about $1 million in sales.

...

The company was backed by about $38 million in funding from investors including Goldman Sachs, ComVentures, Foundation Capital, Fuse Capital, and Mayfield Fund."

<comment><USER20> I think you are correct.

Fpgas are often used as a stepping stone towards cheaper asic or hybrid solutions. asic requires a high volume and a working design, neither of which you have early in the project.

</comment></comment></comment></comment><comment><USER21> Well, for comparison, the cost of a current 100K LUT FPGA on a board is:

$250 for Xilinx Artix-7:

[https://store.digilentinc.com/arty-a7-artix-7-fpga- developme...](https://store.digilentinc.com/arty-a7-artix-7-fpga-development- board-for-makers-and-hobbyists/)

$100 for Lattice ECP5 (85K LUT):

[https://www.latticestore.com/products/tabid/417/categoryid/5...](https://www.latticestore.com/products/tabid/417/categoryid/59/productid/122774/default.aspx)

<comment><USER22> Also Lattice only does LUT4. (Their internal look up tables have 4 inputs) The Artix-7 has LUT6. From what i heard that means you need more than 1.6 times more LUT4 than LUT6. Not including the fact that Artix-7 includes other hardware features which are sometimes wired in to a desgin

</comment></comment><comment><USER20> This use of expensive surplus hw reminds me of the nsa@home project

[http://nsa.unaligned.org/](http://nsa.unaligned.org/)

</comment><comment><USER23> In one of the bash scripts in this article there's a lot of " || exit 1", you can enable this automatically by using "set -e" at the beginning of the script, this works for POSIX shell too. You can get extra safety in bash specifically by doing something like "set -euo pipefail" that will exit on errors, including pipeline failures and also on undefined variables.

<comment><USER3> This will make the program instantly unportable, because not all Bourne shells are POSIX-compliant. Please don't do that. || exit 1 is portable.

<comment><USER24> Where are we going to come across a Bourne shell that doesn't like `set -e`? I accept that this choice might have been dubious 20 years ago, but we don't need to support SunOS 4.1.4 or SCO anymore...

We're talking about standards that were published in 1992-1994 and that the overwhelming mass of the industry followed relatively quickly. To hold back 25 years later is nuts.

<comment><USER25> I see this crop up as "wisdom", for the sake of some quality, like that quality is an absolute. What the parent is literally advocating is that we don't ever fix the mistakes of the past.

If you are generating a script that has to run everywhere, yes have the backend emit the verbose or tricky or unergonomic construct. But most of time, breaking portability to have something that is easier to understand, or more regular, that uses modern facilities is almost always the correct solution.

<comment><USER3> How is || exit 1 harder to understand?

With the exception of GNU autotools, I know of no backends which would emit shell programs. People write programs in shells.

<comment><USER24> ????

Autotools is written in M4.. M3/M4 were developed by K&R to help automate generating mostly shell programs. In 1974-1977.

For someone who purports to be so oldschool, you're sure missing a lot.

<comment><USER3> Please take a moment to pause and consider what you're writing. Someone here wrote "let the backend generate correct code". I responded that people usually write shell programs, not backends.

<comment><USER24> You wrote that you know of no backends--- but we have a long history of macro preprocessing/expansion of shell scripts.

M4 would excel at this adaptation...

Which isn't even necessary, because everything posix conformant has "set -e". And if "posix" isn't good enough, the Bourne Shell back to 1978 has it (probably earlier).

You are hilarious, bro. :D

<comment><USER3> M4 is a generic preprocessor, not a backend shell program compiler.

And I'm not your bro.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Python PEP 3156 - Asynchronous IO Support (AKA Tulip) accepted - <AUTHOR> http://www.python.org/dev/peps/pep-3156/

<comment><USER2> I think the deadline to accept this PEP to ensure asyncio's inclusion in 3.4 was today or tomorrow. And Guido said it was either now or two years from now in 3.5?

So for Python programmers writing new code today: Are you using gevent? Are you still married to Twisted? Do you think asyncore is for more than just toy implementations? Are you crossing your fingers that Tulip will somehow get back-ported to 2.x-3.3?

Do you understand "yield from" yet?

I've been studying this for several weeks now, struggling to balance present and future. If anyone can recommend a better option for later porting (to asyncio/tulip) than toro[0] I would be forever in your debt.

[0] [http://toro.readthedocs.org/en/stable/](http://toro.readthedocs.org/en/stable/)

<comment><USER3> Yield-from already exists in 3.3... it is a performance and verbosity optimization for generators that call other generators.

<comment><USER2> I spent a couple hours last week looking for this post, but I didn't find it until now:

[https://groups.google.com/forum/#!msg/python- tulip/bmphRrryu...](https://groups.google.com/forum/#!msg/python- tulip/bmphRrryuFk/aB45sEJUomYJ)

The question I'm trying to ask is: what are other programmers doing for async in _new_ Python code if they want to support releases prior to 3.3? (I doubt many people care about supporting 3.2 nearly as much as 2.7.)</comment></comment></comment>


Ask HN: What are the best brain-interface devices that a consumer can buy rn? - <AUTHOR> <comment><USER2> The open EEG project lists some open source EEG hardware and _ahem_ 'Active Electrodes':

[http://openeeg.sourceforge.net/doc/hw/](http://openeeg.sourceforge.net/doc/hw/)

</comment><comment><USER3> A keyboard. It's the best in terms of correctness. What meaning of best are you thinking of?

<comment><USER4> I'm guessing they mean EEG monitors or similar hardware</comment></comment>


Former VW engine chief Hatz arrested in diesel investigation, reports say - <AUTHOR> http://europe.autonews.com/article/20170928/ANE/170929793/former-vw-engine-chief-arrested-in-diesel-investigation-report-says <comment><USER2> Meanwhile in Germany, VW is allowed to use tax breaks for the dieselgate fines, so the taxpayer is effectively footing the bill.

<comment><USER3> Fyi, the arrest happened in Germany on behalf of German prosecutors.

</comment></comment><comment><USER4> It's good that they are going after individuals in Germany and the US in the VW case. All too often illegal behavior is only a risk to the company but no (substantial) personal risk to the individuals involved.

</comment><comment><USER5> Always knew this was a single person's fault! Okay, and that other guy's.</comment>


A complete archive of all Intrade contracts - <AUTHOR> http://intrade-archive.appspot.com/

<comment><USER2> Seems incomplete. "Financial / Commodities" only has a few entries.

<comment><USER3> Correct. I started explicitly ignoring these categories: Too much load for the crawler and the financial indexes were already carrying this information.</comment></comment>


Ask HN: Resources for becoming great at Google Analytics - <AUTHOR>

Howdy HN,<p>What resources would you recommend to become better at Google Analytics? <comment><USER2> Try these that I pulled off Google or wade through the hell that is web optimization blogging. Your best bet is to just start playing around. You can't break anything, so go have fun.

www.google.com/grants/education/Google_Analytics_Training.pd

s3.amazonaws.com/portent-ian-files/google-analytics-cheatsheet.pdf

<http://www.webpages.uidaho.edu/~mbolin/fang.pdf>

www.mivamerchant.com/conference_2009/presentations/MivaConf%202009.ppt

publicmediametrics.org/documents.php?docid=94

[http://docs.google.com/viewer?url=http://www.imcanet.com/use...](http://docs.google.com/viewer?url=http://www.imcanet.com/userfiles/file/LTWM2008_Google_Optimization\[1\]\(1\).ppt) www.adamhowitt.com/resources/GoogleTechnologyFinal.ppt

[http://seattletechstartups.com/docs/Google_Analytics_Present...](http://seattletechstartups.com/docs/Google_Analytics_Presentation.pdf)

<comment><AUTHOR> Awesome, thanks Hamilcarbarca!</comment></comment>