Ask HN: Plain Text Resumes? - <AUTHOR>

What are everyone's (especially employers') thoughts on plain text resumes versus word docs or pdfs? I'm in the process of updating my resume and considering this option. I've bounced this idea off of a few people to generally negative reactions, but I can't really figure out why that should be. I know I'd rather receive resumes in plain text. I think it depends a lot on what kind of job you're applying for. But it seems to me that for programmers applying for programming work, plain text should be an accepted (or even preferred) format. Am I missing some reason this shouldn't be so? <comment><USER2> Your resume is a marketing document and you should treat it as such. Text has the advantage that it's universally supported, but it has the downside that it lacks the formatting tools that allow you to design your CV to highlight key areas.

Remember that someone reading your CV isn't going to read every word of it, they're likely to scan quickly through it looking for key points. While in Doc/PDF format you can use typographical tools to aid this (font size, line width, layout, etc.) in plain text you have far fewer options.

This of course assumes that you can put together a well designed CV, obviously a plain-text CV is going to be better than a CV written in size 20 comic-sans (I've actually seen this).

</comment><comment><USER3> I highly mislike word docs for resumes. It provides an implicit assumption that I use MS Word; which is false. I also don't much like the way they look when they're printed.

PDF is at least a fairly open standard and allows proper formatting with all (reasonable) viewers. If you do use a PDF/doc, make sure you spend a little bit of time working on the formatting of the thing. Or just download a LaTeX template..

Plaintext works fine for reading on a screen, but anything done on paper needs some semblance of typography to it.

Generally speaking I keep a copy of my resume in .tex and .txt format, with appropriate tweaks to each to make it look nice.

</comment><comment><USER4> If resumes are gathered and processed by some HR division, it's likely those people will be confused reading plain text. You can please their habits and send a word doc. The same for recruiting agencies for consultants / freelancers.

If it happens that you send resume directly to the technical person, good chances he won't care or even will be more pleased by plain text.

</comment><comment><USER5> I've sent plain text resumes for freelance gigs, and it hasn't been a problem before. Oddly enough, I've gotten more negative comments for PDF resumes than for the .txt resumes.

</comment><comment><AUTHOR> Thanks for the feedback, guys. I'm going to go with gharbad's suggestion and do plain text combined with a PDF via LaTeX.</comment>


Why We Hate Cheap Things - <AUTHOR> http://www.thebookoflife.org/why-we-hate-cheap-things/

<comment><USER2> Reminds me of what Paul Graham wrote:

> Technology should increase the gap in income, but it seems to decrease other > gaps. A hundred years ago, the rich led a different kind of life from > ordinary people. They lived in houses full of servants, wore elaborately > uncomfortable clothes, and travelled about in carriages drawn by teams of > horses which themselves required their own houses and servants. Now, thanks > to technology, the rich live more like the average person.

> Cars are a good example of why. It's possible to buy expensive, handmade > cars that cost hundreds of thousands of dollars. But there is not much > point. Companies make more money by building a large number of ordinary cars > than a small number of expensive ones. So a company making a mass-produced > car can afford to spend a lot more on its design. If you buy a custom-made > car, something will always be breaking. The only point of buying one now is > to advertise that you can.

> Or consider watches. Fifty years ago, by spending a lot of money on a watch > you could get better performance. When watches had mechanical movements, > expensive watches kept better time. Not any more. Since the invention of the > quartz movement, an ordinary Timex is more accurate than a Patek Philippe > costing hundreds of thousands of dollars. Indeed, as with expensive cars, if > you're determined to spend a lot of money on a watch, you have to put up > with some inconvenience to do it: as well as keeping worse time, mechanical > watches have to be wound.

> The only thing technology can't cheapen is brand. Which is precisely why we > hear ever more about it. Brand is the residue left as the substantive > differences between rich and poor evaporate. But what label you have on your > stuff is a much smaller matter than having it versus not having it. In 1900, > if you kept a carriage, no one asked what year or brand it was. If you had > one, you were rich. And if you weren't rich, you took the omnibus or walked. > Now even the poorest Americans drive cars, and it is only because we're so > well trained by advertising that we can even recognize the especially > expensive ones.

[http://paulgraham.com/gap.html](http://paulgraham.com/gap.html)</comment>


Sometimes you can judge a Country by its Airport - <AUTHOR> http://rodinhood.com/judge-country-airport

<comment><USER2> I hate to be "meta," but all of the articles submitted from this domain are basically just a rich guy complaining about his level of comfort and service received by those he deems to be beneath his station. I have no idea why they keep getting voted up, but I´d suspect it´s just his friends voting. The content has absolutely nothing to do with Hacker News. I think this domain should be blacklisted.

<comment><AUTHOR> Sorry to disappoint you Compay.

</comment></comment><comment><USER3> Czechoslovakia existed from 1918 until 1992. From 1993 it's either Czech Republic or Slovakia.

<comment><AUTHOR> Noted with thanks and edited.</comment></comment>


Reddit's Traffic - <AUTHOR> http://www.alexa.com/siteinfo/reddit.com#

<comment><USER2> Jailbait? I assume this is because of the controversy cause by /r/jailbait, right?</comment>


E-Ink, Largely Limited to E-Readers, Appears in a Chinese Smartphone - <AUTHOR> http://www.technologyreview.com/news/506636/e-ink-largely-limited-to-e-readers-appears-in-a-chinese-smartphone/

<comment><USER2> The first cellphone with a primary e-ink display AFAIK was, as the article mentions briefly, the Motorola F3: <http://en.wikipedia.org/wiki/Motorola_Fone> Unfortunately, it was a segmented display, which IMO limited its appeal & practicality. It was also 2006 e-ink tech, which had poorer contrast, slower refresh rate, and lower grayscale level counts than that of today. Additionally, it wasn't "available through Motorola's normal retail channels" in the US.

Really curious to see if this prototype becomes available; I'd like to see it have a chance to succeed. The better contrast levels and refresh rates have made e-ink more viable as a phone display. Unfortunately, e-ink seems to be more expensive than the color LCDs in cheap, low-end candybar cellphones, and the refresh rate and lack of color is not widely appealing. If you're after awesome battery life, it's probably easier to just get one of those and carry a spare battery or buy some sort of battery-pack case.

<comment><USER3> I purchased the Motorola F3 and still have it. Battery life is terrific. If you're used to smartphones it's a downer, but for a cheap functional mobile it's great. It is hard to find replacement batteries though, and the phone does not have US or Canadian network settings. For Europe and Asia it's great. Is color that big a deal? I'd rather have an E-Ink smartphone with great battery life than color. Or at least offer E-Ink on some models.

<comment><USER4> I also have one (that I used in the US btw). The screen was great, easily readable outdoors, the phone was great, super simple, super light. And the battery great.

The dealbreaker was the sms UI: it was absolutely horrible because of the super limited amount of characters on screen at a given time (from memory, it was around 7 or so), it was impossible to text and receive texts in a coherent way.

But for the rest, I loved it.

</comment></comment></comment><comment><USER5> On a similar note, I've been waiting to see an Android tablet, without an anemic cpu, use a high contrast, fast refresh e-ink screen. The Kindle is great, but I find myself mostly emailing articles to it from services like Instapaper/Readability/Pocket and RSS/Google Reader and Flipboard/Google Currents. It would be great if there were a powerful enough e-ink tablet to access dynamic web content directly.

I find I use my tablet and cellphone mostly for reading (articles, books, texts, emails), and the e-ink screen is much more pleasurable for me. Also, I love having a laptop, cell phone, and tablet, but I hate having to charge 3 devices at the end of every day.

<comment><USER6> I think the problem would be that e-ink would require special UIs that have no moving part, don't rely on scrolling, don't rely on colour, etc.

I think "mobile web" has taught us that. Increasingly we are finding that our toaster can run firefox and our heating system can run word but Firefox and the websites it displays weren't meant to run on a toaster.

<comment><USER5> Yes, I agree. "e-ink" optimized apps would probably have to happen for this device. (Pagination instead of scrolling, buttons instead of swiping...) However, these days some displays are getting 30fps (I don't know about latency), so at least animations might be possible. I don't know about the hardware limitations, but it seems hard to imagine the responsiveness of e-ink won't improve enough.

</comment></comment></comment><comment><USER7> Isn't e-ink one of the main reasons the Pebble [1] got $10M in funding?

There's a lot of conjecture in this article - it mentions it "may" be able to make a shatterless e-ink device, or e-ink "could be" made more responsive. Not promising.

In addition what does this gain? Apple pretty much set the standard with glass multitouch displays years ago, and I have yet to see a popular plastic touchscreen phone display recently (scratching and smears are two big problems).

It will be interesting to see what the prototype can offer (as I await my Pebble as well).

[1] [http://www.kickstarter.com/projects/597507018/pebble-e- paper...](http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch- for-iphone-and-android)

<comment><USER8> Technically the Pebble doesn't use e-ink, which is why they call it "e-paper". It's actually a type of passive LCD which uses 1-bit of memory located along- side each and every pixel in order to keep track of state, which vastly reduces the power requirements. Unlike e-ink memory lcds still require power to maintain an image, but the amount is very small (similar to an ordinary lcd watch, for example) so battery life is still quite excellent.

This is the display the Pebble uses: <http://www.sharpmemorylcd.com/1-26-inch- memory-lcd.html>

<comment><USER9> Was this cheaper than real e-ink or what?

Do you know if this is what is done for the displays on jump drives as well or are those true e-ink?

<comment><USER8> I don't know about cheaper, but certainly more available. You can just buy these memory lcd displays commercially. I think it probably takes a lot more work to procure actual e-ink displays. I believe the jump drives you're talking about do use e-ink, since they are completely unpowered when disconnected and don't contain batteries.

</comment></comment></comment></comment><comment><USER10> I would really like an e-ink monitor for reading articles and programming.

<comment><USER11> The WIMP UI really doesn't mesh with an e-Ink display, which is why you'll never see this on consumer desktops. Touch displays have changed everything though & people are more willing to experiment these days, so perhaps something could be done.

I'd love to try one out for programming. Text interfaces (emacs / vim) and a large e-ink display could be a perfect match.

<comment><USER10> I still want an LCD monitor too, but I have a 17 inch monitor for general stuff and a 22" (I think) widescreen monitor vertical for programming. It's the vertical one I'd like to replace.

<comment><USER12> You won't be able to scroll properly in an e-ink display. Either you will code page by page or it will refresh every time you try to scroll

</comment></comment></comment></comment><comment><USER13> I have been waiting for a good Pixel Qi device (in any form factor, really, although a 13" ultrabook or 7" tablet or 4" phone is ideal) to emerge for several years, as it seems a good compromise between utility and readability, although E-Ink appears much better to my eye.

As we've seen with the GS3, though, what people really want are bright and oversaturated displays for occasional media use, rather than the 99%-of-use task of monochrome reading and browsing.

<comment><USER14> > I have been waiting for a good Pixel Qi device to emerge for several years.

Same here. Though an eink display would be almost as nice and seems much easier to get ahold of. But we might not have to wait much longer... Quoting Mary Lou,

> We will be announcing at least a half-dozen new devices with our screens in > them in the next sevreal (sic) weeks.

[http://pixelqi.com/blog1/2012/10/30/another-device-with- pixe...](http://pixelqi.com/blog1/2012/10/30/another-device-with-pixel-qi- screens-starts-to-ship/)

Hopefully the new products will cost less than a grand.

</comment></comment><comment><USER15> Earlier discussion on HN: <http://news.ycombinator.org/item?id=4683083>

</comment><comment><USER16> What is vim like on an e-ink display? Especially the "animation" of cursor movement, text entry, text editing and scrolling

<comment><USER17> Vim on e-ink: <http://www.youtube.com/watch?v=FdmX52SCpG0>

</comment></comment><comment><USER6> I would love to see what apps would be produced if e-ink devices became an important platform. I really think about 80% or the apps I use could be remade for e-ink without losing much functionality.

Forced simplicity is always interesting. Kind of a "didn't have the time to write a short letter" principle.

<comment><USER18> Instead of competing head-on with Apple, Google and Microsoft in the "mobile touch" market, a much smaller player late to the market, like Ubuntu or Mozilla, should probably have tried to differentiate its OS in some strategic and major way or just stayed out of the market. (Note that even if being open- source were enough of a differentiator, which I doubt, one of the established OSes is already mostly open-source.)

Working well with e-ink would have been a good point of differentiation in the mobile market given e-ink's advantage in energy efficiency.

<comment><USER6> 300% 1st Deposit Bonus 25 Free Spins

I think there were 2 big "opportunities" to create OSs. IE times when the hardware existed & the demand existed: netbooks & "mobile." The latter wasn't really an opportunity because the company that built the hardware & generated the demand also made the software. Still it was enough of a gap that android snuck in.

Ubuntu & Mozilla had a wide open chance with Netbooks for a couple of years. There was demand. Manufacturers were keen. Vista was bombing. Users would have excepted an OS that didn't run everything as long as it had some lite browser, lite office app, Skype, media player and a few other bits and pieces optimized for the little display. You could have gotten away with not having MS office or Apple itunes, especially on the first generation Eee.

Both of those opportunities existed because of the millions of apps also know as websites that they could run before any developer even knew they existed. I don't think there will ever be an "in" that big.

e-ink phones?.. Maybe. Battery life would definitely be a selling point. Some people need phones that last longer. But it's predefined as a niche market. It wouldn't be very good on the web (try using a browser on an e-ink to see what I mean. It's cute, but that's it.) so it would need custom apps. Without apps I would love to see music players and email clients for e-ink, it'd be super futuristic. But, to get developers you need scale and excitement. Would a niche player be able to get that?

</comment></comment></comment><comment><USER19> _However, the super-thin capacitive touch e-ink display makes it incredibly light—apparently less than 100 grams_

That's a big win. If the cost is low enough I think this has a lot of potential.</comment>


Orbitz told to stop selling American Airlines tickets  - <AUTHOR> http://chicagobreakingbusiness.com/2010/12/court-orders-orbitz-to-stop-selling-americans-tickets.html <comment><USER2> I can't say I care much. I care more about the fact that Southwest doesn't show up on orbitz, meaning that if I'm flying somewhere I'll check orbitz and Southwest separately.

But American Airlines, unlike Southwest, is _very_ low on my list of preferred airlines, so I'm not going to go check their site just in case it happens to be cheaper.

Still, they know they're losing a certain amount of business, and they've taken this risk for a bigger goal.

<comment><USER3> On the other hand, I really like American, and only use the comparison sites to make sure I'm not getting _too_ bad of a deal. AA out of Chicago is almost always cheaper than everything else.

(Only time AA was too expensive was when I was flying to Singapore. ORD-NRT- SIN was $11,000, ORD-LAX-HKG-SIN on Cathay was $9000. Yes, I even do price comparisons when it's not my money. And yes, the ORD-LAX segment was on AA :)

<comment><USER2> If those are the prices then you're obviously not an economy-class flyer, so AA may indeed work out nicely for you. :)

<comment><USER3> I do fly economy when I am paying for my own travel, and I still find it acceptable. Not non-US airline acceptable, but US acceptable :)

</comment></comment></comment></comment><comment><USER4> I guess I won't be flying American Airlines anymore - I'm certainly not going to go searching through every single airline's web site individually. If they're not on the aggregator, they might as well not exist.

The only way this might work is if American stopped competing based on price and started focusing on the quality of the experience. If AA were consistently less annoying than other airlines, it might be worth looking them up individually.

<comment><USER2> Well as I understand it their long-term goal is to get back onto the aggregators, but with the aggregators getting their information direct from AA instead of a third party (fourth party, really -- it's a middleman to access the middleman) to whom AA has to pay money. This sounds like a fairly legit sort of goal.

I wish AA would stop sucking too, but it's not easy to take a huge company with sucky infrastructure and a sucky culture and make it stop sucking, especially when it's not clear that every million dollars you spend on sucking less will actually result in a million dollars of extra profit. It's usually easier just to start a new, not-sucky airline. Hello Virgin America!

<comment><USER4> So the consumer-facing aggregators are not talking to the airlines, but to an older generation of presumably travel-agent-facing aggregators? If that's what's going on then this seems like a pretty sensible move for AA in the long run.

</comment></comment></comment><comment><USER5> Two points:

One: I haven't really used the aggregators in a while (and even then it's only Kayak). I use ITA matrix to find sane flights at good prices. The only downside is that for peak travel periods their availability data can be out of date, but I think that affects all the aggregators.

Two: For all the folks who complain about airlines being dinosaurs who can't innovate, here you have an example of a legacy carrier attempting to innovate against Sabre/Amadeus/TravelPort by bypassing the middlemen and going straight to the consumer-facing aggregators. True, it's not operational improvements, but it is an example of shaking up the way airlines do business.

interesting reading: [http://en.wikipedia.org/wiki/List_of_global_distribution_sys...](http://en.wikipedia.org/wiki/List_of_global_distribution_systems#Major_systems)

</comment><comment><USER6> Bah. Since I'm platinum on American but not 100% insensitive to price, this is going to force me (and I suspect all their other frequent fliers) to switch to whatever ticket aggregator _does_ carry American.

What a pain, but due to the miles / upgrades / etc. it likely won't cost them any of their repeat customers.

<comment><USER7> why use Orbitz in the first place? It seemed very terribly done few times I searched with it. I like Expedia, even though it is not significantly better.

But this year I used Kayak, Expedia and ITA's Matrix only to search for flights. I then booked directly with the airlines.

<comment><USER2> I also tend to use orbitz to find the cheapest fare and then book with the airlines. Orbitz, expedia, kayak, they're all about the same as far as I'm concerned.

And for hotels I'm mostly using hotwire at the moment, in combination with betterbidding which has so far had 100% accuracy in predicting which hotel I'm going to get... or at least correctly predicted that I'm going to get one of two equally palatable alternatives (Airport Sheraton vs Airport Hilton? Who cares?)

<comment><USER8> After using Hipmunk and ITA Matrix, I won't go back to using Orbitz or Expedia for searching fares. They're still convenient for actually booking things, but that's it.

I've lately had to book some flights between SFO and IAD on very short notice, and with Hipmunk for searching and Orbitz for booking, I can go from deciding that I should get a plane ticket to having it ordered in 10 minutes. For more complex searches, though, ITA Matrix still beats Hipmunk.

<comment><USER2> OK, I'd never heard of hipmunk, but now I've had a look I'm pretty much converted. That's a far better interface than anything else I've seen.

<comment><USER9> \o/ Word of mouth really does work. Thanks, weel! And don't be a stranger, hugh3, drop us a note with any & all feedback (email@example.com) or say hi in Olark chat right on hipmunk.com

</comment></comment></comment></comment></comment></comment><comment><USER10> I wonder what this means for "Orbitz for Business" customers. At my university, if we need to travel for a conference, the only way to get the school to prepay for the flight is to use Orbitz for Business. Otherwise we have to pay out of pocket and get reimbursed.

And I'm sure there are companies out there that have exclusive booking arrangements with Orbitz. All of that means a loss of customers for AA.

</comment><comment><USER11> Will American still show up at <http://matrix.itasoftware.com/> ? If so, it's easy enough to go to American's site when they're substantially cheaper than another airline.</comment>


What's the difference between Fake News and Hypernormalisation? - <AUTHOR> https://axisofeasy.com/axisofeasy/quick-whats-the-difference-between-fake-news-and-hypernormalisation/ <comment><USER2> Love the Adam Curtis reference. Definitely applies to the way in which social media content moderation has evolved. Pre pandemic it was contentious. Now it is treated as if it has been the norm all along.</comment>


Creative marketing strategies for new startups - <AUTHOR> Hey,
So my co-founder and I have launched venuevortex.com 2 months ago. We're still in the early stages of marketing it and have already hit a brick wall. The elevator pitch is that we connect event planners with top quality venues and make it easy for them to communicate and book the venue online.
What we've tried: - Facebook Ad's (sending the users directly to the site) - Google Adwords. - Reaching out to planners on Meetup.com - Reaching out to PR firms (got a few write ups) - Writing blog posts and distributing them via Reddit, Twitter, Facebook, HN etc...
All of these things have gotten us a total of about 20 users. None of which have sent a venue a request yet.
We've cold-called and on-boarded 60+ top venues in Toronto and the metro areas and since we've initially launched in Ontario we've got some great venues throughout.
Any other creative ideas on how to market this product and get it to the general consumers/mainstream? <comment><USER2> From the question, it's not clear who the customer is. It mentions 1. Event Planners, 2. Top Venues, and 3. "general consumers/mainstream". Each of these has different goals and needs and probably will buy a different product if they buy a product in this space at all. So my take is that this may be less a hurdle with regard to marking marketing and more of one around product.

Because of the way money flows in the industry, it may be better to focus on meeting the needs of venues because they will collect money directly from the transaction _and_ can dictate that your service be used for bookings. Event planners on the other hand are _paid_ outside the booking transaction that you're interested in and they have venue options that are unlikely to appear in your marketplace, e.g. churches, parks, etc.

Good luck.

<comment><AUTHOR> Thanks - great feedback, I agree. I'll put it this way for clarity sake, in essence venuevortex.com is a marketplace. The supply-side are the venues and the demand side are people looking for event space for their birthday, baby shower, bridal shower, wedding, corporate retreat, board meeting etc....

Rather than targeting event planning pros, we're seeking general consumers, ultimately anyone that is looking for an event space. Think AirBNB for Event Spaces.

I'm not quite sure if it's a product issue that's causing the dis- traction/lack of use OR marketing? That's the real question/problem that we're actively seeking a solution for! If you have any additional ideas on this it would be greatly appreciated.

<comment><USER2> "Anyone that is looking for an event space" isn't a market segment. The range of professionalism from those looking to hold a baby shower to those holding corporate retreats is as broad as it gets. There's really no common set of features other than the event space.

On the other hand, event venues have common needs and will fall more neatly into a B2B relationship with your company.

That said, it's hard to see an easy value proposition for a middle layer in the transaction. What's to keep the person planning your event from researching venues on your website and then just booking directly with the venue?

AirBnB built itself as a marketplace purely by expanding the pool of overnight accommodations. Not by building a marketplace to connect travellers with hotels. It has been successful by creating a product market fit because it defined a new market.

</comment></comment></comment><comment><USER3> > What we've tried: - Facebook Ad's (sending the users directly to the site) - > Google Adwords

Did you have a professional run the Google Adwords? The most common small business advertising mistake I see companies doing Adwords themselves or use some dodgy brothers company and then announce to the world 'advertising doesn't work'. A GOOD marketer will create results distinctly better than someone simply confident in their ability to give things a go.

Also update the website. Its too generic. What are 'events'? People book conferences, birthdays, weddings. Name categories in a way that inspires/attracts the next click. Sell the sizzle, not the steak. This needs to be fixed before you spend big on advertising.

</comment><comment><USER4> You're building a marketplace so you have 2 sides of needs you have to balance out. I feel your pain as I'm also trying to build a marketplace startup as well.

What I would do is reach out to people who you believe are your target customers (i.e. event planners) and interview them. Then get feedback for your site. You may notice that depending on the event, you could have different needs for different segments. If you do, narrow your segment till you find that the needs are all the same.

You may then have to curate all your venues so that it fits with your target segment. Not all venues may be suitable for all events.

Also, have a chat with your users to understand why they haven't sent a venue request yet.

</comment><comment><USER5> Have you talked to people in person?

Why did you build this?

<comment><AUTHOR> I've spoken with several event planning pros in person, and quickly learned that they're not our target. We built this because we wanted to making finding the perfect venue for your event simple as possible, with software that is easy to use and nice to look at. The users that we're targeting are non-event planning pros - or average joes/janes who are looking for a venue for their bridal shower, baby shower, wedding etc... and would like to consider and reach out to several venues at once to find the right one for them. With venuevortex.com we are accomplishing that. Albeit, because the market is so broad it's difficult to work out a marketing strategy. Perhaps we can target each segment e.g. people who are looking for venues for their bridal shower, then wedding etc... but where do we find these people?

</comment></comment><comment><USER6> I might suggest concentrating on one city, or part of a city if it is huge and concentrate efforts.</comment>


I'll trade my two $50K cats for your $100K dog (YouTube vs Photobucket acquisition) - <AUTHOR> http://dondodge.typepad.com/the_next_big_thing/2007/05/ill_trade_my_tw.html <comment><USER2> "Acquisitions that are done as stock swaps are obviously not the same as cash transactions. Public companies often use their stock as trading currency for acquisitions since it has no cash impact on their business. However, stock transactions dilute the value of other shareholders, sometimes significantly. In a rising stock market no one really notices because the steady share price increase masks the dilution."

He's probably repeating secondhand an explanation he didn't understand the first time, because he got some of the words right but didn't make any sense. Whether you buy a company with cash, stock, bonds, favors, or anything else, the point is to get more than you pay for. AOL swapped some stock for control of Time Warner -- their stock was overpriced, TW was (arguably) underpriced, and when everything settled, AOL shareholders had lost 80% of their investment instead of 99% of their investment.

Trading $250 million in stock for $250 million worth of someone else' company isn't something you have to 'hide' with an increasing share price (and why would the price go up, if the company is blatantly devaluing itself?). Dodge didn't think this through, and it shows.</comment>


Ask HN: Who wants the .app TLD - <AUTHOR>

Me and some friends have been discussing the idea and awesomeness of having a .app TLD . After doing some ( very ) preliminary research we decided that it might be worth pursuing as a project on Kickstarter. First we thought we would ask how many others felt this way, how much you would pay and if you would contribute to a kickstarter project.
Given our early research ( read: limited knowledge ). We would love it if people could give some insight into the process of applying for and running a TLD.
We know this is a very speculative idea, but think it's well worth doing for the tech community. <comment><USER2> You need over $200K (probably more like $500K) just to apply, and then you'll need to beat the other inevitable applicants. If .app ends up being auctioned, you'd need millions.

<http://www.icann.org/en/topics/new-gtld-program.htm>

</comment><comment><USER3> This is where seeing points on comments would have been useful.

</comment><comment><USER4> I work a lot with non technical people. The only domain endings they know is .com and our country specific .de (Germany) some may know .net but often times they will try to enter .de or .com first. For many users a .com at the end is treated the sameway a www. is at the beginning. I don't think you without a .com domain you can reach a big portion of the internet.

</comment><comment><AUTHOR> Sorry if this is not how you do polls on HN I couldn't figure it out.

<comment><USER5> For future reference, you can create polls after a certain (low) karma level by going to <http://news.ycombinator.com/newpoll>

<comment><AUTHOR> I did find out in the end on the HN blog. Thanks for the info though. I will try that method next time.

</comment></comment></comment><comment><AUTHOR> Would you back a Kickstarter project

<comment><AUTHOR> No

</comment></comment><comment><USER6> Why would this be awesome?

<comment><AUTHOR> We are quickly running out of .com and other TLD's that are clearly represent what we do. Many web/mobile apps are now resorting to somenameapp.com as a way to use a TLD for their given choice of name. having a TLD means it's easier for a start. But also when running a TLD you can stipulate the rules for purchase and use. Allowing us to prevent domain hogging, and keep the space clean for applications only.

<comment><USER7> The cost of screening apps manually will make it prohibitive in cost as a TLD. It's a catch-22, speculators actually make the registries a ton of cash. They love speculators. From a registry perspective, speculation IS a business model.

</comment></comment></comment><comment><AUTHOR> How much would you pay ?

<comment><AUTHOR> $50 +</comment></comment>


Autonomous smartphone apps: self-compilation, mutation, and viral spreading - <AUTHOR> http://arxiv.org/abs/1511.00444 <comment><USER2> I'm not that impressed by this.

They talk a lot about "mesh networks" in the "Related Works" section in the introduction. Their work is in fact not related to any kind of mesh network. The words "mesh network" are a very loose collection of concepts, and are used to describe certain classes of IP routing protocols, large volunteer-run ISPs like guifi.net and Freifunk, and p2p messaging apps like Firechat. The authors do not seem to understand the distinction, and their analysis of this "related work" does not rise above the level of "wow, cool decentralized stuff".

On to the actual work being presented, it looks to me like the researchers just put an Android compiler into an Android app (Maybe this is a big accomplishment? I don't know much about Android development). In any case, it has an interface to select a few superficial options for the app, like the icon, and then it will compile a new copy.

Using NFC, the compiled app can be transferred to another phone. This has nothing to do with mesh networks in any sense of the word. They also present an analysis of compile times on various phones, which top out at 330 seconds. Useful information?

In any case, it's cool that they put a compiler in an app, but this paper feels like a massive edifice of fluff built up around a cool weekend hack. I hope that they can pass their class or get their certificate or degree or whatever they're gunning for here.

<comment><USER3> I agree with your analysis. I truly hope that people motivated to make a difference by enabling distributed resistance to censorship of centralized communications infrastructure can see the wisdom in investing time to develop the wifi mesh capability for FirefoxOS or Android. Once a major platform has this functionality, it will spread. I wrote a fairly long paper about ideas in this space over here: [https://bug945047.bugzilla.mozilla.org/attachment.cgi?id=840...](https://bug945047.bugzilla.mozilla.org/attachment.cgi?id=8407268)

<comment><USER4> I haven't read your paper yet but have you looked at Serval?

<comment><USER5> Paper author here... In our main project we implemented an onion routing stack compliant with the Tor protocol specification. Key issue is we avoid using any central server, like directory servers. It uses UDP (not TCP like Tor itself), runs on Android, fully functional, but not mature yet. See our overview talk, [http://wan.poly.edu/p2p2015/keynote.html](http://wan.poly.edu/p2p2015/keynote.html)

> The authors do not seem to understand the distinction

We are very much aware of the difference between ad-hoc and NFC transfers. Note that for dissent and anti-government protest you most likely need something else: Delay/Disruption Tolerant Networking (DTN), see these IETF pages, [http://ietf.org/dyn/wg/charter/dtn- charter](http://ietf.org/dyn/wg/charter/dtn-charter)

> I don't know much about Android development

This is quite non-trivial.

> I haven't read your paper yet but have you looked at Serval?

Yes, we are in contact with them. We invited the Serval people to one of the IETF events I organised some time ago. Sadly they are a bit underfunded. [http://www.internetsociety.org/articles/moving-toward- censor...](http://www.internetsociety.org/articles/moving-toward-censorship- free-internet)

<comment><USER2> Sorry for the harshness of my tone. There's unfortunately a lot of people draping their tech in the mantle of "mesh" without actually introducing any innovation. I had taken this as such a project mostly because I saw no mention of routing protocols. I will take a look at your main work.

</comment></comment></comment></comment></comment><comment><USER6> The github repo[0] for this was posted on HN a few days ago and garnered a bit of discussion[1].

[0] [https://github.com/Tribler/self-compile- Android](https://github.com/Tribler/self-compile-Android)

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

<comment><USER7> wrong link to the discussion

<comment><USER5> correct prior news.ycombinator link: [https://news.ycombinator.com/item?id=10517936](https://news.ycombinator.com/item?id=10517936)

</comment></comment></comment><comment><USER8> We do seem to be building in a lot of risk to our infrastructure at the moment from network connections to software delivery and introducing many single points of failure. It's good for a company that wants to control how you connect to the Internet, what you consume and to generate revenue from that but it's not great in any situation where those single points of failure...fail. We do need to consider alternative approaches which include peer delivery and mesh networking. We have the technology to do that now.

</comment><comment><USER9> Congrats on inventing skynet.

<comment><USER10> Self compiling is not self-sentient.</comment></comment>


The End of Chemical Synthesis - <AUTHOR> http://pipeline.corante.com/archives/2015/03/12/the_end_of_synthesis.php

<comment><USER2> And thus, the beginning of "automated organic chemical synthesis"?</comment>


What If I Don't Actually Like My Users? (2008) - <AUTHOR> http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html <comment><USER2> I once had to use a C API where you had to guess the size of of the buffer of data you were going to get back, and keep guessing until your number was compatible with the amount of data. So I did what any good CS person would do, and started with a small, reasonable number, then doubled it until the API was happy. Was this documented? No. Everything _but_ how you were supposed to specify the buffer size was documented. However, this code worked in production, and AFAIK, it's still running in production to this day.

<comment><USER3> Lots of win32 API calls work this way ><

<comment><USER4> Like which one? Pretty much every single one I know, you pass a buffer and a pointer to a buffer size; the first time you call with buffer NULL and the required buffer size is put in the buffer size; then you allocate the buffer and call again with the proper buffer allocated.

<comment><USER3> QueryDosDevice? You're right that mostly length is passed back, but esp in libs you get this problem you pass memory you own, some underlying function fails with "buffer too small", but buffer length was not in/out in the interface. Places where this can happen are not always obvious from reading the msdn.

</comment></comment></comment></comment><comment><USER5> Note the "Hard to Misuse" list is at [http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html](http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html)

</comment><comment><USER6> > _Here 's my favorite (now fixed) example, from the glibc snprintf man page: > _

Not fixed is that the ISO C wide character version of the function (swprintf) specifies a gratuitously different return value convention from from that of snprintf.

</comment><comment><USER7> I think git usually sits around a -6 or -7.

</comment><comment><USER8> > because I know I'm not as smart as I think I am.

They should print that into every mirror manufactured.

<comment><USER9> Reminds me of a comment included in code that I wrote a couple weeks back:

      // ... Function strcmp() returns 0 on match, therefore, !strcmp() is TRUE on match.

I deliberated with my inner voice for a minute on whether to include a comment or not. Ended up including the above thinking 18 _!strcmp()_ statements looked strangely illogical in context even after just writing it.

<comment><USER10> I always go with strcmp(...) == 0 instead of !strcmp(...).

This better reinforces my mental model of it (like many comparison functions) having 3 possible return values: <0, =0, or >0\. !strcmp(...) may be terser, but it _is_ illogical in that logical not isn't an operator. I dig using it on booleans, or "booleanish" values (null vs non-null pointers), but this conceptual tri-state isn't even "booleanish". But C didn't have a proper bool type for awhile, and C++ inherited it's baggage, so they'll compile it.

Meanwhile C# doesn't even think my "booleanish" tests are logical enough to allow to compile - no null reference tests with "operator!" for me.

</comment></comment></comment><comment><USER11> > -10. It's impossible to get right.

char * gets(char * s) ?

<comment><AUTHOR> Absolutely. Also any interface in C or POSIX specified to return a pointer to local static memory, such as "char * basename(char * path)" (and dirname), or "char * ptsname(int fd)", or "char * asctime(const struct tm * tm);".

<comment><USER12> There's also the _write_ call that succeeds as soon as it can write a single byte, regardless of the byte count passed in.

For example, [https://en.m.wikipedia.org/wiki/Write_(system_call)#POSIX_us...](https://en.m.wikipedia.org/wiki/Write_\(system_call\)#POSIX_usage) warns _" The write function returns the number of bytes successfully written into the array, which may at times be less than the specified nbytes"_

Yet, the example following it ([https://en.m.wikipedia.org/wiki/Write_(system_call)#Usage_Ex...](https://en.m.wikipedia.org/wiki/Write_\(system_call\)#Usage_Example)) doesn't handle that case or error codes such as EINTR.

I remember reading a text describing how to properly use that call, but cannot find it anymore. Faulty examples like the one above are easy to find, though. For example, [http://stackoverflow.com/questions/14417806/are-posix- read-a...](http://stackoverflow.com/questions/14417806/are-posix-read-and- write-system-calls-atomic) and [http://stackoverflow.com/questions/10650861/atomicity-of- wri...](http://stackoverflow.com/questions/10650861/atomicity-of-write2-to-a- local-filesystem) are good questions, but no answer points out that, even if write were atomic, it would not do you any good, as you may have to call it multiple times.

It probably is not that difficult, but I think it would take me a day to wrap this function in something that doesn't explode in your face, and be confident that I did it correctly, and even then, I would wake up in bed wondering whether I handled all edge cases correctly.

<comment><USER13> I can't say this is true in all cases, but I believe that fopen()/fread()/frwrite()/fclose() all cover this for you. You can get the file number for an opened FILE * block thru something like fileno() or filenum() or something.

The f _() calls all buffer for you.

The problem is that write() is entangled in the ioctl() universe in many implementations of 'C' and that gets funky fast.

_Beyond* that, reading and writing may involve making your own furniture to hide the ugly from dealing with peripherals.

<comment><AUTHOR> You can also use fdopen to get a FILE* from a file descriptor, and then use the buffering and read/write logic of the C library, rather than having to write your own write_in_full function.

</comment></comment></comment></comment></comment><comment><USER14> > -8. The compiler will warn if you get it right.

> bind() socket library call ... takes a struct sockaddr [when you are usually > using a struct sockaddr_in]

Except the compiler is correct. If you want to use a polymorphic type in a generic call that requires the parent type, you should include a cast.

From the example in my man page for bind(2):

        int main(int argc, char *argv[])
        {
            int sfd;
            struct sockaddr_un my_addr;

            /* ... */

            if (bind(sfd, (struct sockaddr *) &my_addr,
                       sizeof(struct sockaddr_un)) == -1)
                handle_error("bind");

            /* ,,, */

<comment><USER15> I don't think the complaint is that the compiler won't accept a struct sockaddr_in* where the API expects a struct sockaddr* . I think the complaint is that the API is designed in such a way that obtaining the required struct sockaddr* involves casting between incompatible types. There are more robust ways of doing type erasure, even in C.

</comment></comment><comment><USER16> > I've been coding in C for about 20 years, and about five years ago I spent > an hour chasing a case where I'd done if (strcmp(arg, "foo")) instead of if > (!strcmp(arg, "foo")).

This felt completely intuitive to me the first time I saw it: a comparison of characters can result in "less", "greater", or "equal" much like a subtraction would, and if this is expressed as an integer, < 0, > 0, and == 0 are a very sensible set of possible alternatives, and of those the only one that makes most sense as "equality" is the == 0, which is idiomatically expressed as !. I think if(strcmp(...)), if(!strcmp(...)), and ditto for memcmp() and related "3-value" comparison idioms might be one of those things that divide programmers into two groups: one that instantly sees the elegance of this design and thinks it's so natural and obvious, and one that gets eternally confused by it.

<comment><USER17> Elegantly solving the wrong problem is not elegant, though.

strcmp is a comparison. Comparisons are intuitively boolean unless there's a clear reason to be otherwise, and "false=0, true=nonzero" is well-known. Therefore, "strcmp('foo', 'foo')" shouldn't return 0 any more than "5 == 5" should return 0.

If the function were called "strsub" or "strdiff" and was described as taking the difference of two strings, then this might be an elegant solution, but "comparison" means something specific in a programming context, and this isn't it.

<comment><USER18> In an assembly context, cmp means 'set the flags as though you subtracted but don't do the subtraction'. This particular misdesign is from before C.

<comment><USER13> I blame Ben Franklin for guessing wrong about the sign of the charge of the electron.

(I keed, I keed )

</comment></comment></comment></comment><comment><USER19> I tallied about a -11 using the Youtube Player API today.</comment>


Let's get tea. - <AUTHOR> http://tea.byankit.com

<comment><AUTHOR> Just noticed the coffee thing sitting at the top of HN, and realized I never posted this. I launched this a week ago through diff networks. It's gotten 5000 hits so far, 1700 from California, and 300+ sign ups (just as shocked as you by a ~20% conversion). I've already begun getting tea with people on Friday last week, but it'd be lovely to meet you / anyone you know in the area as well.</comment>


Despite complaints of spamming, Path stands by its app's invitation process - <AUTHOR> http://news.cnet.com/8301-1023_3-57582167-93/despite-complaints-of-spamming-path-stands-by-its-apps-invitation-process/

<comment><AUTHOR> Submitting this article since Nate Johnson (President of Marketing at Path) made some...interesting quotes to CNET.

 _"This is the No. 1 piece of feedback we get from users," he said. "That's why we have this in the new-user flow."_

So that whole 100 friends thing didn't work out?</comment>


Physicists Uncover Geometric 'Theory Space' - <AUTHOR> https://www.quantamagazine.org/20170223-bootstrap-geometry-theory-space/ <comment><USER2> A really interesting read, yet for me the takeaway is still that AdS/CFT correspondence is an area full of theory, devoid of experimentation. You get these incredibly interesting and elaborate models, and sometimes it takes a depressingly long time for people to admit/realize that they're not falsifiable in any conceivable way.

It's an exciting area of research that seems to produce useful tools, but as to whether it is describing actual, physical processes? Ehh...</comment>


Common Lisp [New Site] - <AUTHOR> http://lisp-lang.org/ <comment><USER2> Just in case people don't get it, the home page is not your LCD smearing or failing, it's a slightly transparent gradient over a the city night.

</comment><comment><USER3> It's great that someone is working on bringing back Common Lisp from its deathbed.

However, even on the home page of that website, there are stuff that needs revising in order to make Common Lisp a modern language. This is subjective of course.

      (reduce #'- (reverse (list 1 2 3)))

What's that #'-? Need none of such obscure syntax.

      (mapcar #'string-downcase (list "Hello" "world!"))

WTF is mapcar? The whole car-cons terminology needs to be removed or at least banished to a 'low-level feature' status where most people don't need it, I think. Of course I'm highly influenced by Python where everything has to be written in the way I think, and not the way the computer thinks.

       (make-instance 'book :title "ANSI Common Lisp" :author "Paul Graham")

Make-instance? It's called new in C# and Java which is 3 keystrokes, and in Python and C++ it's exactly 0 keystrokes. It only gets worse with hash-tables:

       (defparameter *d* (make-hash-table))
       (setf (gethash 'a *d*) "b")

which is in Python

       d = {'a': b}

The generalness of Common Lisp means that it's a helluva lot of typing. And reading too! To get people to use it much, I think these areas need a lot of improvement.

And promoting SLIME as an IDE is not ideal either. I know it is amazing, and I use Emacs a lot, but the learning curve for Emacs itself is so steep, and it's so different from anything else currently in use, that I think this in itself is able to drive a lot of people away from Lisp. Not to mention that even though Emacs does exist for Windows, every package update or new release comes with an awful lot of new bugs that come from very few or no testing on Windows. Common Lisp needs an IDE of JetBrains quality and ease of use.

<comment><USER4>
        (reduce #'- (reverse (list 1 2 3)))

You can use:

        (reduce (function -) (reverse (list 1 2 3)))

or

        (reduce '- (reverse (list 1 2 3)))

Then

        (mapcar #'string-downcase (list "Hello" "world!"))

Use:

        (map 'list #'string-downcase (list "Hello" "world!"))

> Make-instance? It's called new in C# and Java which is 3 keystrokes,

Slightly advanced users type m - i complete.

If you want to call it 'new', then just add 'new'. Common Lisp is extensible.

        CL-USER 32 > (defclass a () ((b :initarg :b)))
        #<STANDARD-CLASS A 4020124173>

        CL-USER 33 > (setf (symbol-function 'new) #'make-instance)
        #<STANDARD-GENERIC-FUNCTION MAKE-INSTANCE 4100096004>

        CL-USER 34 > (new 'a :b 10)
        #<A 4020133143>

Hashtables, since Common Lisp is a programmable language, that syntax is user extensible. Example:

        CL-USER 42 > (defparameter *h* #{(a 5) (c 6) (b 3)})
        *H*

        CL-USER 43 > *h*
        #{(C 6) (B 3) (A 5)}</comment></comment>


Ethereum is Doomed - <AUTHOR> http://nakamotoinstitute.org/mempool/ethereum-is-doomed/#selection-7.4-7.22 <comment><USER2> I have actually tested this attack technique (using my own contracts on a local test chain), and I've been in discussions with some Solidity developers and the guy who first published the attack. The situation is not as bad as this article claims.

For starters, you can use address.send(x) instead of address.call.value(x)(). All computations on Ethereum have to be funded with "gas" (transaction fees), and send() only forwards a small amount of gas. The recipient can write to the log but that's about it. TheDAO used .value() which forwards all the available gas.

If you do use .value(), then you can do it safely by doing it only once per method, as the very last step, and only using it in top-level methods. Then any sort of reentrant callback will find any required state changes already done. E.g. subtract from the user's balance, send the funds, and if the send fails then throw. The recipient can call back but the balance is already decremented. Using a mutex is another option. I've tested all this and it works.

There are a lot of reasons Ethereum is designed this way. The most common reason for a contract to run code when receiving funds is to prevent users from accidentally losing their money. E.g. in any contract that holds ether and maintains a ledger with balances for multiple users, if anyone sends ether to the contract address, they'll lose it, unless the contract either throws an exception or automatically adds to the user's balance on its ledger.

User addresses and contract addresses are interchangeable, because it lets you do things like use a multisig timelocked vault to receive funds and anything can send to it just as if it were a regular user account.

All that said, the devs are working on improvements too.

<comment><USER3> _The situation is not as bad as this article claims._

Well it kind of is actually. The people that wrote the DAO script had the script checked by lots of Ethereum experts and the bug slipped through.

So if the Ethereum experts can't stop things like this happening then what chance do individual developers have. Basically creating a turing complete scripting language on the blockchain is not secure.

No financial institution will risk creating smart contracts on this platform.

<comment><USER4> Whenever I hear "expert" I think of [https://www.youtube.com/watch?v=BKorP55Aqvg](https://www.youtube.com/watch?v=BKorP55Aqvg)

<comment><USER5> It can actually be done.

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

</comment></comment></comment></comment><comment><USER6> The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the second system in a series. Its a pattern for failure.

In this case, Ethereum developers built a much more complicated cryptocurrency by making it Turing complete - to the extent of writing their own new computer language and virtual machine to run it.

They skipped over the halfway step of declaring parameters in the payment transactions, that open source enterprise library code, e.g. Java, could execute for for required behavior. No. They made the new code itself a user- contributed and immutable! part of the system.

<comment><USER7> That's actually a pretty good decision in my opinion. At least in this case. Think what would happen if they went for alternative solutions:

1\. If it wasn't immutable, you'd never be sure when a contract changes. That's the basic assumption about contract - once you sign it, whether in real world, or by doing some action in Ethereum, you don't expect it to change how it works. That's why immutable is good.

2\. User-contributed is just how it's supposed to work. It's decentralised. Everyone's a user. The content has to be user-contributed. Having some central publisher/gatekeeper is contrary to the whole idea.

3\. Own VM is debatable. Sure, they could go with JVM, but the scope would have to include much more complexity (classes, namespaces, etc.) than just function/instruction execution. Maybe the limits of javacard would be enough, maybe not.

I really don't think the second system effect applies here. It's not a rewrite of something that existed and had issues.

<comment><USER8> Solidity contracts are already modules which contain functions. They're equivalent to Java classes with static methods or Scala objects. As for namespacing, I don't know how in this day and age programmers can say that's not worth it.

<comment><USER7> Solidity contracts do contain functions and some state. But that's at a fairly different level than Java's classes. Internals are not exported. The contract's structs belong to contracts. There's no need for namespaces within code because addresses provides namespacing already - all your code is normally visible to you already and you'll not get unexpected names shadowing anything in your code.

I'm not saying namespacing is bad, just that namespacing as defined in Java is likely not necessary in ethereum world, as I understand it. It would likely just confuse what's immutable vs what's referenced by name.

</comment></comment></comment></comment><comment><USER9> > Solidity is like programming in JavaScript, except with your bank account > accessible through the Document Object Model.

Such a beautiful, terrifying sentence.

<comment><USER10> This is a very snarky hyperbole. Solidity has as much to do with Javascript as Java does.

For starters, Solidity is a compiled, typed language.

It is still new and has to be improved.

<comment><USER11> > Solidity is a compiled, typed language.

The same language can be both compiled and interpreted, this doesn't affect the semantics of the language. For example, OCaml ships with both a compiler and an interpreter. There exist AOT compilers for JavaScript too.

Also, JavaSript is a typed language. It is just dynamically typed and does too much type coercion.

<comment><USER10> Thanks for the clarification. So, Solidity is a compile-only, strongly typed language? While Javascript is usually interpreted (or JIT compiled) and dynamically typed.

</comment></comment></comment></comment><comment><USER12> Having a little bit of trouble parsing how the attack worked -- so when a transfer happens, the destination account gets to run a command; they then ran a command that called the source's send-ether command, which ran because it was still in 'we owe destination account money' mode because the full initial contract had not concluded?

Then at some point it terminates itself before emptying the source account (and thereby causing a rollback that would cascade back?)

<comment><USER13> My understanding is that it looks essentially like this:

        send(theEther, childDao)
        deduct(theEther, tokenHolder)

But that you can get it to overflow the stack in between the two so that the send completes but the deduction no longer happens.

<comment><USER2> If you overflow the stack it throws and rolls back (which is another attack in certain circumstances). What killed TheDAO is basically that childDao called back the sender method, which sends again without having deducted yet.

Do the deduct before the send, and the whole problem goes away.

<comment><USER14> Right, but would the deduction commit even if the send fails? Isn't this the whole concurrency 101 "Atomic deduct and send" problem?

<comment><USER2> It's not really concurrent, the VM runs one transaction at a time.

The send returns false if it fails. So if you check for that, you can throw an exception, which rolls back the whole transaction just like in SQL.

The reason the send doesn't automatically throw is that if you were doing lots of sends in a loop, you'd actually want to ignore the exception, so if one send fails it doesn't block everybody.

<comment><USER14> >if you were doing lots of sends in a loop, you'd actually want to ignore the exception, so if one send fails it doesn't block everybody.

This sounds like the wrong default behaviour. If we're talking about sending money, and there's a list of people to send money to, I would say that the default behaviour should be to throw an exception, because if not you could end up having money not be properly redistributed.

For example, a simple smart contract to share costs. If one member not longer participates then shouldn't their cut be given to the remaining participants?

The fact that it doesn't roll back everything by default concerns me quite a bit...

<comment><USER2> You can accomplish that by checking the return value. But Solidity doesn't have try/catch, it just rolls back everything upon throw. If send() were to actually throw upon failure, then it would roll back the entire method call and nobody gets paid. A troublemaker could use an account that always throws when it receives funds, and permanently block all payouts for everybody (unless a contract admin has a way to kill accounts).

The best pattern is not to put sends in a loop at all. Just update a ledger inside the contract, and have each user call a withdraw() function to get their money. That way if you're careful you can even use call.value, so users can include as much gas as required, and can withdraw the money directly into any sort of contract they like.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Ethereum isn't doomed. I don't think it will ever have as much backing as Bitcoin because of institutional buy-in; but the world needs programmable smart contracts. Some rich soon-to-be-dead billionaire tech nerds want to be able to do something every year without worrying about a judge taking that away from them. Individual will is what cryptocurrencies are about. Bitcoin in terms of international payments and store-of-value; and Ethereum in terms of contracts and computing.

<comment><USER7> I think you're thinking of use cases that would definitely be stopped outside of ethereum world:

> Some rich soon-to-be-dead billionaire tech nerds want to be able to do > something every year without worrying about a judge taking that away from > them.

You can do things like this, but the law either already covers this, or will adjust. If you gain money, you're expected to pay the usual tax on that gain. First few may get away with it, but once it becomes popular, audits will start.

> Individual will is what cryptocurrencies are about.

Same as above - inheritance tax.

Essentially it's this xkcd situation: [https://xkcd.com/1494/](https://xkcd.com/1494/) Just with wealth gain and tax office instead.

<comment><USER16> The point of Ethereum is to provide something that is different from the real world. If not, it is simply fiat, except that it is 1000 times more inefficient and burns up loads of electricity.

<comment><USER7> It has to affect the real world at some point. If it doesn't, what's the point?

</comment></comment></comment></comment><comment><USER17> The problem with Turing completeness is that if it's not there from the start, people inevitably end up needing features that aren't present in the restricted language, and then a Turing complete language is added to either the original system or a successor, and being an afterthought it usually ends up being a hack job.

Examples: SQL was supplemented with procedural languages for stored procedures, Excel was supplemented with VBA, HTML was supplemented with JavaScript and, well, Bitcoin was supplemented with Ethereum.

So providing a Turing complete language was the right decision as far as it goes, but it's not enough by itself. If you need reliability - which this does - it needs to be the case that typical code does _not_ involves arbitrarily complex computation. Typical code needs to fit stereotyped patterns whose behavior is predictable.

If Ethereum is to continue, it's clear that exhorting people to try even harder not to make mistakes in the current version of Solidity, won't cut it. The language needs to be supplemented or replaced with something that makes it easy to write correct code for the kind of things people typically want to do.

<comment><USER18> There are languages which are both expressive and Turing incomplete, for example Coq. In the Coq language, Turing incompleteness is actually needed to be able to make complete proofs. Maybe Solidity would have been better implemented within Coq, but it's too late now.

<comment><USER17> Is it too late now? It seems to me that it should be possible to implement a better language on top of the existing system, there are plenty of languages that compile to JavaScript after all, so it's still worth discussing what a better language might look like.

You say Coq is expressive; okay, but in what sense, for what purposes? A language which isn't Turing complete - or even one which is - isn't going to be expressive for all purposes. As I understand it, Coq is designed to be expressive for the kind of things people doing research in type theory want to write, in the same way SQL is designed to be expressive for database queries.

What sort of things do smart contracts typically want to say? Are they more similar to type theory research, database queries or something else?

One possible answer is that it's too early to say yet, in which case perhaps extensibility is an important attribute. For example, suppose Racket were used as a language for writing smart contracts, with a backend to generate Ethereum byte code. Being a dialect of Lisp, Racket is highly extensible. It also has an optional type system. Do smart contracts tend to be prone to the kind of errors that are caught by a type system? If so, it would be worth using one.

<comment><USER19> Note that Solidity is not JavaScript, it's just superficially similar in some ways. The comparison with JavaScript is for marketing pretty much.

In particular, Solidity is statically typed.

I would say that smart contracts are a lot like event processors that update bits of contract-local state and enforce preconditions. They are run in a single "thread" in blockchain order, but they can also invoke each other reentrantly (and that's the major source of confusion so far, so it should be limited and made very explicit).

Some contracts perform more complex calculations, e.g. I know of one that calculates compound interest using fixed point math.

There might be room for several different simpler languages for different purposes... It would make sense to use the most restricted language that can express the contract you want.

<comment><USER17> From what I've seen of the discussion on this, you're right about uncontrolled reentrancy being a big source of problems.

One thing that occurs to me: would the command-query distinction be a useful notion here? I have no truck with it in the general context in which it was coined, but in this context maybe it would be useful to draw a hard line distinction between 'I call you to ask for information' and 'I call you to ask for money'.

<comment><USER19> Solidity contracts can define "const" functions which aren't allowed to change state.

For some uses you can also look at the events that a contract emits, which are indexed and searchable off-chain... so client apps can read them, but not contracts themselves.

<comment><USER17> Okay, so const was available as a feature - but not used because it wasn't the default? Some of the discussion on this seems to be saying Solidity supports exceptions and transactions, which should provide a lot of safety here (on error, an exception should be thrown and everything the script just did should be rewound) but the documentation was still exhorting programmers to check return values all over the place. Is this at least in part a matter of bad defaults? I'd be quite prepared to believe so; bad defaults are a much bigger problem than they are sometimes thought to be.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> People (rightly) make the same critique of Bitcoin: it is very easy for regular people to lose their money. To keep it safe you need to be a security expert, and even then there are no guarantees, and mistakes are forever.

My response is the same for both Bitcoin and Ethereum:

Even if these technologies are only used by trained professionals, they can still be revolutionary. Almost no one can safely operate a printing press, and yet that invention has toppled empires.

At worst, these are back office technologies. At best in a decade or two someone will figure out how to design a good enough GUI that a novice can safely explore a powerful subset the technology, trusting that bumpers are in place around the sharp edges.

<comment><USER21> People at large are not supposed to put money in printing presses they can't use properly, they are supposed to put money in books made by those printing presses.

Ethereum is definitively unsafe, it's basically impossible to create code without any bugs, and it's impossible to prove a piece of code doesn't have any bug. That defeats the all purpose of Euthereum.

Bitcoin is just unsafe by nature for the user, although the protocol itself is most probably safe.

</comment></comment><comment><USER22> Here's a better explanation of the attack: [http://vessenes.com/more-ethereum- attacks-race-to-empty-is-t...](http://vessenes.com/more-ethereum-attacks-race- to-empty-is-the-real-deal/)

Ethereum is not doomed. But devs do need to be educated of this attack.

<comment><USER23> It is doomed, who would trust a contract now with real "money"? Unless you have a mathematically rigorous proof that the contract is trustworthy I sure wouldn't.

<comment><USER22> Hopefully no on ever trusts a contract with 100 mill for a while, but for lower values and simpler contracts... absolutely i would.

<comment><USER24> Sorry, but this is bullshit. You sound like Ethereum or SlockIt employee. No one in their sane mind would trust their money a company which can't guarantee security of your funds, let alone good coding practice (the DAO code is shit, sorry -- there are no tests, no comments, no spec, no clear upgrade story etc.). Good attempt, and I can feel for Ethereum folks, but something this important should be rock solid, not "experiment" when you're fucking with people's money. This is not a hacker's playground.

<comment><USER25> "This is not a hacker's playground."

It could have been if they followed bitcoins path and started with 10000btc pizza orders :) Greed take over too soon to realize the flaws.

</comment></comment></comment></comment></comment><comment><USER26> "I thought again about my early plan of a new language or writing-system of reason, which could serve as a communication tool for all different nations... If we had such an universal tool, we could discuss the problems of the metaphysical or the questions of ethics in the same way as the problems and questions of mathematics or geometry. That was my aim: Every misunderstanding should be nothing more than a miscalculation (...), easily corrected by the grammatical laws of that new language. Thus, in the case of a controversial discussion, two philosophers could sit down at a table and just calculating, like two mathematicians, they could say, 'Let us check it up ...'" \--Gottfried Wilhelm Leibniz

</comment><comment><USER27> I didn't know the language was turing complete. Isn't this computing 101? If you want a secure thing then you must be able to reason about it statically. Making things turing complete means any non-trivial property of program correctness can not have a generic solution and so you've just opened yourself up to a world of hurt.

<comment><USER22> The whole point of Ethereum is turing completeness. Ethereum without Turing completeness already exists and its called Bitcoin.

While this implementation of The Dao has failed, Ethereum is the only blockchain where implementing The Dao is possible.

<comment><USER27> This doesn't sound right to me. Contract law should not require turing completeness. First order logic should be more than sufficient. How does having a loop in contract law make any sense?

<comment><USER28> There are also a class of total languages (Coq, Agda, Idris) that are guaranteed to terminate but admit (polymorphic) recursion. This is stronger than FOL but weaker than turing-completeness, and certainly sufficient to implement any feasible contract.

<comment><USER27> I agree. I said first-order logic because I think it is more accessible. Coq, Agda, Idris, etc. employ I think some pretty sophisticated type theory and that would all have to be packaged up in a way that is accessible to an average programmer.

<comment><USER28> > in a way that is accessible to an average programmer.

The average programmer should not be writing multi-million-dollar contracts.

<comment><USER27> I don't think accessibility is a bad thing. I think computing, its practice and theory, should be taught the same way we teach literacy. I didn't mean "average" as in "incompetent". If writing contracts was as simple as writing a few lines of code in some formal language that didn't require a law or finance degree then I would consider that to be a good thing. It would be even better if the system was designed from first principles with solid theory backing it.

<comment><USER28> I totally agree, but the reality is that in order to write contracts that are sure to be correct, you need a level of expertise that involves much more work than just learning how to write programs. Knowing the syntax and usage of a rigorously-typed language like Agda is the easy part.

<comment><USER25> Then the platform is flawed. Average programmers should be able to understand it easily.

It's not that hard, some wants X and some wants Y in exchange.

I'm not a lawyer but I write contracts with my clients. If you keep things simple it should fit most people. making g smart contracts complicated you keep it in the area of a small elite who are knowledgeable of playing safe with it.

I wold go as far as make it as simple as HTML.

<comment><USER28> That's what standardized contracts are for. Tellers don't write the legalese on your credit card receipt. They just print it out.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> I'm getting a strong Accelerando deja-vu here.

(ref: [http://www.antipope.org/charlie/blog- static/fiction/accelera...](http://www.antipope.org/charlie/blog- static/fiction/accelerando/accelerando-intro.html) )

</comment><comment><USER30> As expected, "Ethereum is turing-complete" turned out to be just a marketing meme (or a horrible idea at best), just like "Litecoin is silver", "Doge is community", and all the others.

</comment><comment><USER31> I love that Smart Contracts act basically as bug bounties to make the Ethereum systems, community knowledge, and open contracts improve dramatically.

<comment><USER32> I love how law and court systems are basically bug bounties on legal systems, community knowledge, and social constructs. Society will inevitably improve dramatically.

Oh wait, no. We just turned programmers into politicians and lawyers. I think more people will be pissed when they find out that "trust in the system" ultimately means "trust the writer of the smart contract".

Unlike law, which has admitted that insane things happen and provides "emergency stops" (ie: Supreme Court can say whatever the heck they want and provide a check against any of Congress's laws)... there isn't really a way to add human "emergency stops" to the equation of Ethereum.

<comment><USER31> I hear your sentiment. But not your argument as much. Politicians and Lawyers are inherently > smart contract writers?

'I think more people will be pissed when they find out that "trust in the system" ultimately means "trust the writer of the smart contract".' How is this different than not trusting Lawyers?

'Unlike law, which has admitted that insane things happen and provides "emergency stops" (ie: Supreme Court can say whatever the heck they want and provide a check against any of Congress's laws)... there isn't really a way to add human "emergency stops" to the equation of Ethereum.' Agreed on using Ethereum contracts anytime in the near future (or ever) for anything life or death or over exposing your self financially is insane. There are plenty of cases that are a better fit for a smart contract system. People should invest affordable proportions of their money.

</comment></comment></comment><comment><USER33> Could the person who got the DAO's ETH create a contract to pay out miners who vote against a hard fork with the "stolen" ETH?

<comment><USER34> Probably quite difficult in practice, unless he/she could somehow convince a mining pool or something.

Another option would be to set up mining hardware in a place like China with low cost electricity. However, this would take time, money and serious effort - if you cash out ether to fund it, you likely crash the price, and if you succeed in fighting the hard fork, the split in the community would likely destroy the trust in Ethereum and your funds go poof.

</comment></comment><comment><USER35> What if they had used a language without the possibility of recursion and without loops? I'm being serious. Languages that disallow certain types of recursion, and disallow loops exist. You'd think they would've used something that actually allows for total functions that are guaranteed to terminate in a certain way, instead of a JavaScript clone...

<comment><USER22> We want to allow recursion and loops. We want to be able to run arbitrary code.

We just need to be a little wiser about how we do it.

<comment><USER27> How did this madness start? I don't want law to be turing complete. Especially programatic law. Why are people so nonchalant about this? This is not sane design. You want totality and termination proofs. At least that's what I would look for in any programatic system of law.

<comment><USER36> Biggest rock is best rock.

</comment></comment></comment></comment><comment><USER37> Its too bad, I really thought Vitalik was the Chosen One, but I think he reacted incorrectly here by panicking and showing concern.

If I had been him I would have let DAO fail without even discussing any fork. Be as emotionless about it as the code itself. Admit mistakes were made, somebody (DAO investors) will lose some money in the short term but stay true to the principles of Ethereum.

PLUS even after all this drama, $ETH has a market cap of ~$1B as well as independence (fingers crossed) from government intervention making it an alternative to Fiat currency, as well as a much better block rate than BTC lending itself to mining on consumer-grade GPU's for the moment at least. I'm looking at litecoin LTC as my next crypto-bubble investment as well.

There's still lots of good to be said about Ethereum. DAO is toast, long live DAO2! Ethereum will come out stronger long term.

</comment><comment><USER38> Software is almost always flawed to a certain extent.

The problem with Ethereum is that you can't push a fix to your contract.

<comment><USER39> You absolutely can if you're not too proud to imagine you'll need to upfront.

</comment></comment><comment><USER40> Surely an issue here irrespective of technology flaws or not is the economic impact on the time taken to write smart contracts.

If it now takes substantially more dev time to write a smart contract that is "secure" (ie by spending lots and lots of time testing for vulnerabilities) this will invariably come at a cost.

So while the theory of smart contracts is brilliant this recent hack might go down in history as a case study as to why writing contracts is too expensive to do in all but the top 1% of situations.

</comment><comment><USER41> I wonder if a language like Haskell with a strong type system and strict typing could help. If you were able to express exchange of currency with the type system.

<comment><USER42> I'm pretty sure you can do that. See units in F# for example.

</comment></comment><comment><USER43> The Coinbase founder that a month ago called ethereum the future of cryptocurrency looks kind of silly now.

</comment><comment><USER44> It's now clear that Ethereum's contract system has major security vulnerabilities. This is a killer flaw for something which exists only to secure transactions between mutually mistrustful parties. Maybe someone else will do this again, better. Etherium itself probably is doomed.

There are also hard questions to ask the people involved. The same people seem to be behind Etherium, the DAO, and the programmable door-lock startup which the DAO was supposed to fund. This is suspicious. This might be an inside job. At least three times in the Bitcoin world, some Bitcoin exchange claimed they lost money due to a "hack", but in the end it turned out to be an inside job.

</comment><comment><USER45> I wrote this originally in response to a post by cyphar ([https://news.ycombinator.com/reply?id=11942889](https://news.ycombinator.com/reply?id=11942889)), but I'd really love a response from anyone with more knowledge or thoughts on how the law might interpret this situation in relation to already existing "virtual legal systems". cyphar wrote:

      "It was definitely fraud. Either it was a contract, in which case "taking $50 million without anyone's consent" doesn't pass the officious bystander test. Otherwise it wasn't a contract, so the default is still fraud (though in that case, the DAO would be the thing being defrauded rather than the investors)."

I'd like significantly more details on your legal theory for how this was "definitely fraud" or how "the default is fraud" if there was no legal contract, the split executor was a direct party to the agreement, and the terms of the agreement were followed. "$50 million" was not taken, 3.6 million or so "ether" was split out from the original smart contract/account, which may or may not end up having some dollar value.

In at least two previous threads [1, 2], comparisons were made to the MMOG EVE Online (developed by CCP Games), and I think the analogy raises some interesting questions. EVE is a self-contained artificial system that, so long the system framework itself is not exploited, is ruled entirely by code. It has a digital currency (ISK) that has an official conversion rate from real world fiat currency to ISK, and an unofficial ToS breaking (but non-criminal AFAIK) conversion rate from ISK back to fiat. CCP has nothing to do with this exchange, but exchanges for ether to other currencies are also 3rd party. Virtual items as well as ISK itself thus have calculable value, both within the system, in terms of time/rarity, and in terms of nation-state issued money. There are person-actor driven "contracts" of various sorts, and people driven markets. There is fraud, piracy, and pure chaotic destruction as well, and that's considered entirely within the system framework so long as the overall code rules of the world are not violated.

Given that, what exactly is the legal difference between the DAO and EVE Online? In EVE, if Alice attacks Bob, or infiltrates his organization, and steals/destroys a few hundred billion in ISK (equivalent to a few thousand dollars at current exchange rate), or sets up a fraudulent bank/scheme that makes off with hundreds of billions or trillions (this has actually happened), do you think Bob should be able to sue in a real world court of law? The essence of the situation looks similar/identical to me: that the parties are operating under a non-contract non-legal agreement to be governed within the a specific set of world rules, and that therefore any interactions within those world rules, however angry they might get about it on a personal level and whatever colloquial English they might use to describe it, creates no legal standing of any sort outside. If EVE client/server were hacked (the world rules distorted) it'd be an issue (though still not necessarily a legal one), just as if the Ethereum VM was hacked it'd be an issue, but if those were operating entirely as they should be then what's the basis of legal complaint? What's the generalized objective basis for court involvement in people agreeing to mess around with made up numbers on computers, even if other people decide to try to exchange those numbers for money?

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

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

<comment><USER46> Legally speaking, CCP goes out of its way to emphasize that isk are play tokens money with no cash value, and losing it all is part of the game. TheDAO/Ethereum supports exchanging ether for money. And anyone who lies about contract (beyond smiling and saying "here the contract code, sign it if you want" is commiting a fraud

<comment><USER45> >Legally speaking, CCP goes out of its way to emphasize that isk are play tokens money with no cash value

CCP officially supports converting money to ISK, and there are 3rd party exchanges for ISK to money. My understanding was that TheDAO ran purely on ether, and that any exchanges for money (be it fiat or another digital currency) were also happening purely 3rd party. Does an official line on "don't go the other way" make a material difference? If CCP merely took no stance on it at all, involved in no way but not working to ban anyone doing it, would that change anything? How "seriously" do they have to police it? Is there any case law on this?

>And anyone who lies about contract (beyond smiling and saying "here the contract code, sign it if you want" is commiting a fraud

Can you clarify your point here, and what you were referring to?

1\. (and again): How is there any legal contract here, and if there isn't what's the 'fraud' legally (not a colloquial "fraud" with no legal impact)? Are you arguing that people should not be allowed to have non-legally binding (and thus non-contractual) agreements on shifting around "value" based on coded rules?

2\. In the case of TheDAO, there were no lies, TheDAO stated clearly and repeatedly that the definitive governing authority was the smart contract itself, and TheDAO organization itself was not (or at least, publicly claims it was not) involved in the controversial smart contract execution. Instead it was at least one of the independent parties to the agreement. So if you were referring to TheDAO I'm confused.

3\. In the case of EVE, are you arguing that ISK is different and therefore fraud is legally ok? Or are you arguing that it's still legally fraud?

</comment></comment></comment><comment><USER47> Doom articles mean market debasement is happening.

If you have the ability to invest, this is a good time to do so. you're about to see massive increases in valuation.

</comment><comment><USER48> Fiy, i recently came upon this company [http://m.imgur.com/Hv9n7fk,55JgdgK](http://m.imgur.com/Hv9n7fk,55JgdgK) that wants to sell ETH to Chinese. I checked the company registry, and found out that the guy has registered a proprietorship back in 2013.

Apparently a friend of Vitalik

<comment><USER49> It is just a job posting.

</comment></comment><comment><USER50> ....to succeed. ;-)

</comment><comment><USER51> run for the bitcoin hills!.

</comment><comment><USER52> Absolute trash article.

</comment><comment><USER53> > They created a situation in which bugs would be expected to arise in an > environment in which bugs are legally exploitable. That is hacker heaven.

Every single system has this problem. You think banks aren't hacked?

<comment><USER54> What _legally_ exploitable bank bugs have you heard of? Keyword there being legally.

<comment><USER55> This exploit wasn't legal either. It was blatantly fraud. I've asked a lawyer for their opinion and it was a very simple question to answer. Contracts are never entirely literal and usually there are implied clauses in contracts. There is a very simple test called the "officious bystander": if there had been a neutral bystander who had asked "should we allow anyone to take $50 million dollars without our consent" then unless both parties would've said "of course!" then it isn't considered to be a clause of the contract and it is just simply fraud. The developers of theDAO wouldn't have said "of course" so it's fraud.

<comment><USER21> So, you are trying to be a great libertarian by doing without the courts of law and the state but then, when everything goes wrong with your money, you call for the opinion of the courts of law and for the state to enforce that opinion.

Oh the hypocrisy.</comment></comment></comment></comment>


Show HN: Introducing InstaFollow, the instant follow back button for Instagram - <AUTHOR> http://instafollow.in

<comment><USER2> This is a nice concept. Will try it out in my blog to see if I get a few followers.</comment>


The Milgram Experiment's Results Today - <AUTHOR> http://thesituationist.wordpress.com/2007/12/22/the-milgram-experiment-today/

<comment><USER2> I don't really understand why anyone would think that the Milgram experiment applies less today than it did 50 years ago. People who think "it worked because lab coats had more status back then" are really deluding themselves - or perhaps they're being intentionally dishonest for some reason.

As the documentary says, people are taught to respect and obey authority. The entire school system, military service and corporate world are exercises in surrendering your will and intelligence to a figure of authority, no matter whether they're right or wrong. As long as those systems are the norm, of course people will do what they're told.

Good documentary, in any case.

</comment><comment><USER3> Well, there's the impossibility of getting a good sample. A person who hadn't heard of this experiment already would have to be hopelessly uneducated.</comment>