Stop Looking for a Technical Co-Founder, Learn to Code Yourself - <AUTHOR> http://ror.kateray.net/post/1312957018/the-internet-teaches-you-ruby-on-rails <comment><USER2> As a "non-technical" person who has had success finding "technical" people to work with, instead of trying to learn to code:

1\. Become a domain expert - know the problem you are trying to solve inside and out. Know the market size, sales cycles, etc. Make connections in the industry.

2\. Find Customers - Bring an idea, along with a 14,000 name mailing list that you generated via blogging on the subject.

3\. Bring a design - Actually mock up a set of flows for an MVP. Show it to 20 people, and iterate on their feedback. Find out what is important so when you do start building you build traction right away.

All of these are things that a good "Business Guy" should be able to do and will ultimately be responsible for when they do find a cofounder. Sure, pick up a little RoR or JS, but you aren't going to become a startup quality dev in 6-12 months (or likely more). However, in that same time you could do all of the above many times over.

<comment><USER3> I agree. For the last year I've been beating myself up because I can't code, and have tried teaching myself for years...something just doesn't click for me.

But, I have HUGE respect for devs. I honestly am amazed at the stuff my staff developer can do. At a certain point I just had to give and say, "Well, I just need to make sure I can attract good developers and treat them like the wizards that they are".

As a "non-technical" person myself, I hate when some frat-boy has a pizza/movie delivery service "idea" and is just looking for someone to build the website. Ughh. I never want to be that business guy.

I think that's why I love Hacker News. It gives me an insight into a world I really respect, and I want to understand as much as I can....without actually hacking.

<comment><USER4> Specific to you, I think you just added value to yourself even though you failed at trying to code because the act of trying to learn how to code itself made you discover that it's not as easy as it looks for just anybody, and thus make you appreciate your technical team better.

Not understanding what it takes makes it harder for non-technical people to appreciate talent. You could use your failure here as your selling point.

Of course, now non-technical "frat-boys" here are going to wave the "I tried and I failed" flag, but know that it's not hard for technical people to find out if you really tried or not.

<comment><USER3> Yes, even though I've failed to catch on each time I've tried, I keep picking up more and more of the concepts/lingo.

I do all the mockups and am orchestrating the product development, but the more I learn about programming the more I learn that a single extra box on my "mockup" can mean hours and hours on the backend.

It's so easy to do a mockup and say, "this is how it will work"...turning that into an actual application is where the magic is.

<comment><USER4> I've heard non-programming web designers say, "I've designed this app. Now all I need is to have it coded up" (as though the back-end is merely icing on cake and that the heavy lifting is already done).

disclaimer: I'm mostly a back-end person, and I appreciate how difficult it is to not have sense of design, and I don't take good design work for granted.

</comment></comment></comment></comment></comment><comment><USER5> If you have a startup idea and you don't know how to code, learning how to code enough to implement the idea all on your own is probably not cost- effective from a time standpoint and you're more likely to end up with a mess of non-functioning code than anything else.

That being said, at least to me, knowing even a layman's amount about programming will gain _major_ points with the potential technical co-founders you do meet.

I get approached by friends/acquaintances on a weekly basis with some startup idea. And I mostly think, "So basically you're suggesting I spend 10 hours a week of my free time for six months to build Facebook For Cats, while you make some half-assed attempt to do some marketing or whatever, and if there are any technical issues I can't even discuss them with you because it'll go over your head, and if there are any tedious technical issues you can't even help with those." It's pretty much a non-starter right there.

But knowing even a little bit about programming could go a long way. It means your idea is probably a little bit better than "Facebook For Cats," because maybe in programming you learned about some company's API and how to leverage it. It means I can split up work and give you some of the easier programming tasks and feel like we're putting in close to the same effort. And it means I can tell you things like, "the service doesn't always return well-formed XML so we should find a validator and then run it on the response before we insert it into the database," and you'll know what I'm talking about.

It all starts with the product, and the product usually means code, and having one and a half heads coding will usually be more productive than just one. Learn enough to be that half a head and you'll go far.

<comment><USER6> "Facebook For Cats does sound like a great idea. You should implement it, and we'll split the profits 50-50. I know lots of people who love cats, and I can really reach out to them (I own a cat myself)."

<comment><USER7> sorry, catster beat you to it!

<comment><USER8> And catbook.

</comment></comment></comment></comment><comment><USER9> Stop looking for a qualified medical professional to treat your illness, just pick up a couple of books!

Really, I don't want to discourage anyone from learning, but suggesting that you can learn enough to launch a startup is kind of like deciding that you can do web design because you've used Word. Some people will be able to pick it up in a month, and some will never learn to write decent code.

There's a reason people pay me to sit and stab buttons on a keyboard.

<comment><AUTHOR> As a qualified professional, who would you rather have a meeting with?

a.) Someone who says they have a 'killer' startup idea but no technical ability to execute it.

b.) Someone who has an idea and has already executed a working prototype of that idea for you to check out.

<comment><USER10> Are either of these individuals particularly skilled on the marketing/monetization side?

If so I would take the one that can handle that side better.

<comment><USER10> Why the downvote?

</comment></comment></comment></comment><comment><USER11> LEARN IT YOURSELF. IT'S NOT HARD.

I am a developer that hangs out in startup circles and I get approached several times a week by "idea / business people" if I'm interested in joining a venture as a technical co-founder. My answer so far has always been no.

It's very hard to convince someone that your idea is golden. Even if you do find a co-founder, it's even harder to instill your ideology and passion into them. You should be founding projects with people you know already, not strangers. You don't want an employee -- you want a missionary.

Many non-technical people seem to think that developers lack creativity and need their guidance. What gave them this illusion? The majority of great web products came from people who could write a prototype. Do that and you'll attract attention from developers who will want to join your project.

Writing a prototype is not rocket science, and if you'll try it, you'll also see that programming is very fun and rewarding. Kate Ray hits the nail on the head -- all you need is regular old hard work. I started programming when I was 12 and it's not because I'm Doogie Howser. I just wanted to learn it, so I did.

<comment><USER12> > _IT'S NOT HARD._

YES IT IS.

<comment><USER11> heh. Maybe I should reiterate, this time with only a caps :)

LEARNING to program, with the goal of building a prototype or MVP to attract interest (investors, better devs) is not hard.

Programming WELL, as in solving large technical problems, is obviously hard. But how many founders stay on as technical leads?

Not many.

I saw Dennis Crowley (of Foursquare) speak a few weeks ago. He and Naveen built the prototype and as soon as they generated some interest, they hired Harry to be the dev lead so he could "fix up their crappy code."

The code for your prototype is allowed to be crappy. It probably SHOULD.

<comment><USER12> Sure, many non-technical founders can pick up enough to put together some kind of a prototype. Some will not be able to, simply lacking the disposition. No harm trying if it does not detract from other necessary tasks.

</comment></comment></comment></comment><comment><USER13> There is a larger issue lurking here. Becoming an excellent developer isn't an over-night process. Tutorials will only hold your hand for so long before you get into the woods with concepts that are over your head (unless you have a math, systems, or compsci/engineering education); learning to _program_ and not just _code_ is a lifelong endeavor - you gotta love it for it, not just because you gotta do it to try building a startup.

The larger issue? The technical illiteracy of the general population. Knowing how to point and click (and nothing else) has brought user's expectations down to a point where they think some piece of functionality that takes them three seconds to interact with is a one hour unit of "coding" when in fact, it's more like days worth of thinking, typing, writing unit tests, and debugging.

My cofounder ATM _is_ handling all of the business, marketing, and customer interaction. She only won my allegiance though because she is _technically literate_ \- not to the point of my expertise (otherwise she would be doing it herself) but she _does_ understand that those 40 hours I just spent last week on writing unit tests is worth it instead of breathing down my neck about "let's launch it in a week, this has gotta be ready to make money once it launches, users are expecting it in a week, you just spent a whole week coding and I don't see any changes or updates...".

Kudos to KateRay for taking the reigns; I sincerely hope she/he finds as much joy in programming as I have and do. I also know that in the future, she/he will be more technically literate for a _serious_ programmer to actually be interested in working with her/him.

My only con about this post, as hinted at above, is that it makes out what we [programmers] do to be: "yay I've read the RoR book now I can program!"

<comment><USER14> *she. appreciate the kudos

