Uber and Lyft don't have a right to exist - <AUTHOR> https://jalopnik.com/uber-and-lyft-dont-have-a-right-to-exist-1837680434/ <comment><USER2> _[California Assembly Bill 5] would suck Uber, Lyft, and other gig economy platforms out of their legal vacuum and into well-defined orbits of labor law. It would be doing so in a way that tracks with the reality of their businesses and a common-sense definition of what an "employee" is._

I don't think that a common sense definition of what an "employee" is includes "show up to work whenever you want, take whatever breaks you want, knock off whenever you want, show up wherever you want, work for another company at the same instant you're working for us, get paid for jobs completed rather than hours worked, have a genuine prospect to show a profit or loss, use your own equipment" and likely several other key elements of the Uber/Lyft driver- company relationship.

I agree they're not 100% independent either, but I tend to view them as more independent than employees.

<comment><USER3> "Well, actually..."

Lots of companies are very flexible about employees setting their own hours.

Lots of companies in the service business do not care whether an employee has a second job with another company, even a "competitor."

The issue around getting paid for jobs completed is absolutely a non-issue. Lots of employees are paid for piece-work, or equivalently have paid-for- performance structures.

The issue is whether such payment can drop below minimum-wage laws, and the answer in law is, "no."

So, frankly, while Uber and Lyft are certainly doing their best to act like their drivers are not employees, the criteria you give here do not disqualify them from being considered employees, as there are a non-trivial number of companies that have arrangements like this with their employees.

I'm left to think that it is certainly reasonable for a court to consider all these issues in aggregate and make a determination. It does not strike me as "obvious" either way.

<comment><USER4> > Lots of companies in the service business do not care whether an employee > has a second job with another company, even a "competitor."

Absolutely none of them will let you be on the clock with a competitor at the same time you're on the clock with them.

<comment><USER5> Neither do Uber or Lyft. No driver performs an Uber ride and a Lyft ride at the same point in time.

</comment></comment></comment></comment><comment><USER6> There's constant arguments about this, whether a driver for Lyft / Uber, or a delivery driver of Grubhub, Doordash, UberEats, is either an employee or contractor. And yet, I haven't seen talk of the creation of a new type of worker, one for the gig economy.

I get that there's a big difficulty in creating these laws, with politicians who don't know exactly what the solution is, but someone needs to start by saying look, these gig economy workers are neither "employees" or "contractors" with the current law definitions, so we're going to create a new definition of worker geared towards these cases which makes sure employees aren't being taken advantage of, but also makes it possible for these companies to continue.

<comment><USER7> >also makes it possible for these companies to continue.

Taxi companies have been following worker laws for forever, it's not impossible at all. These companies are just spreading FUD, like big ISPs did back when net neutrality was imposed: [https://www.techdirt.com/articles/20151001/12131332412/hey-r...](https://www.techdirt.com/articles/20151001/12131332412/hey- remember-how-net-neutrality-was-supposed-to-destroy-internet.shtml)

