Show HN: MailMist.com receive-only email accounts - <AUTHOR> http://mailmist.com/

<comment><AUTHOR> MailMist.com is a receive-only email service, which in fact is an email alias provider. To start using the service, just toss an email to email@example.com with the subject line

      Subject: alias alias_name_you_want

and that's all. Well, of course some verification process will be run, but no big deal.

MailMist is a similar approach to privacy problem as the throw away email services, or registering a valid email service provider for a throw away account with a few advantages:

\- Your mailbox(alias name) is yours, you don't share it with anybody

\- You can use it anytime with any service, for it's not a throw away mail, it will not be rejected by the services you use

\- You can create your mailbox name in seconds, without struggling with forms and captchas. You don't have to setpasswords, or secret questions either.

\- We don't allow any mail directly pass through. Spammers are filtered out using simple solutions such as SPF. You'll be receiving only(mostly) the mails you're supposed to receive.

\- You can get rid of your aliases any time you want. Any email hitting those aliases will be dropped, without bothering you.

MailMist is way beta for now and any suggestions will be very welcomed.

Thanks

</comment><comment><USER2> I like it!

Until I came across this I have always used Mailinator, which did the job. This is perhaps even easier as I can just have a single throw away email linked - and use it until I am sick of the spam.

Nice!

\--

Edit: By the way, I think the 2nd example is incorrect, should it read: `Subject: alias jason`

<comment><AUTHOR> Thank you. System allows multiple aliases per email, you can separate your aliases and services as you want. Such as using email@example.com for ..uh.. receiving from mostly spamming services, and firstname.lastname@example.com for, well...

It will also ease the filtering and grouping in MUAs as a side effect.

fixed the example.

edit: typos</comment></comment>


Show HN: This is a project I did to Manage Oracle tnsnames.ora files - <AUTHOR> http://www.tnsmagic.com/

<comment><AUTHOR> I know it needs to be updated to Vista + Windows 7. I'm planning doing it in the near future. I did it for internal company use and we all use Oracle software on XP Virtual Machine by now (for legacy motivation).

The license is going to expire in the next days, I need to make a new build :D

By the way, thanks to all the people going to review it.

</comment><comment><USER2> I really want to like this, but your website is literally devoid of any information that would help someone make a decision about using your software, or telling their friends about it. Can you please either email me more info or update the site to include at least some screenshots?

<comment><AUTHOR> Hi, yes you are right. The site, while the text say the contrary, has been made just for the people of the office :D

The screenshot on the left is _the whole_ software. It is just a menu coming up from a taskbar icon.

But yeah, I will collect some more info and send you. In the mean time you could install and try. It's a quite simple piece of software :) .

</comment></comment><comment><USER3> It looks odd on chrome on a mac: <http://imgur.com/vmu4A>

<comment><AUTHOR> thanks...I'll try to fix. As I said it was just for internal use (only windows), so I din't test too much.

Do you tested also the app?</comment></comment>


The Quest to Mimic Nature's Trickiest Colors (2014) - <AUTHOR> http://nautil.us/issue/26/color/-the-quest-to-mimic-natures-trickiest-colors