</comment></comment><comment><USER15> Vin (of Yipit) has a similar blog post ([http://viniciusvacanti.com/2010/09/cant-find-a-technical- co-...](http://viniciusvacanti.com/2010/09/cant-find-a-technical-co-founder- do-it-yourself/)) but from the perspective of someone who actually just got down into it and wrote the entire site. While not uniquely a NYC problem, it was refreshing to be out in the Bay Area and not be at startup events hearing MBAs pitch "it's like Facebook, but for dogs!"

I tell everyone that asks me about finding a technical co-founder to just learn the basics of databases and a web language (PHP, Ruby + Rails, Python + Django). Either 1) you'll actually learn enough to make your MVP or 2) you'll learn enough to figure out what your product really is and what to look for in a technical co-founder. If you don't have any clue what your technology portion is going to look like, you aren't very attractive to technical co- founders and those that are interested probably aren't the best fit.

<comment><USER16> I don't live in the Bay Area, but I attended Startup School and was actually surprised by the opposite - I met many, many more non-technical people than I would have initially expected.

</comment></comment><comment><USER17> There is a good reason to find a talented technical co-founder. Just saying, "Learn to code yourself" is in some ways akin to saying, "Don't hire a lawyer, just go to law school."

Sure, a "can do" attitude is great, and coding is very learnable, however we are talking about Founders starting a business for profit here, where time is actually of the essence in many cases. A linguistic example is how one can learn survival French in a mere 3 months, but true fluency takes years.

I think it is important to realize there are people who are amazing at doing exactly the things you need done, and though you could learn to do it fairly well yourself in a short enough time, why re-invent the wheel? This holds especially true when a seasoned hacker has much more than just recently learned skills but also has a mental roadmap of pitfalls and work-arounds from their years of experience. No amount of study replaces years of "muscle memory" from projects that have both succeeded and failed.

</comment><comment><USER18> I'm nuts about user experience. I wanted to create software from a UX perspective but I didn't have a job where I could bully people around to make things for me. I also didn't have any friends who were programmers. Basically, no one was going to do it for me and I didn't have cash to hire anyone.

So, about five years ago, I learned how to program.

And the really fun thing I discovered is that I enjoy programming about as much as I enjoy creating user experience. The passions become entwined in way that's meaningful and fun.

No matter how far you take it, understanding programming is going to pay off if you want work in the software business, startup or not. You'll often be able to participate in the problem solving process alongside your technical colleagues, understand when you're being bullshitted, and maybe even prototype things to prove your arguments.

And maybe you'll think it's fun. As long as you're comfortable taking a few years to get there, this is great advice.

</comment><comment><USER19> If you have a technical company, certainly become as familiar with that technology as possible. However, recognize that it takes a lot of talent and experience to become a great developer, and if you don't have it already you are unlikely to be able to magic that up on your own just by doing a few tutorials. The best way to acquire that skillset is to buy it, with money or equity or both.

Edit: note that attaining a reasonable level of skill in technical matters will pay huge dividends, especially in hiring. There are currently no objective measures for determining developer skill. The better your technological chops are the better you will be at determining the skill of potential employees / co-founders. Making sure your startup is populated by the most skilled engineers can make all the difference between success and failure.

</comment><comment><USER20> Why look for a technical co-founder? Why not just hire somebody to do the technical work? Is it the upfront salary which is the issue?

<comment><USER21> Employees care about their companies they way teachers feel about their students, they care about their success and are generally enthusiastic but that particular interaction doesn't define them and it's possible to be just as happy somewhere else.

Founders care about their companies the way parents care about their kids.

I've seen this asymmetry cause some issues where founders don't get why their employees aren't as enveloped in the company as they are. A respectable salary and less than a percent of the stock doesn't get the same commitment as a founder does.

<comment><USER16> A more concise way of saying it might be that for founders it is _a way of life_ , for employees it is _a job_.

</comment></comment></comment><comment><USER22> I think its great when the 'non-technical' co-founder even knows their way around coding a little bit. Otherwise I find you have to explain every single thing to them and they don't have a solid grasp of the problem.

Getting to know your way around a language like Ruby isn't all that hard.

As a technical person, I run into people all day long that have 'big ideas' which are often mashups of existing sites, "Its like Facebook for FOO", and will never find a technical co-founder because they don't have any idea what the scope of the real problem is, or how to distill it down to something small, useful and graceful. Lots of ideas, but having an idea of implementation is great too.

<comment><USER16> Equally important, a technical co-founder must be able to explain complex technical issues in a way "regular people" can understand them. This is dramatically more difficult than it seems. In general, I think one of the true signs of well-rounded intelligence is being able to distill a complex idea into a readily understandable one. Think of pg, Salman Khan (Khan Academy), etc.

</comment></comment><comment><USER23> I don't want to discourage anyone, but you are practically distracting yourself from building a product by learning how to program. Getting really good at something takes many years of practice, and the program you write will likely be full of problems you are ill-equipped to fix.

<comment><USER24> I agree with this, but I think putting in the effort to learn the language or the infrastructure enough to be able to manage a contractor or distinguish between crap code and good code will not only serve you well in the tech startup world but also win you accolades from your team/peers.

I strongly believe being really good at one thing means you shouldn't try to multi-task or wear too many hats. That's counter-productive and recipe for moderate work quality. At the same time, the early days of the startup are the most fragile times. The business guy who speaks engineering or visa-versa will have a huge competitive advantage.

</comment></comment><comment><USER25> I hate to be a naysayer, but this often-expressed sentiment (by pg himself no less, if memory serves) seems somewhat absurd. Perhaps I am a slow learner, but it took me roughly 6-10 years of writing software, learning programming languages, studying CS fundamentals, learning about libraries, APIs, network protocols, character encodings, security and too many other things to enumerate until I really felt comfortable in my ability as a programmer. The first programs I ever wrote were awful; I looked at them again for the first time in years a while back and was shocked at how bad they were. Even after picking up a programming language or two and learning just enough other stuff to be dangerous, my code was still crap, albeit better crap. It wasn't until years later that I was regularly producing what I now consider to be "good code."

The spirit of this post is admirable, but rather than producing more successful startups it will likely only spur the unqualified but ambitious to create nasty spaghetti-coded PHP monstrosities with gaping security holes, which will only serve to make the public at large less trusting of web apps and startups in general. Steve Huffman was a Real Programmer when he wrote the first version Reddit; heck, he even used Common Lisp! ... and he also stored user passwords in plain text. Imagine what those with even less knowledge and skill are capable of doing.

In closing, the people here are either: a) much smarter than I am and much faster learners; b) trying to falsely give others the impression of (a); c) too optimistic; d) or don't remember how bad a programmer they were when they first started.

</comment><comment><USER26> Even if you can't fully learn to code, having a non-technical founder who understands the basics of programming is an amazing advantage.

</comment><comment><USER27> How about try to code for yourself, but learn where your strengths lie. If you hate coding, and really can't stand it with tons of navigation through way too many odd details and abstractions, just draw the line. It is a classic case of weighing the pros and cons.

Being aware of the basics is a huge advantage, but after some serious time invested, don't ignore that coding really may not be for you. It is going to take you forever to get up to speed. You may waste a lot of time and it may become a big mess. It is more beneficial to find a technical co-founder, code less, search more. You also may find that you're a born coder, and it is an extremely valuable to continue going at it, keep coding.

</comment><comment><USER28> I went to the same meetup, and also found it interesting how many questions about non-technical co-founders there were. I'll share my story about meeting my "technical co-founder".

I studied Engineering Mechanics for 6 and a half years, so I'm not exactly non-technical, but when I finished and was trying to start a company, it had been probably 6 years since I'd taken any serious programming (or taken a programming class), and I knew nothing about web technologies. When I originally met my now co-founder, he had an up-and-running website generating revenue that he had started building at 16, and developed entirely on his own, from scratch. (He stored all user data in a plaintext file until he learned about databases.)

When I first approached him about starting a company, he gave me the same line he still gives many others who ask him to join about being very busy with his own projects. So, I went home and started myself. I remember coming across a page on Wikipedia about "relational databases" and thinking "yes, this is what I'll need." So, I downloaded some MySQL software and put together some database architecture, then made some storyboards in PowerPoint, and came back to him a week later. He was a little impressed, but still said he didn't really have time to work on this.

So, I went home and bought a ROR tutorial book and built the Pragmatic Programmer Bookstore model, then changed some colors and page titles and went back a week later and met with the co-founder again. This time, a little more impressed, he agreed to help me put together a really basic MVP that I could use to pitch investors.

In the meantime, I had met with a local group of angel investors, and was accepted to pitch, at an "angel live-fire" session at an Entrepreneurship Summit in town. So, seeing as this thing was going to be presented to a group of potential investors, we both had a bit more motivation to work kinda hard on it.

Through this time, we became really good friends, and he finally became convinced that I'm not just some random non-technical person trying to start a company, that I'm really willing to do what it takes. So, a month later when we were accepted to a seed program and took investment, my co-founder deferred an internship at MS to the Fall in order to spend the summer on the startup with me, then turned it down completely when Fall came around and things were going really well. I've also learned a ton about development from him, and we've put together an MVP really fast that we're rolling out in a few days.

The point of this story is that if I had accepted his "no" and not tried to do it myself, he wouldn't have joined me, and if he hadn't joined me, we wouldn't have had a demo to show investors, and we probably wouldn't have a startup right now. So, "Learn to Code Yourself" doesn't mean just found a company yourself, it means that you do whatever you have to do to start a company, and if people see that you are that hell-bent on making progress every day, they'll be more likely to want to join you.

<comment><USER29> Great story, it really matches up with the first point in PG's latest essay, determination. I don't want to work for a "business" person doing a project on the side. I want to work with someone who has this kind of infectious energy and will get it done.

</comment></comment><comment><USER30> Jeeze, I'm doing my best here, C is hard!

I will say no single effort has been more enlightening to me regarding computer science than trying to understand C. I highly recommend it to anyone with any programming experience.

<comment><USER31> Don't tell me you're learning C first? Good luck!

<comment><USER30> After PHP and JS, which are a great introduction in my opinion.

</comment></comment></comment><comment><USER16> In the startup world, the biggest benefit to being able to do _some_ level of technical work seems to be being able to more quickly attract a truly high quality technical co-founder. If you just have an idea and promise equity, you'll have a tough time attracting top talent. If you have an an idea, promise equity, and are willing to pay a ~market salary, you might do okay - but the idea better be really great since your money will run out.

If you have a prototype/demo and some level of traction, you can much more easily attract better technical talent.

<comment><USER32> As a programmer, I would be more interested in working with a non-technical founder who has these skills:

      - domain experience
      - a good network in the target market / sales leads
      - ability to manage customer relationships and close sales
      - good communicator
      - familiarity with software development process, even if as an outsider

This set of skills would balance well with mine. I don't really care about working with highly technical founders as the second or third person at the company - that's my role. I want to work with someone who can sell and make sure that the product gets in front of customers.

The caveat here is that my interests lie in business systems, not in doing the next Facebook/Twitter/4sq clone.