<comment><USER8> Taxi companies have been treating their drivers as contractors in the state of California for forever. It seems like some of them have been having legal trouble lately because of it too: [https://www.shrm.org/resourcesandtools/legal-and- compliance/...](https://www.shrm.org/resourcesandtools/legal-and- compliance/state-and-local-updates/pages/california-cab-driver-was- independent-contractor.aspx)

</comment></comment></comment><comment><USER9> If you sign the petition be wary of this:

I agree that Uber or its representatives may contact me by email, phone, or SMS at the email address or number I provide, including for marketing purposes.

</comment><comment><USER10> The official rules[1] are somewhat ambiguous, so this might be an interesting Court battle. The key bit is probably _" A worker is an employee when the business has the right to direct and control the work performed by the worker, even if that right is not exercised."_

[1] [https://www.irs.gov/newsroom/understanding-employee-vs- contr...](https://www.irs.gov/newsroom/understanding-employee-vs-contractor- designation)

<comment><USER11> This criterion is ridiculously out of touch with reality. I just hired some people to trim my trees. I told them exactly which trees to trim, in some cases, which specific limbs to cut off. That doesn't make the tree-trimmers my employees.

<comment><USER12> It's more like they agreed to take the job of cutting these trees in a way that you would like for an agreed upon amount of money and then left. They don't work for you, they did some work for you, but they didn't have to, and they wouldn't have gotten paid or been entitled to any compensation if they hadn't. They would have been liable if they had killed your trees in the process.

I think where we're splitting hairs is whether the drivers have a direct relationship with Uber and Lyft that entitles them to the rights of a W-2 employee, or whether they are actually working for the passengers and are therefore 1099 workers merely using Uber and Lyft as a platform to find work.

You see, there's a decent case for the latter, it's what they predicated their original business model on, but given the amount of control that Uber and Lyft _does_ exercise on the drivers, I think that pushes them into W-2 territory. Drivers can't even set their own rates for which they will take a job for example, Lyft and Uber hands the fee scheduling down from on high. The choice is binary, work for Uber or Lyft, or don't work for Uber or Lyft.

There was an interesting but failed startup called Sidecar I think it was. Never got to use it, but the description I received was you put in your pickup and drop off points and the amount you would _like_ to pay, and then it broadcasts this fare out to potential drivers that happen to be available. They see it, and decide if they want to take the fare or not. If Sidecar were still around, I think they would have a much easier time proving their case that their employees are 1099 contractors, not W-2 employees.

EDIT: Some additional thoughts I had after posting this.

As a customer paying for a ride, are you paying to call a Lyft or an Uber? Or are you paying to call a driver. Lyft gives me no options to call upon specific drivers that might be available, or to eliminate certain makes of car that I dislike (damn Prius C drivers), and penalizes me if I cancel. When I'm calling a car, it certainly feels like my relationship is with Lyft the company, not the guy who eventually picks me up. I have no idea who that will be.

<comment><USER2> Regarding your last paragraph: when I call AAA for a tow, I have no control over which tow driver or tow company shows up. That doesn't make the tow truck driver an employee of AAA.

<comment><USER12> You sir, have brought up a decent point. Not an example I'm overly familiar with, but I've seen it in action.

EDIT: took a moment to look into AAA, they advertise themselves as a federation of regional clubs and their customers are less customers and more members. This may not be an Apples to Apples comparison, but lacking sufficient information and experience, I defer to people with more knowledge in this case.

</comment></comment></comment></comment></comment><comment><USER13> I think the part about financial incentives to work longer shifts is a low hanging fruit. This should not be allowed. It basically forces an employee like relationship for an individual to make a practical living (if even). If this were not allowed, uber would be forced to pay higher wages across the board.

<comment><USER14> That's my one complaint. Penalizing drivers for rejecting rides. If you could truly be living your life and set multiple rideshare apps to notify you only when ride fares exceed X rate, then everyone would just set their minimum rate on all the apps and just take the most profitable fares that came their way.

</comment></comment><comment><USER15> If they get classified as employees, does that mean the companies will have more control over how they do their job? I've caught multiple drivers bypassing toll roads (causing a much longer trip) even though Uber includes the toll fee in what they charge me.

<comment><USER16> Uber doesn't really care about your safety, the quality of the ride, or your drivers behavior unless any of these things cause significant PR disasters and result in a very large number of users leaving the platform.

This wouldn't change if the drivers were classified as employees.

Also, do you have any proof drivers are actually able to pocket those missed tolls?

Seems like a win/win, drivers get higher fare due to time, and Uber pockets toll. Why should Uber care?

<comment><USER12> The driver would have to be the one paying the toll, so any money collected for a toll road by Uber would have to go to the driver, otherwise it's just an arbitrary fee Uber decided to collect, not really a charge for the toll.

</comment></comment></comment><comment><USER17> Uber and Lyft are both in the "extractive" business.

Uber and Lyft are a scam to drain both investors and drivers of money which is skimmed off and goes into the pockets of the CEOs, and other business managers.

There is no true profit generated by either the company itself or by the drivers. All business is being permitted by using the investors' money to undercut taxi companies' prices by subsidising customers.

Once the investors finally wise up, both Uber and Lyft will disappear like they never existed.

</comment><comment><USER18> > _To classify someone as an independent contractor, the court said, > businesses must show that the worker is free from the control and direction > of the employer; performs work that is outside the hirer's core business; > and customarily engages in "an independently established trade, occupation > or business."_

This is a bit unrelated, but how would this affect software contractors?

<comment><USER15> It will impact fewer software contractors than we'd think: many contractors really aren't. You're a W2 employee of the placing agency, and they are sending you, their employee, to their client.

</comment></comment><comment><USER19> While it's true that it's bad for Uber it drivers are classified as employees, it's also going to be bad for drivers. Why so much energy directed at punitive measures?

Employee classification only benefits tax authorities who get to collect more money. Why we penalize hiring employees I have no idea but that's how it works.

<comment><USER20> > it's also going to be bad for drivers

how does this follow? Regular employees are entitled to minimum wage, overtime pay and reimbursements for work expenses. The latter in particular would finally put an end to Uber's business model of outsourcing maintenance and risk to drivers, costs which many drivers are very likely not fully aware of.

Being treated as a regular employee, possible unionizing and being entitled to full benefits is a huge boon for working people.

<comment><USER19> Reclassification doesn't create new money.

Things that would actually help drivers:

\- Limit Uber's share of the fare to 10%. Or 5%. And the driver gets the rest

\- Let drivers set strict limits on where they are willing to pick up/drop off, etc

\- Let drivers set their price/terms

Give drivers more control, not less. Making them employees gives them less control

<comment><USER20> a ridesharing service without drivers doesn't exist. Of course reclassification doesn't create new money, if the companies want to be able to operate they'll need to find it somewhere else. Maybe we could start with not making developers millionaires in their 20s and hiring 1k+ sales people for a company that makes a smartphone app.

Literal price fixing might seem simple but seems like a bad market intervention in comparison to giving workers reasonable negotiating power and representation.

<comment><USER19> Is this what's really bothering you? Personally I'd prioritize helping drivers over punishing tech bros. Limiting the app's share isn't a price control, and the most direct way to prevent all the value accruing to a handful of people.

> Maybe we could start with not making developers millionaires in their 20s > and hiring 1k+ sales people for a company that makes a smartphone app.

</comment></comment></comment></comment></comment><comment><USER21> This would be a powerful promoter of autonomous vehicle technologies in ridehail companies. Interesting that if passed, Assembly Bill 5 would become law at about the time the Tesla Network might be implemented. Might actually have a very positive effect on Uber, Lyft et al, just not on their drivers.

</comment><comment><USER22> They aren't contractors, and they are not employees.

That's why its called "gig economy".

</comment><comment><USER23> Uber and Lyft are gaming labor laws in order to get a cheap flexible workforce. To the extent that their business depends on doing so, then, yes, they don't have a right to exist.

I wish drivers could organize and set up ride-hailing collectives, so that we would just cut out Uber and Lyft as the middle-men; prices might be higher because of wages, but it won't all feel like an anti-social scam - and drivers will be able to participate in managing their own lives and put in their professional input (together with consumer groups / regulators) into standard of conduct, service and safety.

</comment><comment><USER24> everyone should be a contractor anyway. Health care should be decoupled from employer.

<comment><USER25> In theory, I'm ok with this, but we also need a stronger social safety net. There's still a certain amount of social responsibility that comes with employing someone full-time, even though it's not required by law. As long as the government can step in to fill the gap, this can work.

What's tricky is that while there are benefits to business because now their business is business, not retaining workers longer than they should, it makes them cold and heartless. But we're humans, we don't respond will to that, and we want to be treated with dignity, even in business transactions.

</comment></comment><comment><USER26> Maybe CA doing stuff like sending itself back into the dark ages of taxis will prompt tech to take up root in other states more. I can only hope.

<comment><USER27> the problem is that in order for you to have your convenient uber/lyft car, people are forced into poverty and homelessness as these jobs do not pay enough.

background on homeless Uber drivers: [https://www.theguardian.com/us- news/2017/jun/17/uber-drivers...](https://www.theguardian.com/us- news/2017/jun/17/uber-drivers-homeless-assault-travis-kalanick)

<comment><USER26> If these labor laws prevent that, then these people allegedly being forced into poverty and homelessness by uber/lyft would just get traditional minimum wage jobs instead which are plentiful at the moment. CA is at its lowest unemployment rate right now. Yet people are still taking these jobs over more traditional ones. So apparently the problem exists in both cases and a more general solution is in order than trying to get rid of contracting-like jobs which other comments point out uber/lyft certainly are (work for competitors simultaneously, no set hours, etc).

<comment><USER27> > would just get traditional minimum wage jobs instead which are plentiful at > the moment.

in which case they would not be Uber/lyft drivers and you would not have the convenience of these services available to you, back into the "dark ages of taxis" .

> Yet people are still taking these jobs over more traditional ones.

yes, and they are living below the poverty level by doing so. The fact remains that your experience of convenient uber/lyft rides depends upon people who willingly or not place themselves into poverty-level wages. For the moment, your convenience requires that people suffer in poverty.

OTOH, if regulations were imposed such that Uber/Lyft had to raise their prices, then you can have the convenience of these services, at a higher cost (more likely though, it would be simply be a regular low-margin business like taxis and supermarkets and no longer profitable to investors), and it would not require poverty-level workers in order to achieve it. This is the purpose of the minimum wage - so that the job market isn't crowded with jobs that do not provide a living wage.

<comment><USER26> My point is gig jobs must not be the real problem here, so the solution to the general problem isn't tanking the gig economy. If uber and lyft were so bad then people would be taking those regulated jobs that are available instead.

I wouldn't mind if uber/lyft prices went up some to pay the employees better but I don't see it as a moral evil to make side jobs available where you're not paid for time doing nothing because there's not a job yet. Re: healthcare it should just be single payer and not tied to employment.

</comment></comment></comment></comment></comment><comment><USER28> So close and yet so far. No business or corporation has an inherent right to exist, and if you can only turn a profit by shafting the people who work for you then you have no business in business.

<comment><USER14> If someone performs a voluntary job without a gun to their heads, the assumption is that they are not being shafted.

Or they are being shafted by life so hard that this represents less shafting that all their other options. Otherwise, if they had better options, why would they take the job?

<comment><USER28> There's no such thing as a voluntary job when the "alternative" is poverty, homelessness, and slow death by starvation or preventable disease.

<comment><USER29> So your proposal is to drive these corporations out of existence and push the people back into poverty?

<comment><USER28> Not all of them. Just the ones that shaft workers. If your business has nothing to hide it has nothing to fear.

</comment></comment></comment></comment></comment><comment><USER30> I think this bill passing would be a good thing, because gig workers need legal protections, and in America most people are also dependent on their employer to help cover the cost of health insurance (another issue itself; healthcare should be free). I know people who are regular uber drivers in LA, and they certainly treat driving for uber like a "real" job. They try to work regular hours; they need to to be able to make rent.

I believe the real issue is the distinct lack of investment in public transit infrastructure in the US. Uber and Lyft claim they're providing a valuable service. In developed nations cities build subways and bus routes to meet the needs of residents. America's philosophy seems to be to never provide a necessary service for free when somebody could be making a buck off it.

</comment><comment><USER31> I tend to bring this up on Uber/Lyft/etc threads, but it seems especially relevant here:

"The Market Fairy Will Not Solve the Problems of Uber and Lyft" (2016)

[https://www.ianwelsh.net/the-market-fairy-will-not-solve- the...](https://www.ianwelsh.net/the-market-fairy-will-not-solve-the-problems- of-uber-and-lyft/)

> Here is the thing about Uber and Lyft (and much of the "sharing economy").

> They don't pay the cost of their capital.

> The wages they pay to their drivers are less than the depreciation of the > cars and the expense of keeping the drivers fed, housed, and healthy. They > pay less than minimum wage in most markets, and, in most markets, that is > not enough to pay the costs of a car plus a human.

> These business models are ways of draining capital from the economy and > putting them into the hands of a few investors and executives. ...

From the drivers' POV these companies are parasites.</comment>


How a fake Justin Bieber "sextorted" hundreds of girls through Facebook - <AUTHOR> http://arstechnica.com/tech-policy/news/2012/05/how-a-fake-justin-bieber-sextorted-hundreds-of-girls-through-facebook.ars <comment><USER2> I wonder how often extortion occurs online as people share self-generated, sexually explicit media. I read something similar last year about Craigslist casual encounters, albeit in that case the extortion was perpetrated for financial gain. My guess would be that it is much more common than is acknowledge. The scammer exploits an inherently emotional and irrational process to gain leverage over a truly unsuspecting victim.

</comment><comment><USER3> For some reason, I have been thinking that Facebook membership was restricted to users over eighteen. I am obviously mistaken, but it occurs to me that this was their policy at some point. Does anyone know?

<comment><USER4> You must be at least 13 <https://www.facebook.com/help/?faq=210644045634222>

Because of: [http://en.wikipedia.org/wiki/Children%27s_Online_Privacy_Pro...](http://en.wikipedia.org/wiki/Children%27s_Online_Privacy_Protection_Act)

<comment><USER5> What that actually means is that you have to claim a birth date of over 13 years ago. There are certainly plenty of children younger than that on Facebook.

<comment><USER4> Yes, this is absolutely true. I should have worded my post more clearly to indicate that this is the policy not the reality.</comment></comment></comment></comment>


Google WebDriver - <AUTHOR> http://google-opensource.blogspot.com/2009/05/introducing-webdriver.html

<comment><USER2> Amusingly their Internet Explorer driver is called Jobbie, which is a scottish term for 'shit'.

[http://code.google.com/p/webdriver/wiki/InternetExplorerDriv...](http://code.google.com/p/webdriver/wiki/InternetExplorerDriver)

<http://en.wiktionary.org/wiki/jobbie>

Billy Connoly using the term: <http://www.youtube.com/watch?v=kmpRQLaxF60#t=2m20s>

</comment><comment><USER3> Thanks for the link.

It seems weird that you test a dynamic language like Javascript by writing code in a statically typed language like Java. <http://code.google.com/p/webdriver/wiki/GettingStarted>

I hope they come up with a scripting user interface that draws from Expect.</comment>


Myths about Hash Tables - <AUTHOR> http://hughewilliams.com/2012/10/01/five-myths-about-hash-tables/ <comment><USER2> Inside the Redis distribution you can find "dict.c" that is a very easy to understand hash table implementation that uses incremental rehashing, that is, when it needs to switch to a bigger or smaller table this happens incrementally in three ways:

1) At every operation you perform there is a rehashing step.

2) You have a function that you can call to perform a rehashing step.

3) There is an higher level function where you can say "rehash for N milliseconds" in case you have some idle time to spend for a good cause inside your program.

Another uncommon thing of dict.c is that it supports the "pick a random element" operation with guaranteed O(1) behaviour.

EDIT: Now that I look at the source, clearly while the code is easy to follow a design section should be present in the dict.c top-comment. I'll make sure to add this, but long story short:

* We use both chaining and incremental rehashing. This means that there is no need to rehash ASAP when the hash table reached the max % of elements allowed. At the same time using the incremental rehashing there is no need to block.

* We support safe and unsafe iterators: safe iterators block the rehashing when they are active, so you have the feeling you are accessing the hash table in a read-only way. Unsafe iterators are ok for looping even while an incremental rehashing is in progress, but is not ok to touch the hash table while iterating with an unsafe iterator (otherwise the iterator no longer guarantees to return all the elements, or to avoid duplicated elements).

* The hash table is rehashed both ways: if it's too full, or if it's too empty. This way there is the guarantee that a table has always a percentage between a min and max. This guarantees that our random element function is in the average case O(1).

* When we rehash, a second table is created, and stuff are moved incrementally from one to the other. When we have two tables, all the lookup / delete operations are run against both the table as the element can be in the old or in the new table. Instead insertions only happen in the new table.

Well these are the main ideas I think.

<comment><USER3> <https://github.com/antirez/redis/blob/unstable/src/dict.c>

<comment><USER2> Thanks, perhaps the design is even more evident here -> <https://github.com/antirez/redis/blob/unstable/src/dict.h>

</comment></comment></comment><comment><USER4> A good article, but two quick thoughts:

1\. With a good hash function, it's hard to accidentally stumble on the worst- case O(n) lookup cost. But against an adversary, it is usually very easy to have that problem. This has been a well-known security issue for over a decade, and over the last 4 years we're starting to see more exploitation of it.

2\. The "little trick" at the end of the document that bumps matching items to the head of their bucket chain will usually provide only a marginal speedup (if many of your lookups hit chains longer than 1, your table is too small or your hash function is broken), and that optimization comes with a cost: lookup now modifies the underlying hash table, which is sometimes very undesirable.

<comment><USER5> Do there exist good hash functions that are resistant or immune to the attacks you mention? For example, does Python 3.3's new hash randomization provide adequate protection?

<comment><USER6> This is what SipHash was made for: it's a cryptographic MAC that's competitive in speed with other hash functions meant for hash table use. The paper describes its design, and the weaknesses with competitors like Python's randomized hashing:

<https://www.131002.net/siphash/siphash.pdf>

Some code for it here:

<https://www.131002.net/siphash/>

<comment><USER7> Interesting, though at 140 cycles to hash 16 bytes, it's much slower than state-of-the-art hash functions, which can hash 16 bytes in just over 16 cycles. If you seed your non-cryptographic hash function with a cryptographically random number, you can get the best of both worlds: fast hashing and collision resistance against an adversary.

<comment><USER8> Not really. The SipHash page contains proof-of-concept code that breaks common good non-cryptographic randomized hashes, i.e., it generates collisions _regardless_ of the chosen seed.

Regarding performance, SipHash is essentially as fast as Python's randomized hash, and quite faster for long inputs (>16 bytes), cf. <http://bench.cr.yp.to/results-auth.html#amd64-sandy> .

<comment><USER7> That code appears to rely on having direct access to the hash function; this seems very unlikely to be leaked to an attacker. More interesting would be code that gets the secret with only access to ordered iteration on the table, which is more likely to leak.

I don't know anything about Python's hash function, all of those benchmarks are still an order of magnitude slower than CityHash (for example), which peaks at 0.16 cycles/byte.

I would be interested to see SipHash put through SMHasher, which is the most comprehensive hash function test suite I know of: <http://code.google.com/p/smhasher/>

<comment><USER9> Seed recovery (which requires access to hash function) is for Python hash. For CityHash, MurmurHash (2 and 3) there are seed-independent collisions.

Of course, it passes SMHasher with 10 score -- it's a _cryptographic_ PRF.

<comment><USER7> > For CityHash, MurmurHash (2 and 3) there are seed-independent collisions.

Are you referring to the "Advanced hash flooding" section of the paper, or am I missing this in another place? That analysis appears to rely on the hash function being highly linear/periodic (ie. you can always add "l" to get back the same hash value). I don't think that City, Spooky, or Murmur are nearly this linear. For example, City is based on CRC32 (ie. polynomial division).

Don't get me wrong, I'm impressed that SipHash is so fast for a cryptographic hash. But modern non-cryptographic hash functions are so fast (especially when they're CPU-accelerated, like City is on Intel thanks to the CRC32 instruction) that I don't think SipHash can claim to be the obvious choice for all hash tables.

I am interested to know though if the random seed + City/Spooky/Murmur approach really does have practical hash flooding attacks.

<comment><USER8> It's pretty quick to generate a lot of collisions, and the set of inputs you get will collide independently of the seed. Look (CityHash64):

$ time ./citycollisions 1000000 > /dev/null

real 0m0.904s

user 0m0.439s

sys 0m0.008s

$ ./citycollisions 3

128-bit key 741b848b0065aec04bb25b26ca2c3e9

CityHash64( 8e69324ad2a005ff2148534148202020, 16 ) = d3290c3d600b8add

CityHash64( 7ae31886221136ba2148534148202021, 16 ) = d3290c3d600b8add

CityHash64( a9a6b9c6888e94ff2148534148202022, 16 ) = d3290c3d600b8add

$ ./citycollisions 3

128-bit key 5e2a23015c89da98172fbcb77ad98468

CityHash64( 8e69324ad2a005ff2148534148202020, 16 ) = 59d0b041b16594b

CityHash64( 7ae31886221136ba2148534148202021, 16 ) = 59d0b041b16594b

CityHash64( a9a6b9c6888e94ff2148534148202022, 16 ) = 59d0b041b16594b

<comment><USER7> Wow, collisions against the best non-cryptographic hash functions that are independent of seed... color me impressed! This does then seem to strongly suggest that a cryptographic hash function is the only way to defend against hash flooding attacks. Props to the SipHash authors, this is some ground- breaking work.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I love hash tables. They're my favorite data structure, maybe.

A story:

Back in the 70s it appeared that every major state university had to do their own version of PL/1. At the University of Maryland it was called PL/UM. I don't know why, maybe it was a testosterone thing ("IBM took a zillion man- years to write PL/1, but look what WE did with three starving grad students, a half-soused half-professor and a keypunch operator!") (Yeah, another version of PL/1, and that doesn't necessarily make the world a better place. Anyway --)

PLUM was notorious for being slow (I don't know about bugs, but they were probably there, too), and it was pretty common for students using PLUM to have to grovel for more seconds of CPU time.

Five or six years into PLUM's use as a student language, someone discovered that all of the symbols were being hashed into the same bucket.

PLUM got amazingly fast (well, faster, at least) after that. But by then anyone with a clue had managed to scam an account on one of the bsd Vaxen and write their stuff in C.

Don't take hash tables on faith. Measure, measure, measure.

</comment><comment><USER11> The first two myths aren't really myths.

In "The worst case is terrible", the author goes on to explain that the worst case is unlikely. That may be true, but it's still O(n).

In "Hash tables become full, and bad things happen", if I'm reading it correctly, the author shows how you can make each hash table bucket a linked list so that each bucket never becomes full. But what happens when you have 1000 items in each bucket? If you keep adding elements and you want to keep reads fast, sooner or later you're going to have to add more buckets, at which time you need to re-hash every element in the table.

I'm a fan of hashtables, but there's some rather suspicious handwaving in this article.

<comment><USER12> _goes on to explain that the worst case is unlikely. That may be true, but it's still O(n)._

It's not O(n), it's more like O(1 + max(0, n - m)) where n is the number of elements in the table and m is the number of buckets. The table can grow up to about n == m and it's still approximately O(1).

 _But what happens when you have 1000 items in each bucket?_

Don't do that. Rather if you do that, then you don't get to complain that the performance of your data structure is that of the fallback strategy instead of a properly sized hashtable.

You should have begin executing your growth strategy back at about 0.5 items in each bucket.

 _If you keep adding elements and you want to keep reads fast, sooner or later you're going to have to add more buckets,_

Sooner or later you're going to have to put more RAM in the machine too. But in the meantime, your trusty old hash-based data structure will give you reliable service.

 _at which time you need to re-hash every element in the table._

If latency is a concern this re-hashing can be done incrementally.

If the hashing of elements itself is expensive, you can store the resulting hash value for each element.

Note that there are three zero bits at the bottom of each 64-bit-aligned pointer value. You could use these to store three additional bits of the hash value, allowing you to grow your table by a factor of 8 without rehashing.

<comment><USER4> _It's not O(n), it's more like O(1 + max(0, n - m)) where n is the number of elements in the table and m is the number of buckets. The table can grow up to about n == m and it's still approximately O(1)._

Isn't that just the long way of saying "O(n)"? It's a _worst-case bound_.

<comment><USER12> I'm guilty of sometimes using big-O notation when discussing amortized average costs as well.

It seems nonsensical to discuss worst-case behavior of hash-based data structures since we can (and should) make it arbitrarily unlikely.

In other words, if O(n) is the limit as n goes to infinity then the probability of actually encountering worst-case beahvior on a hashtable operation is 0 (assuming a non-broken hash function). Near-worst case behavior becomes similarly improbable.

This is different than many algorithms like, say, classic quicksort which have worst-case behavior on values that naturally appear in practice.

<comment><USER13> It depends on the application of the hash table, but malicious agents could 'attack' code by purposefully creating collisions if the author isn't careful. An algorithm expected to run in O(1) that runs at O(n) could be catastrophic.

<comment><USER12> But the solution to that problem (using a cryptographic hash function randomized with a secret) doesn't change the complexity of the algorithm.

<comment><USER13> I'm just pointing out that the worst case time complexity is an issue that can't always be cast aside. Aren't cryptographic hash functions generally slower?

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Just to throw it out there, here's a 6th myth to consider:

> Hash tables are fast

When you're dealing with lots of keys, they're usually the best option out there. But if you're dealing with a small number of keys, a simple array can often be faster. A hash table lookup involves a constant amount of overhead resulting from calculating the key, and possibly also added indirection depending on whether the implementation uses open addressing. If the amount of time that would be spent on a simple linear or binary search of the array is less than (or even not much more than) the time that would be spent on that overhead, then the array will be faster.

Of course, the point where the hash table overtakes the array depends on a lot of factors. As usual the only sure-fire way to know which option is better in a particular situation is to measure.

<comment><USER15> I recently read a story by one of Wirth's students, reminiscing about working on the Oberon compiler. They had several important principles for developing the Oberon compiler that drove development, one was something to the effect that anything you add must pay for itself or improve the speed of compilation --the benchmark being the whole Oberon system. The students had implemented a very fancy data structure, I think a balanced tree, to use with register allocation. Wirth found out and ordered them to remove it and replace it with a linked list. They groaned, but complied--and the compiler was both smaller and faster as a result, despite worsening the worst case.

<comment><USER9> "I still vividly remember the day that Wirth decided to replace the elegant data structure used in the compiler's symbol table handler by a mundane linear list. In the original compiler, the objects in the symbol table had been sorted in a tree data structure (in identifier lexical order) for fast access, with a separate linear list representing their declaration order. One day Wirth decided that there really weren't enough objects in a typical scope to make the sorted tree cost-effective. All of us Ph.D. students were horrified: it had taken time to implement the sorted tree, the solution was elegant, and it worked well – so why would one want to throw it away and replace it by something simpler, and even worse, something as prosaic as a linear list? But of course, Wirth was right, and the simplified compiler was both smaller and faster than its predecessor."

<http://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf>

<comment><USER15> Yes, that's it! Thank you! I apparently misremembered the purpose, but at least I got the sorted tree part right. :)

</comment></comment></comment></comment><comment><USER16> Hash tables are fantastic, but:

Depending on the hash and hash table implementation, large hash tables where elements are spread across several pages in memory can pathologically thrash your caching. You can get similar behaviour to randomly accessing elements in a large array. A cache miss from L2 to RAM is extremely slow and can be about a million times slower if you have to page fault all the way into swap.

This is a good example of a case where the standard model of computer that's used in CS proofs starts to fall over because it ignores hierarchical memory and cache locality.

Hand wavily, accessing every element once in a large naive hash table will give you O(n) page faults on average whereas accessing every element sequentially in a vector will give you O(n/d) page faults where d is your page size. While asymptotically similar, in real life that constant d can be gigantic.

That being said, I'm not sure how the C++ unordered_map handles this, it's just something I experienced when running cachegrind on someone's hand rolled implementation in the past. (I 'fixed' it by making the templated class store pointers, and then locality was greatly improved because malloc's default behaviour.)

<comment><USER12> * A cache miss from L2 to RAM is extremely slow*

Yes, but a properly-sized hash table will result in an average of 1 to 2 cache misses per lookup regardless of how many elements. This is far better than what you get with other structures, except perhaps in specialized cases that happen to follow tree traversal.

 _and can be about a million times slower if you have to page fault all the way into swap._

Disk based data requires specialized algorithms.

 _accessing every element once in a large naive hash table will give you O(n) page faults on average whereas accessing every element sequentially in a vector will give you O(n/d) page faults where d is your page size. While asymptotically similar, in real life that constant d can be gigantic._

Sure, a vector is better when you only ever access elements in a single sequential order and don't add or remove elements anywhere except the end.

 _That being said, I'm not sure how the C++ unordered_map handles this_

C++ defines a method of iterating over all the elements of an unordered_map. I think a typical implementation will just treat the hash memory as a vector and return values from the occupied buckets.

</comment></comment><comment><USER17> > Engineers irrationally avoid hash tables...

Really? That seems about as likely as the statement 'carpenters irrationally avoid using screws'.

<comment><USER18> Indeed, I find academia is averse to hashtables (because of the poor worst- case performance) but engineers think they are the best thing since sliced bread.

<comment><USER12> This "worst-case" issue seems silly to me.

If all your elements magically hash to the same bucket somehow and you end up having to make a list or a tree out of them, you're still no worse off than if you used a list or a tree in the first place.

<comment><USER18> Most hash-table implementations either re-hash or use an O(n) lookup structure. And replace "magically" with "a malicious attacker" and you see it does come up more often.

</comment></comment></comment></comment><comment><USER19> Misses the point about B-trees.

They're not just 'good for inexact matches' - they're optimised for things like database indexes, to reduce the number of seeks over a block-based device (eg a filesystem) required for a index lookup.

<comment><USER4> External tables are an entirely orthogonal issue to this discussion. He's comparing hash tables to in-memory balanced binary trees.

<comment><USER19> third myth in the article compares B-trees to hash tables:

"Trees are better In general, trees aren't faster for searching for exact matches. They're slower, and here's peer-reviewed evidence that compares B-trees, splay trees, and hashing for a variety of string types. So, why use a tree at all? Trees are good for inexact matches — say finding all names that begin with "B" — and that's a task that hash tables can't do."

<comment><USER20> It looks like the paper doesn't refer to B-trees. It refers to binary search trees.

<comment><USER19> and so the article confusing B-trees with binary search trees doesn't exactly increase confidence here ...

<comment><USER4> What "confidence" do you need for a straightforward comparison of hash tables and binary trees? These aren't Apple rumors; this is CS 101.

<comment><USER19> my point is merely that as written, the article is confusing.

to paraphrase: "hashtables are faster. here's some research showing b-trees are slower than hashtables. why would you ever use a tree? prefix matching, that's why."

which misses the point that the primary reason for using a B-tree as a general purpose database index is not about prefixes, it's about block devices (prefixes is an important reason, but it's not the main one)

if the purpose of the article was to ignore implementation and spinning disks and just look at in-memory performance, then don't mention B-trees. they're an implementation-specific optimisation, and it just confuses.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I'm not really sure this article explains any myths about hashtables at all.

Aren't all of these statements obvious is you actually understand what a hashtable is?

</comment><comment><USER15> The reason functional programmers prefer trees is because it's much easier to make them persistent (in the functional sense).

</comment><comment><USER22> Seems somewhat vague, I think it could be a lot more accurate. I'm a bit surprised to see it here.

It claims that it's a myth that "trees are better" than hash tables and just describes trees as better for "finding inexact matches", as in the example "finding all names that begin with B". That's too vague. It's misleading because:

1\. Trees can't just answer any random vague questions, such as "Find all names that have a P anywhere". That doesn't really describe the advantages of trees. I think a more accurate formulation would be "iterating over a range of values" or "finding values based on some ordering" (eg. find the smallest element bigger than X). Or for walking the entire contents in some predefined order. Sure, this is not an article about trees, but it doesn't take more than two sentences to describe that in a much better manner.

2\. For any of the former query patterns, trees _are_ actually much better than hash tables. That's definitely not a myth, which this article would sorta have you believe.

> Chained hash tables are a very good idea. Problem solved.

Wrong. If you don't resize your hash table, the complexity of accesses _will_ degrade linearly as it exceeds its size. If your hash uses, say, 100 buckets each with a linked lists and stores N > 100 values, an access has complexity O(N) (sure, O(N/100) in the best case (assuming perfect spread of hash keys), but that's really O(N)).

Finally, "The worst case is terrible" myth part seems somewhat naive. I think it should at least mention the idea of hash table collision DOS attacks. "This doesn't happen in practice" unless there's some attacker out to get you by triggering that. There's plenty of examples of that happening in practice, of systems vulnerable to that. See example presentation here: [http://www.youtube.com/watch?v=R2Cq3CLI6H8&lr=1](http://www.youtube.com/watch?v=R2Cq3CLI6H8&lr=1) Sure, that's not a reason to switch away from hash tables, but it's definitely something to consider when using them. I get a bad flavor from this simplification of "yeah, this doesn't happen in practice, at least as long as you know what your keys are".

</comment><comment><USER23> C++11 has hash backed containers now if you prefer them. std::unordered_set and std::unordered_map are identical to std::set and std::map except they use hash tables rather than red black trees.

<comment><USER24> Isn't that implementation specific?

<comment><USER12> The standard requires amortized O(1) insert and lookup operations, so it's in practice going to be a hashtable.

<comment><USER18> Any Trie varient will have that as well though.

<comment><USER12> Really? Looks to me like the lookup function is invoking recursion here: <https://en.wikipedia.org/wiki/Trie#Algorithms>

I would think the amortized cost would be O(log_b n), with b being something like the Shannon entropy of each symbol.

<comment><USER18> Well in that case the cost of a hash-function is also not O(1) since the minimum length of a n distinct keys is log(n).

Really both a trie and a hash-function boil down to O(m) where m is the length of the key.

</comment></comment></comment></comment></comment></comment><comment><USER25> There are some good ideas here, but I must take issue with a number of the statements the author makes.

To begin with, it is not a "myth" that hash tables have poor worst-case performance. It is true that this matters little for most applications, and not at all for some, but the worst case is still there. So I would avoid using hash tables, e.g., in safety-critical systems: medical, military, etc. (Or, as I tell my students: don't program a pacemaker in Python.)

And we should note that the excuse that datasets leading to poor performance are very rare, went out 20 years ago. When the person providing your dataset is a teenager who's trying to break your system just for the fun of it, rarity does not mean quite what you might think.

Second, hash tables do indeed have performance problems when they fill up. True, there are ways around this, and any decent implementation of a mutable hash table will include a strategy for handling these situations.

And that suggests a myth the author of this article might believe: that any ol' programmer can & should write their own hash table. I don't agree. Don't write a hash table for use in production code unless you're sure you know what you're doing. And even if you do, someone else's polished & tested hash table is likely to be better than what you're going to come up with.

Lastly, balanced search trees do have better worst-case behavior. That mostly doesn't matter, but sometimes it does. (You have my permission to use a Red- Black Tree in your pacemaker code.)

</comment><comment><USER26> I don't believe most engineers brush off hash tables because of the worst case search. Or even storage costs or implementation complexity as the author suggests.

My reason for shrugging off hash tables for _most_ requirements: cost/complexity of inserts and deletes. Hash tables are amazing when you do offline index generation (circa Google "non-realtime" search).

However, if you ever need to have frequent updates, deletes, or inserts, you need to grow the hash table and in doing so managing the hash table usurps any search gains. For some use cases that's fine - perhaps you only optimize for reads. Hash tables are awesome for read heavy loads. Hash tables are sub- optimal for mixed read/write work loads.

On that note, I believe the Red-Black btree is far superior to hash tables for mixed work loads. RBtree's tend to be more predictable and when your application needs the insert/delete (ie, for real time updates) you don't have to worry about having to find a new data structure.

On a related note, XFS had to switch their hash over to an rbtree to fix a performance issue related to hashes falling over in costs of insert/deletes:

<http://oss.sgi.com/archives/xfs/2010-09/msg00203.html>

Yes there are myths about hash tables but article doesn't touch on the real truths of why engineers avoid hash tables.

</comment><comment><USER27> So we have two ways of dealing with overfullness. We can use linked-list buckets, which are expected O(n) or we grow and sometimes have to rehash the _entire table_ as part of an add.

</comment><comment><USER28> I'm jumping on the occasion to ask a review of my own hash table implementation:

<https://github.com/norswap/nucleotides/blob/master/src/map.c> (think also to peruse the documentation and the tests!)

I'm open to any remarks and criticisms: performance, code style, etc. Since the implementation is meant to be simple and educational I may not act on all of them, tough.

</comment><comment><USER29> Hash Tables make iteration order hard to predict.

Hash functions rarely are meaningful outside of the context of the collection.

The tree interface leads to a simpler world.

</comment><comment><USER30> Hashtables are great until they grow to a significant fraction of available memory. Then there is no way to avoid the cost of rehashing or giving up constant time access - and if your program isn't using most of memory then you can run it on a smaller computer!

</comment><comment><USER31> As a developer I tend to use RB trees in the prototype phase then migrate to a hash table if the performance difference matters.

</comment><comment><USER32> <http://global.sitesafety.trendmicro.com/>

</comment><comment><USER33> I really disagree with this article.

"The worst case is terrible" is not a myth, it's a reality-- and it's spawned several major security vulnerabilities recently. CVE-2012-1150 for example.

"Hash tables become full, and bad things happen." Yes. Yes they absolutely do. It depends on your implementation exactly what will happen, but in every case, you are in for some pain. If you choose the "linked list per element" route, congratulations-- your hash table will gradually approximate the lookup behavior of an unsorted linked list as the number of elements gets larger. If you choose rehashing, you'll have to deal with long pauses in your program during a rehash. Hello, latency spikes! Incremental rehashing could improve this, but only at the cost of degrading memory locality even further.

"Trees are better." For most applications, trees really ARE better. Trees are simple to use and they use less memory most of the time. You really should not be using hash tables unless you have a really good idea of how many elements you are going to have, AND you believe that they will not be accessed in any particular pattern.

"Hash functions are slow." I don't even know what this statement is supposed to mean. But I do know that there are a lot of bad hash functions out there, and it's easy to choose a bad one as a novice programmer. The right hash function will depend on your data-- something I note that this article fails to mention.

"Hash tables use too much memory." A wise programmer once told me, "fancy data structures are only good when N is large-- and N is usually small." That definitely applies here. Another way to look at this is that you need to keep the hash table half empty to keep the good properties that made you choose a hash table in the first place: O(1) lookup, O(1) insert, O(1) delete, etc. So you will just have to pay the memory price.

Hash tables can be very useful for certain applications. But in general, they're an optimization that you should make only if you know what you're doing. You should be very clear on why you're using them, how many elements you expect to have, and what your strategy is if you overflow. It's not for beginners. And if you are optimizing, you should also be aware that something like a radix tree or a B-Tree may lead to much better performance, due to its much better memory locality.

Just about the only really intriguing use for hash tables on a modern CPU is in lockless data structures, but if you're considering writing one of those-- you already know all the stuff I just wrote.</comment>


Harvey Is What Climate Change Looks Like - <AUTHOR> http://www.politico.com/magazine/story/2017/08/28/climate-change-hurricane-harvey-215547 <comment><USER2> Previous floods in recorded history...

[http://m.chron.com/news/houston- texas/houston/article/Histor...](http://m.chron.com/news/houston- texas/houston/article/Historic-Texas-flooding-events-and-Houston- this-7255052.php#photo-7626161)

How they drained the lands...

[https://www.hcfcd.org/flooding-floodplains/harris-countys- fl...](https://www.hcfcd.org/flooding-floodplains/harris-countys-flooding- history/)</comment>


Ask HN: What is the ugliest code you've let slip? - <AUTHOR> I've seen some horrible code run perfectly, and some inexplicable snippet that shouldn't run work well enough.
What have you let make it to production that never should have been there, and likely was only intended as a temporary fix?
Did you ever get around to fixing it? <comment><USER2> I have been told that the code I write is ugly, multiple times by different people.

The only time this has ever bothered me is when it's in the interview process and costs me the job.

I usually stop working on code when it's "good enough", which is to say, when it works.

Maybe I have low standards.

<comment><USER3> Sometimes good enough is best, and other times a refactoring is worth it. Key is to think of it from a business point of view. If you always refactor or never refactor, both extremes are suboptimal IMO. Deciding when a quick fix is good vs. something more considered is an art.

</comment></comment><comment><USER3> I read the gang of four, got a hard on and banged out some code with lots of classes with really long names. Felt damn proud of it at the time. Wanted to be the next Martin Fowler, but probably just some confused poor sod now maintaining that pile.</comment>


Ask HN: What happens after no-deal Brexit? - <AUTHOR> This isn't necessarily an ideal question for HN, but as an Irish person living in the UK I'm increasingly nervous of the fallout from the inevitable no-deal Brexit on the horizon and I trust the opinion of HN users.
What do you think the consequences of no-deal is going to be? Is it as bad as everyone thinks?
When I think it about it rationally it seems like it's going to be absolutely chaotic and potentially violent in Northern Ireland. <comment><USER2> I think if it even happens (several people I know still don't believe it will), it will in the long term lead to the dissolution of the Union. The position of Scotland is pretty clear here, and I can't see that the status quo will remain in Northern Ireland either. Personally as a British citizen I would not be disappointed to see a united Ireland in my lifetime - Brexit was a good chance to read up on all the history, and I do not believe NI should be ruled from London.

I don't think there will be quite as much chaos and doom as some people predict, but the ports situation will definitely be bad (if you listen to the transport professionals, hauling companies etc. who actually _do_ cross between the UK and mainland Europe regularly). Certain medicines will be in very short supply. There's an endless list of things from mildly inconvenient to downright terrible (if you depend on one of the medicines to live, for example).

The economy is _already_ tipping into recession. Leaving the UK's biggest trade union will make this worse. If the Tories somehow cling to power, expect more cuts. Maybe the NHS will be privatised to save money. The poor and disabled will be shat on even more than they already are.

The wealthy will as always find a way to do just fine. Tax evasion will continue and probably grow (exemption from new EU tax directives and policies).

 _More_ companies than have already left will move to the mainland.

 _More_ EU citizens will go back home (whether forcibly due to the draconian rules or out of choice). Priti Patel will smile sweetly as the talent exodus decimates entire sectors.

People will try and get on with their lives, but for many it will definitely get harder.

I hate Brexit.

<comment> J-dawg Related question: how would they decide who gets to be a citizen of (independent) Scotland?

I expect that millions of people would try to find a link to Scotland for a chance of regaining their EU citizenship.

<comment><USER3> My understanding is you can get Irish citizenship if you have Irish grandparents. I'd expect that to be the same and for the Scottish government to offer citizenship to current residents.

My hope is to use my wife's Scottish heritage to move there in the not too distant future.

<comment> J-dawg Any UK citizen can move there while it's still part of the UK. Do you think there would be minimum residency requirements for citizenship?

It's a bizarre thought that we may be seeing English illegal migrants being deported from Scotland in the not-too-distant future.

Also, how quickly could Scotland join the EU? I remember that being one of the sticking points of the first independence referendum.

<comment><USER3> Honestly I wouldn't be surprised to see the Scottish government make it easy to get citizenship, at least in the short term. It would be an easy PR win to show large numbers of Brits requesting Scottish citizenship.

<comment><USER4> I hope so as I'd be one of those applying and moving. The whole Brexit mess is very very depressing. I hope the mess we are making goes to bolster Europe as a whole and show how it's so much better to just get along.

</comment></comment></comment></comment></comment></comment><comment><USER5> I am friends with an MP who is on the Remain side, and I've quizzed him off and on for some time. He tells me there will be some movement in the currency exchange markets, on the London stock exchange, but by and large life will just keep moving along. Manufacturing agreements with Asia and the Americas are in place, so no disruption to most of that. He thinks some food staples might be in short supply but companies have been preparing for Brexit for a year now, so disruption should be minimal. He believes the future of Britain is within the Union, but he personally believes all talk of disruption and shortages is just politics.

Personally, I believe him. I think a lot of politics is filled with doomsday scenarios and fear mongering, but we're talking about a major, modern economy. Brexit reminds me of Y2K. Lots of talk, lots of worry, but nothing really happened.

<comment><USER6> > _Brexit reminds me of Y2K. Lots of talk, lots of worry, but nothing really > happened._

What an ominous analogy. I hope for the sake of those who live there nothing happens - but the y2k bug was more than "lots of talk and worry". People identified the problem and worked diligently to get it fixed before shit hit the fan - just because nothing happened doesn't mean nothing was done. I don't think you should take a laid back attitude and assume someone else will do all the work.

On a related note, I worry this is how climate change will be treated if addressed. Some clueless peoples will simple hand wave the problem away and ignore the years of energy change and research that had to be done because "nothing bad happened"

<comment><USER7> > just because nothing happened

There were substantial problems, but because of the high level of alert, they were fixed very rapidly.

> People identified the problem and worked diligently to get it fixed before > shit hit the fan

This, a thousand times.

</comment></comment></comment><comment><USER3> More than likely the dissolution of the United Kingdom. Scotland will have another referendum if we leave with no deal, and odds are they will vote yes this time. A hard border in Ireland will more than likely result in a vote for re-unification, and depending on how bad it goes for NI in a no deal scenario it's not unlikely for that to happen too.

In the short term we'll probably struggle with logistical issues, getting freight through the ports, shutting down motorways around Dover, etc. There will be more pain for people travelling to the EU, especially for those that do business there. Nothing apocalyptic there but definitely stuff we've not had to think about for decades. We'll end up falling in line with their regulation and things anyway I expect so I wouldn't expect to see any major trade deals with the US any time soon.

Politically even if the U.K. somehow stays together the Conservative party is going to end up bearing the blame for this. There is no real pathway to this being successful for those people that are hurting the most, they were lied to and even if they get what they think they want, they are going to pay the cost of that. How that shakes out is anyones guess, I wouldn't be surprised to see the country swing further to the right with the help of the tabloid press. Especially when we have to increase immigration from non-eu countries to bolster the people that leave, just within the NHS this is going to be required. Couple that with stagnant growth and a continuation of austerity there is going to be some real anger within the working class.

Essentially we're probably looking at another lost decade at least, a descent into darker and darker politics and finally when we're back to the original position when we entered the EU as the sick man of Europe we'll probably vote to rejoin.

</comment><comment><USER8> I'm concerned, but mainly for the mid-term future than immediate starvation and riots.

Borders and ports will cope - _only_ after a period of obviously not having nearly enough customs and other staff for borders and checks. Temporarily difficult then. Particularly as we have a government that doesn't want to spend on any necessary service.

Good Friday agreement is my biggest short term concern. That requires a lack of borders, and Brexit seems to require the impossible in NI. Mid-term I see reunification. Short term could get ugly if there's border posts, and _just one_ incident...

Mid term, it's destroyed UK's international reputation, it's boosted independence thoughts across the nation, and our politicians of all colours are clearly no longer fit for purpose. You tell me where that takes us. I see a further decline of science and business as more goes to the EU than here. Why would a project choose to locate in a post-Brexit UK with no EU agreement?

</comment><comment><USER9> I think the UK will have to give up N.I. to Ireland at some point to avoid an all out war. EU is good at keeping peace the last few decades, but Europe has always been at war internally before that so it looks like it will be back to BAU

<comment><USER10> The Northern Irish who identify as British would not be very happy there. Pretty sure they would not accept this.

<comment><USER11> So are they ready to trash the Good Friday agreement and go back to The Troubles? Because that's the alternative.

<comment><USER10> Why should they have to trash the good friday agreement in the first place? NI voted to remain.

<comment><USER11> They have to trash the Good Friday agreement because it requires a customs- free border between Northern Ireland and Ireland. This isn't possible with Brexit: having a customs-free border means anyone can just import anything into or out of the UK through NI.

Maybe one solution would be to have a county-by-county referendum, where each county in NI gets to decide whether it wants to stay in NI or instead join Ireland. This would make NI smaller, but would concentrate the UK loyalists in it, and the number of Republicans (the ones who want to rejoin Ireland) would decrease a lot (many would be in the counties that would leave, which are probably mostly right on the border, and some might even move), so maybe re- establishing a hard border would be more palatable then.

<comment><USER12> That amounts to repartioning Ireland. The original partition in 22 was traumatic, and we're still living with the consequences today. The partitioning of India in 47, and the British Mandate of Palestine in 48 were also traumatic and bloody events. Partition generally causes forced population transfer, which tends to lead to bloodshed.

<comment><USER11> Well, they're going to have bloodshed anyway, so wouldn't it be better to minimize it? The IRA isn't going to stand for going back to the way things were before the GF agreement.

<comment><USER9> there's already increased IRA activity [https://www.heraldscotland.com/news/17891935.londonderry- bom...](https://www.heraldscotland.com/news/17891935.londonderry-bomb-planted- new-ira-targeted-police/)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Think Mad Max on mobility scooters. I've stock piled food. The Irish border is already an issue, I was there recently when two bombs were found. I doubt it will be pretty.

</comment><comment><USER14> It would require a lot of agreed-upon things to continue as agreed rather than end upon the overarching agreement (i.e. membership of the Union) coming to an end. This is largely what Brexit-positive people seem to think would happen in the case of a no-deal, i.e. "nothing much would change" because to rock the boat would be too much.

</comment><comment> J-dawg What I fear is the UK government (and the press that support it) continuing its policy of doing very little and blaming everything on the EU. For example:

1\. UK leaves without a deal, leaving an open EU border between Ireland and NI. 2\. UK refuses to do anything to enforce this border or stop the movement of goods and people across it. 3\. Ireland / the EU needs to protect its borders so they put up fences and vehicle checkpoints. Perhaps even with help from other EU countries' security forces. 4\. UK right wing press runs stories full of angry language about the 'invasion'

I fear we'll see this process repeated every time there's a shortage of anything - it will all be the EU's fault, and entering into any transitional agreements with the EU (if they are gracious enough to grant us any) will be 'surrender' or 'capitulation'.

This is a worst case scenario, but I fear we are heading for serious civil unrest and violence

</comment><comment><USER15> Interest rate cuts by the BoE, the pound weakens, Asian foreign investment - Japan and China would love to build high speed rail for an international market. Companies like Huawei will offer turn key solutions to government infrastructure projects. You can hedge by buying Swiss francs, Aussie dollars or Japanese Yen. Or purchasing an investment property or a plot of land for future development, immigration from Asia will see a rising demand in housing, cheap accommodation. Long term the UK becomes a type of Hong Kong for wealthy Europeans - tax haven and pivot point of entry into the European market. More jobs will be created in tech, manufacturing and construction.

</comment><comment><USER16> I am quite close to a couple of people actually working on Brexit ... and while of course they won't tell me any specifics, the message that I'm getting from the body language, eye-rolls and exasperated sighs is ... pretty bleak.

</comment><comment><USER17> The Belfast Agreement / Good Friday Agreement will be trashed and we'll lose the tenuous peace we had in NI.

Watch Raab talking about the Good Friday Agreement: [https://twitter.com/deirdreheenan/status/1175701674767388672](https://twitter.com/deirdreheenan/status/1175701674767388672)

And here is the actual document that he hasn't read: [https://www.gov.uk/government/publications/the-belfast- agree...](https://www.gov.uk/government/publications/the-belfast-agreement)

</comment><comment><USER11> Renewed conflict in Northern Ireland, breaking the Good Friday agreement, leading to open war between the EU and the UK, with Scotland seceding during the chaos and joining the EU.

Or, renewed conflict in Northern Ireland and huge tensions between the EU and UK leads to the Queen taking control since the UK obviously doesn't know how to govern itself any more. Honestly, this seems like the best outcome; they'd be better off with royal rule than what they've chosen.

</comment><comment><USER18> It will be bad, although with the complete inability of UK leaders to get anything done or make decisions much damage has already been done.

<comment><USER19> Funny you wrote that.

The whole point of brexit was to be able to make their own decisions.

Didn't start off that well.

</comment></comment><comment><USER20> Isn't "remain" option possible?

Pardon my kidnapping the thread, but I don't think HN would appreciate splitting the discussion.

<comment><AUTHOR> Yep, it's still possible but increasingly unlikely at this point. The U.K. government have made an ultimatum today that the E.U. either accepts their "new" deal, or they leave with none. This deal isn't acceptable to the E.U. so there is an impasse.

<comment> J-dawg Except that under the Benn act, the PM is legally obliged to seek an extension from the EU if a deal isn't agreed.

<comment><AUTHOR> Yes, good point. While I hope that this is the case, my feeling after today is that the PM etc. doesn't care

<comment> J-dawg Sadly that's my feeling too. He's already publicly said he would rather 'die in a ditch' than ask for the extension

<comment><USER3> If the Liberal Democrats back down on Corbyn running a caretaker government we could very well see a second referendum that would more than likely return a remain result.

It certainly doesn't settle things, we're going to have these issues for years to come, but may take us away from the cliff edge.

</comment></comment></comment></comment></comment></comment><comment><USER10> In NI:

\- Irish border posts are setup

\- Lots of confusion at the border

\- Small groups of young men throw rocks at the border guards

\- Escalations occur

\- People die

\- New era of the troubles ushered in

\- 10 years later and thousands killed / displaced

Meanwhile in scotland

\- Scottish referendum tabled

\- Overwhelming support to leave the UK and rejoin the EU

\- Referendum passes (just)

\- UK dissolves into England, Wales and NI

NHS still underfunded.

</comment><comment><USER21> nothing special

<comment><AUTHOR> Can you elaborate on why you think this? Genuine question

<comment><USER21> most important treaties will be negotiated under new treaties, as it's in interest of both parties (people tend to forgot it's not in U.E. interest to have no deal at all). If there was a real threat, The City would have already left somewhere else, and it's not the case. Actually, it's pretty obvious that U.E. makes everything they can to impeach the Brexit that's why I tend to think the real threat is more for U.E. (as an institution) than for UK.

<comment><USER19> Even if you were correct, negotiating treaties takes time and the British politicians have already demonstrated major lack of skills in this area.

EU tried for 30 years to come to agreement with Brits. they dragged their feet and caused lots of friction even when they had great offers. Why would things be better this time?

<comment><USER21> U.E. has already treaty with many countries or others unions (like UE), so it might be pretty easy. Also looks at economical situation in UE, they are not in a situation where they can be in economical conflict with (or at least isolated from) a country like UK

<comment><USER19> Seriously, what is U.E. ?

<comment><USER21> ...well, i'm french, it's written that way, but i can't seriously believe you didn't guess. Right ? ;)

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> We know exactly what happens because it's actually defined in treaties, specifically WTO rules will apply. The UK is a full member of WTO independently of the EU. It's important to remember that "the deal" isn't a thing that was mentioned on the pamphlet that went through everyone's door before the referendum. That just said that the government will implement whatever the people vote for (which was to leave). It's entirely something the necessity of which was made up after the fact, as a face-saving measure by a political class that badly misjudged the national mood.

It is obvious to anyone who has ever negotiated for anything, ever, that no deal is better than a bad deal. Ask yourself why Remainers are so keen to take that option off the table and keep asking for extensions indefinitely.

<comment><USER23> > It's important to remember that "the deal" isn't a thing that was mentioned > on the pamphlet that went through everyone's door before the referendum.

This was the pamphlet of the official Leave campaign:

[http://www.voteleavetakecontrol.org/our_case.html](http://www.voteleavetakecontrol.org/our_case.html)

It said "There is a free trade zone from Iceland to Turkey and the Russian border and we will be part of it", and "Taking back control is a careful change, not a sudden stop - we will negotiate the terms of a new deal before we start any legal process to leave".</comment></comment>


Koliko - <AUTHOR> http://www.koliko.co.uk The UK's largest, simplest, most reliable price comparison website. We offer our users completely un-biased price comparison from over 60M products and 1000's of merchants. <comment><USER2> "Cólico" is a word used for stomach cramps in spanish.

</comment><comment><AUTHOR> uses social data and artificial intelligence</comment>


Test Your IPv6 Connectivity - <AUTHOR> https://test-ipv6.com/ <comment><USER2> I suggest testing by running `telnet towel.blinkenlights.nl`. I have found it to be much more entertaining.</comment>


Death by Hamburger - <AUTHOR> https://blog.marvelapp.com/death-by-hamburger/?utm_source=weekly-newsletter&utm_medium=email&utm_campaign=marvel-newsletter-2017-06-14&utm_term= <comment><USER2> There are two things I dislike in UX: Spinners and Hamburgers. I'll be glad to see both go the way of the Dodo.

<comment><AUTHOR> AMEN to that!</comment></comment>


Kay's 8 - <AUTHOR> http://blog.fogus.me/2012/03/15/kays-8/ <comment><USER2> Check out <http://pyjs.org/>. These people have built a python to js compiler, kind of like the Google web toolkit. It may not be the same as running python natively in the browser, but it is a start.

<comment><USER3> Could it be, that you're looking for this thread? <http://news.ycombinator.com/item?id=3707338></comment></comment>


Show HN: Copy code from Stackoverflow and other similar sites - <AUTHOR> https://chrome.google.com/webstore/detail/copy-code/ophfcfplhjmiakmfeemkpaoofhjlmkof <comment><USER2> Hmm. Your ctrl-c is broken?</comment>


Worldwide Tablet Market Continues to Decline - <AUTHOR> http://idc.com/getdoc.jsp?containerId=prUS25811115 <comment><USER2> I don't know why anyone's shocked. The first few years of tablets sales were by people buying their first tablets because it was the hot new technology. Now that we all have one, there's no need to buy a new one every year or every two years (in the case of cell-phones, which are mostly fueled by carrier subsidies). My HP Touchpad from 2011 still works fine--particularly since I made it an Android tablet by installing Cyanogenmod on it, thus keeping it on a far more recent Android version than any other tablet from this era would carry on their OEM firmware. It's not terribly speedy, but I can still run stuff on it, so for a bedside comic book reader and Netflix machine, it works just fine.* I have no real reason to upgrade anytime soon, particularly since I've got a 2013 Nexus 7 that still runs great.

The industry needs to stop thinking of tablet sales like cellphones and start thinking of tablets like laptops and computers. We're not going to buy new ones every two years because we spent anywhere from $300-$500 on the damn things: we expect them to work for awhile. The same reason that when the computer I spent over a grand building ten years ago stops being able to run modern games on even the lowest settings, I'm going to load CentOS on it and turn it into a media server: because I want to get my money's worth.

* It also fits very well into an iCade cabinet. Touchpad running MAME4Droid inside the iCade is a popular attraction at monthly gamenight.

<comment> TD-Linux >2013 Nexus 7 that still runs great.

The eMMC on mine is toast, I shopped around and couldn't find anything that I liked better and so ordered a new motherboard. Are there any other options around that size that make sense as the Nexus 7 is discontinued?

<comment><USER3> If you find one, let me know. The Nexus 7 was the best Android tablet I've seen.

I've used the iPad mini and it's very very good. It's also twice the price of what I bought my Nexus 7 for.

<comment> TD-Linux Well, my motherboard transplant went successfully, so I'm no longer in the market for a while.

</comment></comment></comment></comment><comment><USER4> I bought a tablet awhile back, not really knowing what I'd use it for, but thinking that it might encourage/inspire new things. In practice, I found only one extremely limited use for it. The 10" screen, turned vertical, most approximates paper books (compared to a phone, e-reader, or widescreen monitor). For textbooks, or other ebooks that need layout and color, it's good, and convenient that I don't need to be at the desk. But that's it. That's the only thing it's good for.

If I'm just reading a text-based ebook, then an e-ink reader is better, even with the smaller screen. If I'm wandering around somewhere, the phone is more portable. If I'm doing anything that requires an actual user interface more sophisticated than 'tap', then a laptop or desktop is better.

As a consumer device, I found the tablet to be a solution without a problem. It excelled at nothing. It wouldn't surprise me if tablets drop back to specific industrial/commercial uses where a laptop/chromebook is too inconvenient and a phone is too small.

<comment><USER5> I have a iphone, ipad and macbook. At home my go to device is the the ipad when I am not at my desk.

The laptop takes way to long to un-suspend, easily gets too hot in my lap, and the battery life all too easily gets turned into something that is just a few hours by the wrong running program. The power jack is located up in my office. It is a portable computer, but spends most of its time on my desk and is handy for several times a year when I bring it out of the house (and the last time I actually grabbed the ipad over my laptop...).

When I need a quick and dirty question what was that movie that came out in 1984 about that cowboy or whatnot pulling out the phone and browsing it is a perfect fit. Same goes for wasting 5 minutes playing a game, checking stocks, maybe see what is new on hacker news.

But at home while the phone is on me, the ipad is usually around the living room and it has all the apps the iphone has, but with a much bigger screen. After selling the ipad2 and getting the Air my only complaint about weight also went out the window. For casual consumption the ipad is my device of choice. A screen big enough that I can read articles, go to websites like ebay and get a real interface and not their tiny mobile version, read pdf's, netflix, play neat games, youtube etc. Given that it has the same charger as the phones there are several charging spots around the living area of the house so it is not off hidden in my office all day.

I have caught myself a number of times starting to browse the web on my phone only to stop, put the phone in my pocket and grab the ipad to continue where I was. I wont be bringing the ipad to work or around town, that is what the phone is for, but around the house be it the living room, backyard, etc the ipad is my preferred choice.

Lastly for kids while I don't give my daughter my phone or my laptop she can use the ipad. I am not sure how universal that is, but just about every parent I know does the same.

To answer your question the tablet is a better device for longer term consumption around the house than a laptop or a phone is.

The upgrade cycle is slower than the phone, but I am not just spouting my opinion I am putting my money where my mouth is and in fact I am expecting a Air 2 in the mail next week.

</comment></comment><comment><USER6> The computing market is in a weird state.

I'm sure we all remember netbooks. They sprung up overnight. I remember Sony and others calling them a "race to the bottom" yet they seemed to disappear almost as quickly as they appeared.

I honestly thought the tablet market was going to be huge. FWIW I use my iPad a ton.

In both cases there was a certain amount of convergence. Costs on laptops came down so you could get good specs for a relatively low cost. The 2nd Macbook Air was (IMHO) game-changing here and it took competitors several years to match the hardware/price point.

With tablets phone have gotten larger to the point where the line between phone is blurry when phones can be 6" and tablets 7". Personally I hate this trend and still have an iPhone 5 because I like the size.

Now I think device longevity has something to do with all this. I'm sure there are people happily using the original iPad, or at least the iPad 2. There's really no reason for most people to upgrade or replace any computer until it dies.

So I don't really know where the market. Laptops/desktops aren't a growth market. If tablets are in decline and netbooks are essentially extinct, what's left? Are phones the only growth area? What happens when that market hits maturity as I'm sure it will at some point?

<comment><USER7> Netbooks haven't disappeared. My family and many friends use them as their only non-smartphone device. They're called "Chromebooks" or "cloudbooks" now.

The tablet market _was_ huge, but it was because people craved cheap, usable laptops (see comment above). Something without a physical keyboard or a stand is simply not very useful. It's a portable TV. People wanted the laptop form factor, and all those keyboard/dock accessories became almost standard.

You're right, though, that device longevity has a lot to do with it. Same with laptops. If you have a decent laptop with a SSD from a few years ago, you're not missing all that much by not buying a new one this year.

I don't really see why there has to be any area for major growth right now. A lot of these form factors have reached relative maturity. We'll eventually get to the point where all the computing power we need fits into our phone, and we can just use "dumb" form factors (TV, laptop shell, etc.) to project our phone. Then we'll really see the decline of the other form factors.

</comment></comment><comment><USER8> The decline in the market is a good thing. It means we're moving towards a place where vendors won't consider their hardware to be cash cows, and release an incremental update every year for people to line up for. More importantly, it means the consumer is starting to wake up to the fact that they don't have to replace their device every two years.

Like the much-heralded death of the PC, I think this is simply a manifestation of the fact that Everyone Already Has One™.

<comment><USER3> Also, where's the innovation? I want better battery life, more memory, cellular data, a memory card slot.

My existing tablet is "good enough" but I'd upgrade for something that is better, otherwise I'll wait until it dies and buy something at a similar price point.

<comment><USER7> Unfortunately, "better battery life" isn't compatible with thinner, better screen, or faster. Of course there is progress being made in CPUs/GPUs that improve battery life without sacrificing speed, but it so far hasn't been revolutionary. The iPad 2 still has specs that work for most people.

As for memory, I assume you meant of the storage (rather than RAM) variety. That's intentionally not expandable, because they want _some_ way to make your old device obsolete.

Cellular data has been available in tablets almost since the iPad came out, so I'm not sure what you mean there...

<comment><USER9> > _" That's intentionally not expandable, because they want some way to make > your old device obsolete."_

This only makes sense if they were increasing storage capacity year over year - but this hasn't been the case for a while.

We've been on the 16/32/64GB system for a preeeetty long time now.

Storage isn't being expanded because the demand for local storage is decreasing for most users - where someone used to sling around gigs of music it's now streamed on-demand. Ditto videos.

Expandability isn't prioritized because most users who bought the old expandable devices never used it, and it creates user confusion when they use it without knowing what they're doing - the lack of an explicit file system in tablet UX means that users don't keep tabs on where their apps/data actually live and then get confused when they eject the memory card.

Expandable storage sadly has always been a niche, power-user feature.

Planned obsolescence is sometimes a thing, but in this case it seems reaching.

<comment><USER3> >Storage isn't being expanded because the demand for local storage is decreasing for most users - where someone used to sling around gigs of music it's now streamed on-demand. Ditto videos.

Is this a feature that the users want? Or a feature that iTunes, Google, Amazon, Netflix, and Spotify want? It's interesting to me that the "drive for bigger drives" stopped the exact moment monetization of cloud services came on the scene.

Me, I'd LOVE to have my entire MP3 connection on my tablet. I'd also like to have enough space to put a half-dozen movies on my tablet for long car/airplane trips. Hell, give me a 1 TB drive and I can store most of my entire video collection in my tablet.

But they're not making tablets that big. Coincidence?

You're probably right, I don't "need" expandability. I _do_ need more built-in memory.

</comment></comment></comment></comment></comment><comment><USER10> The biggest source of tablets is "Other", at 45%. Tablets are now a generic product. Hundreds of manufacturers wrap plastic around a battery, touchscreen, and an ARM-based tablet SOIC chip, loads up the open source version of Android, and sells the result for under $50. That's the real tablet market.

There's been a desperate attempt by the high-end players to keep the price up, but it's failing. The under-$50 tablets used to be something you had to get in Shentzen or via Alibaba. Now they're on Amazon.

</comment><comment><USER11> I don't believe the tablet market is declining at all, they've simply shrunk them a bit and added phone functionality so that they're categorized as phones. If you have an iPhone 6 Plus or a Samsung Galaxy Note, you don't need another tablet.

</comment><comment><USER12> The iPad pro may turn this a bit. Also, are Surface Pros considered Tablets? They have been quite popular.

<comment><USER13> Yeah, I was surprised that Microsoft didn't show up in the list. I'm guessing they didn't count Surface Pros.

<comment><USER14> "Total tablet market includes slate tablets plus 2-in-1 tablets. References to "tablets" in this release include both slate tablets and 2-in-1 devices."</comment></comment></comment>


The days of Google Talk are now officially over - <AUTHOR> https://techcrunch.com/2017/03/24/the-days-of-google-talk-are-over/?ncid=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29 <comment><USER2> I'm still waiting for them to just rm -rf anything about Google Plus.

I know that they rolled the Google Talk features (mostly) into Hangouts, but this is why it's frustrating to stick with the Googleverse. You never know what's going to be there 2 years from now. It's not always progress either. There's something to be said for the relative stability of the Apple "walled garden."</comment>


Futurenda: Auto Scheduler For Life - <AUTHOR> https://www.futurenda.com <comment><USER2> You have no idea how I searched for an app like this! If you add an Apple Watch and mac menu bar version you'll win my heart and a subscription for the unlimited version! ;)

</comment><comment><USER3> Anyone able to use anything on this site in Firefox? No luck here even with most of my addons disabled.

<comment><USER4> We have confirmed it is a bug for Firefox on Download page, we are working on it and it should be fixed soon.

In the meantime, you can download our iOS app on [https://itunes.apple.com/us/app/futurenda/id1183341415](https://itunes.apple.com/us/app/futurenda/id1183341415), or our android app on [https://play.google.com/store/apps/details?id=com.futurenda....](https://play.google.com/store/apps/details?id=com.futurenda.android)

<comment><USER4> We have fixed it. When the CDN delivers the new version(typically within one hour), you should be able to download with Firefox/IceCat without issue.

<comment><USER3> thanks, that has fixed the firefox download page/login issues.

On Safari your google/facebook login options aren't working either. App itself looks very promising though :)

<comment><USER4> Thank you for trying it!

We have just tested it with safari 10.0.3 on mac and safari on iOS 10.2.1, and the login seems to be good. Can you provide us your version/platform of safari so that we can debug it? Thanks.

<comment><USER3> issue seems to have stopped after a full refresh, was having it earlier on two machines (10.11 and 10.12).

Perhaps the earlier fix also solved that one too.

<comment><USER4> Wonderful!

We confirmed the old version do cause safari login issues. We were using some chrome only prefixes, and fixing those also fixed the safari login.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> It's great. I like the concept.

However, the fact that it doesn't work offline is a showstopper.

<comment><USER4> The offline feature is on our task list, but we haven't got time to mark it as done yet.

BTW, libsodium is pretty cool! We are using it to sign our html bundle before delivering it to app. Though we are still testing it, our sodiumed version should come within weeks.</comment></comment>


Ask HN: Your coolest, most useful web design/dev tip? - <AUTHOR>

I've found that web design, and back end development, is surrounded by an amazing community of people. With so many people doing neat things it's no wonder that so many nifty tips and tricks come about. Many of these tips or tricks become part of many people's bag-o-tricks - their "go to" way of achieving neat effects, or awesome typography, or just anything that makes web development that much more appealing. Often times it could be a certain font that you use at a certain size, and it just looks amazing you think. Or, some CSS trick that you feel gives your pages that current, trendy look. Even could be some Photoshop trick that you like to do with images for your sites. Anything. Most people have a few.
So, I thought it'd be fun to share yours. If you had to pick one or two items from your arsenal of tips/tricks, which would they be? <comment><USER2> One simple way to figure out the correct way to create a CSS hierarchy is to avoid using physical descriptions entirely in your tags, and focus on "content" descriptions. Your classes should not ever be called "green", "absolute", "underlined", "float-right" etc. They should be called "main- menu", "primary-container" etc. This carries over into using javascript to control the look of the page: your styles that will be swapped should be called the state of the object, not the physical change (ie: call it "active" not "enlarged").

This may seem trivial/obvious, but if you are working on a large site, or a front end intensive site, it's pretty important and there is a lot of this, even in otherwise clean codebases. If you create lots of subclasses (like "absolute", "red" etc.) you tend to couple the styling of the page with the content in a really messy way (if you go to update the styles of this page you will have to do a lot of html editing as well, which defeats the purpose of external CSS).

</comment><comment><USER3> Sensible includes/templating with PHP or whatever stack you're building on. This is so useful when done well, but I don't know how many times I've seen otherwise intelligent people sitting there copying the same markup/code into every file or banging their head off the wall when Dreamweaver or some other bloated suite tries to update a "template" on 4500 files and upload them to production.

The idea is simple: anything that you're going to put in more than a couple places/files, should be pulled out and put in a separate included file. Your doctype declaration? Your nav bar? Your generic site-wide footer? Put all these kinds of things in includes, update 1 file later and your changes take place everywhere.

</comment><comment><USER4> It's simple and obvious, but few people actually do it: read the CSS spec. Learn the rules for specificity, for vertical margin collapsing, for positioning and stacking, for forward-compatibility.

I know way too many front-end devs/designers who only learned from shitty second hand tutorials, and it always shows.

</comment><comment><USER5> 1: Use framework: jQuery (for animated effects/AJAX), CodeIgniter for backend. Or mootools/scriptaculous if you inclined so.

2: Learn to use CSS selectors effectively. It changed my world in a day literally. Easy to digest source: [http://net.tutsplus.com/tutorials/html-css- techniques/the-30...](http://net.tutsplus.com/tutorials/html-css- techniques/the-30-css-selectors-you-must-memorize/)

3: Only use fancy fonts for headings, never body copy.

4: If stuck on design, browse famous Web Design Gallery or CSS gallery for blog and current trend design. For corporate or more convensional, i like to pick inpirations from templatemonster.com

5: For backend, best to learn from basic. Type the tutorial codes one by one and understand how it works. If short on time, just focus on CRUD operation. When got more time, learn how to optimize it for speed and maintainability. After that, pick any frameworks that is popular and promising. It will help shortern your development time tremendously. :)

</comment><comment><USER6> My #1 tip is to use a CSS grid system such as 960.gs - <http://960.gs/> or Blueprint CSS - <http://www.blueprintcss.org/>

You'll solve so many headaches with layout, at the cost of having ugly CSS class names.

<comment><USER2> This goes pretty much 100% against my tip. Absolutely DO use a grid system for your design, please DONT'T use a CSS grid framework.

Here's why:

Let's say you have a class "column-760" for a 760px wide column. Now let's say you want to re-design the page. Not only do you have to write new styles, you have to go in and remove all the places you've written "column-760" in the actual markup. This entirely defeats the purpose of external CSS, and incorrectly couples style with content. I can't tell you how frustrating it is to work on a page that says something like:

DO use content descriptive class names, DON'T use physically descriptive class names.

<comment><USER6> Why not use semantic class names with the grid system? That's what a tool like Compass (<http://compass-style.org/>) will do for you.

Also, if you're using a template or theme, many of the changes you'd need to make if you were changing the layout would only be made in one place.

<comment><USER2> To be honest I hear you, if you use semantic class names tied to a grid, and keep the class layering to a minimum it's totally fine. But I've just never found a use for CSS frameworks, SASS etc. (and I work on a relatively large public site). CSS has just never been the bottleneck for me, and the few times I've wanted to use variables and other complications have usually been for "clever" hacks, nothing production quality IMO.

As for your second point, it really depends on the coupling. If you are using a grid system, like I was talking about, it's pretty rare that you would ever want to restyle EVERY single 760px wide div (which just leads to more class layering and more of a headache).

</comment></comment></comment></comment><comment><USER7> Use feature detection rather than browser/UA sniffing. Tools such as <http://www.modernizr.com> and <http://www.headjs.com> (limited feature detection but also provides other features) can be very helpful.

</comment><comment><USER8> Learn to use Firebug (<http://getfirebug.com>).

It is one of my most indispensable tools in debugging HTML, CSS, and JavaScript. It's also one of the only remaining reasons I still use Firefox for web development. The tool is simply a life saver if you learn it like the back of your hand.

</comment><comment><USER9> Use SASS, you can define functions and keep your stylesheet modular.

</comment><comment><USER10> zoom:1;

</comment><comment><USER11> visit HN every freakin day!</comment>