Trump Is President. Now Encrypt Your Email - <AUTHOR> https://www.nytimes.com/2017/03/31/opinion/sunday/trump-is-president-now-encrypt-your-email.html <comment><USER3> Government snooping (and, generally, privacy concerns) date back to at least Obama's presidency.

I always assumed that someone would be able to access my Gmail account if they really wanted to, but didn't really care - data mine my emails to deliver more targeted ads that I ignore as easily as the others, fine by me, I thought. However, I came across [0]; whether this story is true or not, it is plausible, and that has made me want to move off of Gmail.

I still use my old Gmail account for ordinary interactions which I do not feel are sensitive and whose reading by a third party would not bother me. For sensitive material, I have moved to ProtonMail [1], a privacy-first email service based in Switzerland and therefore subject to Switzerland's privacy laws, which I use with a custom domain registered under the Cayman Islands TLD. I have moved my cloud file storage from USA owned companies to a VPS hosted in Germany and therefore subject to its data privacy laws. The last step that I haven't taken is to set up a VPN on that VPS, or alternatively purchase a VPN service from a country with good privacy laws.

Overall, I am pretty happy with my shift; I do not feel that I have given anything up and feel reasonably confident that I have the privacy I want for things I want to be private.

[0] [https://wikileaks.org/google-is-not-what-it- seems/](https://wikileaks.org/google-is-not-what-it-seems/)

[1] [https://protonmail.com/](https://protonmail.com/)

<comment><USER4> > Government snooping (and, generally, privacy concerns) date back to at least > Obama's presidency.

In a similar way to how 500 is at least 7, yeah.

To elaborate, "government snooping (and, generally, privacy concerns" date back before the founding of the US. Specific concerns around bulk electronic collection date back at least to the 70s, when concerns were raised over bulk collection of telegrams - a program ("SHAMROCK") dating back to the 40s.

Concerns about _email_ in particular were a thing in the Clinton administration (e.g., see "Carnivore").

I understand the impulse to say "but the other side does it!" And that's not wrong, per se. But it misses the point.

And what's new about Trump is not that he's engaging in more surveillance - <USER2> have no reason to believe that he is. What's new is that he's so very deeply distrusted by such a wide swath of the population.

</comment></comment><comment><USER5> Whether I do or don't, they're just going to imprison me until I comply with a judge's order to turn over the password I've forgotten from all the police beatings and solitary confinement I would have been through at the point.

Technical defenses don't work under fascism. Fascists will just physically and insidiously torture their rivals.

Security through obscurity is the only way to be pretty safe, and hopefully you can get some truly powerful political candidates elected that won't sell the populace into fascism, which is what the US is on its way towards. Beware, truly brazen fascist states will assassinate your political leaders of the opposition. See Russia and China for more details

Until then, stay underground!

<comment><USER6> It seems like "security through obscurity" could only successfully combine with encryption if a critical mass of the population got onboard very quickly. But security-conscious users are just such a minority, even programmers have bad security habits.

Anecdotally, almost everyone I know is using Gmail or Yahoo for email, and has never heard of ProtonMail or Signal. They'd probably mark an email from @protonmail.com as spam...

</comment></comment><comment><USER7> This is applicable regardless of who's in charge of the national security apparatus.

Not that encryption does much good against the state anyway; they'll just throw you in jail until you give them what they want:

[https://arstechnica.com/tech-policy/2017/02/justice-naps- man...](https://arstechnica.com/tech-policy/2017/02/justice-naps-man- jailed-16-months-for-refusing-to-reveal-passwords/)

<comment><USER8> > Not that encryption does much good against the state anyway; they'll just > throw you in jail until you give them what they want:

It's clearly not effective against active, targetted collection by the State, for the reason you mention, but, presuming the encryption itself is secure, it's useful against passive, dragnet surveillance by the State.

</comment></comment><comment><USER9> I found no where President Trump saying Snowden should be executed. He said "Spies in the old days used to be executed"

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

Maybe some haters don't see the difference, regardless NY times shouldn't rephrase it, is there another direct source of him saying that on twitter or video?

<comment><USER10> [https://mobile.twitter.com/realdonaldtrump/status/4724477348...](https://mobile.twitter.com/realdonaldtrump/status/472447734860218369?lang=en)

> _Snowden is a traitor and a disgrace. Make no mistake, he is no hero. In > fact he is a coward who should come back & face justice._

[https://mobile.twitter.com/realdonaldtrump/status/3551192663...](https://mobile.twitter.com/realdonaldtrump/status/355119266317615105?lang=en)

> _Snowden has given serious information to China and Russia-anyone who thinks > otherwise is a dope! He is a traitor who fled-he knew the crime!_

[https://mobile.twitter.com/realdonaldtrump/status/3956837027...](https://mobile.twitter.com/realdonaldtrump/status/395683702757662721?lang=en)

> _ObamaCare is a disaster and Snowden is a spy who should be executed-but if > it and he could reveal Obama 's records,I might become a major fan_

[https://mobile.twitter.com/realdonaldtrump/status/4573149344...](https://mobile.twitter.com/realdonaldtrump/status/457314934473633792?lang=en)

> _Snowden is a spy who has caused great damage to the U.S. A spy in the old > days, when our country was respected and strong, would be executed_

Maybe the 'haters' have a point on this one?

<comment><USER9> Damn that 2013 tweet he really did call for Snowden's execution, I actually think hes a hero.

</comment></comment></comment><comment><USER11> If you're using chrome, a strong recommendation for CryptUp: [https://cryptup.org/](https://cryptup.org/) <\- which does seamless gmail integration for pgp, compatible with all major external keyservers & other email encryption apps; without disclosing your keys to Google (or any third- party), or breaking your workflow.

</comment><comment><USER12> I don't get why talking about signal without mentioning that the same exact protocol is used by the (wildly more popular and Facebook owned) WhatsApp. All my family members, even an old uncle, use WhatsApp. Much easier for them, it has some cool feature nonetheless. So, my comms woth basically my whole family and friends is end-to-end encrypted. None of them was proactive in doing this, it just fell on their laps and - above all - there was Zero friction. We should advocate for making encryption default in more and more popular services, instead of writing the n-th guide or op-ed about how we all should use this or that encrypted service for the technically inclined.

<comment><USER3> WhatsApp has a userbase in the millions, if not billions. It may use the same protocol as Signal (I wasn't aware it does), but its existence is marketed as and understood as that of a messaging app. Signal's identity, in contrast, is predicated upon security. Based on that, along with the fact that Whatsapp is owned by Facebook and so its functionality can be changed by its owners, I would also probably advise acquaintances concerned about privacy to use Signal over Whatsapp.

(Personally, I've been using Threema for E2E encrypted communications with friends who care about privacy enough to not want to use Facebook Messenger or other Facebook-owned platforms.)

</comment></comment><comment><USER13> Is this a problem? I have nothing to hide.

<comment><USER14> "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." \- Edward Snowden</comment></comment>


Don't Hinge Your Career Earnings on Technical Skills Alone - <AUTHOR> https://leveragethoughts.substack.com/p/dont-hinge-your-career-on-technical <comment><AUTHOR> I wrote a post arguing on why one must not rely solely on their technical skills developed doing a STEM degree to make a living. One must also add financial education to their arsenal.

Looking forward to having a healthy conversation in the comments section</comment>


Solving Problems for Real World, Using Design - <AUTHOR> http://www.nytimes.com/2013/12/30/technology/solving-problems-for-real-world-using-design.html?ref=technology

<comment><USER2> No discussion on this story!? It's the best article I've ever read on the subject. Drilling down to the projects was quite illuminating and entertaining for me.

Projects such as Embrace ([http://embraceglobal.org/](http://embraceglobal.org/)) show how cheap products with simple design can actually have substantial impact.

The principle is universal - after you have a clear vision, creating a great product is all about tinkering & hacking.</comment>


A startup founder's hourly rate - <AUTHOR> http://ninjasandrobots.com/a-startup-founder-s-hourly-rate <comment><USER2> Yikes, this is painfully misguided.

The fact that on the 10% chance that a startup is successful the founder's time will need to ultimately have been worth $1000/hour in order to make the gamble worthwhile does not by any stretch of the imagination justify your making decisions as if your time was actually worth that much. Because nine out of ten times, your time is actually worth nothing. [Not to mention that the market doesn't care one bit what your time _would need to_ have been worth to make the gamble worth it for you, nor the fact that increasing your burn rate actually decreases the chance that you'll succeed at all]

Your time is only worth whatever you can reasonably expect it to be worth, and that _has to_ include the chance that it's worth $0. If you start only considering the upside, then you can start justifying all manner of stupid purchases: why walk when you can save six minutes ($100) per trip by keeping a limo service on-call? Why bother cooking for yourself when you can hire a private chef? Hell, why bother coding when you can "only" pay $500/hour and get a best-in-the-business programmer to do it for you? You're still "saving money".

Please don't think like this. It's a recipe for failure.

<comment><USER3> I agree. I had written a post on my blog similar to your line of tought a while back. More along the lines of people are overestimating what their time is actually worth. <http://news.ycombinator.com/item?id=3376081>

<comment><USER4> Great article! Why isn't THIS on the front page?

Direct link: [http://blog.idleworx.com/2011/12/your-time-is-not-worth- that...](http://blog.idleworx.com/2011/12/your-time-is-not-worth-that- much.html)

<comment><USER3> Thanks. I submitted it a while back but it didn't make it too far :-(

</comment></comment></comment></comment><comment><USER5> I agree with the sentiment, but in real life it doesn't work that way.

You get the pots from your parent's house because you don't have pots and you have 10k in the bank. Getting those pots extends your runway by 5%. I do agree with the idea that certain services should be bought, but if anyone really, really believed what they were doing was worth $1000 per hour the first thing they would do would be to hire a do-everything-secretary that would make coffee and lunches, would send emails and do laundry. But people don't do that, what people do is maximize the chance that they can take off.

<comment><USER6> I think 'runway extension' is an interesting/better way of treating the early stages. Using fictitious 'hourly rates' to make decisions seems strange and ultimately counter-productive. Only if you've got a clear way of making money (and customers waiting) can I see it making sense.

In general, I'm sure there are plenty of successful people for whom this worked out but there are probably as many unsuccessful people (that we don't hear from) who ended up spending cash they didn't need to. Cashflow matters.

</comment></comment><comment><USER7> This reads like a call to manage one's self in the same manner that we were managed before we quit our shitty job to do our own thing.

I don't care how much I was making before. And I don't need to code as if there were a gun to my head. I'm not worried about being beat to market, or about the expectations of capital.

I'm just going to do the work I love, within a relaxed atmosphere, in the way that makes me happiest. This seems like a way to produce good work. And eventually, good company culture.

<comment><USER8> I agree; I work for equity- not hourly rates. I work towards completing my projects because I believe them and WANT to work on them. Tasks such as talking to users & adding features is fun for me.

I was actually hoping this article would translate the amount of equity most startup founders receive into a per-hour rate. Now that would be an interesting read.

</comment></comment><comment><USER9> I _need_ to be making $100, so I'm _worth_ $1000. You know, because I'm very unlikely to succeed.

Something doesn't add up here.

That road trip to see your parents (or going out with friends, or stoping to take in the present) is valuable in itself. It gives you time to center and to regain your balance. Thinking that every hour that you take off is costing you a thousand dollars is a great way to burn out.

Saving that $30 on hosting though, that's probably not worth it.

</comment><comment><USER10> Surely a lot of this is more about cashflow vs opportunity cost rather than the "value" of your time.

I would imagine many small businesses fail because they are making the decisions that would make a lot of sense _if_ their company was the big established company that they wanted it to be but not the tiny cash strapped thing it is.

Just about any successful small business founder (not necessarily tech founders) I have spoken to has told me stories of staying up entire nights stuffing envelopes, traveling all over the place to beg/borrow expensive equipment that they required but could not afford or trying to learn HTML themselves so that they could get a basic website up.

Of course for an established company it makes no sense for the CEO to do these things but at this point survival is priority #1.

<comment><USER11> yup a little sacrifice and scrappiness goes a long way vs. chaining yourself to a desk and coding 24/7. I did however like the underlying message of "quit effing around and get stuff done" - thats advice everyone can use.

</comment></comment><comment><USER12> The only time your actual hourly value matches your potential hourly value is when 1) You have significant funding, 2) You have a time-to-market deadline, 3) You have either an income model OR a continued funding potential based on point 2. If you have all of these things, then a day trip to save $600 bucks is a waste, otherwise saving $600 dollar today gives you $600 more for tomorrow. This blog entry is naive.

</comment><comment><USER13> I'll be first to admit, that I don't get the maths.

If a startup founder's hourly rate is <potential value of work per hour> / 10 (using Author's logic).

The saving of $600 is guaranteed, assuming it takes 10 hours, the founder would be "making" $60/hour. Making it more "profitable" than working on something that could potentially worth $5000 for 10 hours (given 0.1 probability, that ends up being $50/hour).

</comment><comment><USER14> Great post and points. BUT most founders (including myself when we started) rarely follow this at least until profitability or funding. (note: I still fall into this trap from time to time)

The reality is that founders, before they have money in the bank, value money more highly than time. Money seems finite vs. time which doesn't seem to be (that's obviously wrong). It's easy to spend extra time doing something vs paying for it to be done because it feels like time is the asset you have plenty of (vs money).

In addition, doing anything can make you feel like you're making progress. When actuality, you're just mistaking activity for progress.

<comment><USER15> The problem is that spending money also spends time, whereas spending time does not also spend money.

Hypothetically, if as a one person startup, spend $1000 on rent and $1000 on food a month, and can expect to work 8 productive hours a day every day in a month (Just imaginary numbers here!)

That means we have an hourly cost of about $8 dollars an hour. Which is to say, for every 8 dollars you spend you have one less hour of time.

P.S the counter intuitive property of looking at it like this, is that if you are spending more monthly, it also takes _more_ money to loose an hour. But this is due to the fact that you have fewer hours to start with, and thus each hour is worth more.

</comment></comment><comment><USER16> I really like the sentiment of the post, and the quotes. It's easy to waste time on things that are not important when starting a business.

However, from a bootstrapping perspective, I think it is useful to look at the value of your time in a different way. If you are thinking about leaving a job that pays $100K at big company X to bootstrap something, you might think of your opportunity cost as $100K. But a lot of that $100K will go to taxes, so when you quit your job you really only loose $60K. What's more, you might spend more on living expenses with your big company job (vacations, etc), that you would give up while bootstrapping but not really miss. So, maybe you are really giving up something like $30K/year in true lost value.

I quit my big company job about 9 years ago to bootstrap a very small company. It has worked out well, and proved quite profitable by whatever measure of opportunity cost you'd like to use. But because when I quit, my taxes went to zero and my expenses went way down, I found that the actual cost to me of forgoing income for a period was much lower than I had imagined.

</comment><comment><USER17> Sometimes All You Have is Time. Sometimes, there is never enough time. The reality is, there are always limited resources of one kind or another, and your primary job as a founder is to maximize the usage of those resources in every way shape and form.

The real practical value of this should be applied to maximizing your time when you are actually "working."

Asking yourself is this coffee break, phone call, friendly chat, HN comment, or whatever else you do at work, "Directly Contributing to Making Money (i.e. talking to users, building features,etc...)"

As a consultant, I set a goal how much money I want to make this year. I assume I get about 800 actual productive work hours a year(being honest with myself) and divide it by the goal of what I want to make and now i have a minimum value of my time.

In this context, when I stay true to it, I eliminate a ton of wasted time at work because I know every moment I waste is another dollar i need to make up elsewhere.

</comment><comment><USER18> This post completely contradicts the incentives behind founding a company in the first place.

A founder should only get (truly) paid on a liquidation event, be it an IPO, acquisition, or a new round of funding (this last one being a very big no-no).

No founder should ever be paying themselves market rate. If you hire a CEO from the outside and you need them for your company to succeed, _that's_ an instance when pay market value. But, if it's just you running the company, you should be keeping cash in the company, deferring to when it really pays off.

Should you be eating ramen for 10 years until you sell a billion-dollar company? Of course not. You also shouldn't be squeezing every penny into your salary until you hit "market value."

I have a trick for how much you should pay yourself: figure out how much you need to make per month so your company focus isn't interrupted with "how am I going to pay rent this month?"

<comment><USER10> What if your not building your business with the intention of (necessarily) selling it or getting IPO?

There needs to be some point at which you say "ok, I've done well so I'm going to reward myself by upgrading my lifestyle"

</comment></comment><comment><USER19> To me, the occasional two-day road trip is necessary to preserve my sanity. Even if it's based on a thinly veiled excuse.

While I think it's important not to waste time away on twitter, reddit, hackernews et al: if you start running a tally of how much $$$ every one of your waking hours is worth, you'll drive yourself crazy.

A related issue I'm having right now though - I only want to spend my productive hours creating and developing. I don't want to do the "social media expert" work as well (test-marketing and promoting my sites, etc.) I feel that my "developer hours" are worth considerably more than the non-development work, especially given that I'm not very good at the latter. I've been thinking how I could engage my unemployed friends to help me out with testing, promoting, etc. and make it a fair deal (based on future success/web statistics) but haven't gotten very far.

</comment><comment><USER20> This line of thinking can be good motivation sometimes (like when you're wasting time commenting on HN and should be working instead, oops), but other times it can be a burden on your psyche.

If you always think in terms of "how much is this activity costing me per hour?" then you will never let yourself do anything fun or relaxing because the guilt will be too much to let yourself enjoy it.

Having fun and relaxing to prevent burnout is equally important to making your startup work, otherwise you will drive yourself (and the business) into the ground, in which case everything is worth $0 anyway.

</comment><comment><USER21> Wow, thanks for including my tweet. :) I wrote that after being annoyed that a good friend, who had finally taken the leap from his full-time engineering job and quit to do a startup with friends wasn't really doing it 100%. In fact, he got bored or something and picked up a part-time job at a clothing store.. for the "discount" he said. Even though he had about $100k already saved up and was living outside of the bay area.

</comment><comment><USER22> I've thought this way before, and it's a mistake if your bankroll isn't gigantic. Cashflow comes before hourly rate (though both are worth thinking about).

</comment><comment><USER23> I like how the articles here flip-flop between "you should be doing nothing but slaving yourself to your company" and "you gotta take some time for yourself, or you'll burn out".

</comment><comment><USER24> I don't think this post is valuable if you take it to the extreme. Obviously hiring a private chef, or limo service for a small startup is not a good idea and you will quickly run out of money. However, if you are smart with your money. Know how much runway you have, and can easily send off simpler tasks to things like Mechanical turk, etc. You can focus on what really matters... building a great product that people actually want to use.

</comment><comment><USER25> Value your time appropriately is good advice, but it does not exist in a vacuum-- the author is just working backwards here to post-justify his decision.

If anyone actually used this logic (note the expectation of 4-9 failures per success that brings about this time valuation), they would be broke very damn quickly. Good luck getting funded the next time after 4+ failures.

</comment><comment><USER26> Sbvtle has made it very difficult to distinguish visually if I have seen something from a particular writer or not. This is bad.

</comment><comment><USER27> I hate to nitpick, but it's very difficult to not get distracted by the horrible punctuation and spelling.

<comment><USER28> The author couldn't proofread because he was so busy making features and talking to users.

</comment></comment><comment><USER29> I love this line:

You should only be working on two things. Talking to users. And making features.

:)

</comment><comment><USER30> Regarding the pots example, you could divide the cost of pots by your burn rate then figure out how much time getting the pots would buy before you ran out of money.

</comment><comment><USER31> Hindsight is 20/20. For the first 18 months when I was workin for sweat equity, it turns out that, thus far, my time was worth $400 /hr then. If things continue to go well, it will have been worth even more. Also, equity is taxed at a much lower rate than salary, so when you include that consideration, it's even more. Of course, had we failed the equity would have been worth $0 :) ... So the question is like what's your time worth at the card table in Vegas? A Silly question without a crystal ball!

</comment><comment><USER32> Nice article, aside from the fact it should be proofread.

</comment><comment><USER33> i just raised a $200k round in 2 weeks, hourly rate = $595/hour. beat that, hot shot</comment>


Ask HN: How does your company determine headcount? - <AUTHOR> How does your company determine headcount for engineering and product teams?  Is it centrally controlled (say by the CTO), or distributed (say to engineering managers), or something in between?  How is PM, designer, and UX researcher headcount determined?  How are teams — and what they focus on — determined?  What are the pros/cons of your approach?
My situation:
I work for a well-funded, high-growth company with roughly 200 employees, 20 engineers, 5 product managers, and 1 designer.  Headcount decisions are all centrally planned by the CTO and CPO, with a degree of input from engineering managers and PMs about roadmaps and swags for "how long things will take."  The CTO and CPO take these inputs and map them onto "bi/annual objectives" — such as "grow monthly active users by X%."  If they feel the swags fall way short of the objectives' appetite, they will increase headcount — after a song-and-dance with Finance.
Pros: - There is a rational framework for engineering managers and PMs to influence headcount
Cons: - Engineering managers and product managers do not have the power to acquire new talent into their teams to complement or supplement the skillset and competencies of the team to deliver better quality products; only velocity seems to count - Teams that are focused on business as usual tend to be penalized with understaffing or overwork because the objective-driven rubric has mostly prioritized new strategies and products - Finance is always the "bad cop;" there's no budget that anyone is aware of (is this a real con?) <comment><USER2> That sounds like a pretty standard and rational process. I've seen headcount handled other, less rational ways.

In any environment with constrained budget (most environments), Eng managers will not have carte blanche to hire. Each person represents a long-term expense for the business and every team always wants more people.

As you roll up the reporting chain, the first person with both budget responsibility _and_ output responsibility is usually at the VP or C-level. That person is responsible for weighing the requests of Engineering / Product / Sales / Support against each other and aligning these bets with the broader strategic priorities and available resources.

Once the CEO allocates budget, why not just hand it off to the teams? When budget is only determined 1x/yr then team sizes and charters are locked for very long periods of time. A truly agile company holds its budget at a higher level and shifts whenever business needs change, maybe many times per year. Maybe everyone thought that Team A needed to hire 3 more people, but then a major customer arrived which required shifting one of those open positions to Team B. Or maybe the opportunity shrunk, and the company is best served by hiring _nobody_ and shifting that budget to a short-term outside vendor as pay-for-services.

If the company is public, then it's more complicated. Are these operational costs or capitalized costs? You probably don't care, but Wall Street definitely does. Weighing these tradeoffs is the job of the VP / CTO / CEO. Underinvestment in support + operations is either a marker of a short-sighted leader, or it's a leader explicitly making a "bad" decision to focus investment elsewhere with a higher ROI.

</comment><comment><USER3> > _200 employees, 20 engineers, 5 product managers, and 1 designer._

If you don't mind me asking, what does this company make? How is it high- growth ?

I'm asking because the ratios of engineering and design with respect to total number of employees is really low.

Talking about monthly active users suggests SaaS, in which case what is going on ? Especially with the remark that engineering struggles to hire.

I don't have much information, but this looks bad to me, and possibly an indirect consequence of being well funded and not resisting the urge to hire too many people. Again, no soecific information, just a knee-jerk reaction to ratios and shared information.</comment>


Tessel: The end of web development as we know it - <AUTHOR> http://www.slideshare.net/TechnicalMachine/tessel-the-end-of-web-development-as-we-know-it <comment><USER2> Everyone on this thread is so dismissive about the language that they forget to credit the accomplishments of these wonderful boards.

See, Javascript maybe a 'bad' language according to many of you, but it has massive adoption unlike other languages. These board creators just want to ease the path for _most_ web developers to become hardware developers. It not only opens up a whole new industry to work with, but also it creates a good 'filter' to filter out the bad ones. I will explain.

The thing about hardware _products_ is that most people dont care about internals. Most of them care about the experience. I am NOT an Apple fanboy, but in this occasion I would like to cite the iPhone's sales as a good example. If you suck at programming in Javascript, it will show up, especially in the Hardware world, easily, and you/your product will be rejected.

Also, when you develop, say, a DSLR Quadcopter[1] with this board, people aren't going to ask you "What language is it running on?", "How slow is your language?". People are going to be asking about the footage you're going to film with it. Let's not dissolve ourselves into the hatred of a language. Instead, let's take the time to appreciate what these developers have achieved and what we can build out of these boards.

Cheers.

[1]A sample DSLR quadcopter for reference: [http://farm7.staticflickr.com/6225/6868828438_e6d798c68d_b.j...](http://farm7.staticflickr.com/6225/6868828438_e6d798c68d_b.jpg)

<comment><USER3> > These board creators just want to ease the path for most web developers to > become hardware developers. It not only opens up a whole new industry to > work with, but also it creates a good 'filter' to filter out the bad ones. I > will explain.

What exactly happened to the programmers who, upon realizing that they had to use a new technology, _learned the new technology_ instead of feature-creeping something until it gets to their familiar JS boat.

I'm not going to rant that this is never going to fly. Were it based on technical consideration, the current image of Web 2.0 would have sunk like a rock, let alone even try to fly. But this is horribly inefficient and backwards that encouraging seems incredibly detrimental to our field.

Come on, people, it's not that hard. If you want to do embedded development, a reasonable subset of C is all you need to know, and it certainly takes less to learn that it took to learn half a gazillion JS frameworks. Ask your boss to give you a one or two-week leave and give you a break from your 70 hours a week streak, and learn something that's actually new for a change.

<comment><USER4> This is increasingly a false choice.

If you use node.js, you have both JavaScript and native modules.

Use JavaScript for the non performance critical parts, use C for the parts that touch the hardware, and leverage the great node ecosystem.

<comment><USER3> Leveraging the great node ecosystem comes at a significant cost in terms of power consumption, complexity of the manufacturing process, board size and of the system itself.

Power consumption and, to some extent, board size have been _very_ significant drags for the Internet of Everything. Mindlessly throwing libraries at them just to help people who are too lazy to learn a new programming technology is only adding a drag on it.

I certainly don't want to drag this into the mud. It's certainly a good learning platform which can provide exposure to a range of devices for people who would otherwise not even hear about them, or for whom the initial technological barriers would be too high to overcome in a single evening. But this is far, far from adding any kind of value to the struggle towards universal Internet connection.

<comment><USER5> If what you say is true, it's a bad sign for the future of hardware. If we fundamentally can't leverage existing libraries, we can't build the standing- on-the-shoulders-of-giants complexity pyramid that allows for such reliable, rapid development in other spaces. It will always remain a niche field.

<comment><USER3> Of course we can leverage existing libraries and standing-on-the-shoulders-of- giants complexity pyramids. Slapping a webserver on them isn't necessarily a good approach though.

</comment></comment></comment></comment></comment></comment><comment><USER6> To me the big story here is that Tessel apparently has a working JS->Lua- bytecode compiler.

Lua has by far the smallest, most portable, easy-to-integrate runtime of any embeddable language I am aware of. JavaScript has good implementations (V8, etc) but they are orders of magnitude larger, more complex, and imposing if you're linking them into your binary.

If this is truly a robust JS implementation, this means that there is now a tiny, easy-to-embed implementation of the programming language that powers the web. This could enable JavaScript to start making inroads in the "embedded language" space, and really become the language of both client and server.

If it can compile to LuaJIT bytecode also, it could also possibly be competitive in speed with other JS implementations, though some of that would depend on how efficient the resulting bytecode can be.

I think this would actually be a cool trend. Having a code-base that can run either in the browser or "natively" is a powerful approach. Though Lua is a cleaner language, JavaScript is a totally decent language if you use it right -- much better than a lot of people give it credit for. Hint: if you think JS sucks because of browser incompatibilities, what you really hate is _bad implementations_ of the language, not the language itself.

Of course another approach to achieve "one language" would be to have a Lua->JS compiler (or Lua->asm.js, or a Lua interpreter in asm.js). But Lua the language is a bit more of a moving target; to preserve cleanliness and orthogonality they sometimes break the language in non-backward-compatible ways.

<comment><USER7> But why not use Lua itself then? It is a very elegant, beautifully consistent language. In a way, it is JavaScript Done Right.

<comment><USER8> To repeat my own comment from a few week back ( [https://news.ycombinator.com/x?fnid=rYqgO4wMtljd4zBdfWM3wt](https://news.ycombinator.com/x?fnid=rYqgO4wMtljd4zBdfWM3wt) ): because enormous numbers of programmers already know JavaScript, and familiarity trumps + libraries being available trumps every other consideration when choosing a programming language, according to actual research ( [http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/pap...](http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/papers/adoptquant.pdf) ).

This is why the presentation keeps talking about web developers. There are more web developers than there are _any other kind of programmer_. If you want to make your programming platform accessible, make it accessible to web developers.

<comment><USER9> Is it really this hard for devs to learn proper languages for whatever they're doing? I almost think knowing multiple languages and having the ability to learn new ones quickly is what it means to be a programmer/developer, etc...

I'd be more interested in what embedded JavaScript would allow to be done that other existing tools can't currently do. After all, if you're a JavaScript person and you needed to do something on a device or platform, you wouldn't wait for a language runtime to become available, you'd just go learn the existing language/tools and build it?

<comment><USER10> _Is it really this hard for devs to learn proper languages for whatever they 're doing?_

It's not hard.

But given a choice between Platform A which says "write in a language that all of you already know", and Platform B which says "write in this language most of you don't already know and would have to put in time and effort to learn before you could do anything useful with this platform"... which one would you bet on?

<comment><USER11> Not sure what sort of crack everyone else is smoking, but I generally base my decisions on how painless it is to develop for a new platform rather than one I already know. Other than that, if I don't know the language, but the environment really kicks ass, I'm going to learn the damn language.

Unless I'm really rushed and have 2 days to do a vast amount of work.

<comment><USER12> Well how could you possibly know for a platform that you have no experience with?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Look, we can bolt training wheels to embedded!

This is all fun for sparking creativity, but it always seems like a massive diss to the EE's in the crowd when web devs run around fronting that they are going to disrupt the embedded world with their transpiled bloatware. EEs are so stupid and use such crap tools!!! Put some damn Bootstrap on that circuit- to-PCB layout tool. It's so not even flat OR responsive! How the fuck am I supposed to drag-n-drop my codez?!?!?!

My favorite is when someone posts a vid of LED PWM or, worse, just basic blinking... You spent how much time and money on what? And you created the embedded version of the blink tag? Definitely a web developer.

Tester board acquired. Let's go find some problems!

Can't wait until craigslist is full of requests for bringing a dream device to fruition... It'll be an iPhone-killer that also sets the temperature of your house and blinks to let you know your dog bowl just tweeted you and donate a bitcoin to the NSA because you forgot to put the induction recharger next to the eFacuet controller this morning. Equity only. NDA required.

One person converts an arduino or whatever to a red-inked start-up that gets taken out for $1B and it's on...

<comment><USER14> History and Moore's law would tell us that at some point we won't have to fiddle bits for every single embedded project.

Is that time now, maybe not. But it seems like a great tool to prototype with. I'm really confused how enabling a whole legion of programmers to get creative with hardware invokes such bitterness in you.

I'm sure what you do is very special, and this is no direct threat to that.

<comment><USER15> And history of embedded systems tells us that at all times you _will_ have to fiddle bits for nearly all embedded projects.

MCU's are getting faster at the expense of getting power hungry. Plus there are a several other things that need low level optimization that C provides. There is a reason why C has such a invincible death grip in the embedded domain. It will take you trillions of dollars worth of investment and nearly two decades of effort if you have to dethrone C from there. Nearly every stake holder, is so deeply entrenched in C its not even pragmatic to think you are going to replace at anytime sooner.

>>I'm really confused how enabling a whole legion of programmers to get creative with hardware invokes such bitterness in you.

All programming, is creativity with hardware. Because the form factor got smaller doesn't mean a thing here.

This is the gripe I have with many Rasberry Pi Users, who call printing hello, world 10 times with a python script as 'hardware hacking'. The situation is so super hilarious.

Say you wrote the same Python script on a laptop with the cover removed, now that you see the electronics inside the laptop and you are also running the python script, did you just got magically creative with hardware? Why wasn't it magic when the electronics wasn't visible.

And yes, for any real creative thing of production and mass deployment value. All the best trying to do it in anything apart from C.

</comment></comment></comment><comment><USER16> Long ago embedded systems were a pain. You programmed eproms with ASM and UV lights were involved. Someday the computorium will be so strong, cheap, and ubiquitous that you can program it with whatever you want. This isn't that day.

I applaud the spirit of what they've done, but that's a shrinkified version of a rack server, not a smartened version of a light-bulb. The Internet of things is more about swarms and emergent behaviors and less about turning everything into a tiny stand-alone version of our datacenter servers.

<comment><USER17> Consider this more a web API to GPIO instead of just a web server and you can see the inherent value.

<comment><USER16> I get it. And its a start. But its so huge and expensive its like considering the rest of the car an API to a tire.

That's a crap-ton of computer and the sysadmin that goes with it to flip a switch. I don't have a beef with programming the 'net of things in java or lua or even pascal. What I'm saying is that that's way too much computing too far down the stack. The closer we get to the GPIO pin, the less computer, expense, and electrical requirements there should be.

I'm just saying that the thing that should be hitched to the actual GPIO pin ought to look and function more like an RFID tag and less like a mini rack server.

<comment><USER18> I cannot agree (I mean I do from a pure techie point of view) but last week I got my hands in a Raspberry PI for the first time and knocked up a traffic light demo for a school in Python, with LEDs directly shoved into the ribbon cable.

I have not been so child-like excited for years.

by throwing a wasteful amount of computing power into just turning on a light, we put this in the reach of more and more people.

we could have web servers in assembly language, and it would be more efficient use of computing resources - but that's not been the optimal way and it won't be here either

<comment><USER19> Hey, this is just one of the necessary steps towards Marvin the Paranoid Android, or perhaps the sentient door...

<comment><USER18> all of which will exist in 42 years of course

</comment></comment></comment></comment></comment></comment><comment><USER20> I can understand the motivation. But not sure if I want to be surrounded by hardware powered by software written by people who think that Javascript is actually a good programming language.

<comment><USER21> I'm one of those who think Javascript is a good programming language (or at least I'd prefer it to any functional language).

Javascript is basically Scheme/Self with a C-based syntax[1][2], and both Scheme and Self are well regarded.

It has a bad reputation because of the terrible code people write using it in web browsers, but as languages go, it's pretty nice.

Browser/DOM APIs OTOH are historically pretty awful.

I suspect many of those who think it is terrible do so based n language snobbery, or they cannot separate the language from what it has been used for.

I may well be wrong, though - what _actually_ makes it a bad language in your opinion?

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

[2] [http://www.ecmascript.org/es4/spec/overview.pdf](http://www.ecmascript.org/es4/spec/overview.pdf)

<comment><USER7> That meme "Javascript is basically Scheme with a C based syntax" has been refuted so many times it's not even funny. Does it have a metacircular evaluator? Is it homoiconic? Does it have macros? Seriously, read SICP or some other Lisp book. You have no idea what you are talking about.

<comment><USER22> And yet you haven't cited even one refutation.

Javascript has first class functions. It has closures. it has nice object/literal syntax. If you don't consider it cheating to use a library, it does have macros if you use sweet.js. It has a metacircular evaluator, from the very beginning called "narcissus", and if it had homoiconicity, it would be even more direly hated than it is now. Having syntax, for better or worse, is a strength that means that people actually use the language. For reals. Not just that one time at college.

The real question is how are any of those features actually useful from anywhere but a theoretical purity standpoint? We're not exactly writing AI systems here. At the end of the day the language is there to write programs. And the sophistication of the programs you _need_ to write in javascript doesn't really need those things most of the time.

<comment><USER7> Probably one of the best written ones: [http://journal.stuffwithstuff.com/2013/07/18/javascript- isnt...](http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/)

But basically, ask anyone with Lisp experience. Only JavaScript people without Lisp experience argue that JavaScript is Lispy.

<comment><USER22> That's one. Not "so many it's not even funny". From the sound of it, you should have been able to rattle off 5 without hesitating. Maybe you meant "one. There's exactly one refutation"

as for your second remark, uh... Douglas Crockford?

<comment><USER23> Douglas Crockford just said that even though Javascript's syntax resembles an imperative language like C or Java, it's much more similar to a functional language like Lisp or Scheme. From that comment a whole myth began which states that Javascript == Scheme. That's like saying Java == C just because both are imperative. Handwavy and completely wrong.

What you should take from that assertion is "Javascript is more functional than imperative" (which is correct) and not "Javascript is lispy" (which is not).

<comment><USER24> Mark Jason Dominus also says the same thing about Perl in his _Higher Order Perl_ book [1][2] and goes onto show that Perl has 6 of the 7 features that Norvig describes has making Lisp different [3].

[1] [http://hop.perl.plover.com](http://hop.perl.plover.com)

[2] _Perl is much more like Lisp than it is like C_ (from Preface)

[3] _... the book "Paradigms of Artificial Intelligence Programming", by Peter Norvig, includes a section titled "What Makes Lisp Different?" that describes seven features of Lisp. Perl shares six of these features; C shares none of them. These are big, important features, features like first-class functions, dynamic access to the symbol table, and automatic storage management._ (also from Preface)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> Every time I see a thing about the internet of things, I get a little excited, but then they don't really show exciting examples of what you should do with it. Outside of Lockitron and Nest, I am unimpressed with what's come out so far. But it's tough. The field seems so expansive that most people get overwhelmed with possibilities, but few bare any fruit. For my part, I've only had one decent idea in the space. I'd love to see a robot that cooks food for me while I'm commuting home. Possibly like a Zojirushi rice cooker that I can program to make stuff at a certain time, but with more flexibility and a web API.

<comment><USER26> Mechanical engineering is really hard. Getting injection molds made is really expensive. 3d printed stuff is janky (right now).

<comment><USER27> Injection molding is the cheapest process on the planet, if you have a production run of >10k for a mass produced product. It is hard to find anything on Earth cheaper than an injection molded object.

<comment><USER25> That's a big damn if though.

</comment></comment></comment></comment><comment><USER28> I fail to see the connection between the end of web development and using javascript to write code for hardware (something that has been done a long time ago).

<comment><USER22> It's a marketing slogan. Marketing slogans don't have to make sense, they just need to bait your clicks _cough_ I mean get your attention.

<comment><USER29> Fool me once ...

</comment></comment></comment><comment><USER17> Tessel is another good idea that will help the DIY homebrewers to relate their existing skillsets into prototyping fresh ideas to a growing market segment.

If you object to javascript being used, by all means go back to building your 555 timers by hand or feel free to construct a competing unit in whatever religion...I mean language...you feel is the one true answer.

<comment><USER30> exactly! This is a good effort and if people have a problem with JS, why not make something like this in their language of choice? I mean i understand why people are hating on JS for this application, but I don't think "robust, mission critical systems" are the aim here. this is just for hobbyists and to let a larger number of people bring their ideas for life. Once you get those ideas out in the open, use some of u veterans could make it in a "proper" language. Currently people dont program embedded systems because the task seems daunting. This project is just an attempt to remove that initiating feel of hardware. Their motto is "Don't teach webdevs abt hardware, teach hardware about webdevs!" and it's a pretty nice way to bring a massive number of brain power to the domain of embedded systems that interact iwht the internet

</comment></comment><comment><USER31> Kudos to these guys that are doing something different. I am sure a lot of web developers out there will be more than happy to try creating new things on a completely different field using their current skills. Seriously, thank you!

It is so easy for the people here to criticize and make a lot of judgements over a few slides and their lack of knowledge of how things work in your product. Don't listen to their prejudgement, these people are obviously not your product's target.

<comment><USER17> I'd say the title is a bit much, but otherwise I couldn't agree more.

There seem to be a lot of close-minded commenters on HN on the weekends.

</comment></comment><comment><USER32> For me, this has a pretty narrow appeal:

1\. For most people, Arduino would be easier to use (being that many Arduino guys are non-programmers to begin with), with a great ecosystem and a variety of hardware.

2\. On the other hand, no one would ever use this hardware for an actual product. Cost is too high, power consumption - I assume - is also up there.

3\. As opposed to Arduino, this is not a "hard" real time system. It's severely limits the development of applications featuring, for example, motor control or orientation sensing (gyros/IMUs). And from what I'm seeing, even Arduino didn't make great strides in the commercial market; product development often requires very precise level control over your hardware as well as real development tools (namely a JTAG debugger).

So we're left with an interesting experiment, the longevity of which mainly depends on the community acceptance. It basically targets web developers that want to turn LEDs on and off. This is as far away from the "internet of things" as one can imagine, unless these things are one-off hobby projects.

Yes, embedded development sucks, and product development can be an exercise in futility and despair - but this is not the answer.

<comment><USER33> I entirely agree. I'd much rather be tied into someone else's ecosystem with an electric imp or Xively, than have to work with hardware designed by people who think the software is the difficult bit.

</comment></comment><comment><USER34> Why compile JS to Lua bytecode rather than just using Lua directly? Lua is very similar to JS, except without a lot of JS's warts.

<comment><USER35> I think the appeal is that web developers won't need to learn another language in order to do embedded development. That's another barrier to entry to embedded development lowered.

<comment><USER36> If you want to do new things, why not learn appropriate ways of doing those things? Is it really so hard to use more than one language when that makes technical sense?

<comment><USER37> As a member of a small startup (4 person technical team, all of us holding down day-jobs as well), the _prime_ decision trigger for technology is "what 'way of doing things' is the person allocated to a particular task going to be most productive in right now?". That's driven us in some directions that're non-obvious to outsiders - our stack is basically ARCH Linux, CherryPi, Python, Arduino, HTML5/JS - I can easily see people thinking "WTF? Why?", but there's some very good reasons behind those decisions - reasons which have probably allowed us to get to market 6 months earlier than if we'd chosen the stack based purely on technical merits rather than considering the skills and competencies of the existing team.

If we'd had corporate funding behind us, it'd almost certainly be different. But as a small startup, I'm 100% sure our slightly odd choices are the right ones for us. (And I could easily see why a different startup might decide node.js/javascript on the hardware was the correct choice for _their_ technical/development team)

<comment><USER38> This is perfect logic for a small startup, it is less so for a hardware team that is going to be pay dearly for changing decisions they make today (moreso than a software team). Hitting a big ecosystem is definitely a viable reason to do something when targeting developers, but what about the longer term costs associated with it? Their goal is to be the bridge that lets web devs start bringing hardware online. I think it's fair to say that other less painful languages with large developer bases were available, and some have the holy trinity of sucking less, being able to run faster, and having a sufficiently large ecosystem around them.

<comment><USER37> FWIW, we _are_ a "hardware team" as well as a software team - and we're fully aware of how much some of our decisions might cost us down the track if we don't get things right enough" today… (details masquerading as shameless self- promotion [http://holiday.moorescloud.com](http://holiday.moorescloud.com) and [http://dev.moorescloud.com](http://dev.moorescloud.com) ))

<comment><USER38> Admittedly my comment (as most comments on the internet) was a bit of armchair generalship. I honestly wish you guys the best because it's a cool concept. Would you guys consider building something for programming in Lua directly as an alternative to the JS to Lua bytecode conversion?

I just wish it hadn't been in JS, partially for the selfish reason that JS inexplicably makes me un-focus in a way that no other language can (it might be the formatting? honestly don't know why).

<comment><USER37> So I (and "we" in my posts upstream) are not the original posts JS hardware team.

(FWIW, on _our_ hardware, flipping the "dev mode" switch to "on", ssh-ing into your xmas tree lights, uncommenting the ARCH/ARM repos in mirrorlist, and running "pacman -S lua" should just work. The API for our compositor (which abstracts the fine timing details of controlling the WS2812 LEDs) is available and documented both on our dev site and on github (or if it's not today, it is scheduled to be up there by next week I think).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER39> Atwood's Law [1] seems to be holding up so far:

"Any application that can be written in JavaScript, will eventually be written in JavaScript."

[1] [http://www.codinghorror.com/blog/2007/07/the-principle-of- le...](http://www.codinghorror.com/blog/2007/07/the-principle-of-least- power.html)

</comment><comment><USER40> I hate the title of this slideshow. It should be "Opportunity for web developers to integrate hardware into their routine".

<comment><USER41> agreed.

</comment></comment><comment><USER42> This was done years ago and is running on 8B+ devices:

[http://www.oracle.com/technetwork/java/embedded/overview/get...](http://www.oracle.com/technetwork/java/embedded/overview/getstarted/index.html)

Java is pretty simple. I think that someone that can program in Javascript can handle it.

</comment><comment><USER43> Having written software for Arduino[1], I see this initiative succeeding for two main reasons:

1\. JavaScript means developers don't have to understand manual memory management to program their hardware (and many developers simply _can't_ grok manual memory management these days)

2\. node.js gives access to the npm package ecosystem - which opens up a huge potential "common lib" to hardware developers (potential because incompatibilities e.g. node.js network support vs luasocket will need to be handled)

Hardware hackers are generally a very curious bunch - they're not afraid of learning a new language on the software side, so it's not really _JavaScript_ per se that is Tessel's advantage here.

Straight to Lua could have been a second choice, but the package ecosystem in LuaRocks is hugely immature.[2] Because Lua execution in a LuaRocks-supporting environment is the exception, not the norm, most developers continue to manually bundle dependencies[3], which again doesn't encourage the package ecosystem to grow.

[1] [https://github.com/snowplow/snowplow-arduino- tracker](https://github.com/snowplow/snowplow-arduino-tracker) [2] [http://luarocks.org/repositories/rocks/](http://luarocks.org/repositories/rocks/) [3] [https://github.com/snowplow/snowplow-lua- tracker/tree/master...](https://github.com/snowplow/snowplow-lua- tracker/tree/master/src/snowplow/lib)

</comment><comment><USER44> How is this board compared to Espruino[1], Johnny Five[2] or other aurdino implementations that can run javascript?

1: [http://www.kickstarter.com/projects/48651611/espruino- javasc...](http://www.kickstarter.com/projects/48651611/espruino-javascript- for-things)

2: [http://makezine.com/2013/07/20/javascript-powered-arduino- wi...](http://makezine.com/2013/07/20/javascript-powered-arduino-with-johnny- five/)

</comment><comment><USER45> If hardware doesn't require a traditional web UI then why even use JavaScript? Did we all suddenly forget the history of why we even have to use JavaScript on the web. Here's a hint: the web browser. I don't use it cause I like it, I use it cause that's what we were forced to standardize on. There are much better languages and frameworks out there we can use for this.

<comment><USER46> Familiarity. If you are someone who builds traditional web UIs, then Javascript is what you know best, and that is the market segment they are trying to attract what this product.

If people truly want the better languages and frameworks that you mention, then the products that come out with those choices should win out in the marketplace eventually.

<comment><USER47> Except that no. Because of players within the market entrench themselves, like JavaScript for example has, there's practically no way for a change.

The iterative change is constantly restricted by past decisions, abstractions and investments. It's very hard to come up with nothnig but "good enough, sort of" solutions in this kind of a model.

I don't even know why I care. Psychology is a bitch, and I suffer. :(

</comment></comment></comment><comment><USER48> This is awesome. I have always been interested in hardware programming, but always hated the languages I had to learn to do it properly (java, c++, c, assembly, etc.).

Technology is reaching a place where I can eventually start doing embedded programming with Ruby. I can't wait for that to happen - I am sure it will.

Makes me very excited for the next 10 years.

<comment><USER49> > I have always been interested in hardware programming

Ok.

> but always hated the languages I had to learn to do it properly (java, c++, > c, assembly, etc.)

Then you weren't interested in hardware programming; not one iota. You were interested in playing around in fashionable languages.

<comment><USER50> > Then you weren't interested in hardware programming; not one iota.

That is a bit of a leap. I read what (s)he meant as more "interested in programming hardware" \- as in controlling hardware and making it do things. That doesn't mean you need to be interested in the low-level hardware side of things to be interested in making the hardware do stuff.

<comment><USER49> Failing to learn what it takes to solve a problem you have is not a viable business case. One doesn't simply decide:

"no this product i want to exist is impossible because I can't be bothered learning something new or because I have a non-technical and non-financial hipster-hued-bias against the existing commoditised technologies that lead me be able to solve the problem."

<comment><USER48> I have no idea what you are talking about here.

Who said anything about solving problems? Viable business cases?

<comment><USER49> if you have something you need to get done for work or otherwise, you use the most appropriate product.

if you "want to learn about hardware" you use the tools and resources that presently exist or make you own. Otherwise you do not want to learn about anything, you just want to screw around so you can tell your boss you are a hardware expert in ruby or some bollocks.

</comment></comment></comment></comment></comment></comment><comment><USER51> So many negative comments so let's say it loudly: this freaking rocks. Massive kudos to the team.

Maybe the performance is not yet on par with C. Maybe it will never be. But using JS means we can use this for very rapid prototyping and move on to C when we do need the performance.

The people complaining about performance are the same ones who build very fast and scalable products that nobody uses.

And about JS, let's remember there are two types of programming languages: the ones which everyone complains about, and the ones nobody uses.

</comment><comment><USER52> Being in the hardware business myself, I can only laud their attempt of simplifying and easing access. However their approach only solves a basic problem that already has been solved for quite a while (access, look at the likes of arduino, contiki os, rasperrypi). The much much harder and real problem is developing a coherent system for 'everything'/'the internet of things'. and others, particularly contiki, are much more advanced when it comes to knowledge, development state and commercialisation. So in short: I want to see product before I am impressed. Other than that I see little novelty and a bad choice of programming language for embedded dev..

</comment><comment><USER53> For the longest time I was wondering how they were fitting node.js in 32 MB RAM when V8 uses something like 256 MB of RAM. I'd never have expected cross- compiling to Lua bytecode.

</comment><comment><USER54> There are three main problems in the "internet of things" field:

1\. The lack of consumer grade sensors that can detect human presence and behavior patterns.

2\. The lack of robust models and open source software describing patterns of human interaction with environment.

3\. Insufficient and incomplete solution to power supply and interconnection problem.

I see any advance in these fields an order of magnitude more important than any new board running [modern language interpreter].

<comment><USER55> People are not going to make hardware for hospital with that dont worry,it's like 3D printers,it is for hobbists / artists...

I dont think the point is really the "internet of stuffs". Just to fool around or to do installations or prototypes.

I dont like the NodeJS logo ripoff though.

</comment></comment><comment><USER31> Watch their video here to understand the product a little better: [http://www.dragoninnovation.com/projects/22-tessel](http://www.dragoninnovation.com/projects/22-tessel)

</comment><comment><USER56> Not that this thread needs any more opinions, but I think it'll work, because the market and the people who want to build stuff with it are there.

No matter how flawed their concept might be, or how shitty JS is as an embedded language, people are out there that want to run with this idea. And when they run with it (one of Tessel's major goals seems to be getting their users to be able to get up and running fast, to boot) -- things will get made. When things get made, lives change, markets get shaken up, simple as that.

</comment><comment><USER57> The theme at this year's JavaOne was (once again) The "Internet of Things" (IOT) and the community keynote address was by Freescale's CEO who proclaimed that the price of an Internet connected (or connectable) uC would need to be about $0.30 (US). At that price point, I can see a world where everything is Internet enabled. Of course, the devices we were discussing were all running Java.

Tessel looks like another implementation that attempts to bring the same technology to another demographic. Their fancy new system (the developer doesn't touch the Lua parts), should have a broad appeal and running NodeJS provides a lot of room to extend the system in the directions needed.

I see a couple problems with IOT and another that's more specific to Tessel ... if these problems have been addressed, perhaps I haven't noticed! Tessel is based on Javascript, but there is no standard for interacting with hardware (performing I/O) in Javascript ... I think the eco-system would be healthier with a whole slew of companies like Tessel, but is anyone working on this standard? The IOT problems are more social (since we have uC that connect to the Internet today). 1) Are we ever going to take the security of devices that cost pennies seriously enough? You might not care if your water heater is rigorously protected when Internet connected, but a few thousand of them that are programmed to turn on at the same time is an issue for the power company. 2) Do I want everything around me to be that "aware". Privacy can be lost in little dribbles and we've seen our increasing power to correlate this data into your identity.

</comment><comment><USER58> I can tolerate JS, but they should also offer a direct way to code and deploy in Lua as well

</comment><comment><USER59> So the whole point is to compile JS to LUA bytecode, the rest is pretty common in all those IOT-related kickstarter projects these days. I would expect four PHDs from MIT to make JS to LUA compilers,even then, why not just use LUA directly, all language has its shiny spots in the real world, in this case, why do I need use JS at all? is LUA that hard to use or should we really use JS for everything?

</comment><comment><USER60> Great slidedeck. Most of the comments here seem to be missing the point that step 1 of 'the plan' is to make hardware more accessible.

With that background, complaining about javascript is a very "No wireless. Less space than a nomad. Lame." remark.

I haven't dabbled with any microcontrollers before, but if I ever felt like it, Tessel would be on top of my list of things to try.

</comment><comment> its-a-trappist To the Tessel team: please do not allow the negativity reflected in the above comments to deter you. You're onto something. Enabling 20,000,000 JavaScript developer to take the jump into physical computing is huge.

One suggestion: there are now several successful platforms for prototyping embedded systems: Arduino, Raspberry Pi, Beagle Board/Bone, etc. What has yet to emerge is a platform that is actually viable for low volume production. If you want to be truly disruptive, find a way to build the other components that are necessary to create real solutions: 12 volt interfaces that can be plugged into a car's accessory port and fire up when the car starts and can cleanly shut down when the power cuts; cases that not only mount the Tessel and its daughter-cards securely, but which pass standard RF emission tests; simple but secure methods for updating firmware on production systems. Make something that not only helps people get started, but helps them to build a business.

</comment><comment><USER61> After seeing HN posts such as "Why hardware development is hard: Verilog is weird"[1] I can see the value of trying to make hardware development more approachable and less niche... And JavaScript is anything but niche.

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

<comment><USER62> To be fair, this won't exactly ease hardware development in any sense that Verilog or VHDL do.

</comment></comment><comment><USER63> And there I was thinking someone finally had created webdev tooling that made webdev more bearable and more like other software engineering disciplines.

Only to find out that it's about yet another hardware board with a bloated software layer so people don't have to deal with pointers.

Meh. Sorry for being grumpy but I haven't had my morning coffee yet.

</comment><comment><USER64> The Texas Instruments CC3000 contains an embedded IPv4 stack, with no support for IPv6:

[http://www.ti.com/lit/ds/symlink/cc3000.pdf](http://www.ti.com/lit/ds/symlink/cc3000.pdf)

If you're trying to build the Internet of Everything with 40 billion devices, you're using the wrong equipment.

</comment><comment><USER65> _electrical engineering tools really suck_

No they generally don't. They are just pretty hard to use but once you get over the learning curve they are just as easy as any other program. Yet of course you still need the electrical engineering knowledge to create something useful with it.

Apart from that: neat ideas.

</comment><comment><USER66> Actually, I think this is the end of hardware prototyping as we know it. And I feel fine about that. This seems like an excellent way to prototype wireless devices before creating a more optimized design.

That said, I don't think it's going to replace said optimized design. There's a big difference between using high level languages on general purpose computers, and using it on embedded devices, and that difference is marginal cost. The marginal cost of distributing a program for a general purpose computer is independent of the performance of the program. The marginal cost of distributing a program that runs on a device you are selling is strongly dependent on the performance of the program. The slower your program, the more expensive the hardware you have to put it on.

</comment><comment><USER67> "You don't. You teach hardware about web developers."

I mean I hate the limitations of C macros and the esolang that C++ can become, as well as facets of every language, but seriously, if language is a barrier then how did anyone learn javascript? It's been said that JS is one of the languages that people think they don't need to know in order to use. Every language is like this, honestly. You write hello world and abstract away from there.

Look at it, clearly, without surrounding distractions:

\---Nobody, I mean nobody, thinks they need to know JS before they start using it, and lo and behold everyone, and I mean everyone, can learn to use it--- What a phoking coincidence!

To some degree isn't the community holding itself up by pretending JS is a security blanket instead of _cough_ that thing that Node is written in that is apparently graduating to a real language? Is anyone going to get absolutely worse at JS when it becomes totally real?

Now, when it comes to setting some pin to hi-state, it becomes very important to be able to execute some instruction to move some register value to some memory address. Do it once. Put it in a C function. Bind C function into Cython. Call Cython from Python. You never have to do engineer your code precisely once you've given the low-level part an API into a high-level language. Let me think about the barrier to entry into writing Cython. Serously, it takes 5 min. Reading the documentation on calling the function that does that thing you need to do takes 5 min.

An understanding of the device and its limitations becomes very helpful when it's breaking. That's something I don't want to figure out from the Phonegap API. I want to reduce my problem to hello world in C, the world where nothing happens if I don't do it, the clear void from which a single expression can be tested without a complicated data-model below it. VM's don't tell you about real devices. I'm not asking anyone to get their RAM emulator out, but can we get over this BS about JS and web being something for everyone but all that code architecture stuff being only for people who double-majored EE and CS? Study a line of brainfuck. Read a minimal program written in LLVM IR. Write a program that outputs '1'. You're programming in that hard stuff. I assure you, you didn't just give away four years of your life and 50k in student loans.

Meanwhile JS/HTML/CSS, while ubiquitous, suck pretty hard. JS is the least sucky. I hate HTML like I hate metastasizing pancreatic cancer. <hello><twice><everything/></hello></twice>. CSS, that language that accepts no math because expressions are hard and Photoshop is easy so only programmers end up using CSS and designers who would benefit from something easier can't be bothered to even learn that(!?!?!?!).

I maintain an application framework that uses data-binding in a terse format, Cython for fast/low-level things, and Python for the development API. AMA. =D

I do want to add on top of this criticism that I was impressed by the work and do applaud the pro-activeness going on. Openness and accessibility are very important. I just think it's very important to constantly, persistently, call "nonsense" at perceived barriers that prevent the community from bootstrapping itself in any way whatsoever. There is a way. It's okay to say JS and C++ are both crap. It's not personal. We can all learn tons of languages and have that one that we use to think in.

</comment><comment><USER68> Where is the video version of this presentation?

</comment><comment><USER69> You can run node on raspberrypi. I don't see how this is so much better.

<comment><USER4> its theoretically lower power consumption - that is a bit issue in embedded.

<comment><USER70> probably faster bootup time and smaller too. also RPi has no analog inputs. the cortex M3 has decent analog in.

I'm with the 1% of EEs who have no major issues with Tessel... except that I'll be facing 1000s of friends who want me to write device drivers for peripherals that aren't in the stock lineup. :)

</comment></comment></comment><comment><USER71> The tone of the presentation is like this: "Hurr durr, look at the dumb EEs, using bits. They probably even design and validate their stuff before implementing it, how retarded and un-agile!"

</comment><comment><USER72> Let them choose the wrong language for the task as long as the hardware is open. Is it open ?

In fact, I think it's what the "internet of things" needs: many open & low cost hardware.

<comment><USER35> Yep,

[https://github.com/technicalmachine/tessel-design- docs](https://github.com/technicalmachine/tessel-design-docs)

</comment></comment><comment><USER73> Just backed it, and I think it's a great idea -- because of npm, and I actually develop in Lua (game scripting...).

I think the commenters here are missing the point: this is a _great_ system for prototyping. Perhaps as software developers, we take prototyping for granted (too damn easy?) but prototyping in hardware is a huge business and this board is great idea.

[http://dragoninnovation.com/projects/22-tessel](http://dragoninnovation.com/projects/22-tessel)

</comment><comment><USER74> Sounds like what WigWag is doing with device.js[1] only not as mature.

[1] [http://devicejs.org/status/](http://devicejs.org/status/)

</comment><comment><USER75> Why go with WiFi instead of bluetooth? Wifi is hard. If I was to give a tessel to a friend pre-programmed, how does he enter his wifi SSID/Password?

Bluetooth avoids all that. Use a smartphone as a proxy to the web. If he doesn't have a smartphone, you could even use Twilio with MMS to send data to the 'cloud'.

Other than that, really cool idea/product. Heck even though I'm a compE I will always choose JavaScript over C/C++.

</comment><comment><USER76> I don't want to be a naysayer, but isn't this just another Internet Of Things board for the umpteenth time? I fail to see how it's anything new.

</comment><comment><USER77> JavaScript is fine. We could do a lot worse. We could also do a lot better. The point is that regardless of arguments hypothetically better languages, we are converging on a ubiquitous scripting language, and its name is JavaScript. If you don't like it, use ClojureScript or CoffeeScript or whatnot. Resisting the inevitable is only going to cost you time and mindshare.

</comment><comment><USER78> Tool's aren't the problem, I think most system level developers in industry are busy doing 'real things' to solve 'real problems' to care much about bringing about the Web-of-Things. They would rather build a sate-light communication link then get paid 50% more to program a toaster. Arduinos are much easier to use then JS.

</comment><comment><USER79> Off Topic: What's that August device they keep mentioning? I'm having a hard time googling for it. Thanks!

EDIT:

Finally I google reverse image searched and found it's the August Smart Lock: [http://www.august.com](http://www.august.com)

Just adding a .com to the august would have done it as well ;)

</comment><comment><USER80> Why all the bashing? If you don't want JS controlled hardware, use the Raspberry PI or an Arduino. It's an alternative, with a different approach directed towards people with a different skillset.

The successful funding shows that there are well enough people interested in this.

</comment><comment><USER81> Tessel has been on a pretty strong marketing push ever since the Espruino funding page went up.

<comment><USER82> It's worth giving Espruino their credit: [http://www.espruino.com/](http://www.espruino.com/)

The campaign was massively successful and a lot of devs I know are excited by it and have ordered 1 or 2 to play with. We've even ordered a couple for the office just for our devs to play with when they need distraction from their work.

<comment><USER81> I'm actually more excited about the espruino. I ordered one early on as well :)

</comment></comment></comment><comment><USER83> _" I'll often drop down to node.js if I really need to be close to the metal"_

[https://twitter.com/shit_hn_says/status/234856345579446272](https://twitter.com/shit_hn_says/status/234856345579446272)

</comment><comment><USER84> This is certainly interesting, but this title couldn't be more hyperbolic link-bait if it tried, especially since content has nothing to do with "the end of web development as we know it."

</comment><comment><USER85> Why go through JavaScript at all? Why no write what you need in Lua?

</comment><comment><USER86> Everyone is talking about the Internet of Things. I wonder when we're going to start talking about firewalls harm the Internet by breaking end-to-end connectivity.

</comment><comment><USER87> This thing will be non-optimal in terms of energy use.

Apple allows for JS in iPhone because they need to have it anyway. Anyone else should do better. At least, no JIT.

</comment><comment><USER88> Arduino for web developers!? I'm sold. I have been working with other boards and dreaming of something like this and here it is! Thanks

</comment><comment><USER89> Hardware programming in a language, that doesn't even have ints? I would call that nice joke, but I fear they are deadly serious.

</comment><comment><USER90> All I hope is that you can write code in Lua directly, rather than the far inferior JavaScript.

</comment><comment><USER91> Is the js to lua(jit) compiler available?

This would enable to write nginx/lua applications in javascript.

</comment><comment><USER92> wouldn't js -> llvm be an easier approach?

</comment><comment><USER93> Plain Lua FTW

</comment><comment><USER94> What is a Mind but a set of actively constructed fabric of neuro synaptic pathways unfolding a maximally-normalized unit-norm?</comment>


Penrose Stairs - <AUTHOR> https://en.wikipedia.org/wiki/Penrose_stairs <comment><USER2> missing in the article, but you can actually make 3D versions of this playing with perspective, although it will only work from a very specific viewing angle.

See, for example the 3D printed penrose triangles on thingiverse [https://www.thingiverse.com/thing:6513](https://www.thingiverse.com/thing:6513)</comment>


Ask HN: startups and A/B testing - <AUTHOR> tl;dr: do you have any example of scientifically sound A/B test that works for an early stage startup? Although I'm a fan of A/B testing, I've found myself confused/concerned about timings.
I was reading Google analytics docs on multi-armed bandit experiments for A/B testing. https://support.google.com/analytics/answer/2844870?hl=en&ref_topic=2844866
In summary, assuming 100 visits/day and 4% conversion rate (CvR) with page A, a scientifically significant experiment for page B to say that the new version actually generates CvR of 5% will require 66 days with the multi-armed approach, or 223 days with the naif 50%-50% approach.
To me, even 66 days seem an enormous amount of time for an early stage startup (say, 1k-to-100k users, 10% active users, growing at 5%/week), where decisions need to be made in a few days. Assuming you can pay for ads, you can probably increase the visits/day, but then the CvR drops down.
So, unless you're testing a really bad A page vs a really good B page, I can't figure out an example where the time required is acceptable (say, max 1 week).
I was wonder if anyone has real numbers that also satisfy a more theoretical appetite ;) <comment><USER2> If you're a typical early stage startup with 100 visits a day then you shouldn't be caring about the difference between 4% and 5% - it's not big enough to matter.

At that stage you should be testing big changes not little ones and increasing traffic.

<comment><AUTHOR> I agree on focusing on big changes, but these hardly need to be _A /B_ tested. A/B should be more for optimization.

So this seems to confirm my idea that (statistically sound) A/B testing is not for startups...

<comment><USER2> You should definitely be A/B testing big changes on things like landing pages.

</comment></comment></comment><comment><USER3> Measure first. Setup analytics correctly so as you get traffic, you can analyze your funnel and decide where to focus on testing.

Multi-armed bandit testing is cool, but at this point is it worth consuming brain cycles on that vs getting more traffic?

<comment><AUTHOR> I totally agree with you guys, traffic first.

But if you look around everybody is just talking about A/B testing. My point is that that doesn't look to me statistically meaningful... it's kind like you're taking the A/B testing approach, but applying it the wrong way...

What I was asking for was a real example of A/B testing for a startup, but you're basically confirming me that this doesn't exist. :)

<comment><USER3> How many steps are there in your sign-up process? What's the progression rate for each step? What area needs the biggest improvement? Focus on that.</comment></comment></comment>


What Aaron Sorkin and David Fincher get wrong about Harvard—and Facebook. - <AUTHOR> http://www.slate.com/id/2269308/

<comment><USER2> They portrayed harvard the way they did to highlight the roles privilege and elitism had to with the founding of Facebook. It's no accident facebook, whose differentiating feature from it's competitors was elitism, was born at an ivy league school, an ecosystem dependent on elitism and social connections for professional advantages. It would be hard to convey this in a 2 hour movie without exaggerating harvard life, that's film bub.</comment>


The worlds most remote base exit is still untouched - <AUTHOR> http://www.espenfadnes.com/worlds-remote-base-exit-still-untouched/

<comment><USER2> What fresh hell is responsible for the scrolling on that site? I realise that he's used to seeing the world flash before his eyes at nauseating speed, but I'm not sure it makes for a great web interface.

<comment><USER3> Scrolling works 100% in my latest firefox 27.0

<comment><USER4> But it behaves... strange. You'll notice it if you use a touchpad and kinetic scrolling. It seems too fast and somehow not very, well, kinetic.

<comment><USER5> Read the article in FF 26 and mouse-wheel scrolling was indeed way too fast and "slippery". Reminded me of all those Flash scroll bars in the 00's that just worked... horribly.\

I pulled this quickly from the source: [http://areaaperta.com/nicescroll/](http://areaaperta.com/nicescroll/)

Curiously, the nicescroll website itself seems to behave a bit better. Maybe it's this implementation that went wrong.

<comment><USER6> It works terribly on the nicescroll site itself. Why do they feel like they need to mess with the scroll behavior? Why break the expected behavior?

</comment></comment></comment></comment></comment><comment><USER7> For those of you who are as ignorant of this as me: BASE is an acronym ([http://en.wikipedia.org/wiki/BASE_jumping](http://en.wikipedia.org/wiki/BASE_jumping)). I don't really understand what _exit_ refers to in this context, anyone care to enlighten? It's surprisingly hard to google info on this, must be a really fringe thing.

<comment><USER8> As others said, exit is where you jump from. Exits matter because not all are safe vertical drops, some are way more stylistic than others and in case of BASE wingsuiting, some lead to specific lines. A line is the flight path a wingsuit pilot takes after jumping. Recent times, proximity flying has been getting more popular, where a person wearing a ram air wingsuit tries to get as close to cliffs, ground, trees or other natural elements as possible. As you can guess, lots of people die doing this.

For an example of a safe exit that immediately leads to a very spicy line, check this video, at 0:40 specifically: [https://vimeo.com/82949889](https://vimeo.com/82949889)

<comment><USER9> My palms got sweaty just watching that video. I don't think that is something I could do.

<comment><USER10> Agreed. I'm so glad the people who do record helmet-cam videos of it, and post them for me to watch instead.

</comment></comment></comment></comment><comment><USER10> What's a interesting about the article is what it _doesn 't_ describe: namely, the nature and details of the conflicts which led to the abort of the mission. I expect the writer is being polite, and considers this an open letter to both sides of the conflict(s).

That said, with all the buildup, it feels a wee bit unsatisfying to not know what went wrong. Perhaps the writer doesn't quite know for sure, since everyone (themself included) is biased.

</comment><comment><USER11> Every time I see one of these videos I have two thoughts. One, insane never could do. Two, that's what flying in my dreams looks like, I can completely see why they do what they do.

</comment><comment><USER12> Not very relevant to hacker news.

</comment><comment><USER13> What is meant by the last sentence?

> For us came on the probable cost of one big awesome flying ride off the > majestic Ulvetanna.

<comment><USER14> The failure of the group to work well cost them mission success (they couldn't do the jump).

</comment></comment><comment><USER15> I don't know why he claims it's untouched, Red Bull sent a team out to base jump from Ulvetanna back in 2010: [http://www.youtube.com/watch?v=70GIbZbBsDg](http://www.youtube.com/watch?v=70GIbZbBsDg)</comment>