Tim Berners-Lee Published a Document Called HTML Tags (1991) - <AUTHOR> https://www.webdesignmuseum.org/web-design-history/tim-berners-lee-published-a-document-called-html-tags-1991 <comment><AUTHOR> Some interesting old tags:

<ISINDEX> "This tag informs the reader that the document is an index document."

<LISTING> "These styles allow text of fixed-width characters to be embedded absolutely as is into the document."

<HP1> "Highlighting. The highlighted phrase tags may occur in normal text, and may be nested."</comment>


On Software Design Patterns - alex-nexus http://en.yinwang.org/blog-en/2012/04/24/design-patterns/

<comment><AUTHOR> While we can be overly proud of ourself and claim to work on masterpieces when we are creating software, it is simply wrong parallel. Software engineering called engineering because it is more engineering than art. If you look at modern architecture, where design patters actually came from into software, you will notice that even masterpieces in architecture nowadays made use of design patters.</comment>


Intel's Toxic Culture - <AUTHOR> https://mondaynote.com/intels-toxic-culture-1b79905adf45 <comment><USER2> I hope Intel strongly executes and puts the current doubts of people firmly behind them. Think the next pick of CEO is going to be crucial - they need someone focussed on execution and someone who stays the course with respect to the long and painful changes Intel will need to make. They have several problems they need to address at once

a. Fix the 10nm process

b. Deal with a new world where a small number of cloud providers are buying a bulk of their CPUs vs the past where they were selling substantial CPUs to businesses. I would imagine that intels pricing power will come into serious attack once the Cloud providers can land a legitimate alternative as a negotiating tactic.

c. Rise of managed environments (Browsers / Languages) where developers are increasingly coding against sandboxes rather than against native code. This means any innovation that Intel does (like AVX512) now has a much longer life cycle before end users can see the benefit since these innovations need to trickle down into features in the managed environments.

d. ARM / AMD will be putting pressure on the low margin part of the business.

e. The new killer workloads are in AI and GPUs / Accelerators seem to be winning on those workloads for now.</comment>


I have found a potential team, but... - <AUTHOR>

So here I am again asking for your knowledge and expertise.
I am currently taking an entrepreneurship class, and in this class we were all required to write up a two page pitch of a product or service idea. We were then given a certain amount of virtual points that we could use to invest in the projects we found interesting and profitable, and the top 2 would have to pick teams for a mock startup. My project came in first, and after responding to some grilling questions from the professor today, I was approached by 3 other students. These students expressed great interest in being part of my team, which is great, but I soon realized that they wanted to create a real team to pursue the development of my idea. I was flattered and excited, and we have exchanged emails to talk about it even further, but after giving it some thought, I grew a bit apprehensive.
I'm not sure if these folks are rockstar hackers, or have the strength to endure a startup. I don't want to jump into this on a high of excitement with people that perhaps might not be fit for it. So, I ask you, how do I go about deciphering whether these guys are persons who are smart, talented, and have a strong personality to undertake such a task? I want to go about this the smart and right way, because I know emotions can fog up the intellect and really mess up your decisions.
Thanks. <comment><USER2> Find a small project (1-2 wks of work) you can work on together and make it clear that it is a trial process to see how you will all work together; something other than your startup (for possible legal reasons in the future). If any of them are unwilling to do this, that should be your first signal that that person isn't right for you.

Also since they came up to you after the presentation of the idea I would definitely make sure they know that whatever you are doing isn't the "one true idea" as it stands now, since it is likely to change significantly as you continue to work on it.

The "just go for it" is advice lite and I wouldn't take it, at least not for choosing your team, which is likely far more important than your idea.

</comment><comment><USER3> Eat with them every day for a week. You will find out a lot about each other.

> ...because I know emotions can fog up the intellect and really mess up your > decisions.

Is there a particular emotion that's giving you trouble? I wouldn't distrust all of them...

</comment><comment><USER4> I think you are over thinking this.

Sit back, don't put in a bunch of cash. Don't let anyone go in over $1,000(two semesters of books), and you should just ride it out.

In all likelihood you will not succeed, but do not take that as a reason not to give it a try. I learned so much from my college projects that sounded very similar to your situation.

And last of all remember that if you were able to come up with one good idea, there will be more, you are young and have decades of life in front of you.

Get out there and run full speed with this team, do the best you can to make a go of it, and you might find your self succeeding. But, if things do not go as planned, chalk it up to just another life lesson, and try again some time.

</comment><comment><USER5> Entrepreneurship is an adventure! You're young yet, give it a shot, and you'll learn a lot. You're team may not be superstars, but if they have the drive to see the project through, and can bring your idea to fruition, it's worth pursuing.

If you feel your idea is a truly radical innovation, and you're willing to give your heart and soul for it, then it might be worth seeking out an ideal team. However, given what you've said, it sounds like you've made this decision on a whim. I'd say, go for it if it feels right.

</comment><comment><USER6> The founding team, like any business partnership is like a marriage. Both are social-economic institutions. Both need chemistry to succeed. Both are really messy and messy when it comes time for the breakup. The child custody fight and the division of the assets may not always be equitable.

Or, the team might do well together, the startup fail, and everyone parts as friends.

There's lots of good suggestions here, and Paul Graham has written a number of insightful essays on the YC library and on his site.

The misgivings might be a simply one of, "Well, if my project is so great ... shouldn't I be more picky about who I want to work with?" It might be some instinct tipping you off. Whatever the case, you'll have to look at both the strategic advantage for you and all the human motivations involved (including your's).

Sorry I couldn't be more specific.

</comment><comment><USER7> Has there ever been a successful business that came about by a guy thinking up a most excellent idea in entrepreneurship class (???) then carefully selecting the proper co-founders and continuing to make ideal decisions until success?

In most stories I've heard or read about successful businesses, the pattern was more like, a bunch of freaks got together, massively screwed up half the time, made a few lucky moves, and kept persevering until eventual success.

I guess what I'm trying to say... is... this seems like the wrong attitude:

"I don't want to jump into this on a high of excitement with people that perhaps might not be fit for it."

If the people aren't a good fit, just dump them and move on. Look at Zuckerburg with Facebook. He worked on Facebook-like ideas three times with various groups of uncommitted people until he finally got it right.

</comment><comment><USER8> First ask yourself how do you know that you have the strength to endure a startup, then ask your potential co-founders some questions (maybe the same questions that appeared in the YC application form).

Other fact that you may consider is that you know them since a couple of days ago.

</comment><comment><USER4> On another note, you need to find any EXPERIENCED entrepreneur you can to start building your network. I have learned so much from my network that I think I would have just kept failing with out them.

Every entrepreneur I have meet is available for lunch or dinner once or twice.

You're business school might know some local entrepreneur's and might be willing to make an introduction. There are also local professional groups that should have networking events for you to meet other local entrepreneurs.

And, finally just have fun, entrepreneurs can be found just about anywhere, the race track, your local movie festival, Great America, and even you're local bartender.

</comment><comment><USER9> You've set out the requirements you want in your cofounders \- smart \- talented \- a strong personality (perhaps you mean fortitude)

Ask them to tell you stories about themselves that exemplify these traits.

<comment><USER10> Asking and listening (imo) will not give you accurate reflections of their true traits. Test them like any other investor would test you for fund- worthiness.

Find out what else they've done to demonstrate they are entrepreneur material. Do a short trial project or two. Pay close attention to how they react to different circumstances during the projects. Challenge their ideas and see how they respond. Ask yourself if you could really work well with them, and if they really improve the odds of success enough to merit becoming a significant shareholder.

</comment></comment><comment><USER11> Here's the question: is the idea so good, that you'll never have another idea that good? Is this billions and billions of dollars material?

If it is, tell them you want to do another project with them for the class and see how you work together -- if all goes well, then you can work on the first, more exciting project.

If it isn't -- it's just a good idea -- then hang out with them for a bit, work with them on a small project, and go for it for the class. If it breaks up, it was a good experience.

</comment><comment><USER12> i would go for it. if it doesn't work out, then still, it will be a good experience. risks, i think is a part of entrepreneurship

</comment><comment><USER13> I'm in a similar situation in that after going it alone for a while I'm now looking for cofounders.

Since I haven't succeeded (yet), I don't have a lot of good advice, save this: it's okay to fail, just don't fail the same way twice. From what I've been reading, most startups simply crawl away and die anyway. So the only risk you're looking at is 1) your startup is successful, and 2) the cofounder doesn't work out. Seems like that is a bit of a long-shot.

I'm not saying the selection doesn't matter -- I think it's the critical factor. What I am saying is that you should learn what makes a good cofounder for you, and that's something you might have to iterate on a bit. Don't sit in indecision wondering what the perfect choice is.

That's my plan, for what it's worth.

</comment><comment><USER14> Just do it. You'll know what you've got, one way of the other, soon enough. Where will you be if you don't do it?

</comment><comment><USER15> find something you _disagree_ with some of them about, and then resolve your disagreement.</comment>


A smart home for stray cats provides food, toys during Beijing's harsh winters - <AUTHOR> https://twitter.com/tictoc/status/1100236566058938369 <comment><USER2> Such a nice thought.! Good one.!</comment>


Spritemapper: CSS sprite map generator using simulated annealing - <AUTHOR> http://yostudios.github.com/Spritemapper/

<comment><USER2> It should be noted that CSS sprites are in general not a new idea. It is a common practice used by most front end developers for the last 4-5 years or so.

However, they are often hand crafted, but there have been in existence many tools that try to do the same thing as "spritemapper" (google results, there may be better ones out there):

\- <http://spritegen.website-performance.org/>