<comment><USER2> A related recent breakthrough: [https://newsoffice.mit.edu/2014/a-new-angle- on-controlling-l...](https://newsoffice.mit.edu/2014/a-new-angle-on- controlling-light) _While it has long been possible to selectively filter light according to its color or polarization, selectivity based on the direction of propagation has remained elusive._

</comment><comment><USER3> I love that her paints mix in _additive_ fashion rather than _subtractive_. Maybe someday that will be seen as the normal way to do it, when our clothes are networks of light-bending nanorobotic goo.</comment>


Deep Molecular Programming - <AUTHOR> https://arxiv.org/abs/2003.13720 <comment><USER2> A warning shot.

I'm bracing for what I think will be rapid acceleration in joint organic- machine experimentation going forward.

Over the next decade, I surmise it's likely we will see everything ranging from constructing and training large-scale organic/molecular deep neural networks with stochastic gradient descent (which is what these guys have done at a small scale) to integrating artificial networks with organic ones (which is what startups like Neuralink are doing) to who knows what else.

We live in interesting times.

</comment><comment><USER3> This paper mentions CRN++, a compiler that translates an imperative language into Chemical Reaction Networks. I had no idea this field existed. This stuff is mind bogglingly cool!

[https://arxiv.org/abs/1809.07430](https://arxiv.org/abs/1809.07430)

<comment><USER4> I skimmed the paper but I still wonder how a (practical) memory would be implemented, and how many bits it could contain.

I think these computations all happen in a "soup", and this means that the memory can only exist as a superposition of concentrations, which I suppose has its limits.

<comment><USER5> Nucleic acids store bits pretty well.

</comment></comment></comment><comment><USER6> Programmable matter. Now we are getting closer to the future we were promised.

<comment><USER7> Well, what do you think life is? It's a product of chemical computation.

</comment></comment><comment><USER8> Until when do I have to wait for an Organic Raspberry Pi to play with?

</comment><comment><USER9> How can a binary-valued network be differentiable?

<comment><USER10> The loss function needs to be differentiable. The paper uses _square hinge loss_ which is differentiable.

<comment><USER9> Thanks, and for those who are wondering how squared hinge loss is differentiable, I found:

[https://www.quora.com/Why-is-squared-hinge-loss- differentiab...](https://www.quora.com/Why-is-squared-hinge-loss- differentiable)

</comment></comment></comment><comment><USER11> future virus and worms will be scary...</comment>


Netheads vs. Bellheads (1996) - <AUTHOR> https://www.wired.com/1996/10/atm-3/ <comment><USER2> > ""How do you scare a Bellhead?" he begins. "First, show them something like > RealAudio or IPhone. Then tell them that right now performance is bandwidth- > limited, but that additional infrastructure is being deployed." Then "once > they realize their precious voice is becoming just a simple application on > data networks," point out "that the Internet is also witnessing explosive > growth combined with 45 percent returns on investment, compared to 5 percent > growth and only 12 percent or so returns for voice." In short," says Doran, > make Bellheads realize they are witnessing their extinction."

That was definitely the real fight going on - control over calls and other services, with the ability to do differentiated quasi-monopoly pricing. Ultimately:

> "IP is hard to charge for? That's not a bug, that's a feature!"

This is the defining feature of the internet: you don't have to go through the billing system.

(If you want to see a telco-designed internet protocol that's in wide use, try SIP: the separation of control and data planes is absolutely characteristic.)

<comment><USER3> > show them something like RealAudio or IPhone

I remember Real, but had forgotten the second - a VoIP phone "Not Cisco's OR Apple's" : [http://www.appleiphonereview.com/issues/see- this-1996-iphone...](http://www.appleiphonereview.com/issues/see- this-1996-iphone-ad-not-ciscos-or-apples/)

(first hit on search for "iphone 1996")

<comment><USER4> Real is still around. They occupy a floor or two of a small office building near the stadium in Seattle. From what I understand, they are essentially patent trolls now.

<comment><USER5> Few things ever cease to exist entirely. There's a hobbiest still running every flavor of VAX out there; still practicing practitioners of all sorts of weird cults. Real is no longer a software company nor can you realistically (no pun intended) use any of it's products. It has ceased to exist in all senses but historical, and the patent troll firm still bearing it's name should be seen as antiquated.

On the other hand, there's probably someone there who believes that they're still fighting the good fight against someone who cheated them, and they might be right. We've gotten so used to cheaters as a society that we really can't tell what's real achievement and what's fraud.

</comment></comment></comment></comment><comment><USER6> Sean Doran, featured in the article, was fired from Sprint the week the article was published. [https://www.wired.com/1997/11/updata-9/](https://www.wired.com/1997/11/updata-9/)

<comment><USER7> God, Wired used to be so high quality.

<comment><USER8> Content maybe, but the edgy weird fonts on garish colors at bizarre angles with varying backgrounds made the print edition unreadable.

</comment></comment></comment><comment><USER9> The MCI hub in Colorado Springs in the 90s was like something out of a movie. And everyone that worked there seemed to think they were actors in a big movie. And the Northwestern Bell / US West / Qwest people were funny, too. Both sides really did talk and act like they were the rulers of the world, and actually hated each other with a passion, but I wonder how often they go to visit the graves of uu.net or others like it. Oh, that's right, most of them were laid off or quit decades ago.

As an old voice guy, it's still hilarious to me that AT&T and Verizon are the two biggest players in cell phones, which probably carry most of the data to end users. The IP guys didn't really figure that one out until it was too late. So they won the protocol fight, but didn't get paid.

<comment><USER10> > The IP guys didn't really figure that one out until it was too late. So they > won the protocol fight, but didn't get paid.

AT&T collapsed and was reborn through mergers and slapping the facade name on a new entity, ending up in the present form as another soon to be bankrupt gigantic pile of debt with zero growth.

Meanwhile all the money went to the IP world: Google, Microsoft, Apple, Amazon, Facebook, Cisco, Qualcomm, Broadcom, Samsung, etc. The IP world saw _all_ the value gain, AT&T and Verizon - once you tally the debt, debt interest, mergers - have seen zero inflation adjusted gain in either their businesses or their stock market values in 20 years.

> AT&T and Verizon are the two biggest players in cell phones

You're incorrectly assessing where most of the money is in phones, which led you to the incorrect end conclusion about AT&T and Verizon being the ones who got paid. Apple all by itself is deriving more value from cell phones than AT&T and Verizon combined. Google search via mobile is generating ~$30 billion per year in operating income, that's more than Verizon is making from its entire mobile segment. Facebook got nearly all of its ~$24 billion in operating income over the prior four quarters from mobile.

The IP/Netheads are the only ones who actually got paid.

</comment></comment><comment><USER11> In the end did it matter? Most of the ISPs who were on the "right" side of the debate ended up bankrupt or acquired by legacy telcos anyway.

<comment><USER12> Yes, I think the only ISP left with a pure "nethead" philosophy is Cogent (see [https://www.youtube.com/watch?v=zGIKT1yw27A](https://www.youtube.com/watch?v=zGIKT1yw27A) ) and maybe HE and they aren't super-successful.

</comment></comment><comment><USER13> Kind of surprised by the number of words in here that I haven't heard in years, most of which I might add, signify mundane things, not specific technologies. Examples: "the Net," "netizen," "workstation"

<comment><USER14> 'netizen' seems to mostly be applied to mainlanders these days

</comment></comment><comment><USER15> As someone who was single-digit in years when this article was written, can anyone give a brief summary of how the fight turned out? Did the RISC-like sedimentation predicted in the article come to pass?

<comment><USER16> Insofar as ATM vs. IP, IP "won".

I had some ATM in Customer sites the late 90s as a LAN / backbone technology. By the early 2000s it was disappearing. IP over gigabit Ethernet and layer 3 switches with wire-speed routing replaced it everywhere I ever used it. ATM is still inside older DSL networks, but I haven't seen it used as a WAN technology in a long time.

I don't know enough about the innards of fast IP routers to say, but my gut says that, given the differences between IP and ATM, there's probably not much in the way of legacy ATM hiding inside our modern gear.

Insofar as the "Bellhead" vs. "Nethead" mentality, as another comment says, the majority of big "Nethead" ISPs have all been acquired by legacy telco interests (I wept inside when CenturyLink acquired Level 3, for example). In the service provider space, at least, I think that the "Bellheads" won.

<comment><USER17> There's a fossil of ATM surviving inside the ADSL protocol (although i suppose there aren't many people still using that) - ADSL has an ungodly stack of different protocols, but at some point, there's AAL5, an adaptation layer on top of ATM, which in turn sits above the physical layer. ATM cells are fixed- size and short, and AAL5 creates variable-sized long frames on top of them. PPP then uses that, and IP uses PPP.

Although from what i remember, the physical layer doesn't carry actual ATM cells; there's some scheme for packing them into large bundles, eliminating the repeated header, for more efficient transmission. So ATM is a sort of fiction which helps translate PPP messages into ADSL frames. It's been a long, long time since i really understood ADSL, though.

<comment><USER18> MPoA (you can guess what the A stands for) has replaced the older PPPoA for VDSL deployments.

<comment><USER17> TIL! I see that MP = multi-protocol:

[http://cs.hadassah.ac.il/staff/martin/Seminar/MPOA/mpoa.pdf](http://cs.hadassah.ac.il/staff/martin/Seminar/MPOA/mpoa.pdf)

</comment></comment></comment></comment></comment><comment><USER16> This was a seminal article of my youth. I still use the terms "Nethead" and "Bellhead" sometimes in conversation, and I refer people to the article fairly regularly. Setting aside the references to particular technologies, I think it gives a good background on a fundamental philosophical business difference.

</comment><comment><USER19> I knew ATM was dead when the compromised on a 53 byte cell (I.e. frame) size.

Apart from the comical absurdity of the choice, the fact that they compromised was the canary that the standards process was a mess. Compare it to the IETF process that has been quite successful.

<comment><USER20> 53 (48 payload + 5 header) was an efficient size for voice. There's no fixed size that's great for data — you always need fragmentation, so it doesn't matter much what the exact cell size is. So although it seemed like an odd number, if you have to pick a fixed size it's a good choice.

<comment><USER12> IIRC the voice people wanted 32 (+5) for lower latency and the data people wanted 64 (+5) for lower overhead.

<comment><USER20> Right. But the overhead difference between 48 and 64 for large-packet data is only about 2%, so data people were OK with 48.

32 would have been a bad choice for data, as a large fraction of all internet data packets are 40-byte TCP ACKs.

<comment><USER21> Aren't TCP ACKs 20 bytes by themselves? The 40 byte total includes IP, which would not be needed if running on ATM, right?

<comment><USER20> In most uses of ATM, a single VC (virtual circuit) carries all the data between a pair of switches. The protocol to set up a new VC is pretty expensive, so it's impractical to set up a VC for each TCP connection or even between each pair of endpoint hosts.

So mostly, VCs carry a stream of packets between switches, each with their own header.

<comment><USER21> In that case doesn't it mean there are 40 bytes of TCP/IP headers and 5 bytes of ATM headers plus a mere 8 bytes of payload per TCP packet?

<comment><USER22> ATM packets (cells?) are fixed size, but you can fragment higher level protocols across them. It's not common to run IP level fragmentation down to ATM sizes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> What ever happened to Sean Doran? His webpage[1] is over 20 years old, and I wasn't able to find anything else about him..

[1] [http://www.clock.org/~smd/new/](http://www.clock.org/~smd/new/)

<comment><USER11> As of ~3 years ago, he wasn't doing so well.

[https://www.gofundme.com/seandoran](https://www.gofundme.com/seandoran)

</comment></comment><comment><USER24> Many of my engineering school colleagues were doing internships at PMC Sierra, a chipmaker whose IP powered the ATM networks. We had many debates...

</comment><comment><USER25> Neat old story. Sean rocks. Bellheads lost except in lobbying. IP Everywhere is real. Screw the bellheads. These fools want you to put 5G uplinks in your house.

</comment><comment><USER26> Ah, I was also 25 then. I was telling my kids today, there used to be an internet with no advertisements.

<comment><USER27> They wouldn't be amused trying using that. Glacial speeds - so no multimedia; no search, no resources which became so traditional one takes them for granted, like maps, social media...

<comment><USER28> I actually enjoyed the internet more back then, or well, slightly after. I think I first went online about 1998. There was something magical about being a 9 year old fledgling programmer communicating via UDP, port scanning and connecting to services, and generally seeing what was out there.

I try to imagine it like space now. We're now looking out into space, seeing what is there. If in 1000 years we have it all mapped out and we just use Spoogle to locate something – "ore rich moon, ores:bauxite, distance:50LY" "1–243,123 results" – the fun of searching and discovering will be kind of lost.</comment></comment></comment>


Top Product Management Books? - <AUTHOR> Recommendations for top product management books? Either "how to" books or just ones that will make me better.<p>Current favorite is "Inspired" by Marty Cagan. <comment><USER2> I've been 'product managing' for 4 years now in NYC and haven't found very many books useful. Here are a few:

-Getting Real / Rework (37 signals) - Build a lean product

-Don't Make Me Think - Usability 101

-Web Analytics 2.0 - Metrics are your best friend

-Viral Loop - Great companies and how they did it

-Delivering Happiness - Last 50 pages are phenomenal for building your company's "culture"

<comment><AUTHOR> Awesome, thanks! Really appreciate the suggestions here and below.

</comment></comment><comment><USER3> Check out Blackblot's new book on Product Management "The Product Manager's Toolkit". In adition You'll find some good reading in this field on the following resource page <http://bit.ly/9qOjwB>

</comment><comment><USER4> "the art of project management", Scott Berkun. From O'reilly media.

This book is gold. but when berkun said that the job is essentially just creating/updating lists for people, i liked my job less and the book more.</comment>


What was programming like before the internet? - <AUTHOR> https://www.quora.com/What-was-programming-like-before-the-internet?ch=99&share=1b8a73bb&srid=uQDqk <comment><USER2> 1: Buy computer magazine

2: find, in amongst other articles; _" Intergalactic Battle Cruiser Hyper wars -free game code!"_ accompanied by lurid illustration showing apocalyptic space battle, replete with explosions, mighty spaceships and exotic green-skinned women in silver bikinis

3: Spend several hours laboriously typing the 3 or 4 pages of closely printed code, line by line, into your Amiga/Spectrum/Dragon/Oric/BBC Micro*

[delete as appropriate]

4: Run programme

5: _" Syntax Error: Line NNN"

6: Fix Line NNN

7: Repeat stages 4 -6 several dozen times

8: Run Programme without it crashing --yay!

9: Letters _XX>* move slowly across screen from left to right... Press spacebar... Letter _O_ moves up screen from bottom to top and hits letters _XX >_... Computer makes feeble buzzing noise, like a bluebottle's fart... Letters disappear... Screen prints _" GAME OVER! --PLAY AGAIN? Y/N"_...

10: Hit "N" and go outside and play football with your mates.

</comment><comment><USER3> Also a good read: [https://www.forbes.com/sites/quora/2013/08/05/what-was-it- li...](https://www.forbes.com/sites/quora/2013/08/05/what-was-it-like-to-be-a- programmer-without-the-internet/)

On HN: [https://news.ycombinator.com/item?id=23362667](https://news.ycombinator.com/item?id=23362667)

</comment><comment><USER4> What I enjoyed about it was that you were always on the bleeding edge. CPUs, memory, hardware I/O were all so slow you we're always looking for hardware tricks or algorithms to make things fast enough to show your ideas.

Info came through magazines, word-of-mouth, or later BBSes/usenet newsgroups (like shared email) received a couple times a day. So we were voracious for it, hang out in game/computer stores to talk to people.

Knowing/remembering was automatic as there was no other way. Always wrote/debugged programs from your head only looking up a few memory addresses you weren't sure about. Could assemble (small program) instructions to machine code in your head, and convert to 8-bit string. Get string address and 'call' it. Going to each others' houses to show n tell or pair program and play video games that we made, bought, or cracked.

</comment><comment><USER5> Nice one. I certainly remember doing more thinking before starting to code, sketching things out on paper&post-it's. No gisting or stackoverflowing things into an editor just to see if they compile! Never had to deal with punchcards, fortunately, had the built-in editors of AsmOne and/or SEKA at my disposal on the Amiga... and POKE on the MSX!

</comment><comment><USER6> > _And, as a user, you could actually call a company, get a humanoid and ask > them a question!_

Human-based customer support still exists today, at least for expensive enterprise software. Companies actually pay for yearly support contracts so they can get their questions answered and get help with technical issues.

</comment><comment><USER7> O'Reilly books. Lots of them.</comment>


New FCC Rules May Prevent Installing OpenWRT on WiFi Routers? - <AUTHOR> http://www.cnx-software.com/2015/07/27/new-fcc-rules-may-prevent-installing-openwrt-on-wifi-routers/ <comment><USER2> (Background: I'm a computer security lawyer at Stanford. This ain't legal advice.)

This is a misunderstanding. The FCC has _not_ tried to ban Wi-Fi device modding. What it _might_ be requiring is locked-down radios. And _only_ radios.

The phrasing of the recent guidance is unfortunately ambiguous, and calls out DD-WRT by name. But the original rules are clear [1], and staff guidance _cannot_ trump Commission rules.

What's more, an attempt to ban third-party software would be inconsistent with the FCC's previous policy. The agency fined Verizon, for instance, when it tried to block third-party tethering apps [2].

[1] [https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-30A1.pd...](https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-30A1.pdf)

      The software must prevent the user from operating the transmitter
      with operating frequencies, output power, modulation types or
      other radio frequency parameters outside those that were approved
      for the device.

[2] [https://www.fcc.gov/document/verizon-wireless- pay-125-millio...](https://www.fcc.gov/document/verizon-wireless- pay-125-million-settle-investigation)

<comment><USER3> For cost-saving reasons, on most WiFi access points the radio is part of the main SoC and is controlled by code running on the main CPU. So it's going to mean an end to router firmware modding in practice.

<comment><USER4> But that's not the FCC's problem.

<comment><USER5> Regulators who don't take into account possible unintended consequences of their regulations should be stripped of regulatory authority.

<comment><USER6> Because they are OMNISCIENT and can foresee every possible unintended consequence right?

<comment><USER5> You don't have to be omniscient to realize an action might have a consequence that wasn't intended. I don't go 100MPH on city roads because I don't have to be omniscient to realize I might end up killing someone even if I don't intend to.

So _OF COURSE_ regulators should consider ways in which their reulations might cause unintended harm. This is a major reason why US Federal regulators almost all have mandatory public comment periods -- third parties might be able to point out some of these unintended consequences. Regulators might not always make the right decision, but they should at least be making informed decisions.

The attitude should be "We considered that possible outcome and the benefits outweigh the harms (or not)", rather than GP's "well that shitty outcome sucks, but guess what? Not my problem".

I honestly cannot believe the idea that regulators should be considering both positive intended and negative unintended consequences of regulations is controversial.

</comment></comment></comment></comment></comment></comment><comment><USER7> Read the actual rule here: [https://apps.fcc.gov/kdb/GetAttachment.html?id=1UiSJRK869Rsy...](https://apps.fcc.gov/kdb/GetAttachment.html?id=1UiSJRK869RsyQddPi5hpw%3D%3D&desc=594280%20D02%20U-NII%20Device%20Security%20v01r02&tracking_number=39498)

Look at item #2 under "Third-Party Access Control" which states a home router manufacturer must answer this question: "What prevents third parties from loading non-US versions of the software/firmware on the device? Describe in detail how the device is protected from "flashing" and the installation of third-party firmware such as DD-WRT."

What they're doing is requiring home router manufacturers to claim their device cannot be flashed to gain FCC approval. Theoretically, the FCC could penalize router manufacturers that allow their routers to be flashed. These manufacturers would then no longer be allowed to sell their devices in the USA.

<comment><USER8> Unbelievable that it actually calls out community firmware as a threat, and DD-WRT by name. There has to be a story behind the genesis of this rule. I mean, these ROMs have been around for well over a decade now with no ill effects I'm aware of. That's not something that the FCC is going to be inclined to spontaneously regulate if someone weren't pushing for it.

So who pushed?

<comment><USER9> What you're seeing here is a policy that came into full flower in World War II but has been a part of radio since the beginning. It's the idea that all paths must be pursued to maintain absolute mastery of signals intelligence on communications channels used by the public. It's as full an example of imperial military doctrine as you will encounter anywhere. This unfortunately puts the military interests of the United States directly against the civil rights of United States Citizens.

Oh yeah, also. It's pretty settled case law that your first amendment rights do not apply to broadcast radio signals.

<comment><USER10> Is that the military, or is that just the fact that we only have so much radio spectrum (it's basically a public good) and everybody wants a piece of it? Have you taken a look at the U.S. Frequency Allocations map recently?

<comment><USER9> I have heard that the current system woefully misallocates bandwidth and that Full Frequency Spread Spectrum transmission would help with that. Of course the current system of government granted monopolies on spectrum allocation would have to go away. And that is a political event of low probability of occurence. At least this week.

</comment></comment></comment></comment></comment><comment><USER11> The FCC has an open rulemaking proceeding that would expand these requirements beyond the 5 GHz U-NII devices covered by the OET document to all Part 15 devices. See paragraphs 45 and 46 on page 18 of the Notice of Proposed Rulemaking (FCC 15-92):

      We propose to modify the SDR-related requirements in Part 2 of our rules
      based in part on the current Commission practices regarding software
      configuration control.  To minimize the potential for unauthorized
      modification to the software that controls the RF parameters of the
      device, we propose that grantees must implement well-defined measures to
      ensure that certified equipment is not capable of operating with
      RF-controlling software for which it has not been approved.  [ . . . ]
      We seek comment on these proposals.

\-- [http://transition.fcc.gov/Daily_Releases/Daily_Business/2015...](http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0722/FCC-15-92A1.pdf)

Anyone interested should file public comments with the FCC in ET Docket No. 15-170 by August 16: [http://apps.fcc.gov/ecfs/proceeding/view?name=15-170](http://apps.fcc.gov/ecfs/proceeding/view?name=15-170)

<comment><USER12> > > [http://apps.fcc.gov/ecfs/proceeding/view?name=15-170](http://apps.fcc.gov/ecfs/proceeding/view?name=15-170)

It now says "Not Found"

<comment><USER13> [http://imgur.com/VUZMVsi](http://imgur.com/VUZMVsi) [https://bpaste.net/show/832abaaa62d8](https://bpaste.net/show/832abaaa62d8)

</comment></comment></comment><comment><USER14> Unflashable firmware means you cannot remove backdoors. Given that the NSA has abused router backdoors in the past, it's not far-fetched to see this as a push from the NSA and related agencies to protect themselves. We've also seen around the world that governments are ready to great lengths to protect their surveillance abilities.

This goes far beyond the standard limitations of restrictions preventing people from innovating. It directly inhibits their ability to protect themselves or avoid conflicting interests between the manufacturer and the user (example: many wifi routers are now, without consent of the household, public access points). Especially if firmware is going to remain closed source (I see no reason why it wouldn't), this is troubling news.

</comment><comment><USER15> I sent this email to the FCC (directly to the chairman, firstname.lastname@example.com, although maybe there's a better address). Feel free to re-use.

Hi! I'm writing about the regulations described at [https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm...](https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?id=39498&switch=P)

I personally use OpenWrt on my home wireless router because it provides more capabilities than the firmware that came pre-installed. It also has a consistent interface, so I didn't have to re-learn how to configure my router when I upgraded. This gave me a lot more choice when upgrading—I didn't have to worry about staying with the same manufacturer to avoid loosing certain capabilities or having to learn a new interface. Also, OpenWrt, being open source, encounters far fewer vulnerabilities than manufacturer firmwares, and existing vulnerabilities are fixed quicker, meaning my home network stays more secure.

Not being able to install OpenWrt on newer devices will make setting up my home network far more frustrating the next time I upgrade my hardware. And on a broader scale, it'll stifle competition—upstart manufacturers will have trouble selling their solutions because businesses won't want to migrate to new software. If OpenWrt eventually becomes defunct because no new devices support it, then the situation will be even worse, because new manufactures won't have a reference point to base their firmwares off of. So these new regulations are actually very anti-competitive given the place open-source firmwares like OpenWrt play in the market.

Allowing end-users to install open-source firmwares is really important. Please reconsider your regulations against it.

</comment><comment><USER16> This is backwards. Instead of regulating devices they should just enforce the law and penalize those who break it. If you're found to be violating FCC regulations you pay a fine. This is pretty standard stuff. The top-down can't-trust-users thing is such bullshit.

The government lets me own a semi automatic rifle but I can't run non-standard firmware on my router because I might hurt someone.

<comment><USER17> And of course vendors still need to update the software, so people will just hack that method. Of course you will be violating the DMCA anti-circumvention statue, so it will be a felony. Not to mention this sounds like effectively mandating tivoization which would prevent them from shipping gplv3 code.

<comment><USER18> Vendors having to come up with an actually secure remote update procedure (rather than ad-hoc secret protocols and "factory passwords")? This is beyond the "greats" like Samsung or LG even.

</comment></comment></comment><comment><USER19> This is interesting because certain parts of the bandwidth for wifi routers crosses into the bandwidth for amateur radios. So in some instances these devices fall under Part 15 (consumer devices) and sometimes under Part 97 (amateur radio) depending on the operator and how it is used.

Some HAMs use hacked routers to implement "broadband hamnet" ([http://www.broadband-hamnet.org/](http://www.broadband-hamnet.org/)) ... theoretically they could transmit from one of these routers at 1500W (in practice much less I presume, and the rules say you have to use the minimum power necessary) ... this regulation would effectively strip them of devices and force the use of devices blessed with a "SDR" label, if I understand it correctly. Facepalm for the masses.

</comment><comment><USER20> I've always wondered what the FCC status was of devices like Sparkfun's esp8266 based boards. [0] They are all based around the same ultra cheap Chinese wifi chip. Seems like trying to make vendors lock down their consumer routers is pointless when the market is flooded with products that don't have such restrictions.

[0] [https://www.sparkfun.com/products/13287](https://www.sparkfun.com/products/13287)

<comment> TD-Linux SDRs that can transmit at wifi bandwidths are also getting cheaper by the day.

And don't forget the billions of wifi devices already out there that aren't subject to this restriction...

I really don't know what or who they are trying to protect.

<comment><USER13> I don't think it's about protection; it's power needing to stay relevant.

If we let this happen, they will continue to roll more and more things into their regulatory sphere. It's almost a law of nature. Eventually they will tell SDR owners that they need a 'license' (because bla bla safety).

The same "logic" will be applied to other gadgets. Open source cars, open baseband, and ultimately, open brain implants. Casualties in the war on general purpose computing.

</comment></comment></comment><comment><USER21> Isn't this as ridiculous as saying all Android phones should be un-flashable and locked-down since you could increase transmit power in the Linux shell, or laptops are no longer allowed to boot Linux, since you could just use your built-in WiFI to jam others. There has to be a line drawn somewhere, how do you really classify a router as a router?

The more "dangerous" WiFi modules are probably not router chips, since they are usually based on closed-source drivers/firmware, but rather ones like the ath9k ones.

Possibly the _only_ good thing that this will accomplish is the emergence of open source hardware/software "routers".

</comment><comment><USER22> The real compromise that everyone could settle for here, I think, would be to split the router's firmware into "baseband" and "control" parts, where all the regulatory stuff only applies to the baseband. Y'know, just like with smartphones.

<comment><USER23> Ah yes, lets add all the problems of vulnerable basebands to wifi routers too. No issues there.

Edit: And the possibility for purposeful maliciousness on the part of the baseband manuf. And after all, all a closed system like a baseband does is increase the cost of replacing it. It might be out of reach of you and me, but is it out of reach of everyone?

<comment><USER22> There's a reason it's called a "compromise." The FCC has a completely orthogonal set of things it cares about, none of which are software freedom. If you _don 't_ give them something like a baseband firmware, the alternative is that the entire router is the baseband firmware.

<comment><USER10> It's always funny when people object to a compromise on the grounds that they don't get everything they want.

<comment><USER24> Look, you don't have to give me 20 dollars, we can compromise, how about you give me 15 and keep 5.

There's nothing odd about rejecting a compromise when there's no validity to the demands.

</comment></comment></comment></comment></comment><comment><USER25> As much as I understand the point of protecting shared spectrum from abuse, has there been many, if at all, instances of custom firmware causing interference issues? If not, this just feels like another attempt at reigning in control over the users and taking away freedom from them.

<comment> TD-Linux There have been cases of manufacturers shipping routers without DFS, where OpenWRT correctly refuses to enable 5GHz Wifi: [http://wiki.openwrt.org/toh/tp-link/tl- wdr7500](http://wiki.openwrt.org/toh/tp-link/tl-wdr7500)

<comment><USER26> Ha!

...oh wait, are you referring to the models that only sell in china? or did the models that pass FCC also did fail?

<comment><USER27> There's a big world of around 6 billion people outside China AND US/FCC where those models could be sold too.

</comment></comment></comment></comment><comment><USER28> Isn't DD-WRT and OpenWRT just router firmwares? AFAIK they don't actually flash or touch the baseband.

The limitation for local regulation can (and should) be done in the base band, many routers will have (or at least used to have) different base bands for North America, Europe, Asia and "Other World" regions.

The router OS it self knows only how to talk to the baseband but it doesn't handle the RF part on it's own it just own.

DD-WRT doesn't know what QAM is or what beamforming is it just knows how to trigger certain flags in you BBP to put it in a specific mode.

Seems to me that all that needs to be done to comply with this ruling is for router manufacturers to ensure that the baseband complies with US regulations and that you cannot unlock these features with software which should be easy enough to achieve by just having a dedicated version for the NA market if they don't have it already.

And it's not like it's new I've only seen a few routers that DD-WRT allows you to actually unlock channel 14 in 2.4ghz is only allowed in Japan, even if channel 14 appears in the selections in many cases it won't do anything and either the radio won't work at all or it will fallback to the default channel.

<comment><USER29> The baseband such as it exists in wireless routers either doesn't run code (ath9k) or relies on the host CPU to upload a firmware image. None of the radios have their own non-volatile storage for their firmware.

<comment><USER28> Does DD-WRT modify the image? don't they work with the original broadcom firmware?

</comment></comment></comment><comment> TD-Linux This could also be a problem for wifi chips in laptops. The existing Linux regulatory domain framework has been sufficient for now.

<comment><USER30> Lenovo already forbids using "unauthorized" cards in their laptops. Most likely for related reason.

</comment></comment><comment><USER31> I am sure $ANY_COMPANY_MAKING_ROUTERS will truly care about this and somehow (for the first time in their existence) pull real security experts out of thin air to make their products secure enough to be actually impossible to re-flash to a custom firmware...Right...

<comment><USER32> As sarcastic as your comment is, the fact is preventing uploads by casual users isn't hard.

<comment><USER33> while still allowing updates, and not violating the GPL?

<comment><USER23> It'd only be problematic legally to ship GPLv3 (or similar) licensed software. v3 adds language mandating that the software be replaceable.

<comment><USER34> There is an exception if law forbids the software from being replaceable.

<comment><USER17> I don't think so. I just read the tivoization section (section 6), and skimmed the rest. The only thing allowed to prevent modifications is if it is physically not designed to do so.

</comment></comment></comment></comment></comment></comment><comment><USER35> Thank you Tom Wheeler, just when I thought there was the slightest chance you might be on the side of the consumer...

While this is probably the most effective route to curb the behavior, it also seems like the most sleazy. If you didn't want DD-WRT allowing non-region channels, why didn't you go after them directly? Probably because the uproar would have been deafening. Instead you go after the router manufacturers because they're easier to control. If you can remove their product from the market, you can instantly curb the behavior.

<comment><USER36> To be fair, DD-WRT isn't an FCC licensed entity, so I don't think there's much the FCC could actually do to them directly.

There's no license to revoke, and I don't think we want to be in a world where the FCC can issue a civil forfeiture for simply publishing code to the web.

The router manufacturers are the FCC licensees, so going after them is the easiest route to compliance.

(The other option, going after users who are broadcasting on disallowed channels or above rated power levels, is practically untenable due to issues of scale.)

<comment><USER35> Shouldn't DMCA shoot this in the head? My right to repair is essentially eliminated when they can completely lockdown the firmware. The second they decide to stop releasing updates, I no longer even have the ability to repair.

<comment><USER37> The "right to repair" under the DMCA is not freestanding like the rights to free speech or a jury trial. It's an affirmative defense ([https://en.wikipedia.org/wiki/Affirmative_defense](https://en.wikipedia.org/wiki/Affirmative_defense)) to an anti circumvention charge brought under the DMCA.

Maybe having such a free standing right would be good policy, but it's not current US law.

</comment></comment></comment></comment><comment><USER38> You could easily see these rules as going much further than OpenWRT, basically anything with a radio transmitter is fair game so that's all the way from USB wifi dongles to laptops and computers that come with installed wifi. After all whether it's a linux driver or OpenWRT doesn't seem to matter at all in this sense.

A couple more steps and Cory Doctorow will be found to be right.

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

</comment><comment><USER39> It's probably worth (re)watching Cory Doctorow's talk at 28c3: The Coming War on General Computation. He mentions this issue around the 23:45 mark, but the whole talk is great.

[https://youtu.be/HUEvRyemKSg](https://youtu.be/HUEvRyemKSg)

</comment><comment><USER40> Looks to me like the only solution in this case is to build your own: a box with PCI slots, pfSense OS, ethernet cards, and a PCI wifi card. Screw the feds!

<comment><USER41> On that note, Mikrotik also makes some fine hardware/software at prices lower than building your own and lower than most entry level consumer routers.

I don't entirely get why people buy new hardware to flash with xx-WRT, although I do get the point for recycling some already purchased gear.

<comment><USER29> When Mikrotik doesn't sell any devices that have both 2.4GHz and 5GHz radios out of the box, I don't think you can classify them separately from "build your own", unless you want to talk about how their cheap 2.4GHz-only devices stack up against the kind of D-Link devices that they give away for free when you buy a modem.

(And btw, Mikrotik's software is nothing special compared to OpenWRT. Hardware NAT support is about all you get last I checked, and it's not worth it.)

</comment></comment></comment><comment><USER42> Ok, I understand where the FCC would have an interest in regulating peoples ability to easily screw around with transmission power or frequency. But why does it have to extend to the rest of the firmware. Can we at least agree on the middle ground where the radio firmware can be locked, but the rest of the firmware is open to modification.

3 years ago I switched to TomatoUSB firmware, and since then I power cycled my router to get it to work again exactly ZERO times. It just works. I use default power and band, and I am not using any special features of the TomatoUSB, the only reason I run it is because it's rock solid, unlike EVERY stock OEM software I ever tried.

On a more interesting note, why are stock OEM firmwares so incredibly bad? I mean, there are open source alternatives they can use, or just write there own stuff that works. You would think that a large company like Linksys or Netgear would have at least one programer worth something working for them. No?

</comment><comment><USER30> This is really sick. So they want to reduce security of routers for controlling the spectrum?

</comment><comment><USER43> I'm in Australia. I _really_ don't want to have to JTAG my router to get it into an operable state.

</comment><comment><USER44> So the ubertooth isn't legal anymore?

Doesn't locking down wifi radios basically outlaw software-defined radio (SDR)? How can SDR exist without infinite control over "modulation types"?

I'm not sure that it is possible to truly lock down a radio to a particular modulation type. Transmitters aren't magic. They cannot be DRMed. They don't even run software. Send them the voltage and they send the signal.

<comment><USER45> Essentially any user-configurable SDR transmitter is sold as "measurement equipment", "non-certified technology sample" or "Class A unintentional radiator". In all cases it means that it's user's responsibility to obtain relevant transmitter licenses and/or ensure that such device does not behave like transmitter and meets all relevant EMC requirements.

</comment></comment><comment><USER46> Is the following information still relevant?

Basically it suggests a flashable device must be classified a "SDR", but FCC jurisdiction does not extend to independent software developers.

[https://www.softwarefreedom.org/resources/2007/fcc-sdr- white...](https://www.softwarefreedom.org/resources/2007/fcc-sdr- whitepaper.html)

</comment><comment><USER47> This would be really bad for consumers' security in light of the current fashion of deploying poor quality firmware full of bugs and dropping support for a product after it has been on the market for a couple of months.

I thought that the linux-wifi people had made some good efforts at regulatory compliance by signing the rules list. While this doesn't nearly make breaking the rules impossible, it makes it enough of a pain to do so that many people won't. The FCC could then go after bad actors who distribute modified blobs with one of those "Notice of Proposed Forfeiture: $25,000" actions the way they sometimes do with CB radio amplifier clowns, rude ham operators, and those pirate FM transmitter hoons who seem to be competing in a contest to demonstrate the worst engineering practices.

</comment><comment><USER48> There are two different documents referred to in the FCC document that the article links to.

The one that talks about preventing loading third party firmware only applies to 5 GHz wifi routers, not 2.4 GHz wifi routers.

The one that applies to 2.4 GHz routers looks like it only requires that software (built in or downloaded) not be able to modify operation to operate beyond the equipment authorization.

Manufacturers of 2.4 GHz routers should be able to achieve that fairly straightforwardly without taking away the ability to run third party firmware.

</comment><comment><USER49> Why is this any different from the situation with GSM (where you are sort-of required to run proprietary software and not allow anyone to flash any "bad" firmware to get a certificate)? Sure there is the ISM frequency band, but a lot of wifi hardware is physically capable of violating both: the allowed frequency and power regulations (which btw can be different in different countries).

Not that I approve this new rule - just saying that it's a natural extension of another existing rule.

<comment><USER45> There are two significant differences:

1) for GSM (and all other 3GPP radio interfaces), regulatory control is completely on the network side. Network says when, where and at what power MS must/can transmit. And significantly deviating from network-dictated parameters does not get you anything worthwhile (except in situations that are totally outside of what normal consumer can reasonably do, like attaching 30dBi directional antenna to GSM phone).

[Edit: 802.11whatever STA radio is also somehow controlled by AP, but anybody can set-up their own AP without specific license and bandwidth allocation to do so]

2) Cellular phones are typically more strictly certified than WiFi devices.

</comment></comment><comment><USER50> You can pry my channel 14 from my cold dead hands.

<comment><USER51> You sir, are the reason FCC even has a job. (Assuming channel 14 is illegal in your place of living.)

<comment><USER28> It is in NA there is a lock beyond channel 11, Europe allows upto 13, C14 is only available in Japan.

The sad part is that most wifi cards won't even able to see anything on C14 none of my phones or laptops see the network on a router which is confirmed to have an open baseband.

But on most router's I've seen the baseband doesn't actually operate on C14 even if you set it up it just defaults back to it's default channel, 12 and 13 can usually be accessed these days on NA routers as well.

Basically every time you operate on a locked channel you are breaking the law, channel 14 in the US the only one which is flat out forbidden (most likely due to overlap with military communication), while 12 and 13 are restricted.

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

</comment></comment></comment><comment><USER52> As a consumer this sucks, but it is also unfortunate for licensed ham radio operators who actually _are_ legally allowed to use greater power on certain frequencies (almost certainly more power than these devices could ever output)

</comment><comment><USER53> On a related note, time to start voting for small government. BATF has been abusing their regulatory power for a long ass time now. Need to reign in these branches.

</comment><comment><USER54> What about installing OpenWRT on RaspberryPi with USB WiFi dongle which can be used like any other router? Can they ban it as well?

<comment><USER48> (I'm not a lawyer or an FCC rules expert)

Would OpenWRT run on the Pi or on the CPU in the WiFi dongle?

Assuming the former, I don't see how there would be a problem here. It is the WiFi dongle that is the certified Part 15 device, and you would not be modifying that device. You would be using for exactly what it is designed and certified for: sticking it into a computer's USB port to provide WiFi access to that computer.

</comment></comment><comment><USER55> Question for an RF engineer: Wouldn't a filter on the output achieve the FCC's (stated) goal?

</comment><comment><USER56> Does this kill software defined radio?

</comment><comment><USER57> long time openwrt user here, FCC is focusing on the right thing with wrong priority. how can we stop that?

</comment><comment><USER58> Really? Blow me FCC - my router, my choice.

<comment><USER10> The FCC's airwaves though. I have my share of ill will towards the FCC, but fact of the matter is while the router might be yours the airwaves are the FCC's to rule.

<comment><USER17> Rule by mandating locked down buggy horrible proprietary software? Absolutely ridiculous. And of course people will just hack the proprietary channel of updates, because of course it will still be flashable. The obvious answer is, make it illegal to use software to do illegal things. Don't outlaw software freedom.

</comment></comment></comment><comment><USER59> Is it even about using put the radio into an illegal mode? OpenWRT has been around since 2004. One does notice those facist in the US governement pushing for weaking security so that the government can spy on everybody... Until there is real and actual data to back up the misuse of open source software, I must say to the FCC "liar, liar, pants on fire!"

</comment><comment><USER60> Just wait until the FCC learns about these crazy things call "software defined radios." They'll have to ban antennas outright!</comment>


HyperCard Stack: Douglas Adams' Megapode Nest Volume Calculator (1991) - <AUTHOR> https://archive.org/details/DouglasAdamsMegapode <comment><USER2> This is right up my alley and I never heard of it till now!

HyperCard was a wonderful creative tool at the time. (I'm pretty sure Bill Atkinson has stated on more than one occasion something along the lines of "If only I added hyperlinks!")

<comment><USER3> HyperCard had hyperlinks, in the sense that a card can link to another card, and even to another stack. It was networking that was omitted, really.

<comment><USER2> You could just link to a stack on a network share, but yeah.

trivia: Macintosh aliases, starting with System 7 I believe, were able to link to network shares and automount them if they weren't yet mounted

</comment></comment></comment><comment><USER4> From: Douglas Adams and Mark Carwardine - Last Chance to See

Excellent book, sad funny and eyeopening.

</comment><comment><USER5> I had to convert the .img file to a .dmg using hdiutil on OS X to get to the stack. Diskcopy under OS 9 w/Sheepshaver complained of -39 unexpected end of file otherwise.

</comment><comment><USER6> This is amazing, thank you! In the 90s I wrote way too much HyperCard and read way too much Douglas Adams, so this is bringing back great memories.

<comment><USER7> Am not sure that doing too much of either of those two things is possible...!

</comment></comment><comment><USER8> ALMOST DID THAT...

Soon after HyperCard was introduced I was working a 'sweet' IT position at The Phone Company, IBM AS/400 stuff. It was burning me out though, I liked the machines but not the corporate culture. The thought that I was destined to have my boss's boss's job some day filled me with a sense of dread, not triumph.

Before that I'd been into PCs since the late 70s 8086|Z80|S-100|CP/M|MS-DOS and had worked for a time doing board/memory level repair of Macs. So I contacted a good friend of mine who was also comp sci professor and colleague and told him "I'm dying here! What's the next best thing? What are you working on?" He told me I was ape-shit crazy and should get over it. The job I had was one that he groomed his students for and most had to leave town to get them, here I had one and was asking him for advice??

But he was really excited about Apple IIs and Macs with HyperCard and the way it could revolutionize High School and University learning. He had the idea that some day with HyperCard apps and networks you could have the brightest HS students begin to choose a curriculum for themselves sail off at their own pace, seamlessly getting through High School and into University courses by, say, 10th grade even?

He used to say "Now we go to school because that's where the teachers are. But tomorrow we'll go there because that's where the computers are." Notice the lack of the idea that computers could become affordable. Give us a break! He thought school was a necessary environment but he envisioned teachers more as advisors than broadcasters dispensing the same curriculum to all students. He also wanted to design his own HyperCard concepts from scratch with better networking. He was convinced that Apple was working to port everything to other PCs. He clearly had something like a modern web browser in mind but we didn't know that then!

If I was foolish enough to leave my IT job I was welcome to join his team, he had some students and other consultants working for him. But in the end I did something else entirely, left the Phone Company rejoining the PC world where offices were being networked to share documents and I stayed with the command line, which led into commercial Internet providers and unix servers.

My poor friend called me a couple years later to say that his investment into HyperCard, the learning courses he'd developed, and time spent had mostly been wasted because of Apple's platform lock-in and Claris predatory licensing and pricing.

</comment><comment><USER9> HyperCard was a great gateway to programming for me as a kid. I've seen Vipercard.net's faithful reproduction, which is pretty cool. What's the closest thing to HyperCard that is modern?

<comment><USER10> It looks like SuperCard is still around, can't speak to how modern it is [https://supercard.us](https://supercard.us)

<comment><USER11> I'd love to find something like that with a modern language.

</comment></comment></comment><comment><USER12> Spreadsheets stole all programming fun.

<comment><USER13> I manage to have plenty of fun in spreadsheets, but I do miss doing pixel- drawing-based animation.

</comment></comment><comment><USER14> I'm just impressed that Mac OS 7 runs on my telephone.

Does this mean that I can make a progressive web app with HyperCard? ; )

<comment><USER15> As rendered by vMac transpiled with emscripten.

<comment><USER16> It's actually the PCE emulator, not vMac: [https://github.com/jsdf/pce](https://github.com/jsdf/pce)</comment></comment></comment>


Second Skripal Poisoning Suspect Identified as Dr. Alexander Mishkin - <AUTHOR> https://www.bellingcat.com/news/uk-and-europe/2018/10/08/second-skripal-poisoning-suspect-identified-as-dr-alexander-mishkin/ <comment><USER2> I just went to the announcement at the commons which was interesting. The most important info came from the Russian outfit"The Insider" who I hope manage to continue without too much being arrested and the like. I think the main guy is hiding at the moment.</comment>


Things every React.js beginner should know - <AUTHOR> https://camjackson.net/post/9-things-every-reactjs-beginner-should-know <comment><USER3> So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or they hold off on adopting the tech until they are shown The Right Way™ by someone else.

The truth is, libraries and frameworks both end up being equally complex to work with, precisely because the _problem of building large applications is inherently difficult_.

It all comes down to personal preference:

Are you the type of person who is more likely to believe you can do something better than everyone else, or are you the type who is more likely to defer to those you believe to be better than you?

Are you decisive or do you agonize over the smallest choices?

Do you feel a compelling need to understand how everything works, or are you willing to implicitly trust other people's systems?

I find it amusing that people who gravitate toward smaller libraries like Backbone.js and React.js rail against frameworks like Ember or Angular for being overly complex, heavy, and "magical", and then proceed to cobble together a Rube-Goldberg-esque system of disparate dependencies to achieve the same goals. When React first started getting popular all you read about was how simple the API was and how it was Easy to Reason About™. Fast forward to today and you need to have working knowledge of WebPack, ES6, Redux, immutable.js, Babel, and a bevy of other dependencies to be aligned with the React ecosystem's ever-evolving best practices.

The exact same thing happened with Backbone.js and it will probably happen again with the next shiny new view-model library to ride the hype train.

It's important that I point out, however, that none of this is necessarily a bad thing. Smaller libraries like React.js and Backbone.js encourage a cavalcade of innovation from which awesome things like Redux are born. But let's not pretend that this doesn't result in a heckuva lot of churn for the average developer whose job is to simply get shit done.

<comment><USER4> You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.

<comment><USER3> > You describe ES6 as some kind of exotic dependency.

To the non Silicon Valley / Hacker News crowd, it certainly is. And using ES6 means you need to make a choice about which transpiler to use, which build tool to use, etc.

> Actually once you get rid of ES6, the only dependencies in your list are > immutable.js which is optional, and redux, which has become the well-known > default.

Well known to who, exactly? Because the "well known default" as of a few months ago was Reflux, and before that it was Flux. Oh, and there's Relay and GraphQL.

When's the "well known default" going to change again? I give it two months before everyone rushes to the next new gotta-have dependency. It's like reading Dr. Suess's The Sneetches.

<comment><USER5> You're not wrong: things do change quickly in the JavaScript world. But have you actually been following this stuff very closely?

"Flux" was never a "well-known default," because there was no single "Flux" library - only Facebook's little written guide and an implementation of the dispatcher (a small part of the overall Flux architecture).

So, there were about 500 different implementations of "Flux" \- none of which I'd say were ever considered a "well-known default" (the biggest ones - Reflux, Alt, Marty, Flummox, and Fluxxor - all have roughly between 1000 - 3000 stars on GitHub).

Then, Redux came on the scene and became the first and only "well-known default". Several of the Flux libraries I just mentioned actually deprecated themselves and put up notices to use Redux instead. As of the time of this writing Redux has almost 13,000 stars on GitHub.

Relay/Falcor are really part of an entirely different thing than React; they are about replacing the traditional REST API with an entirely new paradigm.

<comment><USER3> > But have you actually been following this stuff very closely?

I have, but I'm trying to spin my comments from the perspective of the average developer. People who are passively keeping tabs on what this whole "React" thing is about are probably feeling a little uneasy about all the churn. I agree that Redux has emerged as the clear solution for data management, and I'm a huge fan. But I don't use it with React. I'm keeping my distance from that ecosystem while the dust settles and waiting to see what kind of splash Angular 2 makes.

> Relay/Falcor are really part of an entirely different thing than React; they > are about replacing the traditional REST API with an entirely new paradigm.

But what app doesn't use a traditional REST API? Why _wouldn 't_ people want to use the latest hotness to come out of Facebook™ or Netflix™? It's this kind of uncertainty that keeps people off balance.

</comment></comment></comment></comment></comment><comment><USER6> I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

<comment><USER7> This is a debate that has been going on since I started in the late 90ies.

You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates.

Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language.

.. so they invent template languages...

... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning.

So you end up with a new language to learn, which is usually clunky and ugly just for the bragging rights of "not mixing logic & views". Which is completely stupid. Views can (and almost always need) to contain some logic and the best language for that is the one you're using everywhere else.

<comment><USER8> > ... that then expand to be turing-complete and basically offer everything > their primary language offered in the beginning.

then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty )

so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists already, but since current developers grew up with C like languages, it is not that popular.

IMHO the best compromise is direct support for XML syntax inside languages (which Javascript had at some point with E4X) because I don't think anyone will be able to make developers use LISP like languages on a wide scale. JSX, with some modifications and standardisation could also be a solution.

<comment><USER9> I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following.

Here's a function that always returns true - but it could do any kind of data access. It is just plain Clojure.

        (defn selected? [] true)

Here is a datastructure that represents html:

        [:h2 {:class (when (selected?) "selected")} "Hello"]

Calling the function hiccup.core/html on that datastructure yeilds an html string like this:

        "
Hello
"

So that's great for _strings_ right? But there is an awesome library for ClojureScript called Reagent. And it uses those simple datastructures to generate react components!! I put some more examples at: [http://hiccup.space](http://hiccup.space)

<comment><USER10> I love Clojure, but I'm tired of embedded DSLs, they're a dime a dozen. You can argue the benefits of Hiccup's syntax & s-expr all day, but it's still a different, and unpopular syntax for describing HTML.

The ability to copy snippets of HTML from web, or old code when refactoring, or from Clojure/Hiccup to another language & framework, or changes from developer tool, or familiarity for new engineers, or not having to care about what flavor of HTML is hip today is a huge productivity boost for me.

I would love to see push for template strings [1] in Clojure, it should be trivial with macros. It would only take some time for IDEs to catch up. They're good. So good they've even influenced Python 3 to add them.

        (defui my-component [x]
          "
Hello
")

[1] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/template_strings)

<comment><USER9> So you _actually_ use function names as strings? That seems like a problem, and that it would need its own special editor tooling. Yikes.

<comment><USER10>
        (defui my-component [x]

Hello
)

It's possible to macro the above to the code below, without any language extensions. IntelliJ has powerful nested DSL introspection, it would be neat if Cursive allowed to hook into this through defui's metadata for highlighting. I was a hater of JSX until I used it. Now I hate eDSLs. :D

        (defn my-component [x]
          [:h2 {:class (when (selected? x) ["selected"])} "Hello"])

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> > 5\. Use Redux.js

Well, that is not really something every React.js beginner should know. Feels weird to say that a X beginner should learn framework Y since he is probably just interested in X...

> 6\. Always use propTypes

Worth mentioning that this slows down your application since React needs to check all the props. Don't forget to set NODE_ENV=production when compiling your production script.

<comment><USER12> If you are learning MVC, only learning V is not going to get you far.

I do wonder if things like Typescript can solve a lot of the speed issues.

<comment><USER13> Why would you assume Typescript solves any speed issues?

Typescript's type checking adds overhead just the same. So it's also a good idea to disable checks during runtime.

<comment><USER14> TypeScript doesn't do any runtime checks, AFAIK. In fact, that's one of their stated goals: "Impose no runtime overhead on emitted programs." [https://github.com/Microsoft/TypeScript/wiki/TypeScript- Desi...](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals)

<comment><USER13> To-may-to, to-mah-to. That doesn't answer what I was asking.

Fact: type checking is disabled during runtime.

Why would one assume that Typescript somehow solves speed issues? It has no measurable impact on runtime performance.

<comment><USER14> I was addressing the second part of your comment. TypeScript is a static type checker. It operates at compile time. There is nothing to "disable" at runtime.

But yes, regarding your original question, you are correct, aggressive optimization is a non-goal of TypeScript. It won't improve performance.

</comment></comment></comment></comment></comment></comment><comment><USER15> #10: This guide will be out of date in 3 months.

<comment><USER16> Good that with Google you can limit your search to a certain time frame. Personally, when I Google stuff about React, I set filter to "Past month" so that most results are quite up to date. I wonder if in the future the project that you start doing in the morning will use outdated libs by the evening ;)

<comment><USER3> Does this not seem like a problem to anybody else? Wasn't the whole point of React that it was supposed to be simple? And yet things have gotten so complex you're giving advice that anything older than 3 months isn't even worth reading?

</comment></comment></comment><comment><USER17> Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it.

What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?

Thanks!

<comment><USER18> You can run "webpack-dev-server", which uses your Webpack configuration to serve your scripts with its own web server.

That means (1) it can do incremental recompilation, which I can't live without since my build takes 20 seconds; and (2) it can block requests while compiling, which is way better than having a background thing (e.g. watchify) recompile your code, since it means you're never interacting with a stale (or god forbid partial) compile.

The dev server also does automatic page reloading on recompile via some injected script magic. In my case that means I often don't even need to alt- tab to see my updates, like if I'm messing around with styling.

Webpack also has a whole paradigm that expands the use cases of require() in a pretty interesting and useful way. For example, you can tell it that require("../../icons/lolcat.png") should resolve to "static/lolcat.[8 chars of base64 SHA-256].png" and also do the appropriate file copying. Or you might want require("./stuff.csv") to resolve to a parsed JSON table, or any such transformation. There are a bunch of plugins for common uses. It's common to use require() even to load your CSS, because then Webpack can handle running it through your auto-prefixer or whatever.

It might seem kind of bloated, and I love Browserify for its simplicity, but I've come around to really like Webpack now that I've spent the proverbial 4 hours.

<comment><USER19> FYI, browserify has support for all the cool tricks you list too now; it's just a question of finding and wiring up all the right plugins.

Eg, lessify, css-modulesify, or csvify will handle the cool require tricks, browserify-hmr does the fancy hot module replacement, watchify has incremental recompiliation support if you manage to configure it _just_ right, etc.

Mind you, I find webpack easier to configure (all the fancy browserify plugins destroy it's simplicity), but the two toolchains have had feature parity for a while.

<comment><USER18> Oh, I didn't know that, thanks.

</comment></comment></comment></comment><comment><USER20> #3 Write functional components

I'd say "Write functional components where it makes sense". For simple components that is a reasonable advise, however in cases when you need such methods as `componentDidUpdate` or generally any lifecycle methods - <USER2> won't do and you have to use classes.

<comment><USER21> Not a React guy, but why couldn't the component that updated broadcast that it did so? Or is that componentDidUpdate method a callback to the message I'm describing?

<comment><USER22> Depends on what kind of component just updated. If it's a low level text field, it probably shouldn't broadcast the change to anywhere else in the program. Instead it would invoke it's 'onChange' callback. This way, there are no extra dependencies for making the text field component work. The parent component always provides the onChange callback and takes action accordingly.

However, if the component that just updated is high level, like an entire page or something, then it's reasonable to assume it's a one-off controller component and you should feel free to broadcast messages and couple the component with other parts of the program.

[https://medium.com/@dan_abramov/smart-and-dumb- components-7c...](https://medium.com/@dan_abramov/smart-and-dumb- components-7ca2f9a7c7d0#.1na8fj54h)

</comment></comment></comment><comment><USER23> Fantastic article, in the past 9 months you've hit on nearly all of my discoveries.

Something I do now every time I create a new react app is to create a base class that extends React.Component that uses `PureRenderMixin`. When doing this I can prevent unnecessary renders from props changes. A killer of this would be passing an prop to a child that always changes its identity, like passing a function that calls `bind`, Because bind create a new method every time its call the identity always changes and the method will always be re- rendered. Knowing gotchas like these can help really speed up apps!

</comment><comment><USER24> I tried a different approach here: [https://github.com/kay-is/react-from- zero](https://github.com/kay-is/react-from-zero)

</comment><comment><USER25> What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?

<comment><USER26> This isn't strictly true. Though the workflow isn't ideal yet, it's perfectly possible to build a React project which is initially rendered on the server and then progressively enhanced. I've done it before, as have others.

In fact, my single biggest criteria for any tech I add to my stack is that it doesn't get in the way of server-side rendering (the second biggest criteria is that it doesn't add significant weight to the client-side JavaScript payload).

<comment><USER25> Sounds great. Do you know any good resources for building a react application by progressive enhancement?

<comment><USER27> Google "server side React rendering".

</comment></comment></comment></comment><comment><USER28> # 3. Write functional components

Functional Components don't get Redux's connect performance optimizations which is a good reason to avoid them: [https://github.com/rackt/redux/issues/1176#issuecomment-1670...](https://github.com/rackt/redux/issues/1176#issuecomment-167015145)

<comment><USER29> I think Dan is making a different point. He's saying functional components are just like regular components in terms of speed. The author of this article is saying use functional components so it's clearer when a component needs to be split up.

<comment><USER30> I have to admit I find the author's insistence on defining a component as a function to be a big red herring. Instead, it feels like the presence of JSX outside of the component's render() method is the (potential) code smell.

It doesn't help that several popular React & React Native tutorials out there, for understandable simplicity, opt to use "renderSubThing" methods. In the examples and in my own code so far, I mostly find those sub-render methods to be a proxy for "I don't want to break stride to make a new component, so I'll jam this stuff in a method and refactor later." That's great, so long as the refactor actually happens.

(Hm, that'd be a great candidate for a vim refactoring plugin...)

</comment></comment></comment><comment><USER31> Google cache: [http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://camjackson.net/post/9-things- every-reactjs-beginner-should-know)

<comment><USER32> Should be back up now!

<comment><USER33> Hey, thanks for this.

With regards to redux-thunk, have you taken a look at redux-saga[0]? Any thoughts?

[0] [https://github.com/yelouafi/redux- saga](https://github.com/yelouafi/redux-saga)

<comment><USER32> I've seen it mentioned by a few people, including Redux creator Dan Abramov (who is very open about tweeting links to 'competing' libraries!), but I've only taken a brief look so far.

My initial impression is that it seems really interesting, although I wonder if the use of generators will scare people away. Many devs are already exhausted with the number of new JavaScript features they're being told to learn.

I definitely want to dig a bit deeper and try it out properly though.

<comment><USER34> Best comparison I've seen so far is that it's sort of like "background processing threads for Redux". The downside is that it might not mix well with time-travel debugging, because a saga effectively has its own internal state.

That said, Dan Abramov does seem to think it's a very intriguing approach, so it's worth keeping an eye on.

</comment></comment></comment></comment></comment><comment><USER35> I'v done an integration test example (no PhantomJS, just jsdom) if anyone is interested: [https://gist.github.com/tomazzaman/790bc607eb7ca3fd347f](https://gist.github.com/tomazzaman/790bc607eb7ca3fd347f)

</comment><comment><USER36> Great article! As we have been on-boarding developers with React, we noticed that all of the boilerplate needed to get Babel, Webpack, Redux, and a testing environment (we use Mocha, Karma, and Chai) was simply too much for most people to handle while beginning something new. There are lots of boilerplate projects but telling someone new to fork a project on GitHub and start building an app from there was raising some eyebrows as well.

That's not all, there are really amazing developer tools available for React development like the redux dev tools, and hot module replacement to name a couple. These tools are extremely helpful to beginners but a beginner is not going to enjoy the extra work of setting that up as well.

Imagine if you were going to build an app with Rails and the instructions were to follow a tutorial that had you manually hook up active record, create your bootstrap files by hand, write your own code to rebuild the server ever time code changed… or even forking a boilerplate Rails project and going from there. I don't believe Rails would have become what it is today without the Rails CLI.

What happens when the boilerplate changes? What if you find a XSS vulnerability in the boilerplate project that you used in your last 10 projects. Rails developers have identified and quickly patched several security vulnerabilities over the years. It's usually as easy as updating a gem file to patch your app. With the boilerplate approach, you would have to manually update all of your apps or try to merge the update from the project your forked. That isn't going to be fun at all.

Finally, one of the coolest things you can do with React is server side rendering to build universal apps. At this point, even if you know exactly what you are doing, setting up a new app is going to give you way too much work just to get started. So you'll need to find a boilerplate with server side rendering and fork it. There are way more opportunities for security issues when you increased the surface area of your app's responsibilities. There will be updates to this boilerplate and you will have to merge them into all of your apps. I hope you like manually updating files and resolving merge conflicts on files you don't really understand…

We set out to resolve these problems when we built GlueStick ([https://github.com/TrueCar/gluestick/](https://github.com/TrueCar/gluestick/)). It's a CLI that allows you to quickly generate new apps using all of the tools we like to use on React applications. You have generators for creating containers (smart components hooked up to redux), components, and reducers. Redux is set up out of the box. You have server side rendering out of the box. We also push as much of the boiler plate code into the GlueStick module as we can. This lets you easily get performace and security updates as well as new features by simply updating the node module. You also get a sane folder structure so that all of your apps built with this tool will be easy to navigate.

We built this tool at TrueCar but we open sourced it. That means you can take it and make it your own, contribute back if you want to improve it and you can rest assured that it is backed by a big company that is heavily invested in seeing it succeed.

<comment><USER37> Nice, I like this a lot. I think it's the cleanest and most concise approach I've seen re: universal React/Redux.

Is there a way to override or extend the webpack config though? (without having to fork it) What if some projects need different loaders or want to use code splitting, etc?

<comment><USER36> We have plans to implement this. I don't think it will be too hard to implement. The hard part will be coming up with a clean approach for developers as they build apps. It is on the list of things we would like to add. A PR for this would be greatly appreciated :)

</comment></comment></comment><comment><USER38> Some very good advice here but after reading through the list I had a familiar feeling. Functional, stateless, typed, Redux? Yep, that's Elm.

<comment><USER39> From what I can tell, the only reason to use React/Redux over Elm is to have a more popular resume. This is not a criticism, just an observation.

</comment></comment><comment><USER40> Good advices but I would add TypeScript as well

</comment><comment><USER41> How about TypeScript/TSX? React's components and "views" are easy to type (and you get completion in your IDE) but I still have to find a convenient way to type an Immutable map where each key/value pair has a different type (the equivalent of a TypeScript object). Any idea?

<comment><USER42> you can use the functional way of setState by passing a transaction function (state: State) => State . This allows for typed, immutable updates since the function gets passed a copy of the state.

If you need an object (say to use it in something like Redux), you have to write a wrapper like so: [https://gist.github.com/ebi/d186c4297c84d562aeae](https://gist.github.com/ebi/d186c4297c84d562aeae)

</comment></comment><comment><USER43> ``` <section> <div><h1>Latest posts</h1></div> ```

isn't that div unnecessary?

<comment><USER32> In the example as given, yes. In reality, it has `className="row"`. I stripped out all of the classes from the example code to make it easier to read.</comment></comment>


Baggage and bits: Overage fees have unintended consequences - <AUTHOR> http://www.webware.com/8301-1_109-9969570-2.html?part=rss&tag=feed&subj=Webware <comment><USER2> I don't mind pay-for-what-you-use services... "unlimited" plans of anything rarely reflect the economic realities of providing the service. Paying by usage seems intuitively fair to me.

I do mind that companies try to make money by forcing you to predict your usage in a given month. I never understood why it would be so difficult to dynamically adjust pricing as usage goes up.</comment>


What does it take to be an expert in computer programming? - <AUTHOR> https://www.quora.com/Computer-Programming/What-does-it-take-to-be-an-expert-in-computer-programming <comment><USER2> This is a transplanted answer to a Quora question:

[https://www.quora.com/Computer-Programming/What-does-it- take...](https://www.quora.com/Computer-Programming/What-does-it-take-to-be- an-expert-in-computer-programming)

The problem is that in the body of the Quora question, which is omitted in the Forbes transplantation, the asker elaborates that he wants to master C++. Without knowing that, the immediate reference to C++ makes no sense, nor does step #1 saying to "become an expert in computer programming" when that sounds like the exact question itself.

It's usually better to post the original article rather than a wrapper article, especially when the wrapper contributes nothing and even confuses matters.

Edit: BTW, answerer takes the notion of the value of being full stack and blows it out to include all of computer science, computer engineering, anthropology, sociology, psychology, literature, and poetry. Cute, and maybe entertaining to some, but probably less than truly helpful. Become a Renaissance man as a prerequisite? Sure, and pick up deity status too, ya know, just in case.

<comment><USER3> But Quora is often behind a login-wall. So linking there renders the link unusable for many (including me).

<comment><USER4> I think it is changed, I just noticed a close button on that login-wall. Does it unlock all?

<comment><USER5> Yeah, I just noticed that too, and managed to read the post.

</comment></comment></comment></comment><comment><USER6> According to Toptal and Codility, if you want to be regarded as a top web developer, you need to be able to complete 3 exercises similar to calculating the area of the intersection of two rectangles, that may or may not intersect, in 90 minutes . So, you should tailor your learning around that.

</comment><comment><USER7> Hello. I am glad this thread showed up, so I can post my all time favourite link (so far) on the subject:

what makes great programmers different: [http://www.drdobbs.com/architecture- and-design/what-makes-gr...](http://www.drdobbs.com/architecture-and- design/what-makes-great-programmers-different/240001472)

</comment><comment><USER8> An expert in computer programming might make ~$180,000. But, a non-expert with basic skills might make up to $120,000. Seems like a lot of work to get that extra $60,000.

The industry should be paying the experts at least double what they are currently making.

<comment><USER2> Or quadruple or more...

The industry -- all industries, in fact -- should be paying employees commensurate with their contribution to the success of the firm. Explain how to do that well and I'll nominate you to the Nobel Committee. In the meantime, we have startups for realizing returns from out-sized contributions.

<comment><USER9> _In the meantime, we have startups for realizing returns from out-sized contributions._

I don't think they solve the problem anymore. The VC-funded ecosystem is just another shitty corporate ladder (engineer => eng. manager => founder => angel investor (i.e. rich) => VC). It's now a reputation economy that depends more on pleasing the right people than on engineering excellence. Hot off the press: [http://michaelochurch.wordpress.com/2013/07/09/three- capital...](http://michaelochurch.wordpress.com/2013/07/09/three-capitalisms- yeoman-corporate-and-supercapitalism/)

Most of how the current crop of startups defines engineering excellence is not talent or CS expertise but "track record", especially if it involves "scaling" (that's a business anti-intellectual's nomenclature for "hard stuff I don't understand"). That has more to do with careerist maneuvering than any real drive to understand the fundamentals of computer science, software engineering, or anything else that's truly important.

I think that game's done. Yes, there are outsized returns due to the fact that the real value potential of a talented software engineer is $500k-5M, but engineers aren't going to capture the next 10 years of surplus in VC-istan. Management will.

The opportunities are somewhere else. I'd like to see more action in the mid- risk/mid-growth space that's currently underserved (too risky for bank loans, not risky enough for VC): [http://michaelochurch.wordpress.com/2013/03/26/gervais- macle...](http://michaelochurch.wordpress.com/2013/03/26/gervais- macleod-17-building-the-future-and-financing-lifestyle-businesses/)

</comment></comment></comment><comment><USER10> 1\. Become an expert in computer programming.

2\. Understand computer science.

3\. Understand computer engineering and architecture.

4\. Understand people.

5\. Understand bullshit.

Then, try programming a game from 20 years ago.

<comment><USER11> Truth is 2 is not important, 4 and 5 are most important.

<comment><USER12> #2 is very important, and sadly very under valued. You'd be surprised how many candidates I interview who don't understand the basic concepts behind time complexity. I'm not even talking about big-O. I'm talking about the idea that simple algorithms are dominated by a fundamental operation, and that in order to make said algorithm faster you must reduce the number of times you perform that fundamental operation.

So when I ask "if that method were performing too slowly, what would you do in order to make it faster?" I'm often met with answers-phrased-as-questions like "use Vector instead of ArrayList?" Or often the confident statement "use HashMap" because apparently HashMap magically makes things faster... Except we ask this question about a range query (aka checking "if x < y" instead of "if x == y").

<comment><USER11> Sorry, but understanding basic data structures is not difficult. This cannot be regarded as computer _science_. The examples he gives ("Recursive Towers of Hanoi", ...) attract the wrong people - those who are deeply depressed after their first year as 'real-world' programmer.

<comment><USER12> I agree that understanding basic data structures _shouldn 't_ be difficult, but for a remarkable number of candidates it apparently is. Further, basic data structures is as much computer science as the "cell theory" is biology. It's a set of fundamental concepts that's quite core to computer science.

</comment></comment></comment></comment></comment><comment><USER13> I stopped reading when I saw that the first step to becoming an expert programmer was to become an expert programmer.

<comment><USER14> Recursion brah.

</comment></comment><comment><USER15> According to Peter Norvig, it takes time

[http://norvig.com/21-days.html](http://norvig.com/21-days.html)

</comment><comment><USER16> "There are even serious discussions about whether C++ semantics can be formalized, that is, whether it is mathematically possible."

Since it is mechanisable (several compilers exist), surely it is "mathematically" possible to formalise the semantics. The question is maybe rather whether there exists a mathematically _elegant_ formalisation? Glancing at the formalisation of C in the K framework [1], I'm not sure the answer to this question is positive.

[1] [https://code.google.com/p/c-semantics/](https://code.google.com/p/c-semantics/)

</comment><comment><USER17> Why do I need to click the "Continue to Site" link to view the article? Is there something wrong with my browser or that's the way the website is?

</comment><comment><USER18> First prong of becoming an expert in computer programming is "becoming an expert in computer programming"? How can I read this when there is a syntax error in the third paragraph?

</comment><comment><USER19> expert in computer programming == expert in computer programming + 4 other things?!? This doesn't make sense.

<comment><USER12> "You have to walk before you can run."

Or if that's too nebulous, remember that knowledge is a hierarchy and mastery is a perception. In order for someone to perceive you as a master at a particular skill, you must also be highly competent in a number of other tangentially related skills.

<comment><USER20> But with this article (and I somewhat agree with programming in general), you have to become an expert at running before you can get really good at walking. Then you can start to learn about the finer points of the crawling maneuver, and when to apply it.

</comment></comment></comment><comment><USER21> Why is Forbes discussing this? Amd even when it is, it seems like a link baiting headline!

<comment><USER22> Forbes licensed Quora content to boost its SEO?

<comment><USER23> Seems like some kind of mutually beneficial relationship.

Looks like Quora is a contributor to Forbes[1], but that no one gets paid[2]. At least that's what the answer that I can read without signing up for Quora says...

[1] - [http://www.forbes.com/sites/quora/2013/07/08/what-does-it- ta...](http://www.forbes.com/sites/quora/2013/07/08/what-does-it-take-to-be- an-expert-in-computer-programming/)

[2] - [http://www.quora.com/Quora/When-a-Quora-users-content-is- rep...](http://www.quora.com/Quora/When-a-Quora-users-content-is-reproduced- on-Slate-or-Forbes-or-any-partner-for-that-matter-is-the-user-compensated)</comment></comment></comment>