</comment></comment><comment><USER33> People always bring up Jobs and Woz in these discussions. IRS a useful example, but not as an example of fate or extraordinary luck. It's a great example of one of the most common, reliable ways to find a technical cofounder. Jobs immersed himsel in his local tech scene, where he met Woz and started working on stuff with him. Rather than mythologized or fetishizes the pairing, is it so strange to think Jobs might have checked everyone out, ascertained that Woz was the best guy there, and then chose him as his guy? Sure they became friends and all, but I think it's important to realize Jobs made a deliberate choice when he started hanging out with Woz. He wasn't groaning about not being able to find a dev, he went and met them all, spotted the best guy, and started a company with him.

Jobs chose Woz. If you can't find good people and get them on board with your plan, no web app or meetup will save you. Go out. Meet people. Choose the best guy whose company you enjoy and make friends.

</comment><comment><USER34> Better than learning how to code, learn how to build your app. That is a bit different. If you learn how to code you will hit a wall once you start reading about encapsulation, recursion, trees, data structures etc (all of which I have yet to mess with).. Instead write down what your application needs to do at different levels and learn how to do each one.

</comment><comment><USER35> Just did that!

Couldn't find a co-founder so I decided to learn. Took me some weeks but now, after a few months, I'm comfortably with coding and improving where I can. Still need to improve my javascript skills.

Still lots to learn but at least I can put out a decent app in a few weeks time.

Should have done it years ago but I guess it's not too late to learn...

<comment><USER36> If you learned to program in "some weeks" you are a genius.

Just a couple of hints: don't store your users passwords, don't trust inputs from your users and enjoy yourself.

<comment><USER35> I had a CS background but didn't do any coding for about 17years so the basics were already here...

Thanks for your tips.

</comment></comment></comment><comment><USER37> I've said it before and I'll say it again. As a non-technical person trying to become technical (as an intellectual exercise as well as work on my own stuff), the simplest, yet hardest, thing to understand is "something easy" really isn't.

You think you got a minimal feature set for your project? Think again. Cut it in half.

I have a travel site as my personal project, and I still don't have the ability to select the dates for when you're traveling. Sounds crazy, but it's something that not many of my users have asked for... yet. It probably helps that the main focus isn't about selecting dates you want to travel, however.

</comment><comment><USER38> I can see though how someone would think that finding a technical co-founder through sheer charisma is an easier route than learning to code. But usually that's probably mostly ego.

</comment><comment><USER39> Stop looking for a Business Co-Founder, Learn to Sell Yourself.

</comment><comment><USER40> I think it's important to learn how to hack, if only simply to be able to fundamentally "follow along." I'm a big "idea" guy; and, most of my ideas have often been internet based. Being a lawyer, it never occurred to me to learn how to hack. This last week I started teaching myself at Google Code University. If you're halfway intelligent, it comes pretty quickly, particularly if you work through the practice problems.

</comment><comment><USER41> It seems that there's some kind of happy medium to be struck here. If you want to learn how to code, great, and it's something good to know if you want to work on a startup regardless.

Yet it's unlikely you're going to master a given language within a few months, so there may still be room to seek out someone who has had experience with it for a long time.

tl;dr Learn how to code, but there's still a time to work with longstanding hackers.

</comment><comment><USER42> Disagree 100%.

While it's true there have been people that have been good on both sides of the fence: coding and selling (Bill Gates)

Some people are just not technical people, and are not meant to code because they're just more cut out to sell, market or pitch ideas to people.

One of my good friends is a person who is comfortable socializing with clients, and is a very persuasive salesman, but he is not a coder; never was and never will be.

</comment><comment><USER43> puts 'What do you need to build your startup?' reply = gets.chomp while reply == 'a technical co-founder' puts 'learn to code yourself, bitch' end

That's kinda what I was hearing lurking around HN for the past 6 months. I've never written a line of code in my life but 3 weeks ago I stopped looking aimlessly for someone with skills, and I'm back to the drawing board learning Ruby. Of course, I'll almost surely still need a technical co-founder in 6-10 months. But I'll be in a better position to see if he's good and I'll understand what he's doing. Also, I'm meeting lots of programmers this way. If all I get out of these 2/3h per day is a great co-founder, it'll be very well worth it.

As a noob, I find the stuff suggested on the post a tad intimidating. It was good for me that my first contact with ruby was the very soft <http://tryruby.org/> and the second one was Chris Pine's book <http://pine.fm/LearnToProgram/?Chapter=00>

</comment><comment><USER44> This totally depends on the person's situation. If you have an idea and can help the project financially, you are likely better off getting a technical cofounder. But if you just have a supposedly great idea and nothing else to bring to the table, either the idea has to be unbelievably good, or you need to start learning how to code yourself.

</comment><comment><USER45> It's about empathy.

Works both ways, too. If you don't know enough finance to understand a cashflow model or enough about writing to appreciate how to craft a pitch (or put together an effective landing page - whichever matters for your business), then you aren't a founder, you're an employee with a fancy title.

This is a high bar, but foundin' ain't easy.

</comment><comment><USER46> Would you tell a techie that they can teach themselves to be a business guru for a startup? Each person has their own skills and should use those as best as they can, and work with someone complimentary to assist with the stuff they just aren't good at doing.

Simon@LabSlice

</comment><comment><USER7> I've been thinking about this for a long time too. One of the questions Im sure other people in a similar boat would ask is: which programming language?

<comment><USER40> Many of the languages can ultimately produce the same result. If you look at Google, facebook, and twitter, they all use different languages.

One that kept popping up often in my search was "Python." Consensus was that it was pretty user friendly. Plus, the guys at Dropbox built their application with it...if it's good enough for them, it's good enough for me. I say, just pick one and get started.

</comment></comment><comment><USER47> stop looking for a non-technical co-founder, learn to sell yourself ;-)

</comment><comment><USER31> Personally, I find no use in people with just ideas. Not even if they have drafted their site down to the T.

This is because I'm at an advantage. I can easily learn and do whatever it is they know and do. Things such as marketing, refining the UI, feature ideas, user interaction, etc. These are things that are MUCH easier to do and learn than programming.

I would not start a company with anyone who wasn't an EXCEPTIONAL programmer. No, a weekend programmer will not do. Honestly, you'd have either provide funds, or something of extremely high value for you to receive equal ownership of any company I spend my valuable time and work on.

The only time I would recommend you spend your time learning how to program is if your roadmap includes hiring programmers better than you to improve or redo the code. You'd have to build the prototype yourself, get funds, hire good programmers and take off from there.

Other than that, I wouldn't automatically join your project, even with a prototype.

<comment><USER48> A rewrite:

"Personally, I find no use in people with simple technical skills. Not even if they can program a time machine into a Commodore 64."

"This is because I'm at an advantage. I can easily learn or hire whatever technical skills they have. Things such as coding, databases, server architectures are trade skills and basically a commodity. These mechanical skills are MUCH easier to do or find than imagining a valuable product, finding a market and customers, selling the product, and building a business."

Etc, etc. Undervaluing the contributions of other fields such as sales or marketing is the mark of someone with little real-world battle scars, regardless of the direction of the contempt vector.

Unless this was satire, in which case Bravo.

<comment><USER31> Sorry to burst your bubble, but ideas people are generally useless.

I'm not 'undervaluing' the skill I'm simply weighing them and engineers win.

'the mark of someone with little real-world battle scars....'

The opposite is more true with engineers, we hate it when we are shown products by people without the 'battle' scars to properly gauge the value of a project.

Like I said, I can more easily learn those lessons than they can learn to program.

I, as a 'technical' person find absolutely no value on someone who doesn't understand the deep technical implications of any project. As a team we'll learn the marketing. In the end, we can outmaneuver any silly person with just ideas that delegates them.

BTW, this is my opinion. Not to say it won't work, that's just how we 'technical' people see ideas people.</comment></comment></comment>


Ask YC: what's the most technically impressive startup you remember from recent memory - <AUTHOR>

Web or client. I'm more interested in client software just because we seem to talk about web companies so much. Any takers? <comment><USER2> Like.com is pretty cool. It tries to help you shop for things based on physical similarities, they've got a neat image recognition thing going. I was surprised when I saw it actually work.

Also cool is Shazam Entertainment's music recognition software. [http://www.shazam.com/music/portal/template/pages/p/company_...](http://www.shazam.com/music/portal/template/pages/p/company_profile.html)

Apparently, if you hear something on the radio or whatever, you dial up shazam and they can tell you what it was. Magic, I tell you.

Then there's Heroku, which is kind of 'wtf amazing' to me.

<comment><USER3> like.com is strange, it really does work quite well! but I just don't know that people look to buy things that way :)

<comment><USER2> Well, I might, except that the price for many of the items is a little bit insane.

</comment></comment></comment><comment><USER4> Web - YouTube for all its hype made it ridiculously easy to convert video formats into Flash Video. No one I recall had done that before. Ask anyone if they thought they'd see videos embedded in web pages by the normal user..

