The resource leak bug of our civilization (2014) - <AUTHOR> http://countercomplex.blogspot.com/2014/08/the-resource-leak-bug-of-our.html <comment><AUTHOR> Previously: [https://news.ycombinator.com/item?id=8679471](https://news.ycombinator.com/item?id=8679471)</comment>


PySonar: an Advanced Static Analyzer for Python - <AUTHOR> http://yinwang0.wordpress.com/2010/09/12/pysonar/

<comment><USER2> Yin Wang is awesome and his work on programming languages and type inference is super impressive. We've been using his PySonar (v1) to build a global index of Python code and it works far better than we or anyone would have expected, for a dynamic language.

Here are some examples of what PySonar can do:

* Python stdlib, sorted by most-used functions: [https://sourcegraph.com/hg.python.org/cpython](https://sourcegraph.com/hg.python.org/cpython)

* Finding everywhere a function is used: [https://sourcegraph.com/hg.python.org/cpython/symbols/python...](https://sourcegraph.com/hg.python.org/cpython/symbols/python/Lib/logging/getLogger)

* All usages of the Django URL render_to_response function: [https://sourcegraph.com/github.com/django/django/symbols/pyt...](https://sourcegraph.com/github.com/django/django/symbols/python/django/shortcuts/render_to_response)

* All usages of the Flask @app.route decorator: [https://sourcegraph.com/github.com/mitsuhiko/flask/symbols/p...](https://sourcegraph.com/github.com/mitsuhiko/flask/symbols/python/flask/app/Flask/route)

This is all done using PySonar v1-based static analysis on Python code. PySonar v2 is even better.

</comment><comment><USER3> Very cool!

From a pragmatic perspective, I'd like to see an extension of this that enables me to ask PySonar to insert some validation magics in my functions and object methods to enforce the caller to use the appropriate types.

</comment><comment><AUTHOR> Which is now open-sourced at: [https://github.com/yinwang0/pysonar2](https://github.com/yinwang0/pysonar2)</comment>


Tesla Ventilator [video] - <AUTHOR> https://www.youtube.com/watch?v=zZbDg24dfN0 <comment><USER2> I am glad this isn't just another bag valve mask with a linear actuator. Unless the patient is heavily sedated a system that just pumps air in and out can cause damage to the lung because it isn't working with the patient. This Tesla system unlike the other corporate ventilator PR stunts is monitoring pressure, and heating the air going in.</comment>


Data storage and transfer using human muscle contractions (2018) - <AUTHOR> http://peterbuczkowski.com/projects/medium-machine <comment><USER2> > The information can be anything. A seemingly uncoordinated twitching finger > could be a song when placed on a piano or the right pin number when placed > over an input panel of a cash dispenser. Until the signal is not decoded, > even the carrier is clueless about its meaning.

Is that true? I've never heard of 'muscle memory' being an actual memory like that...

\---

However, I'd like to point out that there is in fact a well-established kind of memory which lets you use a human to carry a large amount of memory while being 'clueless' about not just its meaning, but what the encoding even is: visual _recognition memory_.

You can recognize whether you've seen an image before; given appropriate datasets, this allows encoding messages into a human's visual recognition memory without them being able to elicit this knowledge in the absence of the target images. This can be used for tricks like storing passwords, or multiplying 10-digit numbers: [https://people.csail.mit.edu/andyd/rec_method.pdf](https://people.csail.mit.edu/andyd/rec_method.pdf) I calculate that you could feasibly store 5.8 kilobits per human: [https://www.gwern.net/Spaced-repetition#fn61](https://www.gwern.net/Spaced- repetition#fn61)

</comment><comment><USER3> If this works then this would be a way to store passwords or private keys unconsciously in the muscle memory of the only person who should have access to them.</comment>


IPv6 is here - <AUTHOR> http://www.apnic.net/publications/news/2011/delegation

<comment><USER2> IPv6 is in no sense here. The fiat allocators can exhaust their address space completely and the Internet will continue to function indefinitely; it will simply become more expensive (first marginally, and then significantly) to hold a static address.

There are deep problems with universal deployment of IPv6 far beyond simply getting people to throw a switch; the number of popular software packages that will malfunction when addresses cease being representable in scalar integers is large.

<comment><USER3> The natural solution will be that IPv4 addresses will start getting more and more expensive as they become scarce. At some point, switching to IPv6 will be the cheaper option, and then the switch will happen.

<comment><USER4> But if you only buy an ipv6 address, the people who are only on ipv4 can't get to you. By itself, the ipv6 address is nearly worthless. The only people who have them now are people who also have an ipv4 address. ipv4 isn't going away any time soon...

<comment><USER5> Take any prefix thats currently unallocated and make it so that you slap that in front on any ipv4 address.

Volia now everybody has an ipv6 address.

<comment><USER6> Currently IPv4 addresses fix nicely (exactly) into a 32-bit integer. How do you propose that software storing addresses as such will be able to use a larger address without an update? (Not to mention all of the other reasons, like the different packet format to accommodate the larger address space among other things)

</comment></comment></comment></comment></comment><comment><USER7> This needs a better headline, given the gravity of the announcement. IPv6 is by no means _here_ , and really has nothing to do with this news item. To me, "IPv6 is here" says absolutely nothing about the real news here - APNIC having received two /8s (and one forthcoming), making them the recipient of three out of seven of the remaining /8s.

The gravity of this announcement is that we are now in the Exhaustion Phase of the ICANN policy on IPv4 depletion: [http://www.icann.org/en/general/allocation-remaining- ipv4-sp...](http://www.icann.org/en/general/allocation-remaining- ipv4-space.htm)

If anything, it means we need to boogie on IPv6 now, but that's not new (and is only tangentially related to the announcement).

<comment><USER8> Definetley, inaccurate headline. The problem is, this is a historic moment, it's just extremely difficult to explain why. This is more lime the beginning of the end. It's going to be long and drawn out.

<comment><AUTHOR> I won't really deny that. I can't really come up with a catchy title for what actually happened today, but I feel it's pretty important.

<comment><USER9> "The end is nigh...for IP4!" perhaps?

</comment></comment></comment></comment><comment><USER10> Is nobody else afraid that instead of IPv6 we're now going to get more and more layers of NAT?

Sure, for us geeks that's totally unthinkable... no servers, no P2P?!? But most users, who are content with just web & email, will probably never notice the difference.

ISPs will surely find it easier to turn NAT on than to switch to IPv6, and the backlash might be close to nonexistent.

<comment><USER11> It's not clear that NAT is cheaper than IPv6; huge NAT boxes are pretty expensive.

</comment></comment><comment><USER12> As I understand it, this is the last few IPv4 blocks being handed out. This leads people to conclude that IPv6 is here? If anything, it seems to me that it's "IPv4 is gone", and we need to take steps to ensure that that wasn't the last thing we had.

</comment><comment><USER11> IPv6 is _not_ here; that's the problem. This is a momentous announcement, though.

<comment><USER13> IPv6 IS here, I believe you meant to say it's just not evenly distributed yet!

</comment></comment><comment><USER14> Here, yes, but not particularly wide-spread and slowly becoming more necessary.

A little tool I built last week .. is your site IPv6 ready? <http://ready.chair6.net>

<comment><USER15> I like it. You should also add checks for ipv6 glue records. I advertise ipv6 dns servers but I do not yet have glue, so you still need to connect to my dns servers over ipv4. According to your tool I just have to convince google to add AAAA records to their MX targets and I'm set, but I'm not :)

<comment><USER14> Thanks for the suggestion.. I added a few more DNS-related checks. I think I have the tests/logic right but please let me know if you spot any errors.

</comment></comment></comment><comment><USER8> Ok, ipv6 is here. Or not. Anyway, when is Amazon going to support ipv6 on ec2?

<comment><USER16> While Amazon still has no native IPv6 you can at least use 6to4 for now to evaluate/test, see my guide and script at: [http://binarymentalist.com/post/2984855918/try-ipv6-on- amazo...](http://binarymentalist.com/post/2984855918/try-ipv6-on-amazon- ec2-using-6to4)

</comment></comment><comment><USER17> Even after innumberable discussions about this subject, I still don't get why people are so afraid of NAT.

The main concern seems to be about ISPs starting to NAT everybody and their dog. Well, guess what, they just can't do that. For starters because their users would get very angry when their torrents stop working, and would jump ship for any other ISP that announces that it either doesn't do NAT or has implemented IPv6.

There is still a huge amount of work that can be done to compress the usage of v4 address space. Maybe not much that the RIRs or the ISPs can do, but as the cost of owning a static IPv4 address goes up (and I believe that it will go _way_ up), end users will start compressing their public services into fewer addresses and giving back small subnets to their providers to reduce costs. I mean, who the hell needs to have a mail server and a web server in two different public addresses when they can just do port-forwarding over a single address? (And since most servers are on DMZs with private addressing, they are mostly doing it already, it's just a matter of renumbering.)

The case most likely to go NAT is also the most likely to go IPv6: mobile devices. These are mostly behind NAT already, and going IPv6 would actually reduce costs for ISPs. It would also put ISPs in the track for more extensive IPv6, since the major problem now is that people have little knowledge of how IPv6 works and ISPs are trying to avoid the pain. The issue is, of course, that 99.9% of mobile devices don't support dual-stack and even in a pure v6 configuration don't actually work properly.

For this I predict that in 10 years the move to IPv6 will still be half-way. Considering that we are so close to IPv4 depletion and there is virtually _no_ IPv6 to be seen, I'm being faily optimistic.

<comment><USER13> How will the cost of owning a v4 space go up? It's yours, the price is set, and ARIN/IANA et al have not mentioned any intention of increasing price.

<comment><AUTHOR> For people that don't actually have their own allocation from a RIR, the price will likely go up. It's a matter of supply and demand, their provider is going to have a shrinking pool of IP addresses from which to assign new ones to servers. It seems likely to me they will start charging additional fees for more IP addresses.

</comment></comment></comment><comment><USER18> We are by no means out of IPv4 addresses. The next step is that all of the entities who needlessly snapped up /8 space early on and sat on it for so long will be selling it off. The list includes GE, Xerox, IBM, HP, Apple, MIT, Ford, Halliburton, Prudential Insurance, Bell-Northern, Merck, Eli Lilly, the DoD/military (who has 13), USPS, and CSC. Just half of this space is 234m IPv4 addresses.

<comment><USER19> Sigh... this idea has to get thrown out every time there's an IPv4-exhaustion discussion. I guess I'll be the one to do the public service of debunking it this time.

* You can assume that each of the /8s have plenty of infrastructure relying on them, meaning $millions in migration costs. Do you think that the holders will just give them up tomorrow, or do you think its more likely they'll sick some lawyers on the problem? So even if you CAN get them back it'll take years.

* For each /8 you successfully extract this way, you buy the world mere WEEKS of time.

IPv4 allocation isn't completely efficient -- we all know that. The real problem, however, isn't efficiency. 2^32 is just too small of a number.

<comment><USER20> Although the /8s have an entire infrastructure relying on their current situation, it is not unthinkable that the economical advantage of making subsets of their space available to third parties will become more attractive than just letting it sit idle. It might even justify the migration costs. So maybe we'll see parts of IBM, Apple and HP transform to IP/DNS providers.

Apart from that, it's not a question of having the /8s 'give back' IP adresses -- it's about them monetizing their available IPv4 space, out of their own volition.

Whether that relieves the IPv4 shortage for weeks or months doesn't really matter. What matters is what value they can extract from it.

<comment><USER19> The "IPv4 marketplace" idea has serious issues of its own, though:

1\. it's ARIN (and, I think, other registrars) policy that you do not `own' your assignments in any legal sense. So if you sell them you may be committing fraud. If the deal goes bad it's not clear what the legal recourse would be. This is just a flipside of the "take back the /8s" problem: it gives too much for the lawyers to do.

They might even collide: suppose a large company with a /8 (say, Haliburton) decides to open a IPv4 marketplace. In response, ARIN says "well its clear you have more IP space than you need, so we're taking back your allocation effective next month" Now who has the rights to those IPs: the people who paid Haliburton for them, or those that got them in new assignments from ARIN?

2\. Just having an IPv4 address isn't useful if it isn't routable. To split up a /8 into tiny salable bits means that all of the backbones need to update their BGP route prefix filters.

If this were done under the auspices of ICANN this wouldn't be a big problem at all: if ICANN says that the allocation policy for an address range has changed then all of the big players will follow suit. (There can be a few remaining routing issues for a new /8 on the periphery but they tend to get sorted out fairly quickly)

Would a similar announcement from Halliburton have the same effect? Doubtful, especially if it is done in opposition to ICANN's wishes. So probably any IPs "bought" in this system won't actually be routable.

3\. Related: even if there was a healthy, 100% legal marketplace for IPv4 space it could only be practical if they were bought and sold in large chunks exclusively. If everybody who wanted some space for their company had to buy their own /28, the global BGP routing table would completely explode.

The only workable marketplace would be at the ISP level.

4\. The registries are all united in wanting IPv6 deployed. Having companies making big profits selling their lucky IPv4 windfalls means that there would be deep-pocketed people with a vested interest in stalling IPv6 even more... after all if IPv6 were widely deployed the value of `their' IPv4 addresses would plummet.

Now it is true that if the IPv4 situation becomes dire enough, some of these players might decide to suddenly get into the hosting game and put more of their IP space to use. For instance, Apple has a /8 and just built a HUGE datacenter.. maybe they want to do their own version of EC2? The idea is a little odd but maybe not unthinkable

</comment></comment></comment></comment><comment><USER21> If people are really interested in speeding IPv6 adoption, the fastest way might be for government and/or industry to subsidize IPv6-only broadband for consumers (via existing ISPs).

Imagine $1-5/month DSL to your home, price-locked for 3 years--except it's IPv6-only. Lots of cost-conscious people would sign up or switch to save $xx/month, even if it meant their Internet access was crippled for a while.

But it wouldn't be crippled for long, because with such an underserved user base, the major services most people care about (Facebook, Google, etc.) would very quickly start to cater to it (even if the demographics did skew low- income), because it would be a green field and a big opportunity to build longer-term user relationships to monetize down the road.

</comment><comment><USER22> This might be a stupid idea, so feel free to roundly berate me, but...

Given that a switch to IPv6 has potential to cause widespread problems, and that we might be facing such a switch before they are ironed out..

Can we not simply update IPv4 and add a new octet to the address space? So _255_.255.255.255.255, then call everything distributed so far 000.xxx.xxx.xxx.xxx and make a start on the 001.xxx.xxx.xxx.xxx address space.

I appreciate that we would need to update a lot of software to handle the new octet, but I can't help feeling that would be much easier to do (with the advantage of easier "failing gracefully" / backward support).

But networking ain't my thing :)

<comment><USER23> As I understand it, the problem for IPv6 is with existing routing hardware and with testing. So if you're going to go through all the effort to add a new octet (which requires changing the IP packet format to allow for the extra space, for example), then you might as well go all the way to IPv6 and solve the problem once and for all.

<comment><USER22> Ah, the IP packet format - hadn't considered that aspect, cheers. As you say - wouldn't make sense.

<comment><USER6> Not just the IP packet format. Most software ends up storing IPv4 ip addresses in a 32-bit integer (because it fits exactly). All of those pieces of software would need to be updated to work with IPv4's 'new ocetet' as well. As the other poster stated. If everything needs to be upgraded, then might as well do it right the first time.

</comment></comment></comment></comment><comment><USER24> The final paragraph is somewhat ominous:

"APNIC reiterates that IPv6 is the only means available for the sustained ongoing growth of the Internet, and urges all Members of the Internet industry to move quickly towards its deployment."

In other words, as wmf has already said, IPv6 isn't here. But it needs to be, and soon, otherwise the game is very rapidly going to be up.

</comment><comment><USER25> I only have a basic understanding of IPv4 vs IPv6, so can someone explain to me:

a) what impact will this have on me as Joe Public internet user?

b) what impact will this have on me as a web developer?

Or point me to suitable websites that explain in quick skimmable chunks...

<comment><USER13> a) Eventually (most likely next year or later), if you do not have IPv6 connectivity, there will be new content and sites added to the global internet that you will have no way of accessing at all from your v4 connected computer.

a2) Alternatively, in a year or so, you get service from a brand new ISP that has no v4 connectivity (so, you are v6 native), and you cannot access _anything_ on the v4 Internet around the world (e.g. most things today).

b) Don't store IP addresses as 32bit integers, or as 15 character strings. Be aware that geolocation services probably don't do well with v6 addresses. Make sure your deployment platform has the infrastructure in place to serve both v4 and v6 customers (or at least v6 after a year or two) - AAAA dns records, etc.

<comment><USER26> Why would a new ISP have no v4 connectivity? They'd be connected to someone, and they would likely have v4 connectivity. Wouldn't they be able to have a private network connection to them (10.x.x.x)?

<comment><USER13> You can't eBGP route private addresses. (well, you _can_ , but if you do, you should be shot).

The new ISP would need it's own space to announce (it's not much of an ISP if it's got no customers to give addresses too, so it needs addresses. It's also not much of an ISP if it's only got one upstream, so it'll need PI (provider independent) space, allocated to it from it's RIR (ARIN, RIPE, etc). And that'll all be gone soon :)

</comment></comment></comment></comment><comment><USER27> So when does the entire internet fall apart then?! Millennium bug, anyone..??!</comment>


Genes that separate humans from fruit flies found - <AUTHOR> https://phys.org/news/2017-09-genes-humans-fruit-flies.html <comment><USER2> I feel sure that I have met cow-orkers in whom these genes may not be fully functional...

</comment><comment><AUTHOR> article has a really weird title nonetheless</comment>


I Google everything - <AUTHOR> http://wernah.com/2012/03/i-fucking-google-everything/ <comment><USER2> Great article.

A side point, but one that is more interesting to me: in my social circle, I'm the only person who _actually_ Googles everything. When I sit down to have a conversation with most people, and questions about _facts_ come up, I instinctively start Googling. Almost no one else does this. People will prefer to spend an entire conversation trying to guess the population of e.g. Greece, rather than spend 5 seconds to just find it out.

And they don't seem much interested in the answer when I provide it, actually.

<comment><USER3> _And they don't seem much interested in the answer when I provide it, actually._

I'm the sort of person who would happily spend an entire conversation trying to guess the population of Greece and frown upon anybody who tried to Google it. I like the fun, social 'game' of trying to work out random stuff from a few first principles . Having someone Google for it and tell me is like someone telling me the ending of a movie. Sure it saves me the two hours having to sit though the movie, but it kind of misses the point. It's not like I actually care about what the population of Greece is.

<comment><USER4> That's interesting. I didn't know people would think like that. Your post explains a lot, now the world makes much more sense. Thanks for posting it :)

Now I wish people online would put a huge disclaimer saying "I'm only interested in arguing for the fun of it, not in finding an actual solution" before their posts. That would have saved countless hours of online typing wasted for nothing.

I mean, nothing wrong with finding it fun to discuss. But I wish I could accurately tell when that's the person's goal, versus whether it's a person who actually finds solving real problems more fun than talking, like I do.

Well, anyway, already learned something new today. My day is complete.

edit: wow this is bigger than I thought, now I've been reading through older HN posts where I was mind-blown about "why would he even post that? What's his motivation?". Now I feel like I can finally make sense out of it. I feel so stupid for never noticing something so simple. The world is different now.

<comment><USER5> "Now I wish people online would put a huge disclaimer saying "I'm only interested in arguing for the fun of it, not in finding an actual solution" before their posts. That would have saved countless hours of online typing wasted for nothing."

there's many things that get expressed "between the lines". arguing for the fun of it has benefits. for one, ideas get exchanged, validated and who knows: maybe something useful comes out of it.

<comment><USER6> Arguing an idea vs arguing a fact are different things. ("Reply" is meant to bring the comment in right thread, not to counter the previous comment)

</comment></comment></comment></comment></comment><comment><USER7> The stuff that can be looked up on Google constitutes a very small sub-set of the interesting things to know about the world, because a vast majority of knowledge doesn't exist yet (e.g. google stops being regularly helpful after year 2 of a PhD, for example). The Einstein quote is a perfect case-in-point. He didn't memorize the stuff in books, but he also didn't spend his life looking up stuff in books (modern translation : the internet). Make and invent people. It's much more fun than gooyouface.

<comment><USER8>
      > google stops being regularly helpful after year 2 of a PhD, for example

... and then you switch to _google scholar_ ;)

<comment><USER7> Which stops being helpful after year 4 : )

</comment></comment></comment><comment><USER9> I hate this fact. Not because the internet is in peril of going down, or because it's not convenient (of course it is) - but because we're confusing access to information with knowledge.

Access to information will tell you a number, or an answer, or even give you an amount of text about something. But knowledge lets you understand the bigger picture - how something came to be, or why.

At some point we become the needle on the gramophone, rather than the record. All we can say is what we've heard or read. It's the opposite of thinking, and it makes me worry.

<comment><USER10> Trivia is not useful knowledge in today's world. The most important thing is problem formulation. Once you have figured out the right question to ask, answering it is usually easy.

<comment><USER11> This is why I'm so fascinated with Vernor Vinge's "wearables" future, and why I think parts of it are such an accurate representation of the near future. For instance, high schools have classes called "Search and Analysis" -- basically advanced Googling & result interpretation. People have recognized that the ability to formulate the proper query is almost as important as being able to understand the results.

Check out his short story _Fast Times At Fairmont High_ [1] and the short _Synthetic Serendipity_ [2].

[1]: [http://en.wikipedia.org/wiki/The_Collected_Stories_of_Vernor...](http://en.wikipedia.org/wiki/The_Collected_Stories_of_Vernor_Vinge#Fast_Times_at_Fairmont_High)

[2]: [http://spectrum.ieee.org/computing/networks/synthetic- serend...](http://spectrum.ieee.org/computing/networks/synthetic-serendipity)

</comment></comment></comment><comment><USER12> Mandatory xkcd : <http://xkcd.com/903/>

You know, I do this a lot. It affects me in interviews as well. But the paranoid OCD geek in me wants to retain a local copy of all the information in case the internet ceases to be, and as much as I can in my brain.

I have considered locally copying wikipedia but given up after the effort that might be required. Anyone got any experience or tips?

This is also why I love man pages.

Edit: Just in case anyone is not aware check this out:<http://en.wikipedia.org/wiki/Wikipedia:Database_download>

I was asking if anyone knew of the easiest way and I see some options below. Thanks, I'll look into those.

<comment><USER13> I also like this <http://thewikireader.com/>

<comment><USER12> That's awesome! I wonder if there are any options with a bigger screen, or if any of the ereaders can be made to store wikipedia locally.

</comment></comment></comment><comment><USER14> > _I've heard whispers of a time when people could talk shit at pubs and not > be audited by wikipedia on the spot._

Talk "shit" or "bullshit"? The latter we could stand to reduce. The former...well, I guess it is annoying that any dolt can Google up a list of 500 comebacks. So I guess the emphasized skill is in delivery rather than wit.

> _Where cognitive energy would need to be spent to work out your bug, instead > of copying and pasting the error._

I don't even know how com sci algorithm courses pose a challenge anymore. Google was barely a thing when I took it and when we occasionally stumbled on obscure papers with it (or Excite), it was like finding the teacher's answer book out in the open.

> _Where you had to actually call your friends or family to see what they were > up to._

This is not such a loss. I think back when you had to call people, your conversations had to be more deliberate (i.e. I'm calling Jane to break up with her/give condolences about her dead mother) and planned. Not planned out in what you were going to say, necessarily, but planned out in that you wouldn't just call up a non-close friend and have a lengthy conversation with them. Whereas with online chat and Facebook, I've had long rewarding conversations with people whom I may never had the temerity to cold-call about anything.

<comment><USER15> "Talking shit" can mean exactly the same thing as "talking bullshit", in the UK at least.

<comment><USER16> In the US, talking shit means saying something negative about someone. John said I stole money from him? He's just talking shit. This could include truths; perhaps I did take his money, but there's more to the story than John mentioned. John paid me money for a service I performed but he thought it wasn't worth what he paid. John said I'm a cheat when I beat him in poker, but that was just the way the cards fell. He's talking shit about me again.

Talking bullshit would mean knowingly lying. John paid me for a service I told him I could perform, but I was bullshitting him when I said that. I can't actually perform the service. The mayor campaigned on lower taxes, but he knew he wouldn't be able to change that law.

<comment><USER15> Here you can "talk shit _about_ " which has the meaning you use (e.g. "I was just talking shit about my colleagues"), whereas just "he's talking shit" is similar to bullshit, except maybe a little less angry and more dismissive.

<comment><USER16> Yes, that's the same thing I was referring to. Talking shit (with no modifier) is, in my experience, an uncommon phrase to use in a sentence; the only time I can recall hearing it is when person1 is telling person2 that person3 was talking shit about them. In that situation, the "about you" part is implied, and you can leave it off. "Don't worry about it man, he's just talking shit." That implies person1 is saying person3 said something negative about person2.

Now, what I would be doing in a bar is "shooting the shit". This means you're just telling bullshit stories (wild, made up, inaccurate, designed purely for entertainment). I caught a 30" bluegill is bullshit, and I would only say that when I'm in a bar shooting the shit.

<comment><USER15> > _Yes, that's the same thing I was referring to. Talking shit (with no > modifier) is, in my experience, an uncommon phrase to use in a sentence_

No, no, no! In the UK it is not uncommon! People over here are talking shit all the time, often not about anyone.

<comment><USER16> Language is a wonderful, complex, irritating thing. The same words in the same language meaning two different, completely context-sensitive things. The same word being used in completely different ways. Not being able to describe the use of a word without long, protracted arguments giving multiple examples of the usage. Even in the same county, the same language is used differently based on geographical region.

It amuses me to hear a US citizen use words and pronunciations I know are from the UK, just due to exposure to the BBC. In the US, Hyundai is pronounced "hun-die" or "hun-day", but I have a coworker who is very much an American who pronounces it "high-un-die" because the only time he hears the word is when watching Top Gear.

The Internet makes it difficult to tell which dialect the author is speaking, spawning these arguments and fostering communication between people 3000mi away from each other. That's a wonderful thing. Now if only I could figure out what a curry is and why everyone seems to love it over there.

<comment><USER17> I'm actually pretty surprised about the curry thing. Here in the UK we get so much US media (films and TV) that I feel like I have a fairly good grasp of what they have in America. Not having curry has shocked me though.

<comment><USER15> Do they not have curry or just not call it curry? Admittedly I don't think I'm ever eaten anything like that when in America, but never really thought about it..

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> When you hold a bunch of information in your head, you benefit from your brain's penchant for making weird collisions and connections. Serendipity rules.

</comment><comment><USER19> These days, the important thing is to know the right question. Once you get that far, the rest is easy.

eg, you want to extract a date from a sentence. If you don't know the question, you might google "get date from sentence". If you do, then you'd google "date regular expression".

You still need to know stuff - just not as much of each thing, so you can know more. It's like memorizing the TOC of a book rather than the content of every chapter.

<comment><USER20> > If you don't know the question, you might google "get date from sentence". > If you do, then you'd google "date regular expression".

And then you've got two problems :) [https://www.google.co.uk/search?q=natural%20language%20date%...](https://www.google.co.uk/search?q=natural%20language%20date%20parsing)

</comment></comment><comment><USER21> I know taking issue with Einstien is not a good idea - but I'll do it anyway. Learning - and putting as much relevent material in your working memory is beneficial to seeing the bigger picture and quick informed decisions. A collection of one line facts (what you get when you look something up) does not make wisdom. Sure, most of us have extremely small working memories, but it does not negate the benefit for learning and retaining material on a subject.

as an example, I find when I have to look up the syntax for each.. and... every.. function... my programming proceeds at a snails pace. Just an example.

<comment><USER22> Feynman makes a good point when he's describing why he isn't a genius.

Someone shows him a blueprint and he just happens to know X because (I can't remember, something he did last week) and that's such a little thing, but everyone is "wow!" and then someone else asks him a question and really, Y is the obvious answer because square root Z is (something something something) and everyone says "wow".

It ends up that Feynman worked on a lot of stuff, all the time, and remembered a lot of it.

I guess Feynman wouldn't have remembered his phone number unless it had some interesting characteristic.

<comment><USER23> With a very possible "interesting characteristic" being the measurements of the lady who answered the phone.

</comment></comment></comment><comment><USER24> The comedian Pete Holmes did an amazing routine on exactly this phenomenon, on Conan O'Brien:

<http://www.youtube.com/watch?v=PQ4o1N4ksyQ>

</comment><comment><USER25> The ability to 'Google it' does not mean you have the ability to understand it. There is a difference between looking up Jeopardy facts and building a fundamental understanding of the subject and being able to discuss it, or build upon it to come up with new ideas.

</comment><comment><USER26> "For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise." —Plato, Phaedrus

</comment><comment><USER27> "Where cognitive energy would need to be spent to work out your bug, instead of copying and pasting the error."

I am pretty sure I would have gotten higher grades if I had known about StackOverflow in college. There is definitely value in figuring out things for yourself, but at the same time, staring at a C program acting differently every time because you didn't understand pointers from Day 1 and your dataset kept getting randomly overwritten, only had me learn a deep dislike for C programming.

</comment><comment><USER28> Is it bad? No. Is it acceptable? No. Where is the line? It's okay to spend your whole day trying to get tutorials out of Google because the documentation sucks or you just have no idea how the f you can start with that idea. But you must be able to digest them effectively and extends those tutorials beyond just tutorials, and make something out of them. Otherwise, if you just reuse tutorial codes from top to bottom everywhere, then you are not learning. You are copying.

</comment><comment><USER29> That (externalizing our memory) has been ongoing for long time. Going back in time; Computerized searching, Indexes, Libraries, Books, Written language, probably something like counting stones in pre-history.

I think it's utterly awesome. Combined with viable wearable computing I know everything ever put online. Just might take me a few moments to remember it (search time/connection speed).

It is the #1 reason copyright limitation, net neutrality, information freedom must be fought for.

</comment><comment><USER30> filetype:pdf has been my secret weapon. I use it like fifty times a week looking for white papers, case studies, etc for various subjects. The wealth of information hidden in these little gems is invaluable.

</comment><comment><USER31> I tell people all the time.. "Do you remember when you could bullshit anyone." Now they just type your BS into their smart phone.

<comment><USER32> It was a simpler time. You could misinform just about anybody about anything. Yoko Ono? Sure, her influence in the Beatles would arguably ruin them forever, but after John Lennon's death she went on to invent Skittles.

It's an art now though. You have to pick little tidbits that SOUND plausible but you can never really verify.

I, for example, told my (American) flatmate months ago that no living person other than current sitting monarch can appear on a British postage stamp. Had to backtrack when the Royal Mail announced every British gold medal winner at London 2012 would get their own stamp.

<comment><USER33> According to [http://en.wikipedia.org/wiki/List_of_people_on_stamps_of_the...](http://en.wikipedia.org/wiki/List_of_people_on_stamps_of_the_United_Kingdom) what you said did used to be approximately correct.

</comment></comment></comment><comment><USER34> The only thing comparable to Google searching is Twitteer search. Case in point: this morning after reading the sad news of director Tony Scott's death, I inevitable felt morbidly curious about what the circumstances or motivations might have been. Plenty of other people will too, so eventually it will find it's way into the press, but only after days or maybe weeks. So, I opened Twitter on my iPad and searched for 'Tony Scott rumours' and there was the likely answer among the first few results. Of course it was only unconfirmed conjecture but enough to satisfy my curiosity so I wouldn't spend any more time thinking about the event.

Tweets are more instant and just more human IMO. It means you can better leverage your understanding of human behaviour when you try to search for things.

</comment><comment><USER35> The OP should Google "@viewport" so his site can be accessible to mobile devices.

</comment><comment><USER36> Heads up to the author. This site is pretty horribly broken on chrome for Android. The left menu bar is fixed width and I can't even scroll to see the text.

<comment><AUTHOR> Thanks mate, i'll check it out

</comment></comment><comment><USER37> I find this similar to the math vs arithmetic issue. Math is not arithmetic. We used to have to spend a lot of time on arithmetic to do math. Now we skip the arithmetic since a calculator or computer can do it leaving us free to do the fun and interesting part, math

Similarly, we used to have to wonder about simple facts. Now though simple facts are at our finger tips leaving us to move directly to the deeper more interesting topics.

</comment><comment><USER38> The problem with this is that while it's super easy to look up facts, it's also super easy to spread false information on the web and make it look official and correct. It's quite amazing how many conspiracy videos are on youtube (along with 'true believers' sharing them on facebook). You can look at it as enabling niche information to get out, or you can look at it as a mass fleecing of a generation.

<comment><USER39> There are trolls on Twitter who make it their mission to make big media fall for big-ass lies, like the death of heads of state, etc.

</comment></comment><comment><USER40> I also like to Google everything, even individual words or proper names I already know the meaning of, just because I can. I use the Google Dictionary Extension for Chrome. Just double-click anything on the web and it pops up. Pretty awesome stuff.

[https://chrome.google.com/webstore/detail/mgijmajocgfcbeboac...](https://chrome.google.com/webstore/detail/mgijmajocgfcbeboacabfgobmjgjcoja)

</comment><comment><USER41> Memory is an essential, invaluable tool to support knowledge. Knowledge isn't an accumulation of facts, and it's important to chain them into coherent ensembles to be able to understand them, therefore training and enhancing intelligence. I both try to remember everything of significance (NOT factoids, or phone numbers) AND google everything. This is absolutely not contradictory.

</comment><comment><USER42> A year ago there was a study conducted on that topic: <http://www.sciencemag.org/content/333/6043/776.abstract>

It's behind a paywall, but you can read a number of commentaries, e.g.: <http://news.columbia.edu/googlememory>

</comment><comment><USER43> I have friends that don't even type URLs anymore, they just type 'youtube' into google every time and click the first result.

<comment><USER44> Yes. I have seen this a lot with friends and co-workers. They always google the site instead of typing in the URL or even creating a bookmark. Even for sites they go to 20 times a day.

Interesting consequence, one person, who had just created a new web page using a GUI website building tool a moment before, tried to get to the site by googling it and was surprised that it did not show up in the search results. I explained that the site was just created and Google hadn't indexed it yet. The person just gave me a blank stare.

</comment></comment><comment><USER45> Anyone else hit 'command + w' to see what it does to then have the damn window exit on them ..... ARGH!!!! :)

</comment><comment><USER46> Very interesting read. It makes me wonder if it is all about access time and the complexity of the query, then to what extent could "Google everything" be able to outsource our brain space?

</comment><comment><USER47> Who's the overly-PC type who removed the "fucking" from the title that was originally here?

</comment><comment><USER48> As a side note, your blog looks very nice, but is unusable on a Nexus 7 in portrait mode.

</comment><comment><USER49> I personally etymonline.com everything.. root fetishist.

</comment><comment><USER50> The problem with Google is that it's mostly out of date.

</comment><comment><USER51> Great article.

</comment><comment><USER52> > Shit-talking in the pub.

I've become that guy, that whenever a sticky fact comes up for debate, people just turn to me because they know I'll be looking it up.

What I really enjoy is when some asshole refutes the evidence and stops talking to me. For good.

</comment><comment><USER53> I'm a free thinker.

I don't really appreciate people who want to "sit around and wonder about shit they can look up". I'd much rather sit around and think or discuss things that cannot be looked up, to define myself as a person based on opinions I form within documented knowledge...

Do I personally subscribe to absolute or relative morality? Thanks to documented knowledge, I have a decent grasp of the concepts, so I can have an informed think about the question. On the other hand, I could sit around arguing with a bunch of hipsters trying to figure out what the difference is (if there's enough time left after the preceding argument over whether or not water boils at lower temperatures in high altitudes).

And honestly, I've always looked things up, I had a set of old encyclopedias I bought from the library for about $10 when I was a kid, and if they didn't have what I was looking for I could go to the actual library and look through drawers of cards or microfilm to find the answer. I remember looking stuff up on computers about 20 years ago on SIRS, and even before that via BBS files.

Finding information is mainstream now, and all the pseudo intellectuals are crying because their power base of personally invented knowledge is crumbling and they lack the mental faculties to think freely on a higher level and reason for themselves.

<comment><USER54> All you're doing here is endorsing sophistry over knowledge.

There's a place for logic and there's a place for facts. Focusing on one over the other leads to persons being so "open-minded" that their brain falls out.

<comment><USER53> What a nonsensical comment.

> All you're doing here is endorsing sophistry over knowledge.

What? First, sophistry, has little to do with anything I wrote. Second, I'm most certainly endorsing knowledge.

> There's a place for logic and there's a place for facts.

Really? Do you have little slots for them on your spice rack? Logic and facts are the fabric of reality. This a comment I'd expect from someone desperately wanting to be right despite being pathologically wrong.

> Focusing on one over the other leads to persons being so "open-minded" that > their brain falls out.

How was I focusing on one? Logic and facts are complimentary, and even if you somehow exclusively focused on one, how would that lead to extreme open- mindedness? And how is being open-minded bad? (You are also misusing the "being so open-minded their brain falls out" quote which is meant to meant to convey that you should be open-minded [good] but not foolishly accepting of poorly formulated ideas [bad]) What do you even mean by this comment? It is nonsense.

I think you read my comment, self identify as a hipster or "bullshitter", had an emotional response of wanting to retort and instead wrote a post that illustrated one of my points.</comment></comment></comment>


The Landlord Asks for a Christmas Rose - <AUTHOR> https://daily.jstor.org/the-landlord-asks-for-a-christmas-rose/ <comment><USER2> > "With these small, tender acts, called "serjainties," lords retained the > claims to their grand estates."

I googled "serjainties" and the only results are links to this article. I'd have thought that someone in the history of the internet would have also recorded such a weird word...</comment>


Apple, it's time to move on from "OS X" - <AUTHOR> https://medium.com/@pauli/apple-it-s-time-to-move-on-from-os-x-cb94d167c77d#.p7ekxrssi <comment><USER2> The article describes a non solution to a non problem, with ridiculous BS like: "That's a terrible way to brand a consumer product. It turns a harmless product name into a mild form of hazing: a new Mac user is bound to feel stupid at some point when the mistake gets corrected. Humiliating newbies is not to anyone's benefit."

Yeah, it so much hurt OS X, which only got it 5x larger from 2% in the late nineties to 8-10% usa market share today, for what's essentially an expensive upmarket product.

<comment><AUTHOR> The product with the market share is the Mac.

When Apple has such a powerful computer brand, isn't it weird that the Mac operating system is called something else and spelled in a way that nobody knows how to pronounce?

<comment><USER3> But the branding of the operating system doesn't really matter, because the operating system isn't a product that's sold on its own. The way you get a copy of OS X is by buying a Mac. So it's not really a problem if most people don't know its name, since they'll never be shopping for it anyway.

(The one exception is if you want to upgrade the OS on an existing Mac, but even then Apple has it covered; the only places where you can buy that upgrade are places staffed by trained salespeople, so you can just ask for "the newest OS for my Mac" and they'll know you mean OS X version whatever.)

<comment><USER4> Mac OS X upgrades are only available from the MAS (Mac App Store) now.

</comment></comment></comment></comment><comment><USER5> "a new Mac user is bound to feel stupid at some point when the mistake gets corrected. Humiliating newbies is not to anyone's benefit."

If you feel stupid or humiliated because some dickwad corrected your "Oh Ess Ex" you have more important problems in your life (and the dickwad too).

</comment><comment><USER6> I'm pretty sure both pronunciations are acceptable.

<comment><USER7> Agreed. Don't really know anyone who would say you are wrong for calling it X vs. 10. There are more important things going on in the world. :)

<comment><USER6> True, but that hasn't stopped people from being extremely anal about similar things.

I've just never encountered anyone correcting OSX before I saw this post.

</comment></comment></comment><comment><USER8> By the title I thought I'd hear some compelling arguments for Apple to ditch it's os and create a new one. I'm more of a Linux person myself but from what I'm reading osx could use some improvements. It turned out to be an article on semantics and pronunciations...</comment>


Why Eve Online's economist thinks Bitcoin could be a scam - <AUTHOR> http://www.polygon.com/2014/5/5/5677734/bitcoin-plex-isk-eve-online

<comment><USER2> His main argument boils down to: there is a risk because I don't know and/or understand the code; but with the reference source code being public, this is his limitation, not the system's.

</comment><comment><USER3> Whilst I am dubious about the value of Bitcoin for everybody, I can see that it has two very strong benefits it gives to its users.

It's main benefits are in its anonymity and unregulated border transfers. These two things give the currency something which others do not.

Also someone sitting on a lot of bitcoins cannot just dump them because there is limited demand. Flooding the market would drop the price and therefore remove the reason for dumping the coins, like a real commodity.

</comment><comment><USER4> pot, kettle, black.

<comment><USER5> I think "takes one to know one" might also apply. I don't think "hidden massive pre-mine" is such a stretch, but I'm not a... Crypto-economist? Forensic crypto-accountant? The mining difficulties were much lower in the beginning, right? So mine a load in the beginning, sell the scam, cash out?

I'm not saying it's a scam, but is it unreasonable to suggest it might have started as one?</comment></comment>


Ask HN: How was my old Google account compromised? - <AUTHOR> A moment ago I received an email from Google stating that a Google/Gmail account I created for a side project many years ago, just had a successful password reset and login from Hong Kong (IP 22.214.171.124). I've since changed password and added my current mobile number to beef up the account security.
The Google account doesn't matter much to me and there was no sensitive information stored on any of the Google services but I am honestly baffled how hackers could successfully reset the password. The account was created for a small side project that never took of, so no one knows about it (I hadn't signed into it for years). I did use the gmail address to sign up for a couple of services (flickr, skype, tumblr, etc, dropbox) but the password for every single account was very strong never re-used.
Any ideas on how attackers could reset the password? Anyone experienced something similar where an seemingly "impossible" password reset was successfully executed by attackers? <comment> 1970-01-01 Why don't you ask Google?

<comment><AUTHOR> They don't do this type of support, do they? Haven't been able to find a phone number or email address.</comment></comment>


The Wrong Abstraction (2016) - <AUTHOR> https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction <comment><USER3> I found the following comment very insightful in a past discussion:

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

I reproduce the relevant part:

 _Dependencies (coupling) is an important concern to address, but it 's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code._

State > Coupling > Complexity > Duplication. I find that to be a very sensible ordering of concerns to keep in mind when addressing any of those.

<comment><USER4> There is a quote by Linus Torvalds that is relevant here:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

<comment><USER5> "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." \-- Fred Brooks, The Mythical Man Month (1975)

<comment><USER6> I looked up the full text of the book, but couldn't figure out what tables mean in this context.

<comment><USER7> The quote comes usually with "data" instead of "tables" and "algorithms" instead of "flowcharts".

</comment></comment></comment></comment></comment><comment><USER8> Yup.

On the one hand, often there can be shared lines of code without a shared idea, this shouldn't be a candidate for being factored out into some new abstraction.

On the other hand, you _may_ want to introduce an abstraction and factor out code into a common library / dependency / framework when there's a shared well-defined concern/responsibility.

That said, on the gripping hand, I say _may_ because even if there's the opportunity to introduce a clean future-proof abstraction, introducing it may be at the cost of coupling two things that were not previously coupled. If you've got very good automated test coverage and CI for the new common dependency and its impact upon the places it is consumed, then perhaps this is fine. If the new common dependency is consumed by different projects with different pressures for change / different rates of change / different levels of software quality then factoring out a common idea that then introduces coupling may cause more harm than good.

<comment><USER9> People often forget "copy-on-write". Coupling doesn't have to be permanent. If refactor to create a sahred component, and then you want to modify a shared component to help one client, you can fork it -- it's not worse than simply not having created the shared component in the first place.

<comment><USER10> In my experience people will most likely just hack the shared component by adding awful arbitrary if-statements or other such hacks, rather than fork the shared component. This is the path of least resistance. Once this happens a few times that shared component begins to be seen as a central component and is quite a complicated mess.

<comment><USER11> Well, after enough settings are added, take a look at your components, and define a clearer 2.0 version of them.

When systems need to use newer functionality, port them to the new components.

I've had a mixed experience with this, but at some point you get the API right, and then it works.

</comment></comment></comment></comment><comment><USER12> The Go community has always embraced this. On the Go Proverbs page[1], it's expressed as "A little copying is better than a little dependency" — true, it's not precisely the same idea, but close.

[1] [https://go-proverbs.github.io/](https://go-proverbs.github.io/)

<comment><USER13> Hmmm...I feel like these ideas can be refactored into one idea. BRB

</comment></comment><comment><USER14> I experienced a crystal clear example of this about 15 years ago. I developed a prototype of perl script that read data from one folder, filtered and enhanced it, and wrote it out to another folder, where it was picked up by another process. The script was configured by another perl file that contained the paths to read and write from. The initial (pre-production) deployment had the two folders adjacent, so the config script looked something like

        $input_folder = "/some/annoyingly/long/path/my-cool-project/input/"
        $output_folder = "/some/annoyingly/long/path/my-cool-project/output/"

At some point the script was handed off to some other dev who looked at those paths and apparently thought "that's not DRY!", and changed the code so that the config file just had

        $project_folder = "/some/annoyingly/long/path/my-cool-project/"

and actually append the "input" and "output" in code when needed (fairly elegantly leveraging some existing keys that already defined those two strings).

The problem was that when I developed the script the actual consumer hadn't been finalized, so that output folder path was just a placeholder. When it comes time to deploy we get the actual path which is now some NFS thing like

        /mnt/other-services-host/other-service/input/

At this point I naively go to the config to update my $output_folder variable and discover the code changes made by the other dev, which have made it impossible to separate the two folders, and because of the "elegant reuse of existing keys" made it a huge pain to even change the code back, since the assumption that the last segment of the path had to match the intended use was deeply baked in. At this point I think I just started swearing for a week.

<comment><USER15> Too much abstraction?... Or not enough abstraction?

      $project_folder = "/whatever";
      $input_folder = $project_folder . "/input";
      $output_folder = $project_folder . "/output";

<comment><USER16> This does not solve the problem. The input and output folders had different roots in the production app.

<comment><USER17> However, that abstraction is very localized and thus easy to remove (once the new understanding has been gained), so I'd say it is better.

</comment></comment></comment></comment><comment><USER18> Dijkstra also beautifully sums up this concept in his 1972 ACM Turing Lecture [1]:

> The purpose of abstraction is not to be vague, but to create a new semantic > level in which one can be absolutely precise

[1] [https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...](https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html)

</comment><comment><USER19> Just copy-paste code and add a comment pointing to the source (starting with TODO helps you find those later).

It will become obvious which duplicated code to abstract when you find yourself changing all/many at the same time or fearing you'll forget/break something if you don't change all instances. Writing tests is also a good motivator as it means even more code per duplication (and reduces the fear of breaking something).

It really takes a lot of duplication for this to get out of hand. Wait til it happens, you're a software engineer you'll figure out how to get rid of duplicated code just fine. Coming up with a great abstraction is extremely difficult before seeing at least a few examples.

</comment><comment><USER20> I recall when ESR tried to school Linus Torvalds about the "curse of the gifted student" and that Linux would collapse under the complexity of device driver code duplication. Linus didn't care because he was more concerned about introducing code dependencies that would block developers and make them less productive than some duplicated code in drivers maintained by different people.

      Date:	Tue, 22 Aug 2000 16:00:52 -0400
      From:	"Eric S. Raymond" <email@example.com>
      To:	Linus Torvalds <firstname.lastname@example.com>

      Linus Torvalds <firstname.lastname@example.com>:
      >
      > On Tue, 22 Aug 2000, Eric S. Raymond wrote:
      > >
      > > Linus Torvalds <email@example.com>:
      > > > But the "common code helps" thing is WRONG. Face it. It can hurt. A lot.
      > > > And people shouldn't think it is the God of CS.
      > >
      > > I think you're mistaken about this.
      >
      > I'll give you a rule of thumb, and I can back it up with historical fact.
      > You can back up yours with nada.

      Yes, if twenty-seven years of engineering experience with complex
      software in over fourteen languages and across a dozen operating
      systems at every level from kernel out to applications is nada :-).
      Now you listen to grandpa for a few minutes.  He may be an old fart,
      but he was programming when you were in diapers and he's learned a few
      tricks...

More here:

[http://lwn.net/2000/0824/a/esr-sharing.php3](http://lwn.net/2000/0824/a/esr- sharing.php3)

[https://news.ycombinator.com/item?id=11077799](https://news.ycombinator.com/item?id=11077799) (2016 discussion)

</comment><comment><USER21> I still regularly fall for this trap. My instinct to "DRY" is so ingrained into me that I always find myself deduping similar looking blocks of code. I think this culture is a knee jerk reaction to dealing with code bases on the opposite end of the spectrum where entire classes are "copy and pasted" with only a single change. I've had the misfortune of dealing with these kinds of projects.

I now try to find the middle ground by remembering to "do the simple thing" even if it appears less elegant. This makes it easier to refactor in the future (if required) at which point more information will be available to design a more appropriate abstraction than would have been possible before.

<comment><USER22> However, let's not go too far: I think DRY is a good default for new programmers. They can learn to break that rule as they gain experience.

</comment></comment><comment><USER23> Removing duplication != abstraction.

Many copy & paste scenarios can be avoided without creating any meaningful abstraction. Generally this is best done with a stateless (pure) function that has few if any conditionals and does not involve design patterns such as inheritance, overriding, or even creating new compositions. It should feel easy and boring when you are doing this.

Abstraction is a new representation that calls for deep thought and I agree is easy to mess up.

The need for DRY also depends on type-safety. Type-safe boilerplate generally adds verbosity, but few bugs. This article is coming from the Ruby world where a bug lurks behind every untested line of code: this can create a lot of pressure to make boilerplate free code which can end up turning into abstractions. But every code change (without code coverage) in dynamic languages is also an enormous risk. In type-safe languages the compiler can help ensure that the process of removing duplication is correct.

<comment><USER24> I agree. I suspect the author is coming from a purely-oop background, where making a subclass/trait is a very costly and clumsy way to reuse logic.

In a functional paradigm, even the most trivial of abstraction pays off handsomely. This is exactly what "map" is for example.

<comment><USER25> Trivial doesn't mean it wasn't well thought out. On the contrary the more trivial the abstraction the more likely its more general, since it has less constraints.

</comment></comment></comment><comment><USER26> > When dealing with the wrong abstraction, the fastest way forward is back. > ... Re-introduce duplication by inlining the abstracted code back into every > caller.

This can be tricky if the person who wrote the abstraction takes it the wrong way. At my previous company, I've been yelled at for doing this. Some developers get emotional about their code, in which case undoing their abstraction causes offense. How do you get around this?

<comment><USER27> I find that the best approach is to talk to them first, explain your use case, ask them how to solve the problem.

Most of the time you will either be welcomed for your proper obsequence, or find out that there's a jealous guardian of that code and no matter what you do it won't alleviate that tension anyway.

<comment><USER22> Yep, always talk to the person who made a WTF-inducing change. It's even possible they've thought of something you didn't.

</comment></comment></comment><comment><USER28> What I go to war against lately is abstractions that are only there to save people some typing. I strongly believe abstractions are there to abstract -complexity-, not to save you some typing (if the bottleneck doing your job is your typing speed, ask your boss to give you harder problems, hehe).

Being able to evolve 2 pieces of code separately is powerful, and realistically is a more common case than wanting a change to pop up in 2 different places.

</comment><comment><USER29> There's another angle to this which I think is quite important. 4 years back, I joined a team where the tech lead would always warn developers about the abstraction problem described here.

Very regularly I'd hear "Code duplication is fine, do not use an abstraction here". What he meant was "In this case the abstraction might be incorrect. Use abstractions only when they actually relate to business logic, not just because two pieces of code happen to look the same". Unfortunately, while that was very obvious to him, to new developers to the team (like me) it sounded like "Do NOT use abstractions, they are evil". Over the years I developed a habit of never thinking about abstractions because they are evil. I duplicated code that should have been abstracted and today we pay the maintenance cost for that.

tl;dr: Experienced folks, be careful when you caution your peers against abstractions. Be very explicit and assertive that they _CAN_ be used correctly and one shouldn't avoid them.

<comment><USER30> This is good advice. I've come to the conclusion that, when suggesting almost anything to do with Development, I really need to be at pains to prevent it being received that the answer is _always_ either Black or White at _all_ times.

It's hard to get across that the answer is usually one of the Greys and, even then, the shade will probably vary a little from time to time.

Rules are the children of Principles, they're important handrails as you're learning but to progress from there you have to understand the Principles behind them and how they confirm or contradict eachother.

</comment></comment><comment><USER31> When in doubt, I use this rule of thumb:

\- It is ok to have the code duplicate twice. Add a comment to track the conscious decision.

\- But when I find myself to do it the 3rd time, it is time to think if I can factor it out.

Three use cases tell me more than two about how things can be abstracted and if it makes sense.

<comment><USER32> But the whole point of this discussion is that you should probably duplicate as many times as needed if it helps to avoid wrong abstraction.

<comment><USER22> No. The point of the article is that it's ok to undo an abstraction that has done more harm than good. Abstraction and DRY is still a good default mode of thinking.

</comment></comment></comment><comment><USER33> The question is whether updates can be made against both copies of the duplicate, requiring synchronization. It's the difference between a replicated slave copy of a database and a real distributed one. The first is easy. The second is very hard.

<comment><USER34> I'd argue if you find yourself needing to do this, it actually might be a hint that abstracting is appropriate, as it's proof there is more than superficial commonality _. Like so many things, I don 't think there's a way to make any hard and fast rules, and figuring this out is more art/experience/taste than science.

_ Not including cross-cutting concerns that modify all usages (eg, changing your logging or dependency injection library).

</comment></comment><comment><USER35> The "wrong" (less than optimal) abstraction might be better as long as it's rigorously documented, which is rare, of course. In the right hands, it can be an important stepping stone to a better abstraction. I'm dreaming already.

Duplication has it's own set of dangers leading down the road to a verbose mess of convoluted crap code in most cases.

Most established code bases make me want to puke before long.

<comment><USER36> The older I get the more I appreciate XP. The Rule of Three in particular becomes a bigger presence in my life as time goes on.

With two copies of the code you can't be sure if the similarities are factual or coincidental. At three the situation begins to crystallize quite rapidly.

<comment><USER37> Couldn't agree more!

[https://en.m.wikipedia.org/wiki/Rule_of_three_(computer_prog...](https://en.m.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

</comment></comment></comment><comment><USER38> After all the hemming and hawing about this, I'd really like to see a real case study on it. It's never been an issue for me. I've had functions where I added parameters later on for new use cases to fit the function to them, yes, but I never felt like I was suffering for it. Maybe DRY isn't so bad after all.

</comment><comment><USER39> I agree with this so much. The way I've put it before is, the difference between under-engineering and over-engineering is that you can fix under- engineering.

<comment><USER40> Personally I don't think that's entirely true. Both under- and over- engineering can be hard to fix.

What definitely does make things easier is simply having less code to fix. Although measuring the 'amount' of code is at least somewhat subjective.

<comment><USER41> Yes! I think what I've come to is: Spend more time thinking about how to do something more concisely, rather than spending time thinking of how to abstract the code. Sometimes the former leads to the latter. But less code--or rather more concise code (not to be misrepresented as "fewer characters" or "everything in one line"!)--is almost always better for maintaining the code into the future.

</comment></comment></comment><comment><USER42> I prefer disposable code over reusable code [0], i.e. code that's easy to delete instead of easy to extend [1].

The nature of software development is change. Extensive use of abstractions can make your code base rigid and averse to change.

[0] [https://bjoernkw.com/2016/11/06/writing-disposable-code- not-...](https://bjoernkw.com/2016/11/06/writing-disposable-code-not-reusable- code/)

[1] [https://programmingisterrible.com/post/139222674273/write- co...](https://programmingisterrible.com/post/139222674273/write-code-that-is- easy-to-delete-not-easy-to)

<comment><USER43> I love that post from @tef_ebooks. Actually I come to HN/Reddit every day to find another posts like that one, but only happens once or twice a year..

</comment></comment><comment><USER44> Eric Evans maybe said it the best that code should be rewritten again and again as new insights come from the domain to get closer and closer to the real thing. Every time we write the code we gain new insight so the original should be essentially written closer to the real things with these new insights. I've been taking this approach coupled with ddd where the aggregate root's pure domain logic is relatively easy to actually discard and recreate.

I can't find the snippet but it's somewhere in the "DDD is not for perfectionists" vein

</comment><comment><USER45> While unexpected features can definitely complicate something that was merged into an abstraction, bug "fixes" also matter and they can be worse:

\- Programmers may look at a bug in a simple shared function and conclude that it "obviously" should be fixed, and do so quickly without really understanding what else could go wrong. (As a completely contrived example: You "fix" something that previously couldn't return a negative value, and move on; turns out this "fix" allows a bug somewhere else to crop up, a catastrophic improper cast from signed to unsigned, blowing up your -1 into an iteration over billions of expensive operations.)

\- Bug priority levels vary between features, even if code is shared. Your abstraction may make it effectively impossible to fix just _one_ high-priority feature, if your deployment is (say) set up to run hours or days of regression tests on all affected parts. Generally, the more segregated things _actually_ are, the easier it is to set priorities well.

Just because something is duplicated doesn't mean that it's that way forever, either. At a good branch point, such as a new project, you can _aggressively_ prune out things that won't apply to that branch even if they helped keep things stable on the previous project.

<comment><USER36> My own read in this situation is that this problem is almost always less of an issue in code that is very explicit about what it's doing. A function that uses nouns and verbs with a very precise meanings survives these changes better than wishywashy code.

"Generic" functions make it difficult to find all uses or even understand what scenarios they belong to. With bland say-nothing nouns and meaningless verbs like execute() or process() that appear everywhere in the code, you're just crossing your fingers and hoping for the best.

</comment></comment><comment><USER46> I've done exactly this where I'm just extending my code in an ugly way. Two alternative patterns to extending a function with a parameter switch are to pass in a function to the function or split the function into multiple functions around the bit thats different.

Definitely a lot harder to fix when you've done this though.

I think "the wrong abstraction" is too lofty a title this is just about oversize functions.

</comment><comment><USER47> The "wrong" abstraction is still a nexus of control and understanding - <USER2> point you know the code will return to under certain circumstances

this is not to say that if you rollback the code and _then commit_ tonfinding and implementing new abstractions you won't win - but the second part is necessary or you are just digging a deeper hole.

think of it as a wrapped transduction - younhave to do the second part as well.

NSTAAFL

</comment><comment><USER48> I think this sometimes gets used as an excuse for people who don't want to deal with another layer of indirection added by an abstraction. The gist of this touchstone blog post is that we need to be willing to abandon our abstractions as soon as we start special casing them. It's not wrong to abstract, it's wrong to cling to an abstraction that is broken.

</comment><comment><USER49> I can't agree with this beyond the high-level sentiment. Perhaps the example is just not good. In the listed example the error clearly lies with programmer B who decided to extend an abstraction with a branch. That's not extending an abstraction - that's squashing 2 different abstractions into one function!

<comment><USER50> Which is the point of the article!

<comment><USER49> but the article argues against creating the abstraction when the functionality was the same in both places, which I disagree with. To be honest, the whole topic disregards whether the two pieces of functionality are actually doing the same thing in a domain-logic sense or simply a code sense, which is the heart of the issue. If the similarity is coincidental (e.g. validation on two model types temporarily happens to be the same) then the abstraction should not occur. If it is not (e.g. two distinct operations on a model type happen to have an identical subroutine) then the abstraction should occur.

<comment><USER51> It is easier to introduce the right abstraction later. The article argues that if there will be no specific abstraction, programmer B would create the right abstraction without hacking on top of existing. This becomes more oblivious when the application is in maintenance and everyone is risk averse.

</comment></comment></comment></comment><comment><USER52> I really like Sandi Metz as a speaker, and am pretty sure she has thought about these problems much deeper than I have. However, I often find myself wondering if most of the problems she is trying to solve would go away if programmers spent more time thinking about their code.

The case filled code that she is describing seems to be a result of the programmers not fully grasping the purpose of the code, and being unable to tell if the current abstraction is fitting. I understand that deadlines and the sunk cost fallacy play a factor, but, at least for me, finding the right abstractions / architecture is most satisfying part of coding! Shouldn't that be what these programmers are focusing on in the first place?

</comment><comment><USER53> I think people tend to focus on specific symptoms of bad code (duplication, in this case) without thinking about what makes good code.

Ideally, we'd like our code to be:

\- Mutable (i.e. easy to modify

\- Understandable

\- Good at doing what it's supposed to do.

\- Other stuff that I'm forgetting.

The general recommendation against duplicate code is intended to promote mutability (by avoiding multiple implementations that need to be changed). If you apply it blindly without keeping mutability in mind, you can get situations like the one the authors describes.

I see some of the same myopia when people talk about testing. Testing is there to ensure that your code is correct, and that it's easy to make changes without affecting correctness. As soon as you find yourself writing tests that aren't for those two reasons, consider whether it's worth the effort.

</comment><comment><USER54> What if the programming language could choose the right level of abstraction for you automatically? For instance a language like Rust forces you to structure your code so as to avoid race conditions etc., it's extra effort but once you've done it it should work. What if a language forced you to make the right abstractions or else it won't compile? We have self-balancing trees, couldn't we have a self-balancing programming language? I keep thinking about some way of programming which is more visual, perhaps involving graphs, where the problems of over/under abstraction would be more obvious and the graph could somehow balance/normalize itself somehow.

Just off to prototype this now, should have it done by the end of the day... :)

<comment><USER55> You would need a working AGI (Artificial General Intelligence) for that to work.

And at that point, you don't really need to worry about compilers, you just have AGI looking at the code.

What you are proposing requires a technological miracle to implement. That's why it doesn't make sense. When we can do miracles, we will obviously use them in the mentioned and in many other areas. The problem is to create AGI.

</comment></comment><comment><USER56> I don't get this post and I don't get all the comments in support of copy pasting code, and against DRY. I am going to need a real life example of when copy pasting is a good idea, because I've never seen it. Giving some 'shared code' a name really doesn't seem like it's a dangerous path.

 _Programmer B feels honor-bound to retain the existing abstraction, but since isn 't exactly the same for every case, they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter._

Programmer B's poor decision doesn't mean you should reach for ctrl-v, in my humble opinion. But I'm willing to change my mind, if there's a compelling case.

</comment><comment><USER57> I had this in mind recently when doing the Cryptopals challenge, which requires you to implement the Counter mode of block encryption[1]. In that case, encryption is the same mathematical operation as decryption. I still figured I should have two different functions for encryption vs decryption to make it more obvious which variables are intended to hold a plaintext vs ciphertext.

[1] [https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_\(CTR\))

<comment><USER58> Depends on language, but if the type system supports encrypted and plaintext types/traits, this is the way to go.

<comment><USER57> Good point, I didn't think of that! That would be a better way to do it! (At least in some respects.)

</comment></comment></comment><comment><USER59> Good idea in general. Not sure I agree with the idea of inlining a bunch of code in order to refactor an abstraction.

I've always found the easiest way to refactor is to get really good code coverage on the outermost layer of code that uses the abstraction, remove/ignore unit tests if there are any on the abstraction itself, then refactor the abstraction with vigor until it feels appropriate and hopefully elegant or is removed if necessary. As long as all your tests still pass, you should be good to go.

</comment><comment><USER60> I usually end up with quite a bit of duplication before I even think about creating any type of abstractions.

There's no point trying to think about abstractions before you know what the problem is.

<comment><USER61> There's also a solid YAGNI argument against abstraction, especially when circumstances or requirements can change.

You don't yet know what abstraction you need or what extensibility or generalizability you need, and prematurely extending in these directions can either paint you into a corner where you have to do terrible things to avoid throwing things away and rework, or else you have to bite the bullet and do a bunch of rework.

There can be a lot of benefits to just duplicating things like config, occasional pieces of function bodies, classes with modified functionality, or even using whole projects as templates, like quickly getting a collection of inter-related web servics going with copy/paste code and factoring out common code later.

</comment></comment><comment><USER62> Watched the talk a few years ago. Several times. It really hit home. Before, I would try to introduce abstractions as soon as I had one instance of duplication. After, my code has more duplications, less nesting, less abstractions. It's easier for a newbie to understand (or myself down the line), it's easier to delete and modify. I've shared the mantra "duplication is better than the wrong abstraction" with colleagues on many occasions.

</comment><comment><USER63> Imagine in 6 months you have survived a traumatic brain injury and you're required to maintain the awful crap that younger/smarter you thought, at the time, was clever.

Abstraction is bad and is the price you pay for being able to move lots of things around at once. WET (Write Everything Twice) > DRY (Don't Repeat Yourself) because you might be able to grok what the heck you meant at the time. It kills me that my colleague wants to be clever. NO! Clever is bad!

</comment><comment><USER64> His just circles the problem i think. It is a symptom of programmers not taking responsibillity for their own code. To cover your ass in the best possible way you have to write as little code as possible and that is what happens when a person sees a function that sor of doeas what they want. For some reason we think this is deduplicating code and it is good. But at least I have never been taught this in scool or by anyone in my work. We should treat it for what it is: an antipattern used by programmers to avoid taking responisbility. Another side to this coin is some times the «enablers» who create unneccesary abstractions. These are people who play at being livrary designers when they sre supposed to be developing applications as fast and safely as possible. The people who creates complex tools and unneccessary integrations inside the application code they write. Now, we are all risk averse and enablers to different degrees and at different times. To counteract these antipatterns i think it is important that we teach a few things: that functions/method should have a single purpose, if ou have a boolean argument and a if you should refactor. Rabbit theory of code. And at a higher level: always keep the focus on the business requirement and do codt brnefit analysis (light wieght in our head). And take time to learn the domain and tools you are working with. This also requires experience. But if we focus more on teaching people to learn sbout these things i think it may improve things

</comment><comment><USER65> In a similar vein, see "Premature Flexibilization is the Root of Whatever Evil is Left":

[https://product.hubspot.com/blog/bid/7271/premature- flexibil...](https://product.hubspot.com/blog/bid/7271/premature- flexibilization-is-the-root-of-whatever-evil-is-left)

</comment><comment><USER66> Shameless plug: Building White-Box Abstractions by Program Refinement ([https://mehrdad.afshari.me/publications/building-white- box-a...](https://mehrdad.afshari.me/publications/building-white-box- abstractions-by-program-refinement.pdf))

</comment><comment><USER50> I'm currently working with a driver developer. He doesn't have access to simple connections. (Everything is a linked list.)

Every single lookup was a copy & paste while loop with business logic inside the loop, and then a break statement.

This is a textbook example of when not to copy and paste.

</comment><comment><USER67> I use the "dueling sins" model of "copying versus coupling." Early lifecycle code benefits from the flexibility of copying. Mature code benefits from the coupling forces of abstraction. Both have the capacity to do harm.

<comment><USER36> Do you follow Jim Highsmith at all? His philosophy is that there are no answers. That we are minmaxing a bunch of competing criteria and trying to do the best we can.

In his words: we are a solving problems, we are resolving paradoxes.

<comment><USER36> Too late to fix typo: we are _not_ solving problems, we are resolving paradoxes

</comment></comment></comment><comment><USER68> Personally, I'd still err on the side of creating or thinking about an abstraction rather than duplicating code. While creating the wrong abstraction is a problem, it should be a deliberate choice, and duplication should be picked only in the rarest of cases, or where the logic is trivial. If a future requirement renders the current abstraction wrong, it should be refactored to fix the abstraction. If folks are adding edge cases to the current abstraction instead, that is a culture issue that must be fixed. And you should always have good test coverage anyway. This article makes an assumption that future developers are lazy or incompetent and will not fix the abstraction, and I think that we should strive for a culture where such laziness is not tolerated, instead of living with duplicate logic everywhere.

</comment><comment><USER69> This is analogous to confirmation bias. Existing code is the current narrative. New requirements are like new evidence. With each piece of new evidence, you must reconsider the narrative to fit all the evidence.

</comment><comment><USER70> When you find yourself at his step 8 you don't necessarily have to go back and fix all the sins of the past. There's a cost to this which may or may not make sense to pay. You could simply not use the bad abstraction.

<comment><USER71> It should also be pointed out that when you find yourself at steps 6 and 7 you don't have to sin, and when you find yourself at step 1, you can obey more complicated heuristics than DRY, like "I will apply the rule of three if the duplicated code is pretty short and not inherently self-contained" or "if this big method looks like it will change, instead of fully abstracting it, I'll just break out the bits that look like neat little functions".

You only find yourself at step 8 after a suite of bad decisions, and possibly even bad decisions that you signed off on during code review.

</comment></comment><comment><USER72> Premature abstraction. Especially endemic to large enterprise projects.

</comment><comment><USER50> One of the easiest ways to fix this is with lambda functions or callbacks. Each caller passes a lambda function or call back that is the specific case that's unique to the caller.

<comment><USER40> In the case they're describing this should almost surely not be a lambda function. Those should be reserved for when an arbitrary function makes sense, but it's unlikely that someone would have abstracted a function that could have done _anything_.

It's much more likely that the code in question is responsible for one particular thing, and switches between several different ways to achieve some sub-goal. Those parts should be lifted into some kind of interface, where the different variations are lifted into different implementations of that interface. A lambda function is the most general interface possible, so it's probably not the best choice, you'd eventually end up with callbacks calling each other without it being entirely clear which callback does what.

<comment><USER73> > A lambda function is the most general interface possible

A typed lambda function (i.e., with a defined arguments + return signature) is exactly as specific as any other typed interface, an arbitrary lambda function isn't, sure, but there's few languages where a static interface and an arbitrary lambda function are both available tools.

</comment></comment></comment><comment><USER74> I am seriously going to start doing this. Great suggestion and the authority and insight with which it was presented gives me a lot of confidence it'll work out. Thanks

</comment><comment><USER75> Nature obviously agrees. Look at the structure of the genome with all its gene duplication with minor variation. Copy-paste-hack is one of the primary mechanisms of evolution.

<comment><USER76> Nature takes billions of years though, as it has to operate in blind watchmaker mode. We don't have that luxury. Not often, anyway.

</comment></comment><comment><USER77> one problem with duplication is that its tempting to copy the code you need and replace the appropriate parameters or values. Its pretty easy to mess that up.

</comment><comment><USER78> Sometimes it's good to let some duplication proliferate before trying to condense it. You don't always know which way it is headed.

</comment><comment><USER79> The real problem is that very few people knows how to tell which abstractions are "wrong".

</comment><comment><USER80> I also like what Rob Pike used to say: "A little copying is better than a little dependency."

</comment><comment><USER81> When optimizing for complexity, this is a reasonable argument. What about optimizing for performance? It might be cheaper to make a network call in one place and have multiple consumers each use the result, even if each of them needs to use the result in slightly different ways.

</comment><comment><USER82> Premature abstraction...

</comment><comment><USER83> About half way through I realized this was true of mythology.

</comment><comment><USER84> TL;DR: don't put switches in functions.

<comment><USER85> No just don't switch on a new kludgy ad hoc argument:

//bad:

int countlines(file afile, bool hasfuckeduplineendings, bool needtobusywaituntilreadswillsucceed)

My preferred solution, and I don't claim that this is correct, is just to put a global variable

bool nexthasfuckeduplineendings = false; //set to true before counting lines in a file that needs preprocessing for fucked up line endings

bool needtobusywaituntilreadswillsucceed = false; // this is a hack. Certain specific files will just fail to read for an unspecified period of time, they will fail and fail and fail and then succeed. For cases that we know this will happen, set this to true.

See how awful and fucked up this is?

It is "obvious" that this hack is just so wrong.

But is it really? It's clear, gets shit done, and is super transparent about how wrong it is.

Should every reader hang in a busy loop?

Should every reader preprocess line endings?

Maybe "no" and "no".

What do you all think?

<comment><USER84> I think you should copy/paste the whole function, change one of the copies to suit your needs, and then factor out any subroutines the functions have in common.

This is what OP recommends too.

<comment><USER85> That works okay for the first bool, but for the second duplication wouldn't there be 4 versions already?

<comment><USER84> You can have 1000 versions. As long as the function is mostly free of side effects, except whatever side effects are documented in a public interface, then you can scale the repository linearly without any real increase in complexity.

This is because while the namespace is wide, in practice you work within a "working set" of your daily use packages.

</comment></comment></comment></comment></comment><comment><USER86> What happens when Rails and Javascript is the wrong abstraction?

<comment><USER87> 404</comment></comment>


The Beer Archaeologist - <AUTHOR> http://www.smithsonianmag.com/history-archaeology/124099064.html

<comment><USER2> Related, there's an episode of 'Brewmasters' that covered DFH brewing this beer. It's worth checking out (although the show's been cancelled).

</comment><comment><USER3> The whole article on one page: [http://www.smithsonianmag.com/history- archaeology/The-Beer-A...](http://www.smithsonianmag.com/history- archaeology/The-Beer-Archaeologist.html?c=y&story=fullstory)

</comment><comment><USER4> I thought this was really cool... I wonder what that beer tastes like.

<comment><USER5> I tasted Dogfish Head's Midas Touch a couple months ago, when the American Brewers Association came to São Paulo for a little road show of sorts.

Now of course, no one can possibly know how it compares to the original brew it attempted to reconstruct. I remember in particular a rather long ramble about how they were pretty sure _but not quite_ that they were doing the right thing using the saffron as conservant.

It's well-worth giving it a try if you're lucky enough to live in the few places in the US where you can easily and reliably get a hold of it.

If you need to do the connoisseur thing, you'll say it resembles a ale, but trully it resembles nothing I have tasted enough to deserve a lable. Call it experimental, or indie, hell, it's Dogfish.

It's got honey and grape notes in it that make it almost taste like a weird crossover between beer and wine. Very fruity, would feel a little bit dry on the tongue if it weren't so perfumed. The saffron itself is amazing and comes as part of a second layer of scents once you take a sip of it.

It's a very drinkable beer (in spite of its hops), but maybe a bit too sweet and perfumed to stick to it for a whole night. It struck me as candidate for a really great companion to a home-made chicken and pequi risotto, mmm.

<comment><USER6> From the way you describe it, it sounds like a "barley wine"[1] (actually a type of very strong beer, despite the name).

[1] <https://secure.wikimedia.org/wikipedia/en/wiki/Barley_wine>

<comment><USER7> It isn't quite a barley wine, at least it doesn't taste like any barley wine I've had before. It has some hints of mead, but the grape is what makes it different. If you live in the SF Bay area, you can definitely find this at either City Beer Store or Healthy Spirits.</comment></comment></comment></comment>