\- <http://csssprites.com/>

\- <http://css-sprit.es/>

\- <http://csssprites.org/>

But most of them are shitty web interface tools and not very well suited for a scriptable developer environment.

This is why I like this implementation. It seems nice, I'll probably try it on my next project.

<comment><USER3> Another "shitty web interface tool" for sprites:

<http://spriteme.org/>

Runs as a bookmarklet.

<comment><USER2> This one I have actually used and is not so "shitty" - but still the same problem of deployment, but thanks for reminding me :)

</comment></comment></comment><comment><USER4> The resulting CSS is really inefficient.

1\. It should only write the URL of the background image once, and only background-position on the rest.

2\. The most widely used width/height should be specified as the default and width/height properties only included when it differs.

Also, to avoid the need of any padding between the images you can emulate background-crop with pseudo elements (<http://nicolasgallagher.com/css- background-image-hacks/>).

</comment><comment><USER5> For those of you using Sass: The latest version of Compass got built-in support for sprite generation.

<http://compass-style.org/help/tutorials/spriting/>

<comment><USER6> I really love Compass. I'm a django/python guy and it still fits in nicely to my dev flow. You still have to know css to use it, but it removes a lot of the pain of actually writing css.

</comment></comment><comment><USER7> Hey my co-worker just built a similar tool for creating sprites: <https://github.com/jakesgordon/sprite-factory>

It doesn't use simulated annealing, which is pretty neat, but it does generate really well packed pngs:

        sf --layout packed --pngcrush awesome/

Leads to 87x80 at 6,873 bytes vs 103x92 at 7,237 bytes on the awesome image font demo. It will also output either sass or css.

</comment><comment><USER8> Looks good! Unfortunately the page doesn't go into much detail - does anyone know if it can handle repeating, or images that have to be at a particular edge of the sprite?

<comment><AUTHOR> You can't really have a repeating background that is a section of a sprite image in CSS, afaik, so no. That's a limitation of CSS in general, not just this tool.

<comment><USER9> actually, you can. well, at lest for 1 dimensional repetition. but the sprite image dimension will be limited to either vertically or horizontally. i use this one: <http://csssprites.org/> \--> "Spriting" x- and y-repeated images: SmartSprites supports turning background images repeated along x and y axes into sprites.

(on a side note, has anyone compared this with SmartSprites?)

</comment></comment></comment><comment><USER10> I was working on this very same problem a while back. I've never heard of simulated annealing, let alone its application to the 2D bin packing problem.

Here's my implementation of Jim Scott's lightmap packing algorithm (<http://www.blackpawn.com/texts/lightmaps/default.html>): [http://www.joelverhagen.com/blog/2011/03/jim-scotts- packing-...](http://www.joelverhagen.com/blog/2011/03/jim-scotts-packing- algorithm-in-c-and-sfml/) if you're interested.

</comment><comment><USER11> Seems like a nice tool. Thanks to Stylus, I've been able to migrate to base64 encoded images in the stylesheet instead. Just one download for styles, and I don't have to think about it.

</comment><comment><USER12> Nice idea. It seems like a workaround for HTTP's one-request-per-file problem, rendering it useless once HTTP gets "fixed". Will this be useful once something like SPDY gets commonplace?

<comment><USER13> The Google speed team (who I think are behind SPDY) are also looking to build spriting support into their WebP image format. I would presume that a single large image would potentially compress better than multiple small images, particularly if the format is designed for this use case.

Obviously the two improvements aren't necessarily linked, but in the short term they're going to be mostly used together when Google controls both ends of the connection.

</comment></comment><comment><USER14> Animated gifs still cannot be sprited? i.e smilies for ex, cannot be sprited?

<comment><USER15> I don't think that would be a great idea.

</comment></comment><comment><USER16> Fantastic, just what I've been looking for!

</comment><comment><USER17> The webfont example is distracting for me.</comment>


Netbook, tablet and refrigerator magnet in one, running Linux - <AUTHOR> http://www.alwaysinnovating.com/

<comment><USER2> Dupe: <http://news.ycombinator.com/item?id=500365>

</comment><comment><USER3> I know I'm getting one.</comment>


How Tech Can Build - <AUTHOR> https://stratechery.com/2020/how-tech-can-build/ <comment><USER2> This is an interesting commentary on Andreesen's piece, but it doesn't really change or contradict anything.

At the end of the day, the US is a litigious society covered in Byzantine regulation that most people aren't even aware of. This covers the most basic things: would you like to build a townhouse for your family with just one parking space? Illegal in the vast majority of the United States, where 2+ parking spaces per home are required by law. Want to build an apartment building in San Francisco to capitalize on the incredible demand for housing? You'll spend at least 6 years getting a building permit, and what you're actually allowed to build will be mostly the result of ugly haggling with special interest groups along the way. These are just a few examples I happen to be familiar with.

We've chosen for things to be like this by the way we allow our government at every level to be captured by lobbyists, special interests, and partisanship. Realistically, to change things, we need reform that fixes the way the government itself operates, and while there are many ideas that sound good, everything has unexpected side effects. That is a very, very hard problem, to solve.

<comment><USER3> This is so very, very wrong.

[https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood."

What you've written is an all-too typical complaint of people who don't bother to understand the history of our existing legal, political and social structures. It's easy to hand wave and vent about "regulatory capture" (I do it all the time).

But go and dig down and find out why that 2+ parking space rule exists. You will find a massively more complex, and much more pro-public, pro-people, pro- progress agenda in play than anything you just wrote suggests.

I remember an example of this sort of thing that I came across in eastern WA about 20+ years ago. A small town there was facing protests because it was about to put down ("execute") several wild horses that were hanging about the town. The law was very clear about what had to be done, but the public, both in town and elsewhere in the state were aghast. The horses were healthy, beautiful and there seemed to be no good justification for killing the as the law required. People complained about the law being an ass (no pun intended) and said that this was the perfect example of government inflexibility and law making by people with selfish interests.

But all it took was a little history detour to go back and find out why the law(s) in question had come into being. It had indeed been the case that in the not too distant past (by global standards, not necessarily those of the western US), wild horses had indeed been a problem in town, and that the towns people had tried several approaches to dealing with and/or fixing the problems. None of them had been very successful, and some 80 years earlier, the town had reluctantly adopted a law where an unowned horse, if not claimed by anyone within a reasonable period of notice, must be put down.

This wasn't government inflexibility, or stupid law, or selfish interests: it was a community improvising to deal with a tricky situation, and doing so imperfectly. Improving this particular law, and others like it (such as your 2+ parking space case) isn't going to happen by assuming that the existing legal framework exists because of malintent. It's going to happen by carefully understanding the context and motivations and knowledge that led to the current laws, and only then setting out change them, hopefully for the better.

<comment><USER4> The parking space rule exists so black people can't move into cheap apartments that would exist without it.

<comment><USER3> Assuming this to be true (though see my reply about zoning below - I think this is an incomplete answer), then that's great, you have now cleared Chesterton's Fence, and are in a position to propose a replacement.

But notice how utterly different your argument is to the OP, who talked about excessive government regulation, regulatory capture and so on.

(and yes, one can make a case that codification of racism in law statutes is a _kind_ of regulatory capture, but it's really not what most people mean when they use that term)

</comment></comment></comment></comment><comment><USER5> This is just the nature of the world. There are enough defensible reasons to screw your own team so people will do that anyway. The real reason is that once you've hit some degree of prosperity, loss aversion overtakes gain seeking. Today's America is therefore focused on maintenance of its wealth.

You can try anything you like, but it won't work. America cannot build in the real world because it constrains itself out of fear of losing what it has, because it has so much.

All these articles and open letters and appeals are just the same as internal company memos at massive corporations exhorting innovation. But IBM can't innovate, no matter how many innovation labs it funds. It just can't. The fire is dead and that's a property of what it's hit: the upper limit of prosperity. The next innovation won't come from IBM and it will rocket past IBM and then hit its own upper limit.

Perhaps the only recent big companies that have innovated are Apple and Amazon. Maybe there's something to be learned from their relative approaches. But America as it stands won't build, because it can't build. The excuses will be numerous: "law written in blood", "do we want to end up like X who built but built wrong", "America is big", "America is sparse". But the problem is none of that. The problem is that America won, that America is prosperous and glorious, and so it can no longer countenance any risk of loss.

<comment><USER6> "It's tough to get out of bed to do roadwork at 5am when you've been sleeping in silk pajamas" - Marvin Hagler

I think there's definitely something to be said for Elon Musk sinking his entire Paypal fortune into Tesla. Hitting the reset button and starting again from ground zero is one hell of an incentive to succeed.

</comment></comment><comment><USER7> I want to like a lot of this. The UK is full of "crap towns" with poor housing, poor design and environs that are generally anti-human (as well as anti- a lot of other things). I don't particularly agree the problem is "regulatory capture" unless that's simply a shorthand way of saying, "we, as society, have agreed that inertia is our preferred approach". In some cases it may well be regulatory capture; in most I don't believe it is (obvious case in point for housing is green belt: we know it's a nonsense, but it's an absolute political impediment, not a regulatory one. The people do not want to build there).

There shouldn't be problems with people having access to healthcare, or living in housing which is not just healthy but is also pleasant. People should have access to nature as well as all their other conveniences, working should not require long commutes and we shouldn't be generating the absolute tsunamis of waste we currently do just to survive.

There are constructivist answers to all these problems. Andreesen appears to be suggesting it's just a matter of willpower. I don't believe the solution is that simple.

</comment><comment><USER8> _> has tech [...] been the primary source of American innovation because it represented the future? Or has it been the future because it was the only space where innovation was possible, because of things like inertia and regulatory capture in the real world?_

Here's a third option: Due to Baumol's cost disease, if the wages for Java programmers rise, the wages for CNC milling machine programmers are going to go in the same direction - and if manufacturers can't pay, there will be a "skills shortage"

Why would a graduate who can program _and_ design electronics do the latter, if the former pays 3x as much straight out of college?

<comment><USER9> Are you familiar enough with Baumol's to comment on why we don't see this effect in, for example, medicine vs basic biochemistry? Presumably there is a lot of overlap in these cohorts, but most research jobs pay significantly less than research jobs.

Both industries seem to be "more productive" these days as well, with massive gains in biological research techniques over the last 20 years.

I guess it is easy to see something and give it a name, but the wikipedia description didn't leave me with a very solid understanding.

<comment><USER10> > but most research jobs pay significantly less than research jobs.

I think your comment has a typo, but my answer to the question I believe you are asking would be that there are far more people seeking to have medical jobs than there are positions available in licensed medical schools.

There is no shortage of qualified people seeking to do medicine. They just can't do it as there are hard licensing restrictions on who can do it and those restrictions require formal degrees.

Of the people I know in the more poorly paid biochemistry research field, most have tried or are trying to jump over to medicine/medical research. They just can't get admitted to med school or can't get approved in some other way. There is no rise in the price of labour because there are just so many potential and willing workers that medicine is not altering the supply of labour for biochemistry research in a meaningful way.

In the case of the developers, there are no restrictions on who can be one. There are no formal requirements at all. You could be a high school dropout and if you can code well, there is work for you. If you have the skills, you can go be a developer. It is more as though nobody wanted to be in medicine as biochem paid more. In that scenario, there would be very few doctors.

<comment><USER9> Your correction was correct, thanks for still seeking to answer the question.

I think I generally agree with your premise -- there are large gates in place and the licensing is much harder to achieve than a college degree. Though I think this setup breaks down partially (But not completely) when we view that PhD biochemists are still paid far less than doctors even with roughly equivalent time horizons and some level of institutional gating (4-6 years for PhD, maybe a PostDoc).

Either way, this is a fun new frame to play around with. Thanks for your time!

</comment></comment></comment></comment><comment><USER11> >"First, tech should embrace and accelerate distributed work. It makes tech more accessible to more people. It seeds more parts of the country with potential entrepreneurs. It dramatically decreases the cost of living for employees. It creates the conditions for more stable companies that can take on less risky yet still necessary opportunities that may throw off a nice dividend instead of an IPO. And, critically, it gives tech companies a weapon to wield against overbearing regulation, because companies can always pick-up- and-leave."

The next big "tech" revolution is working from home -- and distributed working. It has been around, like the way smartphones were around before the iPhone -- in concept, but never realized in practicality. It is an imperative that tech should accelerate and develop a cohesive set of products that will enable iPhone like working from home.

<comment><USER12> This is so true. Half the VCs you talk to want you to re-locate to the Bay Area.

What does that mean to someone mid-career (you know, the type with enough experience to really do something big and build) - it means:

\- They often have kids.

\- They may have student loans from advanced degrees

\- They have to worry about healthcare for their whole family

\- They may be willing to live on ramen-noodle salaries, but dont want to subject their kids to it.

Unless seed funds and VCs start allowing more reasonable founders salaries, ___or allow non-bay-area founding locations with reasonable cost of living_ __, the numbers often just _dont work out_

At this point in the discussion, I will often have a load of people jumping on me to "get roomates" or "eat pasta" or the "all schools are good" argument. Let me pre-answer those:

1\. OK, so you have a family with children. Do you really want roommates?

2\. Yes theoretically I can eat pasta everyday and save money. But is that really the life I want to give to my family (FYI, I can easily work on wall street and make a half-million salary, so really...)

3\. No, not all schools are good. My high school for example had metal detectors on entrance. A staff member died from a heart attach after a confrontation from a student. No, not all schools are good. Perhaps you want to subject your kids to that, I dont.

So what do you end up with? Rich kids funding other rich kids building juice squeezers, after which they will just join the VC firm and perpetuate the cycle.

And as for the eggheads, present them with a shitty enough "deal" and it makes total sense to either go to a big firm or go work on Wall St. "Thought Leadership" is cheap.

<comment><USER13> I'm surprised that things have gotten to a point where these points have to be considered as salient.

What the fuck.

</comment></comment></comment><comment><USER14> nice constructive counterpoint to [https://a16z.com/2020/04/18/its-time-to- build/](https://a16z.com/2020/04/18/its-time-to-build/)

a key point (IMO) innovation happened online becuase being a new space enabled by novel technology, it wasn't regulated yet. But now it's mainstream, so inovation will decrease.

also, this quote from an intervier questioning Marc Andreessen

> a "primary technology" would need to involve, you know, some fundamental new > insight in code, some proprietary set of algorithms.

tells me that so many people just don't get it. software due to being immaterial just doesn't play by the same rules as other mechanical machines.

I know I cannot explain it properly; but why is open source such a superior way to develop infrastructure software?

finally

> Human progress in this view is solely online.

IMO, we don't need a new cleverer algorithm. I believe that Amazon's success is not some really sophisitcated piece of code, but the way in which they integrated computer technology into the very core of the organization.

<comment><USER15> > I know I cannot explain it properly; but why is open source such a superior > way to develop infrastructure software?

Isn't it just cost? As you say software is immaterial and so the only real cost is in the labor to create it which open source neatly does away with.

<comment><USER16> Well, there's still the operational cost of setting up and running the hardware (again, skilled labor), but at least the software is free.

<comment><USER14> yes, but at least until everything went back into the (mainframe) cloud, the opreational cost of running the software was coverd by the user.

My pc's hardware is mine, and the electricity bill is also mine.

So 'licensing' software is very much a form of rent.

Quite frankly this is an open problem. e.g. the debate about AWS suddenly providing, redis, elastcisearch, etc as a service and making the original developers redundant.

</comment></comment></comment></comment><comment><USER17> I can identify with this essay. And, I've always wondered why people don't want to build, why people are so hell bent on preventing others from building. I mean, what on earth is the problem with letting others build? build more housing, build more transportation? Even when a start up wants to do something as simple as put more buses on the road, it quickly gets shut down by regulation (at least in the bay area)

</comment><comment><USER18> I tend to think the technology industry could benefit from a heavy dose of humility. This isn't just a problem for people at the top - it is pervasive at all levels and professions within the technology industry.

That would go a long ways towards the ends being discussed.

<comment><USER19> I'm surprised this is being downvoted. Again and again we've seen really smart people who made a great photo app try to bring their approach to something that's genuinely hard for reasons that go beyond how to write code or build a SaaS business, and leave a trail of wreckage in their wake.

Healthcare, education, civic life, etc. are all extremely valuable problems, but only if you actually get it right. Humility doesn't mean don't tackle them, it means recognizing that your expertise in one thing doesn't translate to another automatically.

There are counterexamples, and they'll all tell you that the code was the easy part.

</comment></comment><comment><USER20> _Third — and related to both of the above — figure out an investing model that is suited to outcomes that have a higher liklihood of success along with a lower upside._

The tricky part is that the type of build projects Andreesen argues for are more costly, have a higher risk and a lower upside compared to most software startups.

We need substantially more capital allocated to the VC segment before the focus will shift to these projects.

</comment><comment><USER21> I'm amused by these morality screeds from rich tech thought leaders.

"Why don't the talented sacrifice easy money in software by getting into [insert super regulated, low-margin business]?" says profit-maximizing tech capitalists who ignored said businesses for a decade.

I will make the best decisions for me, and you will make the best decisions for you. If you want to charity-fund a business that helps society more than your profit margin, then pay me the same amount of money and eat the loss on your end. I'll keep working at what pays me the most, as will 99% of everyone.

<comment><USER22> For that reason, I prefer Chamath Palihapitiya's 2019 annual letter [1] over pmarca's essay. It's not merely descriptive of societal problems at large, but calls out actor and makes prescriptions. Two lines from the letter

> Governments can do a lot to make it more expensive for Big Tech to hoard > human capital and allow this talent to flow more naturally to small > businesses and startups so that they can more effectively compete and create > vibrant ecosystems.

> The intellectual lobotomization of smart, young STEM talent has been an > explicit strategy by Big Tech fueled by unseemly profitability and hi flying > stock prices.

I think the reason why pmarca's essay is so tame in comparison, is that pmarca believes you can have the best of both worlds: high venture returns and non- tech societal progress that doesn't necessitate government.

[1] [https://www.socialcapital.com/annual- letters/2019](https://www.socialcapital.com/annual-letters/2019)

<comment><USER21> This is excellent and I enjoyed it deeply. Thank you for linking it. I didn't agree with everything but I especially liked his focus on friends, family, health, and being true with oneself over the opinion of others. This VC seems very respectable.

</comment></comment></comment><comment><USER23> Can VCs co invest in trillion dollar government infrastructure projects? Roads bridges hospitals online education healthcare etc. ?

<comment><USER24> They already have in several of the things you listed.

Online Education? Coursera, Lynda, Pluralsight, Kahn Academy, Youtube for crying out loud.

Healthcare? - Healthtech is becoming a big thing, I had the opportunity to interview at a company that is currently working on a private health cloud where they aggregate all of the info about you, your smart watch, your phone, etc. (Note: That you choose and opt into) to make it available to determine the best outcomes for you personally and help the Dr. working with you practice individualized medicine.

You list other things, but hospitals are being changed by technology at an amazing pace, the fact that now during a pandemic I don't have to leave my home to see my PCP, you think that was the burdened bloated Hospital beracuracy that came up with that?

You then list roads and bridges, but the point is that yes, VCs and entrepenuers could figure out how to solve those too given time and a enough freedom, even we can't see it right now, it may be because our vision is just too limited to see what could be, that's what makes entrepreneurs, real entrepreneurs, different they are visionary.

<comment><USER25> How is a healthcare app going to replace surgery, radiation or intensive care?

<comment><USER24> How did Amazon replace you reading a book in your house? It didn't alter the underlying fundamentals but it changed the way we think about it, and again you miss my point, most of us can't figure out things like that, we can't see how we would do that. Some people can, make it so they have the freedom to build and create and they can do things you've never dreamed of.

Also a healthcare app won't replace those things but robots, computer vision, and ML could. Or they could make it so that a Dr. instead of doing 8 surgeries a day could do 80, or a Radiation machine that is totally self managed. You pop in it runs the test then it can interpret results with a 99.99% accuracy. There are lots of ways tech can augment and improve healthcare.

</comment></comment></comment></comment><comment><USER26> FWIW, NIMBYism, self-interest are ruining all that is great about America - [https://slate.com/news-and-politics/2015/01/the-upper- middle...](https://slate.com/news-and-politics/2015/01/the-upper-middle-class- is-ruining-all-that-is-great-about-america.html)

<comment><USER12> Thanks for posting this excellent article. This really resonated both as a Brooklyner and as a full-time founder of a health-tech startup (for 3yrs.)

Lesson Learned: whatever doctors or hospitals say in their "Thought Leadership" pieces...if you end up making medicine more efficient and threaten their fee-per-use system, you will get tons of of pushback from the first-do- no-harm crowd. Talk is cheap, you should focus on what the AMA and individual medical Boards do, not what they say.

Epilogue: I'm back at a larger startup.

</comment></comment><comment><USER27> Ben's analysis is fine. It's not really relevant to the big picture imo.

Andreesen needed to do more than just call for action in his blog post. He should have committed his own funds towards the goals he is calling for. Gates is doing a lot via his foundation. Dorsey is committing a significant portion of his net worth towards goals Dorsey wants. Without something more than a blog post, it's just a blog post.

This virus won't be defeated by 'software' in the Silicon Valley sense. It will be defeated by vaccines. So help the labs create and distribute a vaccine. Or if that's too short-term, look at any of the problems that this pandemic has laid bare- there's lots to fix that is not VC-funded startups.

<comment><USER10> > Andreesen needed to do more than just call for action in his blog post. He > should have committed his own funds towards the goals he is calling for.

That was the part I found frustrating about his original post. He talks of the need to build and the need to push people to build, but when he is one of the 1000 most capable people of building in North America (between his past experience building, his vast network, and his billionaire level of wealth), he prefers to sit back, sit on plenty of corporate boards, and wait for solutions to walk in the door.

</comment></comment><comment><USER28> I wrote a writeup about this article, and the "Time to Build" article that inspired it, here. Kind of a tl;dr and hopefully a useful summary.

Of Stratechery's points, I think I agree the most with the one about distributed work.

[https://www.reactever.com/time-to-build- reflections](https://www.reactever.com/time-to-build-reflections)

</comment><comment><USER29> We have known what to do since the 70's, e.g.:

        Permaculture (Bill Mollison)
        Pattern Language (Christopher Alexander)
        Design Science Revolution (Bucky Fuller)

Plus things like the _hypercar_ and passive solar architecture, etc. All of this was worked out decades ago. But then... in the 80's everyone got high on cocaine; in the 90's it was raves; in the 00's it was the internet (and war); and in the 10's our phones.

I am glossing over hella stuff, of course, but my point is that we have all the answers already (just as Bucky calculated half a century ago.)

[https://en.wikipedia.org/wiki/Hypercar_(concept_car)](https://en.wikipedia.org/wiki/Hypercar_\(concept_car\))

</comment><comment><USER30> _> Third — and related to both of the above — figure out an investing model that is suited to outcomes that have a higher liklihood of success along with a lower upside. This is truly the most important piece — and where Andreessen, given his position, can make the most impact. Andreessen Horowitz has thought more about how to change venture capital than anyone else, but the fundamental constraint has remained the assumption of high costs, high risk, and grand slam outcomes. We should keep that model, but surely there is room for another?_

I'm puzzled that the above paragraph was written by Ben Thompson with his background including an MBA and the writing of insightful articles about startups.

The reason VCs don't invest in other non-VC things like "boring" and "low- return" city infrastructure projects, or small/medium businesses to help communities -- is because _that 's not what the people who put money into their fund expected them to do_.

Some folks seem to forget that VCs are ultimately managing _other people 's money_. Pension funds, university endowments, charities, some wealthy families, etc. The investment officer working as custodian of a teachers' pension fund didn't give money to a VC like a16z to build a new sewer system. The pension fund is looking for 15-20% returns and looked to a16z's expertise on evaluating startup founders. That's what they _specialize_ in. Previous comment about the complexity of different investments leads to specialization: [https://news.ycombinator.com/item?id=21365966](https://news.ycombinator.com/item?id=21365966)

I think Ben's idea is that Marc A (and a16z) is _influential_ and so they can put out a prospectus for a new type of fund with a _different investment thesis_ that avoids YC software startups and focuses on low-risk low-return low-margin "hard" projects. Well here's the problem, the pension fund officers will not think it's a good use of their money and will invest their money elsewhere. Therefore, the VC fund using Ben's ideas does not raise any money.

The customers (Limited Partners) with the millions to invest is the constraint that any person raising a new fund with "feel good" ideas faces. E.g. let's say you want to create an investment fund that _" feeds poor 5-year old children nutritious meals and reads books to them because children are the investment into our future."_ Ok, it sounds noble but when the investment officer of the Firemen Retirement Fund asks how it makes money, you need to have a credible answer. Otherwise, your fund gets no money and the feel-good investment thesis goes nowhere.

My previous comment on why alternative investment ideas don't need essays about it. They just need financial mavericks to pursue it and everybody will copy them. ([https://news.ycombinator.com/item?id=21588264](https://news.ycombinator.com/item?id=21588264))

However, Andreessen Horowitz is probably not the financial maverick that can prove the alternative investment idea will work. Their firm and their staff are built to understand software startups. Somebody else has to lead with Ben's ideas.

<comment><USER31> You're right about a lot of this, but I think what you're missing is that Marc Andreessen did this financial maverick thing once, which is why he is influential. So it is probably right that Andreessen Horowitz the fund is not the right vehicle for such a thing, but having written his open letter, and with a deep well of influence and (presumably) some unique talent for setting up investment vehicles, _Marc Andreessen_ the person is well positioned to put his money where his mouth is and work toward making this new kind of investment vehicle work.

Yes, this would involve finding new kinds of LPs or selling the same LPs on a new vision with different trade-offs, but that finding-LPs-and-selling-them work is exactly what it took to launch Andreessen Horowitz, so it is not crazy to suggest that perhaps Marc Andreessen is well positioned to get to work on this.

The response to your other comment you linked (edit, this one: [https://news.ycombinator.com/item?id=21588626](https://news.ycombinator.com/item?id=21588626)) is also interesting and meshes with my intuition that there might be more of a market for this than your giving credence to. I would also add that a benefit of this possible market may be that it could be a lot bigger than the pool VCs are currently constricted to. I think one interpretation of what we've seen with unicorns (and SoftBank, which is increasingly looking like a debacle) is that there is more money that wants in than there are businesses with the right model for the kind of VC money they are getting. It is plausible that a more sustainable model might be found in a much broader market of less risky companies.

</comment></comment><comment><USER32> We're great at building private wealth. We suck at building public wealth. We built a database worth a trillion dollars. We've built oligopolies in vital industries.

The newspaper reports on "the economy" by a private wealth measure -- the stock index. Another measure -- jobs -- is reported in numbers and not dollars, because the numbers are a leading indicator of public support for private wealth.

We haven't begun to fight for our survival until we agree to tap into private wealth.</comment>


Ask HN: Multiprocessing & concurrency: C, Python, Clojure (& Go :))? - <AUTHOR>

I've never looked into Clojure so far (sorry :) but how does this compare to OpenMP(I)? Or even with Python's parallel processing capacities? How much would performance difference vs. implementation ease be between a C MPI and Clojure parallel processing implementation? Or how would Clojure's MP libraries compare to Python's multiprocessing.JoinableQueue and Manager? Would it be worth considering learning Clojure? And, yes, I know I should learn a new language per year, but then I would at least like to know how it compares to Go - as I am considering that because of the channels, but I now often hear Clojure named alongside Go for exactly those reasons.<p>So, just from the MPI perspective: Clojure, maybe Go, and Python or C(++), what are you using and why? <comment><USER2> I'm a sysadmin for a university HPC facility. We basically have users split into two groups. Single node and Multinode. We even have separate clusters for them. We have one cluster with infiniband interconnect and the other with gigabit ethernet.

The multinode users love MPI because it screams over infiniband. These are people running genome mapping simulations or fluid mechanic simulation etc. This is actually a minority of our users. Most of our users are perfectly content with our dual socket hex core westmere cluster. They use various applications for their simulations, but most of them have difficulty scaling past 12 cores anyway.

So, in my experience, MPI is great because the hardware becomes the limiting factor, and the other implementations are a little more software bound. So if you have a couple hundred cores available for a single job, you are stuck with MPI. If you are sticking to a multithreaded implementation, the other languages you mention might be a good solution.

<comment><AUTHOR> Impressive admin work you have there :) Thanks, that is I think the most concise answer summing it up. So, as you are even in the "right environment" for that - one question might be left another guy raised: got any thoughts on Haskell about this?

<comment><USER2> So the majority of our users are either running commercial software, or running something home-rolled. The home-rolled software is generally the product of years of slapping bandaids on something someone wrote at such-and- such university. Almost always written in fortran 77.

It's becoming a bit of a problem, because we know they have terrible inefficiencies in algorithms and are not very well optimized for our system. But a ME Professor is more interested in the splashback effects supersonic turbines create than how efficient his simulation is. If it takes an extra 100,000 CPU hours, thats only an extra week for a 500 processor job. As long is it works well enough, they generally don't want to touch it.

So in that climate, there is very little research done using languages other than fortran and C. When it does it usually it comes about as a result of an interesting library that does X and is written in Y.

We are a small shop, especially for a 10,000 core system. We've only got 3 full time employees and three student employees:a part time web dev, a part time hardware tech, and me (Also part time.) . I've been trying to spend my time working with users and optimizing their code but for the most part they just aren't that interested. I think the prevalence of fortran shows a lot about the overall mentality. Just use what works, and get as much use out of it as you can.

</comment></comment></comment><comment><USER3> These are two questions (see the recently posted parallel clojure talk).

For concurrency (short version: this means multiple processes doing different things sharing some small amount of state), I'd say Clojure, Go, and Python are all good choices. Really, anything with either immutable data structures and good IPC support (Clojure has this, agents are fantastic for IPC), or coroutines (Go, Python, Lua...) will give you great concurrency control.

For multiprocessing/parallel processing (short version: this means multiple copies of the same processing working on smaller parts of a large data set), OpenMP is a great way to go. I have gotten a lot out of Clojure and Hadoop (on a large cluster), and the new pvmap/pvreduce look like they'll help a lot on the single node, multicore front. I would not trust Python to do these things fast, and I can't tell you about Go. If you can partition your data successfully and prevent GIL problems, Python will do fine.

<comment><AUTHOR> Ok, I should have said that I am only interested in the "multiprocessing" aspect; That sounds pretty promising what you write about MP in Clojure, although. Concerning Hadoop, I have my doubts about it - I never switched and now I even read people are going back to SQL & OpenMP (or MPI) anyways. Python's "old wound" GIL story is "solved" (let's say, "patched" ;) ) since 2.6 (if you can accept the huge overhead from multiprocessing's calls for coarse-grained threads), so I am fine with that so far. So, has anybody got insight into how Clojure (or even pvmap/pvreduce specifically) performs against either OpenMP/MPI or Python?

EDIT: I maybe better should say, how much easier it is to use. After, all it is a JVM, so it will be slower than C, obviously, but you also get rid of the million of possible bugs you can introduce in it (which makes using Python so attractive to me). So, is there a good reason for somebody who as used either Python or OpenMP for multiprocessing to switch to Clojure?

<comment><USER3> Python is almost always memory-heavy. C is not, if you do it right. Of course, C, if you do it right, will be the fastest, it's the "do it right" that's hard. Clojure, on the JVM, will be slower than C "done right", but faster than most C, because the JVM's JIT is surprisingly smart. Any performance problems you get with Clojure can usually be mitigated by adding type hints to force your repetitive calculations to use primitive type operations, which will get compiled by the JVM to direct machine instructions, as fast as C.

You should switch to Clojure from Python because it's faster.

You should switch to Clojure from C because it's easier, and more specifically, easier to get it to a certain level of speed (which is high).

Don't let the JVM fool you into thinking it's slow. It isn't.

<comment><AUTHOR> Well, I do not quite agree with your argument that Python is "always memory- hungry". As a matter of fact, writing "good" Python code is a very seldom observed art and most performance issues can be gotten rid of if you know enough about the language and follow the style and design advices of true "Pythonistas", as the "gurus" there call themselves (and many more who do not deserve that title ;)). However, I have been programming several years in Java on an earlier assignment, where stuff got so clumsy I wrote a 6 page manual for my team outlining "don't do's" in Java because it would either cost tons of performance or memory, mostly related to very basic stuff such as instantiation strategies and everything that might be "good" for OOD, but bad for performance. We ended up writing most of the core of the system in Lisp and then generated the "light-weight" Java stuff from a DSL one of our Lisp "masters" had conjured, to avoid all the bloat you have to go through to write simple things such as walkers, etc. in Java. If I ever had real memory problems ever, I must say it was with JVM, and it took me months to, for example, come up with a solution to index a few TBs with Lucene and the JVM "crashing" (well, hanging) because of gc (although that was back more than five years now, so things will have gotten better, I admit). Nay, I must say the Python/C combo is much to my liking. I want something that fits into that picture, not so much an alternative. And there I currently see Erlang as quite promising combo to my two favorite languages, after going through all the advice and pointers everybody here gave me.

<comment><USER3> > As a matter of fact, writing "good" Python code is a very seldom observed > art and most performance issues can be gotten rid of if you know enough > about the language and follow the style and design advices of true > "Pythonistas", as the "gurus" there call themselves (and many more who do > not deserve that title ;)).

First of all, should performant code in your language be "seldom observed" and require the knowledge of the "gurus"? I should hope not.

I have written plenty of optimized python in my day, and it's always been a decent constant behind c or java, no matter how many of the "best practices" I follow. Pypy may be a different story, but their toolchain was too complex and slow last I looked.

Most of python's best practices are language bugs, anyway. Generators are great, but most of the rest is crap. I should cache my namespace lookups outside the loop? Why can't you do that for me, Python? That's one of the simplest compiler optimizations we have. All the fastest Python is written in C extensions. Why do you think this is?

<comment><AUTHOR> As an update: Python 3k solves the namespace issue you mention. (And I hope more and more dev's will finally move on, I love it and only can say it is 100% worth the switch! I'll never again code in pre-3k if not forced to.)

And no, I am not saying that Python outperforms Java, obviously. But it can provide very decent performance at very low LOCs. And then you can identify the bottlenecks and implement that part in C. Overall, a much faster approach than writing in Java (and, obviously, than writing in pure C) with final performance rates beating a JVM easily.

EDIT: No, that is actually even too complicated than what I mostly need to do: For the real bottlenecks I usually just need to find the C library that solves that hard part (e.g., some number-crunching stuff I am doing) and already has a Python wrapper, or you generate one (hello SWIG), or, worst case, you really have to write one (yet have to find that case, although).

</comment></comment></comment></comment></comment></comment><comment><USER4> Seeing how I'm currently in Chicago for ErlangCamp (which is excellent so far), it's relevant for me to recommend Erlang if you want to go big in the multiprocessoring and concurrency stuff.

I know that wasn't one of your 4 mentioned languages, but it's worth a mention.

<comment><AUTHOR> Yeah, that would be number five and I was considering adding it, actually; However, I am not really sure I like it, because the speed of Erlang isn't that great and I for that point always favor anything that can keep up with C (and, the Go guys at least promise they will; so I'd like to see how fast Clojure can go on a JVM). Now, I know Python can't, but then you can always first write your prototype in it, and then later fix performance considerably with some C.

<comment><USER5> If you have some heavy computation parts that you could implement in some lower-level language like C, then you might want to check out Erlang again.

Erlang is really good at making the coordination layer efficient (the message passing and threads are fast) as well as usually rather clean. The original use-case for Erlang, telecomunication switches, are written in a mix of Erlang and C. The low level stuff (handling call-data and similar things) is handled by C, and the high-level structure of the program is in Erlang.

<comment><AUTHOR> Followed the advice I got here from you and others and am now studying the language. And, so far, I must say, Erlang rocks. Naturally it will be a few weeks before I can write something real and make more of an educated decision, but it really looks very nice so far - so many solutions to problems I have. I especially like the "selective message passing" bits and the ways you can operate on bitstreams already.

</comment></comment></comment></comment><comment><USER6> I've been a happy user of Python's multiprocessing package, for the following reasons:

* It's really natural if you work on an OS that has fork() (i.e., not Windows), you just need to create a Pool after you've initialized everything and can use Pool.imap (in much the same way as itertools.imap) after that. * Distributing data for initialization (which is ~100-200MB in my case) would add another level of complexity if I wanted to distribute tasks among several computers automatically.

At the granularity I'm working (most single tasks use >10ms, many >100ms), a simple worker pool works just as fine as the ForkJoin model that Clojure parallel is based on.

OpenMP and OpenMPI are for a very different use case where you know (pretty much) exactly how long the different parts of an operation will take, so you can make different processors (or different nodes) take different, determined- in-advance, chunks of the problem. Usually, the "parallel map" abstraction implemented by Python's multiprocessing, Java's ForkJoin, or Hadoop/Disco is much more useful as a quick fix to parallelize something than if you start out with channels and try to build something on top of that.

TL/DR: It depends on your workload what multiprocessing workload is right for you. For most bread-and-butter workload where you can use a parallel map function, multiprocessing/ForkJoin is just fine; OpenMP is great if you have a very predictable split between processors and are willing to jump through additional hoops to squeeze out the additional 5-10% of performance. Don't use queues etc. unless you know you need them. Multi-node solutions (MPI, map/reduce) usually add another layer of complexity because you need to ship the initialization data to each node (if you need, e.g. a statistical tagging or parsing model).

<comment><USER7> Can't you also use OpenMP for the quick-fix "parallel map" abstraction? The typical C way of mapping an operation is to do it in a loop, and if the loop iterations don't depend on each other (as in the mapping case), you can just add a "#pragma omp parallel for" at the top of the loop to make it execute via the worker pool.

<comment><USER6> If the execution time of the function varies considerably (i.e., some of the sub-problems are faster to solve), then you want to be able to keep the other processors busy with the next sub-problems while one of them keeps gnawing at a particularly difficult one.

If the timing is very predictable, OpenMP's parallel-for construct fits your bill very nicely.

<comment><USER7> Hmm, I thought OpenMP's worker-pool management did do that? E.g. if you have an 100-iteration loop, and have your num_threads set to 10, then it'll start up the first 10 subproblems; the first thread to finish will get the 11th, etc. If one of the first 10 is really slow, the other threads will still move on to churn on the rest of the loop iterations. Or is that not how it works?

<comment><USER6> Actually, you're right. OpenMP allows you to choose between "static" scheduling (where it would just cut the 100-iteration loop into 0..24, 25..49, 50..74, 75..99 if you have four processors) and "dynamic" scheduling with a specifiable block size (where it would, for a block size of 10, first chop off four iteration blocks of 0..9, 10..19, 20..29, 30..39, and allocate the other six blocks depending on which processor wants more work first).

According to the OpenMP tutorial, the default for OMP_SCHEDULE is implementation dependent, and the gcc OpenMP implementation uses dynamic scheduling with a chunk size of 1 by default.

</comment></comment></comment></comment></comment><comment><USER8> Both Clojure and Go have very interesting features to support parallel computing. Both are definately worth learning. Go's implementation is rather immature at this point in time. Some of the libraries and the garbage collector are really slow but things are changing rather quickly in Go land right now.

Go's design makes much more efficient use of a single machine's resources than any JVM based language ever could. In terms of memory it is comparable to C or C++. Goroutines are very lightweight because they use a variable size stack, so Go supports much more fine grained parallelism. Whether you need that or not depends on your application of course. I found goroutines much simpler and intuitively accessible than the large set of Clojure's parallel primitives. But I think reasonable people can have different opinions on that one as STM (software transactional memory) is attractive too and immutable data structures do make some things simpler.

Of course, Clojure is a Lisp dialect, which has other benefits that have nothing to do with parallelism. However, for many of my own tasks, memory usage is critical and Clojure hogs memory even more than regular Java, so that's why I would prefer Go once it matures a little. I think Go can replace C and C++ over time. Clojure will never do that in its current JVM based implementation.

In terms of raw performance, if memory is not the issue, you can expect similar results from Clojure and Go, provided you make use of static type hints in Clojure (which doesn't look pretty) and you give Go's creators some more time to optimize the stuff that's known to be slow.

</comment><comment><USER9> MPI applications are usually written in C or Fortran, namely because the use case is number crunching. That's very different from what Clojure and Python are associated with. There aren't many scientific applications targeted to virtual machines or dynamic languages for this very reason. (I know about Sage and NumPy, etc. I am referring to LAPACK-style computations.)

</comment><comment><AUTHOR> To sum up what you so far have responded: For data distribution it seems, OpenMP and MPI are still the best implementation if you expect to have a constant runtime for each of these tasks. On the other hand, for task distribution (say, ms > 10 or 100, and variable runtimes), any of the higher languages (e.g., Python, Erlang, Clojure) are acceptable abstractions to ease their development.

There seems to be no language that truly would facilitate distributed computations (multicore & multiprocessor) significantly, however (maybe Haskell?). Is that really it, there is no language that is specifically apt for the new multi-core/-processor machines popping up everywhere that will make programming life easier for those architectures, especially when I want to do some algorithmic speed-ups? I am a bit disappointed, in a way.

<comment><USER10> good backgrounders on the concurrency landscape (messaging/actors, STM, datfalow

<http://blog.ezyang.com/2010/07/graphs-not-grids/>

[http://www.igvita.com/2010/08/18/multi-core-threads- message-...](http://www.igvita.com/2010/08/18/multi-core-threads-message- passing/)

[http://erlware.blogspot.com/2010/07/brief-overview-of- concur...](http://erlware.blogspot.com/2010/07/brief-overview-of- concurrency.html)

[http://www.sauria.com/blog/2009/10/05/the-cambrian-period- of...](http://www.sauria.com/blog/2009/10/05/the-cambrian-period-of- concurrency/)

[http://www.slideshare.net/twleung/a-survey-of-concurrency- co...](http://www.slideshare.net/twleung/a-survey-of-concurrency-constructs)

</comment></comment><comment><USER11> you may want to consider ZeroMQ, depending on what you're trying to do, the python libraries are very good, they work hard to avoid copying excess data, as well as releasing the gil appropriately [http://stackoverflow.com/questions/35490/spread-vs-mpi-vs- ze...](http://stackoverflow.com/questions/35490/spread-vs-mpi-vs-zeromq)

<comment><AUTHOR> Nice pointer to a MPI library I wasn't aware of - thanks!

<comment><USER11> zmq isn't an MPI library, it's a generic messaging library

they refer to it as sockets on steroids

<comment><AUTHOR> Ah, well, I should have a closer look at times... Thanks for the hint ;)

</comment></comment></comment></comment><comment><USER12> I don't use any, but from looking at the syntax and code examples the newcomers make pretty small incremental improvements. I think a DSL that separated out the control flow from the rest of the code would get things going in the right direction. I'm hacking one together for Javascript.

As far as performance vs implementation here is a handy chart [http://shootout.alioth.debian.org/u32/code-used-time-used- sh...](http://shootout.alioth.debian.org/u32/code-used-time-used-shapes.php) That's for generic language things, but concurrency probably doesn't stray far from the overall performance.

<comment><AUTHOR> Hmm, so you would not say that Clojure's or Go's approaches are worth it in terms of programming ease? The plots you point to looks at least seems worrying: Python is smacked on the concise 0-axis, C on speed. Clojure at least makes no especially good grounds on those plot, as I already expected. However, I was hoping people would say it is so much easier writing a parallel implementation of the code I am using that I switched to Clojure/consider using Go/whatever.

<comment><USER12> The charts are for general language use, not specifically concurrency. Go and Clojure are better than locks and mutexes of C, but there were similar ideas in Scala and other languages along the way and the newcomer improvements don't land far from those.

So Go, Clojure, F#, Scala, Python could proabably be lumped into the same ease of implementation category as far as concurrency. They'll all make a mess if you have complex control flow. This <http://news.ycombinator.com/item?id=1824683> (which you've already seen) or [http://en.wikibooks.org/wiki/F_Sharp_Programming/Async_Workf...](http://en.wikibooks.org/wiki/F_Sharp_Programming/Async_Workflows) is what I call a mess, but it's as clean as it gets for now.

I think the real test is whether people start using concurrency as the norm and not as a separate use case (since it's annoying to write). I don't think these languages will have that effect.

</comment></comment></comment><comment><USER13> I would add Erlang and node.js to the list. I need to build a HTTP server for frequent polling for a project that I am working on (polling or websockets if available, lots of users) and I narrowed down building that component in either Erlang, node.js or Python.

I have really taken a liking to the Erlang model. Processes share no memory and communicate by passing messages. There is no shared state locking/mutex.

Once I have more data/information (benchmarks, ease of development/integration etc.) I will publish my results.

</comment><comment><USER14> Like everything, it depends on the problem. There are problems which needs parallelism but cannot use many of the languages mentioned by the OP. Eg: Realtime Multi-channel video encoding. Most of such systems use custom processors. Unless massively multicore mesh architecture (like Tilera TILE64) become common place, we are stuck with using such custom processors and that would mean using plain old C. Once mesh based multicore becomes cheaper and commodity, we will see use of other languages in such problem spaces.

</comment><comment><USER15> Go promises good concurrency, but you might want to do a bit of research before dedicating much resources to it. Last time I checked, their os threads to goroutines scheduling was a bit wonky.

Though it's entirely possible I screwed something up or missed an important bit.

<comment><USER16> Go does concurrency well, but it's designed for concurrency on a single machine, not so much parallel processing on many different machines.

<comment><AUTHOR> Well, I greatly suspect they will add that kind of stuff later, reading blogs about what the long-term goals of the language are. I think Go might be a serious newcomer in that aspect, considering they want it to level with C in performance. However, I don't want to start a g8 discussion (and yes, I don't like the syntax either... :), I'm especially interested in how good the ease of use vs. the performance of these languages compare, as I still use Python and OpenMP for that stuff.</comment></comment></comment>


Ask HN: How to create contact from email/gmail signature? - <AUTHOR>

I've finally found the source of my frustration with the virtual rolodex: creating the contact.
A fantastic feature of the physical rolodex is that one needs to simply place the business card in the rolodex to "create" a contact.
Since email is a dominant form of communication and source of new contacts, does anyone know of a simple way to parse the email signature to create a contact?
(Personally, I don't care if the virtual rolodex is 37Signals Highrise, Apple AddressBook, or Gmail Contacts because I'd be willing to switch if I could create/sync contacts with a "click".) <comment><USER2> When I was on Windows I used Copy2Contact (nee Anagram)[1], and loved it. It looks like they now have an iPhone version and a Google Apps version on the way.

[1] <http://www.copy2contact.com/></comment>


Ticketmaster is evil and must die (2008) - <AUTHOR> http://consumerist.com/2008/10/ticketmaster-is-evil-and-must-die.html

<comment><AUTHOR> It seems nothing much has changed since this post. I just backed out of an online ticket purchase and will trust to find tickets at the venue instead because I'm equally upset by the amount of the "convenience surcharge" and it's name.

Any startups out there tackling this quasi-monopoly?

</comment><comment><USER2> As I've said before, Ticketmaster's reason for existence is to be hated. It allows events and venues to charge close to the market-clearing price, while pointing to Ticketmaster as the bad guy who is "gouging" you.</comment>


OSX: Why does installing Safari 5 force me to restart? - <AUTHOR> http://i45.tinypic.com/2qupycy.jpg

<comment><USER2> Because JavaScriptCore and WebKit are in use by various components of the OS?

<comment><AUTHOR> Damn you and your logic! I've been jaded by Chrome/Firefox not forcing a restart for a while now :( I don't use Safari but I always leave it in my 'software updates' box until something important comes in because I really just don't want to restart my computer.</comment></comment>


11 Helpful Tools for Every Step of Building a Mobile App - <AUTHOR> http://www.entrepreneur.com/article/237242

<comment><USER2> This is awesome. It helps! Thanks for this post

<comment><AUTHOR> Thank you!</comment></comment>


All Windows 10 PCs will support HoloLens next year - <AUTHOR> http://www.theverge.com/2016/8/16/12503868/microsoft-windows-holographic-windows-10-shell-features <comment><USER2> As pointed out in the articles comments as well, Verge ended up with a more confusing headline than they intended. From as far back as the HoloLens, Microsoft said that Windows Holographic, the libraries and UX that HoloLens runs, will be a part of every Windows 10 install.

The questions that have remained have been what exactly that meant and the actual news in the article is that Microsoft has demoed announced one of the obvious uses of Windows Holographic which is that it will support a wide range of VR/AR hardware, including some new mixed reality projects from Intel ("Project Alloy").</comment>


Rust RAII is better than the Haskell bracket pattern - <AUTHOR> https://www.snoyman.com/blog/2018/10/raii-better-than-bracket-pattern <comment> T-R Something to keep in mind - linear types are on their way[1], with exactly this usecase in mind. Simon Peyton Jones gave an excellent presentation on the topic[2], briefly discussing exceptions, as well as giving a mention to ResourceT and the phantom type solution in the article (described as channel- passing).

[1] [https://arxiv.org/abs/1710.09756](https://arxiv.org/abs/1710.09756) [2] [https://www.youtube.com/watch?v=t0mhvd3-60Y](https://www.youtube.com/watch?v=t0mhvd3-60Y)

<comment><USER2> Please, don't add them to the language. Use the library approach instead, it is much more Haskellish.

<comment><USER3> Is it possible? I mean, to add linear types via a library? I feel like it would have been done already if it were.

<comment><USER4> I am always impressed by what the ocaml/Haskell people can do compared to my language of choice (scheme).

Iirc Oleg Kiselyov implemented proper delimited continuations in ocaml as a library, without touching the runtime or compiler. Something similar has been done in Haskell.

I doubt fully dependent types can be implemented in Haskell without extra help by ghc. There has been lots of work in the area, and last time I checked you could simulate DT to some degree, but it never was as powerful as the dependant types in idris. Iirc t were some edge cases where the typing became undecidable.

<comment><USER5> >Iirc Oleg Kiselyov implemented proper delimited continuations in ocaml as a library, without touching the runtime or compiler.

To clarify this, the library you're talking about implements most of the functionality in C, reusing the runtime's exception mechanism. So it doesn't require any upstream change to compiler or runtime, but it also can't be implemented in pure OCaml.

<comment><USER4> Hmmm. I remembered incorrectly then. The bytecode version is possible in pure ocaml, but for native it apparently needs C.

For Haskell it is however possible. There is a neat paper by among others Kent Dybvig.

</comment></comment></comment></comment></comment></comment><comment><USER6> The thing is that, in Haskell, even when you attach a function to run during destruction, the runtime doesn't guarantee that the function will be called promptly, or even at all. Rust drops (runs destructor and deallocates) values as soon as they go out of scope; C++ too. In Haskell you depend on the whims of the GC, which makes RAII unusable. (The Haskell approach of not guaranteeing destructors being called does have its merits; when many C++ and Rust programs are about to end, they spend the last few cycles uselessly deallocating memory that would've immediately been freed via _exit(2)).

Therefore the RAII style wouldn't really work in Haskell. The current bracket approach is still better than RAII in Haskell.

That said, the ST-style trick of a phantom type variable is pretty well-known. Unfortunately not many people knew the same trick can be used for non-ST as well. I feel like as a community we should be encouraging this style more often.

UPDATE: I wrote the original comment with the incorrect assumption that drop functions will always be called in Rust. This is wrong. Please see child comments.

<comment><USER7> > when many C++ and Rust programs are about to end, they spend the last few > cycles uselessly deallocating memory that would've immediately been freed > via _exit(2)

thank god they do this. how many times did I have to manually force linux to release sockets because badly coded C programs which opened sockets forgot to release them causing them to hang up for ~5 minutes after the process ended. With proper RAII classes this does not happen.

<comment><USER8> Your example combined with the parents observation show that C++ put under the same construct the concepts that should be separated: memory allocation should be handled differently from the construction, destruction and other resource allocation.

<comment><USER6> Memory allocation and deallocation on the heap basically mean calling the `operator new` and `operator delete` functions in C++. The language provides a default implementation but you can override it.

Constructors are orthogonal. The job of a constructor is to construct your object given that the space for the object is already allocated. This could be on the stack, where allocation means bumping the stack pointer, or in-place in preallocated storage (like std::vector), or the result of calling `operator new`. Simply using the `new` syntax does both as a shorthand.

Similarly the job of a destructor is to destruct your object without deallocating it. One can in-place destruct without deallocating, or destruct and then deallocate implicitly when the stack pointer is adjusted, or not at all. The `delete` syntax does both destruction and deallocation as a convenience.

</comment></comment></comment></comment><comment><USER9> You can also have the exact opposite problem with RAII, where a resource survives the end of a transaction, because there is still a live reference to it hidden away somewhere (say, due to some debugging code holding on to it).

This is a classical liveness vs. safety dualism. "Something good will eventually happen" and "nothing bad will ever happen" are promises whose solutions are often in conflict with one another.

The general problem — to make transactional state changes and transactional control flow (i.e. expectations about these state changes) match up precisely — is not easy to solve in the general case, especially once you move on to things that are less trivial than simple resource acquisition/release matching.

<comment><USER10> Oddly, Rust's ownership system really does solve these problems, and Non- lexical lifetimes should eliminate accidental scope-broadening. Unless you are doing some mega-schenanigans, an e.g. MutexGuard gets released precisely when you think.

Your point about this being difficult to solve in the general case is true, it's just worth pointing out Rust intends to do that hard thing anyway.

<comment><USER9> > Oddly, Rust's ownership system really does solve these problems

No. Rust's ownership problem solves it for trivial cases, at the cost of making it hard to do other things (such as sharing references past the lifetime of the owner without resorting to Rc<T> or Arc<T>, at which point you don't really have lifetime guarantees anymore).

The essential limitation of Rust is that (without resorting to Rc<T> and Arc<T>, which would put you back to square one) it is conceptually limited to the equivalent of reference counting with a maximum reference count of 1. In order to make this work, Rust needs move semantics and the ability to prove that an alias has a lifetime that is a subset of the lifetime of the original object) and may even sometimes have to copy objects, because it can never actually increase the (purely fictitious) reference count after object creation.

This inherent limitation makes a lot of things hard (or at least hard to do without copying or explicit reference counting). Structural sharing in general, hash consing, persistent data structures, global and shared caches, cyclic data structures, and so forth.

In short, you have the problem with shared references less, because Rust makes it hard to share data in the first place, for better or worse. (Again, unless you resort to reference counting, and then you get the issue back in full force.)

<comment><USER11> > it is conceptually limited to the equivalent of reference counting with a > maximum reference count of 1.

This is a thing people say, but I think it's misleading. Reference counting can increase the lifetime of an object, but borrowing cannot. I've seen this _really_ trip up beginners.

> This inherent limitation makes a lot of things hard

It can make them _different_ , which can be hard, but these things are _already hard_. And some people think it can make them easier or even better; see Bodil Stokke's work on persistent data structures in Rust.

<comment><USER12> > This is a thing people say, but I think it's misleading. Reference counting > can increase the lifetime of an object, but borrowing cannot. I've seen this > really trip up beginners.

I'm not sure I follow.

The only reference-counted language I've used is (pre-ARC) Objective-C. There, it was a very common idiom to "borrow" objects - so common that it didn't even have a name. There was just objects you "retained" (that is, staked a claim on), and ones you didn't.

Maybe there's a pitfall to how the "automatic" part of automatic reference counting is typically implemented?

<comment><USER11> It has been years since I've written objective-c, so I'll write out some psuedo-code. This may be wrong, please correct me! (It should map to C++ pretty directly, and certainly does in unsafe Rust.)

* You have an object. You call retain on it. You have a count of one.

* You also have a pointer to that object. The "borrow" in your analogy.

* You return this pointer, and stash it somewhere. The object still has a count of one, so it's still live, so this is okay.

* Later in your program, you use that pointer to call release.

Here, we've only ever had a reference count of one, but our object has lived across arbitrary inner scopes. In Rust, this would not work, unless you dropped into unsafe.

Obviously, with Arc and autoretain this kind of code doesn't get written anymore, I would hope. And even without, it wouldn't be guaranteed, so you'd want the "borrow" to actually bump the refcount. But Rust is about _guaranteeing_ that it can't.

<comment><USER12> Ah, I think I follow.

So, it sounds to me like it's not necessarily that Rust's model is fundamentally different from "ref counting with a limit of 1", at least in terms of how you _should_ be managing your memory, so much as that the language doesn't let you some things that you really shouldn't be doing in the first place.

Sometimes it felt like Objective C wouldn't just let you point a gun at your foot, it would actively cheer you on while you did it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> How do you handle errors at resource release? When you close a file, the final writes take place, and they can fail. What's the idiom in Rust for getting them out?

Python's "with" clause, and the way it interacts with exceptions, is the only system I've seen that gets this right for the nested case.

<comment><USER14> I don't think Rust can notify on a failing destructor other than panic!ing. AFAIK the best you can do if you want to handle errors on close is to call `flush()` (which does return errors) before dropping the object. Of course that nullifies the benefits from RAII.

I don't know if there's an elegant way to solve this. If Rust had exception you could use that but then again in C++ it's often explicitly discouraged to throw in destructors because you could end up in a bad situation if you throw an exception while propagating an other one. How does Python's "with" handle that?

<comment><USER15> > I don't think Rust can notify on a failing destructor other than panic!ing.

Much as in C++, this is not really allowed: drop runs during panic unwinding, a panic during a panic will hard-abort the entire program.

> I don't know if there's an elegant way to solve this.

I don't really think there is. Maybe opt-in linear types could be added. That would be at the cost of convenience (the compiler would require explicitly closing every file and handling the result, you could not just forget about it and expect it to be closed) but it would fix the issue and would slightly reduce the holding lifetime of resources.

Furthermore, for convenience we could imagine a wrapper pointer converting a linear structure into an affine one.

> How does Python's "with" handle that?

You'll get the exception from `__exit__` chaining to whatever exception triggered it (if any). Exceptions are the normal error-handling mechanism of Python so it's not out of place.

<comment><USER14> >Much as in C++, this is not really allowed: drop runs during panic unwinding, a panic during a panic will hard-abort the entire program.

Right, I didn't really consider that a "drawback" because I'm in the camp that considers that panic! shouldn't unwind but actually abort the process here and there anyway. But you're right that if you rely on the default unwinding behavior panic!ing in destructors is a very bad idea.

<comment><USER16> > But you're right that if you rely on the default unwinding behavior

You do rely on the default unwinding behavior anyway at least for `cargo test`: the test framework depends on being able to catch the unwinds from `assert_eq!` and similar.

</comment></comment></comment></comment></comment><comment><USER17> Interesting! Michael is one of the more prolific writings and practitioners in the Haskell space (I read just about everything he writes) so it is interesting to also read his take on Rust.

</comment><comment><USER18> Isn't this just because withMyResource returns IO a rather than IO ()? It doesn't seem reasonable for it to return the resource.

</comment><comment><USER19> Would be interesting to know why memory leaks are possible in Rust, if RAII is so deeply integrated into language.

<comment><USER20> Like this:

      fn leak() {
          // Create a 1KiB heap-allocated vector
          let b = Box::new(vec![0u8; 1024]);
          // Turn it into a raw pointer
          let p = Box::into_raw(b);
          // Then leak the pointer
      }

Obviously that's kind of blatant, but there are more subtle ways to leak memory. Memory leaks aren't considered unsafe, so even though they're undesirable the compiler doesn't guarantee you won't have any.

Reference cycles when using Rc<T> are a big one, but generally it's pretty hard to cause leaks by accident. I've only run into one instance of leaking memory outside of unsafe code, and that was caused by a library issue.

<comment><USER21> The most obvious ways to leak are calling `Box::leak` which is also a very useful API and `mem::forget` (the latter is mostly useful for working with unsafe code).

</comment></comment></comment><comment><USER22> tl;dr - Try rust.

The mechanic point of this article is pretty clear:

\- it's possible to be unsafe in both Haskell and Rust when dealing with resource cleanup

\- Rust does a bit of a better job in the general case though it has it's own warts (see the other comments, it's hard to deal with issues during `drop`-triggered cleanup)

I want to make a muddier meta point -- Rust is the best systems language to date (does anyone know a better one I can look at?).

\- The person who wrote this article Michael Snoyman[0] is mainly a haskell developer, he's the lead developer behind arguably the most popular web framework, yesod[1].

\- Haskell developers generally have a higher standard for type systems, and spend a lot of time (whether they should or not) thinking about correctness due to the pro-activity of the compiler.

\- These are the kind of people you _want_ trying to use/enjoy your language, if only because they will create/disseminate patterns/insight that make programming safer and easier for everyone down the line -- research languages (Haskell is actually probably tied for the least "researchy" these days in the ML camp) are the Mercedes Benz's of the programming world -- the safety features trickle down from there.

\- Rust is _not_ a ML family language -- it's a systems language

\- People who write Haskell on a daily basis are finding their way to rust, because it has a pretty great type system

When was the last time you saw a systems language with a type system so good that people who are into type systems were working with it? When was the last time you saw a systems language that scaled comfortably and gracefully from embedded systems to web services? When have you last seen a systems language with such a helpful, vibrant, excited community (TBH I don't think this _can_ last), backed by an organization with values Mozilla's?

You owe it to yourself to check it out. As far as I see it rust has two main problems:

\- Learning curve for one of it's main features (ownership/borrowing)

\- Readability/Ergonomics (sigils, etc can make rust hard to read)

Admittedly, I never gave D[2] a proper shake, and I've heard it's good, but the safety and the emphasis on zero-cost abstractions Rust offers me makes it a non-starter. Rust is smart so I can be dumb. C++ had it's chance and it just has too much cruft for not enough upside -- there's so much struggle required to modernize, to make decisions that rust has had from the beginning (because it's so new). It might be the more stable choice for a x hundred people big corporate project today or next month, but I can't imagine a future where Rust isn't the premier backend/systems language for performance critical (and even those that are not critical) programs in the next ~5 years.

I'll go even one step further and say that I think that how much rust forces you to think about ownership/borrowing and how memory is shared around your application is _important_. Just as Haskell might force you to think about types more closely/methodically (and you're often better for it), Rust's brand of pain seems instructive.

[0]: [https://www.snoyman.com/](https://www.snoyman.com/)

[1]: [https://www.yesodweb.com/](https://www.yesodweb.com/)

[2]: [https://dlang.org/](https://dlang.org/)

<comment><USER23> > When was the last time you saw a systems language that scaled comfortably > and gracefully from embedded systems to web services?

Have a look at ATS[1], it supports many features that are available in Rust, and let you build proofs about your code behaviour. It's quite type annotation heavy though iirc, but it's very efficient.

[1] : [http://www.ats-lang.org](http://www.ats-lang.org)

</comment></comment><comment><USER24> "RAII" is not "Rust"; "the bracket pattern" is not "Haskell"

<comment><USER11> This is true, but the blog post uses these two as concrete examples, so the title is still accurate.</comment></comment>


List of DL topics with resources for a quick brief, especially before interviews - <AUTHOR> https://github.com/vlgiitr/DL_Topics <comment><AUTHOR> Vision and Language Group, a deep learning group at IIT Roorkee, has made a list of topics of DL with resources which one should be familiar with, and that could come in handy before interviews for briefing up.

[https://github.com/vlgiitr/DL_Topics](https://github.com/vlgiitr/DL_Topics)

Feel free to contribute any amazing resources that have been useful for a quick prep before your interviews, and star the repo if it is helpful to you!</comment>


Steve Yegge |  Ancient Languages -- Perl  - <AUTHOR> http://steve.yegge.googlepages.com/ancient-languages-perl

<comment><USER2> This is dated and just wrong. I really don't see that he is saying anything other than Larry Wall is crazy, so don't use Perl.</comment>


Yahoo Limits Retention of Personal Data to 90 days - <AUTHOR> http://www.nytimes.com/2008/12/18/technology/internet/18yahoo.html?ref=technology <comment><USER2> The headline is misleading and this story is horribly one-sided. It is written as though Yahoo's policy is a breakthrough for privacy:

"Under the new policy, Yahoo will delete the last eight bits of the Internet Protocol, or I.P., address associated with a search query after 90 days."

This is the same trick that Google is trying to play on us. Basically, they still retain all information they use to track you indefinitely, except for 8 bits of it. With decent data-mining software you can still identify somebody pretty accurately even without those 8 bits.

Here is a better story that gives better information: <http://tech.yahoo.com/news/nm/20081217/wr_nm/us_yahoo_data>

<comment><USER3> The internal memo I got said "Anonymizing user log data". I doubt we are going to try to put it back together. You give us too much evil genius credit.

<comment><USER4> Removing the last 8 bits or, by the way, the whole IP address from the user log data DOESN'T make it anonymous.

<http://tinyurl.com/l8rfm>

 _"Yahoo will also hide cookie data related to each search log and strip out any personally identifiable information, like a name, phone number, address or Social Security number, from the query itself."_

There's much more personal information in a few month of search logs than that.

</comment></comment></comment><comment><USER5> _"I.P. addresses are digital tags that can identify a specific computer"_

That's misleading. An IP address can't always uniquely identify the client computer. For starters, people can use proxies or anonymizers.

 _"Yahoo will also ... strip out any personally identifiable information, like a name, phone number, address or Social Security number"_

Who is giving their SSN to Yahoo, and why??

<comment><USER6> Anyone who searches on a social security number to see if it has leaked online anywhere.</comment></comment>


What One Does - one startup founder's story - <AUTHOR> http://www.pixelmonkey.org/2010/10/16/what-one-does

<comment><USER2> Great post. The feeling of creating value for the world rather than for money is something I can both relate with and admire--and I'd like to believe that's the real reason engineers become engineers! Best of luck out there.

</comment><comment><USER3> Awesome post.</comment>