Client - IntelliJ (yes, it's an IDE that I use but they hired smart, some near-wizard-level Czech/Russian programmers and did the marketing from the states - to impressive success on both ends)

Client - Portal - ok it's a cool game but shows that ground-breaking ideas can come from students [Digipen] (<http://ps3.ign.com/articles/721/721542p1.html>)

</comment><comment><USER5> Haha, sorry I'm missing the web/client question, but <http://www.memjet.com> is technically impressive to a ridiculous level.

Oh yeah, Johnny Chung Lee's future startup is also pretty technically impressive.

<comment><USER4> I agree. Some of the most technologically impressive startups are doing stuff with actual hardware (note hardware is a broad term to encompass everything from cells to robots)

"2007 Young Innovators Under 35

Since 1999, the editors of Technology Review have honored the young innovators whose inventions and research we find most exciting; today that collection is the TR35, a list of technologists and scientists, all under the age of 35. Their work--spanning medicine, computing, communications, electronics, nanotechnology, and more--is changing our world." <http://www.technologyreview.com/TR35/index.aspx>

P.S. I vote for the Roomba - bringing robotics to consumers in a safe, friendly non-Robocop kind of manner

</comment></comment><comment><USER6> PeakStream (now part of google) - <http://arstechnica.com/news.ars/post/20060918-7763.html>

<comment><USER7> I wish I could play with their technology, too bad Google is hoarding it.

</comment></comment><comment><USER8> First one that comes to mind is the Jing Project by Techsmith. Really handy way of doing screenshots and recordings. Sounds silly until you actually use it.

<http://jingproject.com/>

<comment><USER9> I also like UI, especially the simple sharing to web, but on my machine it is awfully slow (laptop 1,67 GHz / 1 GB / Vista). I don't have it running in the background, and starting it takes about 20 seconds. I guess the .NET framework is not the lightest one.

Might be a silly argument, but I love stuff like Irfanview that opens up in milliseconds and works really fast.

Jing is anyway a cool piece of software. Technically impressive? Maybe...

</comment></comment><comment><USER10> Google Maps

</comment><comment><USER11> Fon.com

Yahoo! Pipes

Wikipedia

Powerset (touted as the Google search killer)

</comment><comment><USER12> Joost</comment>


When Will Machines Exceed Human Performance? Survey of ML Researchers. - <AUTHOR> https://arxiv.org/abs/1705.08807 <comment><USER2> Why is this incongruence?

Only 20% of respondents expect "Chance of global technological progress dramatically increases after HLMI" happening 2 years after HLMI is achieved, while 80% picks the other choice, "30 years after". (Table S4)

Here is the definition of HLMI from the survey: "High-level machine intelligence (HLMI) is achieved when unaided machines can accomplish every task better and more cheaply than human workers."

It appears to me that if machines or software, which can be replicated billions of times in the span of two years, can do _every_ task better and cheaper than humans, it is akin to having 100+ times more active researchers working on R&D with much higher bandwidth of communications among them than human researchers do.

It is true that we might be limited by computer hardware availability, but given that the median time of HLMI predictions is 45 years from 2016, we are unlikely to be limited by hardware then.

Another possibility is that most predictors believe they will be limited by the speed of physical experiments, my answer is that smart simulations should allow HLMI to perform many experiments without waiting for their real-world results. A recent paper from OpenAI has shown us that learning in simulations can be effectively transferred to solving real-world tasks. ([https://blog.openai.com/robots-that-learn/](https://blog.openai.com/robots- that-learn/)) In 45 years, the quality and scope of simulations would be far better than in 2016.

<comment><USER3> It's sort of a weird definition for HLMI since it involves cost. I.e., if you can replace an engineer but leasing the hardware, power etc. costs more than the engineer's salary it doesn't count?

This is an important point, because ignoring that it could be the case that the first HLMI requires significant computational power to run - definitely to train, I'd expect, at least. So you can have a 5x human agent on some super computer but you have to build 1000 of those before you start talking about significant impact.

</comment></comment><comment><USER4> Amusingly, the median response for 'AI researcher' is almost 40 years after 'all human tasks'. I am not sure that those being surveyed shared a common understanding of what was being asked.

<comment><USER5> And also almost 40 years after 'Math researcher'. The AI researchers do seem to hold what they do in high regard...

<comment><USER6> I mean, AI research seems like it will be the last to go by definition: as long as there is anything else around to be taken over by AI then that is a justification that the AI researchers aren't done right?

<comment><USER5> But AI research goes when the AIs are capable of doing the AI research, not when every last AI question has been researched. Why will that take nearly 40 years longer than math research?

<comment><USER7> Deliberate poisoning of the training data.

<comment><USER8> That cannot be filtered out by high level mathematical logic? Imaginary. ;)

</comment></comment></comment></comment></comment></comment><comment><USER9> Experts are known to be bad predictors of the future outcome of their fields. Many times these predictions obey the Gaes-Marreau law.

In the case of AI, according to one particular study, something similar happens: expert predictions are contradictory, indistinguishable from both non-expert predictions and past failed predictions.

[https://intelligence.org/files/PredictingAI.pdf](https://intelligence.org/files/PredictingAI.pdf)

<comment><USER10> I cannot find anything on Google about the "Gaes-Marreau Law" or "gaes- marreau".

Could you please link me to something that explains it?

<comment><USER11> It's 'Maes–Garreau law'. Kelly made up a 'law' based on a few AI predictions falling into a certain range; but you can see from the linked paper (which uses like 20x more predictions) that it's not really that accurate a law and there's more that goes into AI forecasts than just +X years. (For example, China vs the West in OP, which is interesting and makes sense thinking about it, but hadn't occurred to me.)

<comment><USER9> Yes, it's not actually a law, but a (perhaps cynical) heuristic.

Possible interpretations: * People do not want to sound too optimistic but they hope to see some improvements before they die; * People hope they are dead before someone proves them wrong; * People deal with temporal magnitudes in the order of the human lifespan and close multiples.

The last one, and then the first, are my guesses.

</comment></comment></comment></comment><comment><USER12> I like this, but I feel it's a little optimistic (or pessimistic depending on your view). Isn't asking ML researchers when AI will dominate human performance a bit like asking a barber if you need a haircut?

<comment><USER13> Who would be better qualified to give an estimate?

<comment><USER14> One aspect of qualification is domain knowledge, which experts certainly have. Another aspect of qualification is calibration, which can only be proved & adjusted over time with a track record. A number of academic studies of prediction markets and other forecasting systems have shown that well- calibrated non-experts, with no skin in the game, often do better than actual experts, who often have poor track records as a result of incentives (or selection) to hype and extremize.[1]

Philip Tetlock has written on this topic for years. Two of his books are Expert Political Judgment and Superforecasting.

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

Edit: So to directly answer your question, rather than AI experts, I'd prefer technology experts (AI or otherwise) with a track record of well-calibrated predictions.

</comment></comment></comment><comment><USER15> These studies are always interesting, but I don't think they have much more scientific validity than, say, asking a bunch of religious fundamentalist preachers when the second coming of Jesus is going to be. No one knows how difficult it's going to be, and while we've overcome a lot of challenges, I'm positive there are many more to overcome before we get to human-level intelligence in computers. Whatever that means.

<comment><USER16> What would it mean for a prediction to have scientific validity? No one can know the future of course. But if you are going to try to make a prediction, surveying a bunch of experts is probably the best strategy. If nothing else, the wisdom of crowds phenomenon shows the average of a bunch of wild guesses is often surprisingly close to the correct answer.

<comment><USER15> All I mean is that these predictions have to be taken with a grain of salt. I feel like there's an inherent assumption here that the scientific and political landscape will remain unchanged and progress will continue at or exceed it's current pace. There are plenty of things that could prevent this from being true -- nuclear war, economic/political collapse, natural disaster, to name a few. I do hope they're accurate -- mainly because I think it would be cool to see human-level AI in my lifetime -- but at the same time I remain skeptical

</comment></comment></comment><comment><USER17> It's funny how surgeon is listed as the farthest out application of in the abstract. I think surgery is in fact the easiest of all the listed jobs in an AI sense, but it might depend more on advances in robotics.

</comment><comment><AUTHOR> I modified the title for accuracy. The original title misleads, slightly, IMO: "When Will AI Exceed Human Performance? Evidence from AI Experts." I swapped AI out and replaced it with ML.

The paper itself uses the acronym HLMI (high level machine intelligence). Quoting:

"High-level machine intelligence (HLMI) is achieved when unaided machines can accomplish every task better and more cheaply than human workers."

So a collection of machines could accomplish HLMI, without needing any single machine to do it alone.

<comment><USER16> I disagree with your modification. They are definitely talking about actual AI. Computers that are actually generally intelligent and can do every task humans can do.

<comment><USER18> The only bit of the book _Superintelligence_ that I liked was the historical bit at the start, where it described the problem AI researchers have: as soon as they achieve a milestone in AI, the goalposts shift and that milestone is no longer considered an AI marker.

The simplest example was "can make a human believe they're talking to another human", which was achieved with ELIZA. Before then, what ELIZA could do was "AI". After, it was "just this thing, you know"...

</comment></comment></comment><comment><USER19> I think explaining your own actions in games is a weird thing to ask for. It requires "aboutness" (that you're thinking about the problem). Aboutness is a really inefficient way to handle problems, but it's handy because we can apply it to all new situations, because we have general intelligence. Conversely, when humans have trained hard at a task, they generally lose aboutness, like an ANN. Things are done on instinct, feeling etc. In short, the NN has been trained, and general intelligence is no longer required to do the task. Indeed, it's been superseded.

More damningly for this kind of survey: Aboutness for a single task is not the same as general intelligence. And it's general intelligence that we want.

<comment><USER5> But it seems to me that general intelligence (or perhaps consciousness) is "aboutness" for your own thinking.

</comment></comment><comment><USER20> We should use deep learning to find out when

</comment><comment><USER21> I agree we're still a few orders of magnitude behind on the myriad of technologies that will enable the terminator like robots... however, the exponential progress we've been making in computer science (e.g. machine learning) is making the likelihood of discovering these critical bits very realistic.

</comment><comment><USER22> These people are not subject matter experts in these fields...

An interesting question would to have them consider the location and the IP environment. Will 10% of the public have their laundry folded by AI in the east or west first? Will it be wrapped up in patents?

</comment><comment><USER23> If you asked aerospace engineers what they thought of the future in 1960 they would've said we'd have Mars colonies and asteroid mining would've revolutionized our economies.

<comment><USER24> I'm developing a theory that America's thoughts on what technology is capable of swings wildly between two poles (possibly with every generation?): A strong luddite streak that pooh-pooh's technology, followed by a ridiculous fantasy that technology can do everything. We're firmly entrenched in cycle "B" right now; their Martian colonies is our true AI.

We think everything is just around the corner because so much has changed over the last few decades, without realizing that those changes have only come in certain areas, while the rest of the technical world is proceeding along at a much slower, more methodical pace.

I saw an ELI5 post the other day from someone on Reddit asking what air traffic controllers did, that software couldn't do better. I actually had to sit for a moment and ponder the person (almost certainly a youth, admittedly) who thinks we're already at the point on the futurism curve where the task of safely coordinating air (or any!) traffic is better done by a computer than a person. They just couldn't wrap their heads around the idea that a group of trained people, in 2017, with advanced software and visualization tools at their disposal, might be better at that than a computer acting on its own.

The example fits elegantly because I do think AR is in our future (and our present) and I'm absolutely thrilled about what it's going to bring to the world. But the idea that we're going to replace (waste) the meat computer in our heads - let alone that we _can_ \- within the next few... What, years? Decades?

Anything in that timeline seems ridiculous to me, and not because I can't imagine such an incredible and future, but because I know how the technology works, I know how far away it is from replacing (not augmenting, which again is today and I think has a rich future ahead of it) human brains and senses. Yes, automation is going to replace all our jobs, and also the sun is going to burn up someday. We need to prepare for both - arguably the former more adroitly than the latter - at a pace that makes sense both for humanity today and humanity in the future.

</comment></comment><comment><USER25> Doesn't machine performance already exceed human performance in a number of areas? As was just demonstrated this week when AI beat the world's beat Go player?

<comment><USER26> From the paper:

> Defeat the best Go players, training only on as many games as the best Go > players have played. For reference, DeepMind's AlphaGo has probably played a > hundred million games of self-play, while Lee Sedol has probably played > 50,000 games in his life.

<comment><USER27> Seems a bit unfair. Go player study games of other players too, they don't just rely on personal experience.

<comment><USER28> But it's still much less than 100 million games. If I assume that playing a Go game (or looking at a record and understanding the moves taken) takes one hour (which is a wild guess since I'm not familiar with the game), 100 million games take nearly 11408 years.

</comment></comment></comment></comment><comment><USER5> 11 or 12 years before a bipedal robot is human-equivalent in a 5K in a city? I'm skeptical, if only for reasons of power supply.

<comment><USER16> Drones can travel pretty far. And they are a lot less energy efficient than a walking robot, because they need to constantly expend energy to fight gravity.

<comment><USER5> I just realized that I was assuming battery-operated. If you make it gasoline- powered, then I can see it.

<comment><USER29> I can't imagine a more depressing future than one where the streets are filled with two-stroke terminators running errands for rich people!

</comment></comment></comment></comment><comment><USER30> we are, in general, really bad about predicting what is technologically solvable in a given timespan.

They thought machine translation would be solved in 5 years in the 60s, too. I'm vastly more skeptical.</comment>


Open Source VLC media player 2.0.0 is out - <AUTHOR> http://www.videolan.org/vlc/releases/2.0.0.html <comment><USER2> Wow. I cannot believe the pettiness of comments here. VLC is a fantastic media player, and I'm quite appalled to see the conversation here dominated by such little gripes. VLC plays media more reliably than any other program I've tried, on Windows, Linux or Mac OS X. And whether or not you consider it perfect, reaching the 2.0 milestone is something to be lauded, not bitched about.

<comment><AUTHOR> Geeks and video geeks love to tweak at the best their media players. VLC is not the best tool for that, compared to selecting your own renderer, own codec pack+configuration and own subtitles codecs. This is normal.

However, since VLC is getting too mainstream, I see more and more of hate that is unjustified. When asked why, they cannot explain why. This is a bit annoying to be honest.

Finally, VLC being Cross-Platform cannot be the best on all platforms. We do our best, but we cannot be 100% perfect, especially with so little time. We need to do a company, but what Business Model?

<comment><USER3> Don't listen to the haters. We (me, my wife, my family) are all using VLC and don't care about anything else.

It can open all media files we care until today.

It displays subtitles correctly.

It enhances the sound of some media files that would otherwise have lower volume level when played on Windows Media Player.

It is cross-platform: we use it on Mac, Windows, and Linux.

Did I tell you that people around me are happy users (regardless the UI tweak?) because it just works with minimum effort to install?

Keep the very good work.

<comment><USER4> While praising this player let me add that I absolutely love the ability for increased playback speed!

This is a great timesaver for keynotes, lectures, and shows which move too slowly ;)

<comment><USER5> This is absolutely true. Some keynote speakers just speak rather slowly, or repeat themselves and you can easily get away with 1.3x speed. Even though it sounds funny.

I really wish there would be some sort of plugin that could select an even higher speed for silent/quiet parts.

I figured "how hard could it be" (having some experience writing tiny softsynths in the past I wouldn't even mind writing a low quality pitch- preserving resample filter) but digging into it, coding a plugin for VLC is pretty arcane. At least, I couldn't figure it out without having to dig into all sorts of audio/video decoding issues I didn't really want to get in to.

If anyone has any tips it would be greatly appreciated. I cannot promise I'll manage to code that particular filter but at least I can have some fun writing crazy VLC filter effects :)

</comment></comment></comment></comment></comment><comment><USER6> Still doesn't have an option to remember playback position. Users have been asking for this on the forums for years.

Most of us use VLC to watch movies and not all of us finish them in one sitting. I hate having to find where I left off...

<comment><USER7> This is why I use SMPlayer. It has all the features of VLC and is less resource-intensive, to boot.

Edit: also displays subtitles a lot better.

<comment><AUTHOR> Display subtitles better? You did not test 2.0.0. This is exactly what was fixed in this version.

You might need to use the OpenGL output on Linux, though.

<comment><USER7> Just updated to 2.0.0 on Arch x64, and things subtitle-wise are not much better. They still look much less grainy on SMPlayer, though I may be able to mitigate that at least partially by fiddling with the settings (though ideally this wouldn't be necessary).

But trying VLC out reminded me of a few more issues:

* Activating the controls while in full-screen mode (by hitting the bottom of the screen) is temperamental

* There's a lag after unpausing the video before audio starts playing again. Not functionally relevant, but it drives me nuts.

<comment><AUTHOR> Did you try the OpenGL output?

</comment></comment></comment></comment></comment><comment><USER8> Anyone else having issues with the delay in volume control? I'm used to the volume changing instantly whenever I change it with the mouse wheel, but in 2.00 there seems to be an annoying delay of about a second for each change, at least on my PC.

<comment><USER9> This appears to be the relevant bug: <https://trac.videolan.org/vlc/ticket/5654>

<comment><USER8> Thanks for the link. It certainly looks like it.

</comment></comment></comment><comment><USER10> Does the move to LGPLv2.1+ for libVLC, libVLCcore and libcompat allow for Applidium's VLC iPhone port (<http://applidium.com/en/applications/vlc>) to be resubmitted to the App Store after some minor changes?

<comment><AUTHOR> Yes/No.

We also need to move many VLC modules to LGPL, since VLC/iOS needs static linking on this platform.

But, I am working on it. It takes a lot of time, and I am already doing much on my free time.

</comment></comment><comment><USER11> Ok, so first thing it did upon starting a movie in OSX was decide to rebuild the font cache.

Wasn't this a problem on windows that was fixed?

<comment><USER12> Same here. I also find the "Use the native fullscreen mode on OS X Lion" option terribly slow.

<comment><USER13> I can't believe this option is enabled by default, native fullscreen mode is by all accounts a bug marketed as a feature in Lion, _especially_ for a video player. It provides zero functionality over "non-native" (??) fullscreen, and actually severely degrades the experience in many situations. Namely, if you have two monitors, native fullscreen is completely broken as it:

1\. Forces you to full screen on the main monitor regardless of which monitor the window is currently in. So if you click it on your left hand monitor it jumps to your right hand monitor.

2\. Forces you to look at linen (!!!) in the other monitor. It doesn't even do the slightly less broken behavior of giving you black on the other monitor, it literally fills it up with that ridiculous linen repeated pattern so that it can optimally annoy you as you are watching the movie. Not to mention that you _should_ have the option of actually using your other monitor for actual work.

This is why I just can't use iTunes or Quicktime for watching video content anymore. Because someone literally went in and deleted working code. Quicktime used to have nice options for blacking the other screens or not, etc. and they were _taken out_. Were people demanding this feature in VLC or something?

<comment><USER14> > I can't believe this option is enabled by default

Because it's the platform default. That's how it should be.

> It provides zero functionality over "non-native" (??) fullscreen

Wrong. It puts you in another "Space".

You can argue that you like OS X's fullscreen feature, but VLC implements it just how it sould be.

<comment><AUTHOR> > Because it's the platform default. That's how it should be.

Yep, this is the exact reason. None of the developer like it much, but using the default option on a platform improve the integration.

</comment></comment></comment></comment></comment><comment><USER15> I had to go in and delete the old version of VLC (1.12) that I had installed, and also delete the old preferences before the new version would work properly for me.

The new graphical look in OSX (perhaps other systems as well, I don't know about them) has gotten some critique, but I think it looks great.

<comment><USER16> There was a script provided with the OS X .dmg (at Goodies/Delete VLC Preferences)

</comment></comment><comment><USER17> I love VLC. Just today I was playing around with the streaming feature which I had not realized was so awesome. Plus the fact that it plays anything I have asked it to. Glad to see this open source project going strong! Keep up the good work VLC devs!

</comment><comment><USER18> First off, VLC is awesome, and VLC team are heroes, imho.

I ended up having to go back to 1.11, as it ended up choking on the 1080p60 files my vidcam produces, though at first, for a minute or two, it worked better than 1.11 win32 (where i have to slow it down to 67% speed to get smooth playback).

The u.i. changes (removal of slow down and speed back, and see playback speed) threw me for a moment, but then I saw I could customize the u.i. really easily, which was great.

Can't wait til the day it can tap into my Nvidia GPU (460), but i know that's a non-trivial problem.

Anyhow, overall, congrats to the team, and I look forward to some additional upgrades so I can tap into the new features.

-a

<comment><AUTHOR> They are not removed, just hidden by default. The view menu and the customize menus are your friends.

</comment></comment><comment><USER19> I'm curious why no one ever brings up the legal status of VLC. It's an incredibly popular program, and is likely illegal in the US. Their FAQ (<http://www.videolan.org/support/faq.html>) used to make this explicit, mentioning who and where you'd have to send payment for patent royalties and that decoding DVDs is against the DMCA, whereas now any mention is relegated to the legal section (<http://www.videolan.org/legal.html>), where they encourage you to make your own judgment.

Wayback machine: [http://web.archive.org/web/20091201230711/http://www.videola...](http://web.archive.org/web/20091201230711/http://www.videolan.org/support/faq.html)

<comment><USER20> The USA is not the world. Many US software is illegal in other countries, that doesn't mean we need to keep telling everyone that (say) some software is illegal in China everytime it comes up.

</comment></comment><comment><USER21> Loving everything about this!

</comment><comment><USER22> >New video outputs for Windows 7, Android, iOS and OS/2.

OS/2 ? Why ?

<comment><USER23> Why not?

My guess, and it's just a guess, is that a few guys with old OS/2 machines thought it would be cool, so added it. Highly unlikely they devoted mainline VLC devs to it.

<comment><USER22> I just thought there's some secret OS/2 using club (outside of legacy industrial machines :))

<comment> guard-of-terra There totally are. People still use OS/2 because they think it's the best desktop OS ever created, they are tiny in numbers but are more than capable of serving themselves' needs.

<http://www.ecomstation.com/> \- they even have this.

</comment></comment></comment></comment><comment><USER21> What do they mean with "New video outputs for Windows 7, Android, iOS and OS/2." ? It's not the "android" or "ios" version they are talking about, since those are still in development, right?

<comment><AUTHOR> Android nightly build works fine. We need to finish the UI.

</comment></comment><comment><USER24> I'm still using the old 0.9.9 version because that's the last version that has the old Slow Motion = Deep Pitch sound effect when you slow down the music. I actually like my music to sound deeper when I slow it down. So I've refused to upgrade for years.

<comment><USER25> Preferences - Audio - Uncheck _Enable Time-Stretching audio_

I did need to restart VLC for that to take effect. This is VLC 1.x (whatever the latest in the Ubuntu repos is). I suspect the option is still available in VLC 2.

</comment></comment><comment><USER26> Interesting new look. I was excited about getting HTTP Live Streaming support in VLC, however, it seems to be broken for sliding playlists, which is surprising since I thought it hooks into libav* for a lot of that stuff, which does have support.

<comment><AUTHOR> VLC HLS support is not using libav, for many reasons.

Can you file a bugreport for a sample?

<comment><USER26> I'll see what I can do, unfortunately generating a sample sliding window playlist isn't the easiest thing in the world to do (I can't post the feed I'm testing it with). Looking at access logs it appears to have something to do with reloading the playlist, as the access intervals don't look like Quicktime's or an iPhone's.

</comment></comment></comment><comment><USER27> Made me think how much effort goes into the stuff so I can say "I was just watching a video on the second monitor using VLC."

Seems like version 1.1 does not pick it up for update via 'Help / Check for updates'. Dont know if its by design or a little, tiny bug.

</comment><comment><USER28> Does anybody have a link to the source? It's giving a 404 from the website right now.

<comment><AUTHOR> OOps. Just fixed it.

</comment></comment><comment><USER29> Love VLC! Good to know it is moving to LGPL, if it means we can have VLC on iOS.

</comment><comment><USER30> Any pointers to Ubuntu (10.04) packages for this version of VLC?

<comment><USER25> 10.04? No. But this PPA seems to have the up-to-date package for 11.10: <https://launchpad.net/~n-muench/+archive/vlc>

</comment></comment><comment><USER31> Windows and OS X only?

<comment><AUTHOR> Source is done and packagers for Linux are doing builds now.

</comment></comment><comment><USER32> I love VLC but my buddy swears by Media Player Classic (at least on Windows). Anybody else?

<comment><USER33> When all else fails, VLC always works. Media Player Classic (on windows) does a fair job, but breaks a lot as well. VLC doesn't break for pretty much any medium :) Love it.

</comment></comment><comment><USER34> Thank you guys. I prefer VLC on all the platforms I use. It gives me what I need for free.

</comment><comment><USER35> And I still can't use the multimedia keys on my keyboard to control it while minimized.

</comment><comment><USER36> I can't find any indication that this new release supports 3D, did I miss something?

<comment><AUTHOR> Nope, only a fork does.

</comment></comment><comment><USER37> Does it consumes more CPU than 1.12?

<comment><USER38> on my core duo, intel crap gpu, winxp it did consume much more.

      test : old, low quality 480p divx

      version     |  cpu usage  |  comm.
      vlc 2.0.0f  |  ~ 15%      | half of it being system calls.
      vlc 1.1.11  |  > 1%       | smaller than one pixel in proc.exp graph

sad since vlc was usually the lightest ( sometimes trading quality for fluidity )

<comment><AUTHOR> This is a bug then. Can you file a bugreport or mail me?

<comment><USER38> mail sent at gmail.

Sorry for not having filed anything, I'm still don't have this reflex...

</comment></comment></comment></comment><comment><USER39> How is it acceptable that SourceForge download links are HTTP and not HTTPS?

<comment><USER39> Is there a reason this comment was modded down?

<comment><USER40> I didn't vote down, but why would open source downloads need to go over HTTPS? It's very expensive to encrypt such large files for each download. Furthermore, many of the advantages can be gained by checking the MD5.

<comment><USER41> VLC is probably illegal in some countries due to the patents applying to a lot of video and audio codecs. If Sourceforge downloads were over an encrypted connection, one could avoid monitoring.

<comment><USER42> That illegality applies to the developers of VLC, not to people downloading it.

</comment></comment></comment></comment></comment><comment><USER43> On OS X: MPlayerX - On Windows: MPC and/or KMPlayer

Until VLC becomes more "native" on OS X and improves its interface, I don't think I'll be using it. In any case, I've downloaded it on my PC, so I'm keeping an open mind towards it.

<comment><USER44> MplayerX and Movist are both in Mac App Store and both are playing one upsmanship on releases since getting there. It's great for video loving users.

I normally use Plex Client (playing from Plex Media Server) but some sources crash Plex if the type of digital audio changes midstream, so I'll play that source in one of these, depending on whether I need the subtitles or am watching a whole series at once.</comment></comment>


Show HN: A New Sign-In Component for the Modern Web - <AUTHOR> https://medium.com/pwabuilder/pwa-auth-a-new-sign-in-component-for-the-modern-web-e8c0257273f0 <comment><USER2> This is the most frictionless implementation I've ever seen for OAuth sign-in, congrats for the work and thank you for the effort. Perfect for lazy folks like me. I'll definitely use it somewhere.

</comment><comment><USER3> Not everyone will have accounts with those other services. Some people will want to make the account separately, or alternatively to use OpenID.</comment>


Why can't computers program themselves? - <AUTHOR> http://www.quora.com/Why-cant-computers-program-themselves/answer/Tikhon-Jelvis?__snids__=754960619&__nsrc__=2&share=1

<comment><USER2> "Hence, computing science is —and will always be— concerned with the interplay between mechanized and human symbol manipulation, usually referred to as "computing" and "programming" respectively. An immediate benefit of this insight is that it reveals "automatic programming" as a contradiction in terms."

\- Dijkstra [http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036...](http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html)</comment>


Amazon Should Replace Local Libraries to Save Taxpayers Money - <AUTHOR> https://www.forbes.com/sites/panosmourdoukoutas/2018/07/21/amazon-should-replace-local-libraries-to-save-taxpayers-money/ <comment><USER2> Horrible article, an unbalanced piece written with many fallacies. Libraries provide lots of value for communities and that's exactly where we should not start to save money.

<comment><AUTHOR> I don't disagree, I posted it because it deserved to be widely panned.</comment></comment>


The avant-garde art of book stacking in stores of Japan - <AUTHOR> http://en.rocketnews24.com/2013/06/03/the-avant-garde-art-of-book-stacking-in-stores-of-japan/

<comment><USER2> One of the signs say "Jenga is absolutely forbidden".</comment>


The Cannons on the B-29 Bomber - <AUTHOR> http://www.popularmechanics.com/military/weapons/a18343/the-cannons-on-the-b-29-bomber-were-a-mid-century-engineering-masterpiece/ <comment><USER3> This article makes it out like gunning computers as a whole were some kind of new and revolutionary technology - while it's a feat of miniaturisation and lovely engineering, some of the earliest computers (either mechanical or electromechanical) were specifically for gunnery. Firing an artillery or naval shell 20 miles requires some pretty complex (well, if you're in a firefight - it's not that hard but it's not "oh let me think about that a moment") maths to compensate for aerodynamic effects, spin, and the Coriolis effect.

[https://en.wikipedia.org/wiki/Rangekeeper](https://en.wikipedia.org/wiki/Rangekeeper) has a decent summary of the development of this tech.

<comment><USER4> Speaking of targeting computers, one of my favorite videos on YouTube is a training film describing the theory of operation behind a purely mechanical fire control computer by the US Navy circa 1953 [https://youtu.be/s1i-dnAH9Y4](https://youtu.be/s1i-dnAH9Y4)

<comment><USER5> I love that film, but it's kind of weird that it doesn't mention what's probably the most important invention that makes this type of computer possible: The torque amplifier.

All the devices shown suffer power losses between input and output, some of them severe. A torque amplifier has two shafts that are 1:1 geared for speed but the output shaft has extra power taken from a third supply shaft, like the supply to a logic gate that lets it drive more output power than it draws from its inputs.

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

</comment></comment></comment><comment><USER6> This confirms for me a complaint I've always had about the Millennium Falcon. A ship equipped with hyperdrive would certainly have had targeting systems as good as a B-29. There would have been no need for the midships ladders to the gun stations.

<comment><USER7> But the best part of old WWII movies were the dogfighting scenes. And the movie you reference was cribbed from there. So, poetic license.

</comment></comment><comment><USER8> They're talking about M2 .50 heavy machine guns; the B-29 didn't have what are considered "cannons" (usually 20 mm or more).

For the most part, defensive guns on bombers weren't all that useful; even with a fire-control computer aiding you, it's very hard to hit a (possibly maneuvering) moving plane from another moving plane. It would probably have been better to omit those heavy guns and turrets and to leave those gunners on the ground to save weight, lives, and resources.

<comment><USER9> The guns on a bomber were never really meant for engaging aircraft. They're meant to deter fighters from ever getting near the bomber. Not many pilots are willing to sit directly in the path of machine gun fire, even if it is not very accurate. German anti-aircraft figured this out as well. They switched to shooting mostly tracer rounds. You aren't going to hit anything in the first place, so you might as well just scare the crap out of them.

There were some WWII 'gunship' style modifications of planes, but that was not that common.

For a more modern comparison, consider that the Bradley fighting vehicle carries anti tank missiles. Sending a group of Bradleys directly against tanks would be suicidal. The Bradley has aluminum for armor. A well trained set of tank crews operating even WWII vintage vehicles would decimate them. Instead, the misiles are there to deter tanks from engaging them. It also provides the crew with an enormous psychological benefit. That benefit is they at least have the benefit of being able to respond to an enemy tank with a potentially lethal weapons system. Ironically of course the TOW missiles on the Bradley destroyed more Iraqi tanks the M1 tank ever did in the Gulf war. But that is because Iraqi tank crews either had no experience or had armored vehicles in horrible condition.

<comment><USER10> Given that the Bradley was designed to fight Eastern Bloc forces on the plains of Germany (which comprises rolling terrain, closely spaced villages, streams, etc.) a vehicle that can be tucked behind cover and fire lethal anti-tank missiles isn't just decoration.

One of the most interesting cold war AFVs was an M113 chassis with a cherry picker and 15 TOW missiles on it. Armor is nice, but a hill is even nicer.

The problem is that the US army is still equipping itself superbly to fight the Eastern Bloc in 1985.

<comment><USER11> > One of the most interesting cold war AFVs was an M113 chassis with a cherry > picker and 15 TOW missiles on it. Armor is nice, but a hill is even nicer.

Is this what you're talking about? [http://russian-tanks.com/the-m901-armored- missile-vehicle.ph...](http://russian-tanks.com/the-m901-armored-missile- vehicle.php)

</comment></comment></comment></comment><comment><USER12> And Germany - and the world at large - was at the edge of ground-air missles [1], making cannons on bombers obsolete.

[1]

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

[https://en.wikipedia.org/wiki/List_of_German_guided_weapons_...](https://en.wikipedia.org/wiki/List_of_German_guided_weapons_of_World_War_II#Surface- to-air_missiles)

<comment><USER13> The "edge" as in "napkin weapons that would've never have been able to have been deployed and worked, effectively"

<comment><USER14> It was called flak and was quite effective. The Germans also deployed air to air missiles that were basically rockets with flak warheads on them. See the bomber guns had an effective range of 1000 yards or whatever so if you stood off 1200 yards in your ME-109 and launched rockets that blew up in 1200 yards that worked pretty well.

I've read a couple memoirs of WWII pilots, interesting stuff. I'm pretty sure they're all dead now, whats documented out there is all we'll ever have.

As for effectiveness, well, bomber aircraft losses were tremendous until the end of the war, yet they lost the war anyway. So its hard to say. If you can down 10% of the B-17 per bombing run against ball bearing factories, but still lose the war, was it effective or not? Or looking at the staggering economic and logistics costs of the air war, skipping the air war and focusing on shipping over tanks that don't suck might have ended the war in '44 or earlier, so maybe it was ineffective. Imagine if the winter battle of the bulge never happened because the war was already over by winter rather than lasting till spring. Or maybe no bombing would have meant more hardware would have meant the D-day invasion getting pushed back into the sea Dunkirk II style. Its an evenly balanced enough argument that academics will never lack for discussion topics.

<comment><USER15> I have a theory that even though the bombers didn't necessarily always hit what they were aiming at, the bombing campaign was important in tying up the Luftwaffe and degrading its capabilities through attrition, thereby hastening achieving air superiority, which provided a major advantage in the later ground war. I'm not sure that better tanks would have made as much difference; and, furthermore, I suspect that the US was able to absorb the costs of the air war without much difficulty, so it wasn't really siphoning resources away from things like tanks.

I'm not sure what to make of the Sherman tank. On the one hand, it was famously under-armored and under-gunned; on the other hand, it was fast, maneuverable, reliable, fuel efficient, cheap to produce, and perhaps easier to ship across the ocean than heavier German-style tanks would have been. So, in the final accounting, I'm not sure if it was really a bad tank or if its shortcomings were justified in the big picture.

I'm not any kind of WWII expert, so please fill me in on what I don't know.

<comment><USER16> The really crazy thing is just how much more massive the scale of the war on the eastern front was. Some of the Luftwaffe fighter aces racked up 100 or 200+ confirmed kills, primarily against the Soviets. Other pilots who flew close air support on the Eastern Front flew thousands of combat missions, destroying hundreds or thousands of tanks, artillery pieces, and other vehicles.

</comment></comment></comment></comment></comment><comment><USER17> That "share on pinterest" feature sure is annoying when it blocks text.

</comment><comment><USER18> Can someone please explain how the gunner/computer established the range and speed of enemy aircraft? The article says "a gunner would focus a series of dots" but unless at least two gunners are focusing the same plane I have no idea how they calculated range and speed. Thanks.

<comment><USER19> I used to be a gunner on an M1A1, and although we had laser range finders, we also practiced with the old style optical sights that were installed alongside the main gun. How range finding works with optical sites is you usually have a series of marks in the viewfinder that you use to physically measure what you're aiming at, so if the tank/plane/whatever is between particular two pips (or whatever; edit iirc the M1 had two curved lines you would placer over the target) you know that it's about x meters away. The pips are calculated knowing the average length of the object, so this is, in practice, close enough.

The procedure is; measure the target, then use cross marks on the cross hairs to raise the gun tube to the appropriate level, manually guess lead and defilade, fire, on the way. It obviously takes practice to get good at. I found it curious that the US Army continued to teach/train/use this method, as well as land navigation with compass/mapp instead of gps. The idea is to not rely on technology entirely.

Edit: turns out I am describing stadiametric rangefinding:

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

<comment><USER20> Regarding teaching land navigation by compass:

I teach light infantry tactics to new lieutenants for the US Army. There's a couple reasons to use old-school methods over relying on your GPS:

* Using a compass and a map gives you a much better feel for terrain. One of the common problems with lieutenants is a disregard for advantages and disadvantages of specific terrain. I feel that this is by far the most important point. Understanding and visualizing terrain from a map is a hugely valuable skill that impacts most points of an operation, specifically route planning, where to place your machine guns, and where to attack the objective from.

* GPS can be jammed. This point was driven home hard by the novel Ghost Fleet. Ghost Fleet is a white paper turned into a novel (because no one would read a whitepaper) on what a future war with China would look like. I'm pretty sure Ghost Fleet is also the impetus for the Naval Academy re-adding celestial navigation to their classwork.

* GPS doesn't always work, or takes a while to get enough satellites to get a fix. You know what really sucks: taking fire and not knowing where you are.

* Batteries are heavy. Yes, tech is improving and you typically only need AA batteries. But soldier weight for light infantry is and continues to be a challenge.

<comment><USER10> In the early aughts I wrote a simulation for training infantry to call in artillery strikes. It relied on compasses and maps for exactly these reasons. Another point is that understanding what the automatic tools are doing for you makes you better at understanding the automatic tools (and why they're failing when they fail).

</comment></comment></comment></comment><comment><USER21> Some more links on the electromechanical fire computers of the B-29:

[http://www.twinbeech.com/CFCsystem.htm](http://www.twinbeech.com/CFCsystem.htm) (scroll down for technical information from the user manual)

[http://www.glennsmuseum.com/bombsights/everything.html#B-29_...](http://www.glennsmuseum.com/bombsights/everything.html#B-29_Central_Fire_Control_Computer) (great pictures)

[http://web.mit.edu/STS.035/www/PDFs/Newell.pdf](http://web.mit.edu/STS.035/www/PDFs/Newell.pdf) A bonus link, review paper on WWII electromechanical fire control computers.

</comment><comment><USER22> I was quite surprised to learn recently how the B-29 was (A) about as expensive a project as the atomic bomb and (B) almost a complete failure (until the firebombing of Japan) due to no one knowing about the jet stream.

<comment><USER23> I believe there was also the prospect that if the B-29 hadn't been available the atomic bombs would have to been dropped from the British Lancaster - <USER2> was the only other bomber capable of carrying them at the time.

</comment></comment><comment><USER24> Out of curiosity (and possibly a dumb question), what is the main constraint preventing modern (subsonic) bombers from carrying CIWS-type defense system against missiles? Is it size, weight, recoil, aerodynamics, or special radar requirements? The initial push behind removing gun systems appears to have been development of AA missiles and increased reliance on fighter escorts. Yet modern CIWS on sea vessels have become so effective against missiles that they significantly upped the cost and requirements of anti-ship warfare, to the point that a single missile fired at a ship is not expected to be successful. Given advanced enough CIWS (using directed energy in near future?) one basically doesn't need stealth or other fancy/expensive/less reliable features.

<comment><USER25> I'm just guessing here, but I'm going to bet that defensive ECM is probably deemed better effective per pound that CWIS.

It's worth noting here that CWIS' effectiveness hasn't really been proven. But what is certain is that it's theoretical effectiveness is being questioned as missiles get faster. The original 20mm CWIS had a pretty limited range. The Europeans went to 30mm with Goalkeeper, and now both are set to be replaced with either directed energy weapons (faster tracking, better accuracy) or systems like SeaRAM, which can engage further by switching to point defense missiles instead of guns.

I can see how directed energy weapons could be attractive to aircraft once the power density issues are solved, but right now they're simply too heavy.

</comment></comment><comment><USER26> How did they do this without transistors? The only thing I can find is this diagram here which looks like a small box: [http://www.twinbeech.com/images/TURRETS/cfc/CFC%20computer19...](http://www.twinbeech.com/images/TURRETS/cfc/CFC%20computer197web.JPG) which is smaller than a vacuum tube. I'd assume you'd need vector calculus to calculate the path of a bullet?

<comment><USER27> The first thing to keep in mind is that these are not general purpose machines. They only do one thing, which is estimate the trajectory of a particular type of bullet, given several inputs.

This lets the designer do a lot of precalculation, so they might use a series of cams that approximate known curves or differentials some known ratio.

Useful google terms are things like "mechanical fire control computer" or "mechanical tide predictor".

Check out "Old Brass Brains" it might give you an idea of how to approach this kind of problem mechanically; or at least how sophisticated a mechanical approach can be.

</comment></comment><comment><USER28> I had no idea that fire control computers in airplanes were so sophisticated in the 1940s. Truly amazing! I don't know what I thought, but I guess I assumed that air battles back then relied primarily on line-of-sight and tracers to compensate.

It's amazing how effective automation can completely transform an activity and elevate it to a new plane of effectiveness. I'll channel Andreessen and say: technology is eating the world.

</comment><comment><USER29> Linkbait title. They built something complex, but who knows if it was good or not?

<comment><USER30> "It was a plane so advanced, we wrote in June 1945 about how one crew fought off 79 fighter planes, downing 7 of them, during a bombing run on Kyushu, Japan. Its weapons platform was so dominant that fighter escorts were no longer strictly necessary—as Major General Curtis LeMay put it simply: "These big boys can take care of themselves."

<comment><USER29> Remember that the war was basically over at that point, and they were fighting against an enemy starved of resources and experienced manpower, particularly pilots (cf. kamikaze tactics).

The "79 fighter planes" claim doesn't pass the sniff test to me either. Remember that two months after this, the Japanese didn't even bother sending fighters to even try to intercept the planes that bombed Hiroshima (for example).

I'm not saying that the claim is definitely false, but I wouldn't take anything written in the press during the actual war at face value.

<comment><USER9> I always figured the Japanese assumed the plane in the case of Hiroshima was a reconnaissance plane gathered ground photographs and checking on the weather. As you correctly noted, they didn't have many resources. I'd figure a lone reconnaissance plane would rank pretty low on the list of targets they were trying to intercept.

<comment><USER31> Even a lone bomber plane would not have been that much of a threat at this point. Bomb the weapon factories, the war is over. If they had known what was coming they would have deployed a lot more and evacuated the civilians.

We all know what happened instead.</comment></comment></comment></comment></comment>


Amazon's Hot New Item: Its Data Center - <AUTHOR> http://news.wired.com/dynamic/stories/A/AMAZON_WEB_SERVICES?SITE=WIRE&SECTION=HOME&TEMPLATE=DEFAULT&CTIME=2008-02-02-01-12-48 <comment><USER2> An interesting article, although nothing really new if you've been following AWS for a while.

The part I just don't get though is the mentality that having core systems in- house is a "liability". Yes, you do need to understand servers, load- balancers, network designs, etc to do this in-hosue. I've been bitten too many times by vendors that have their thumbs up their ass on even simple things. 12 hours to restore 100MB of data (after an email ticketing back-and-forth volley that rivaled a Wimbledon match). Servers being hastily shut-down with no notice. 90 minutes for a managed services provider to add a firewall rule to block an (admittedly juvenile) DoS/bot-gone-bad. And, I could go on.

I just seems to me that if your core business hinges on your servers being available and on-line, you should be a little less removed from that operation.</comment>


Craigslist Eyes Navel. What Will It See? - <AUTHOR> http://blog.getsatisfaction.com/2008/04/16/the-get-satisfaction-api-is-here/

<comment><USER2> wrong title?</comment>


Writing graphics software gets much easier - <AUTHOR> http://web.mit.edu/newsoffice/2012/better-programming-language-for-image-processing-0802.html <comment><USER3> Ack, while the paper looks to be legitimate (and has big names like Marc Levoy on it), the beginning of this write-up is terrible. Facebook absolutely did not buy Instagram for its filters as they are well understood technically - <USER2> bought Instagram for its exploding community. Furthermore, as of at least Instagram 2.0, filters were all heavily GPU accelerated and can be performed in real-time on the phone, i.e. massively parallel and unlikely to need any benefit that Halide might provide.

<comment><USER4> One of the original paper authors here. Some things got lost in the translation into a news piece. Here's our take on Instagram:

Instagram is only able to perform the most trivial filters expressible as point-wise operations (mostly curves and vignetting). These are easy to parallelize. If we want to go beyond that (e.g. clarity in Lightroom, which uses a more complex algorithm called Local Laplacian filters), we need to be able to write fast, complex, image processing pipelines on embedded devices more easily. Currently these sorts of things are possible on embedded (see Adobe's various offerings for iOS), but they take expert engineers a long time to write.

<comment><USER5> …and even with simple point-wise filters, Instagram had to manually code all its filters for OpenGL ES to run on the GPU to get reasonable performance. Last I heard (months before the acquisition), only one or two people at the company could write new filters, since they were the only ones with enough esoteric knowledge to build reasonable imaging pipelines in GL ES, even as simple as those pipelines were.

The point here isn't that it becomes possible to do things no one could do before, but that it becomes radically easier so:

1\. More people can build fast imaging pipelines than previously had the skills to do so. 2\. Even those who had the specialized skills can build and explore fast imaging pipelines radically more easily.

Still, this is a research language and compiler, so there are plenty of limitations and rough edges. The main point is to demonstrate and explore a potentially better way of doing things in this domain, so future languages and tools can learn from this experience. But we have found the actual tool to be quite powerful in practice, and so are making it available to the public.

</comment></comment></comment><comment><USER6> Results are impressive with "snake image segmentation" alone but OK with other algos. <http://people.csail.mit.edu/jrk/halide12/>

I didn't get how algorithms expressed in this language are faster, if it is just a 'Representation'. Is it because of its efficiency in parallelization? If so, any hand tuned assembly should be on par with it. any other thoughts?

Btw, the title "Writing graphics software..." is misleading as 'Halide' addresses only Image processing on CPU/GPU but nothing to do with 3D/2D graphics software.

<comment><USER7> I have some utility for image processing algorithms but I am no expert in the field, nor do I have any desire to become one - I just have some ideas I want to implement.

The idea that I can write my algorithms in this language and target them at the CPU initially (to keep costs down while focusing purely on photo processing), then have it running on Amazon's EC2 GPU infrastructure later with no changes when I want to (and can afford to) expand into video processing is pretty awesome.

And all of that while having the code apparently run faster than hand tuning (which I have no interest in doing) would allow. Implementing a parallalizable hand-tuned algorithm does seem like it should be faster, but even if that were true I don't have the time or expertise for attempting that.

</comment></comment><comment><USER8> The paper has sample code: [https://docs.google.com/viewer?url=http://people.csail.mit.e...](https://docs.google.com/viewer?url=http://people.csail.mit.edu/jrk/halide12/halide12.pdf)

</comment><comment><USER9> Every language I read about is dubbed the second coming, and I rarely hear about it again. Why is that?

<comment><USER10> It's very difficult for languages to "escape the lab" as it's often put. I'd say the biggest factors are:

\- Developers are often reluctant to learn new tools.

\- Project managers are reluctant to use new languages, seeing a small community as a risk.

\- Academic projects have different priorities than industry. Implementations done by academic teams often need substantial work before they meet industry needs.

This boils down to visible necessity. Without that, it's difficult for a language to reach critical mass. But the visibility part is tricky, because it's really a marketing problem, not a technical one. Sometimes organizations are blind to their own pain or even are attached to it, believing it's necessary (ORM comes to mind). Sometimes a language spreads because someone less risk adverse has very visible success, creating a pressure to copy their choice (37signals and Ruby for example).

But language research is still worthwhile even if it withers after publishing. The ideas propagate, and often end up as features/libraries in more broadly accepted languages (erlang probably inspired akka for example).</comment></comment>


Data-Oriented Design - <AUTHOR> http://www.dataorienteddesign.com/dodmain/ <comment><USER2> The table of contents is enticing. However, affirming the disclaimer noticed in the header & footer, the text would profit from attention from an editor.

</comment><comment><USER3> Is there a way I can export the entire document to a PDF?</comment>