Ask HN: Favorite HN quotes? - <AUTHOR> "I still think Oracle is two engineers thinking about B-trees and then several million salespeople" <comment><USER3> What pg has called the "comeback of all time". After a back-and-forth about someone's chances of success. from [https://news.ycombinator.com/item?id=35079](https://news.ycombinator.com/item?id=35079):

> Of course it's a bold statement. But if I wasn't bold...

> Did you win the Putnam? If not, please don't be "bolder" than this guy: > [http://en.wikipedia.org/wiki/Ravi_Vakil](http://en.wikipedia.org/wiki/Ravi_Vakil)

> Yes, I did.

<comment><USER4> It just makes me so sad that I discovered HN so late !

<comment><USER5> That thread was unbelievable, man hackernews discussions were very enlightening back then, drew houston even introduced his startup in that thread.

</comment></comment></comment><comment><USER6> From 2007 on Dropbox

"I have a few qualms with this app:

1\. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

2\. It doesn't actually replace a USB drive. Most people I know e-mail files to themselves or host them somewhere online to be able to perform presentations, but they still carry a USB drive in case there are connectivity problems. This does not solve the connectivity issue.

3\. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?"

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

</comment><comment><USER7> "JavaScript is the XML, the Yugo, the Therac-25 of programming languages. The sheer amount of human effort which has been expended working around its fundamental flaws instead of advancing the development of mankind is astounding. The fact that people would take this paragon of wasted opportunity and use it on the server side, where there are so many better alternatives (to a first approximation, every other programming language ever used), is utterly appalling."

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

</comment><comment><USER8> [https://news.ycombinator.com/item?id=17364748](https://news.ycombinator.com/item?id=17364748)

" _Sorry, but we need a Turing-complete language for ads and tracking. Preferably with JITting, and unfettered access to the GPU and other misc. peripherals like GPS, webcam, etc. In return you get free cat videos.

You're welcome._"

</comment><comment><USER9> Sorry, I have usernames for these, but not links to where they were.

"Play stupid games, win stupid prizes." \- Nicholas_C

"We're all on mushrooms, you've just been drinking tequila all night - <USER2> means you get to fix the flamethrower..." \- bigiaian

"You've got to be a twit to believe Twitter." \- hardworkforyou

"Nothing is as dumb as being too smart." \- bonesss

"Advice is free, until you take it." \- em0ney

"Any sufficiently advanced incompetence is indistinguishable from malice." \- philipov

</comment><comment><USER10> incidentally i kept track of two in my personal note of quotes that stuck with me:

"Those ideas are also based in my anecdotal experience, and perhaps it comes from a willingness to question some "fundamental axioms from scratch", but at the same time maybe that's a) not always a bad thing to do from time to time, and b) if your fundamental axioms are good there is no reason that you won't come back to them." - [https://news.ycombinator.com/item?id=17296020](https://news.ycombinator.com/item?id=17296020)

"Augmenting human intelligence, while leaving the hearts as they are, is a loss, not a gain." - [https://news.ycombinator.com/item?id=17196155](https://news.ycombinator.com/item?id=17196155)

</comment><comment><USER11> This is a good collection: [https://dnluu.com/hn- comments/](https://dnluu.com/hn-comments/)

<comment><USER12> Haha I came to post one I saw on your link - "Most people realize by their 30s that prestige is a sucker's game; it's a way of inducing people to do things that aren't much fun and they wouldn't really want to do on their own, by lauding them with accolades from people they don't really care about."

Also, the link you have is wrong - it's [https://danluu.com/hn- comments/](https://danluu.com/hn-comments/)

</comment></comment><comment><USER13> My all time-favorite HN comment is from fiaz.

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

> fiaz XXXX days ago | parent | favorite | on: Ask News.YC: How to re-motivate > yourself?

APOLOGIES for making this post so annoyingly long, but I really hope you find value in the words below. \</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-----

I'm going to first share a personal experience from my early trading days to illustrate where I'm coming from. I used to wake up at 4:30 am everyday in the Chicago suburbs to beat rush hour traffic and make it into downtown Chicago at 6:30 am. In order to wake up so early, I fell into a habit of sleeping at 9:00 pm and like a robot waking up at 4:30 am. This simple routine was indirectly helpful when things seemed darkest. For the first six months, I lost money and was ridiculed constantly by other traders who were more successful than me (which was about 20 other guys CONSTANTLY using me as a punching/whipping bag). The only thing that kept me going was the fact that some of the very same traders that would be making wise cracks at me for losing money were some of the most successful people I knew at the time. For better or worse, if I needed a trader to model myself after, it was the same people that were telling me how bad a trader I was - and although I was not open to really hear what they were saying, they were right about my skills in every way (but their feedback was always packaged in some sort of insult). After racking up some rather hefty losses, I was determined to quit at one point during month four, but because I had a habit of waking up at 4:30 am I simply "forgot" that the night before I told myself I would quit and spare myself further humiliation...by then I was warned that I was now on the red list of traders ready to be cut. Also, my personal savings were starting to approach zero (the base "draw" for house traders was enough to pay for food; you usually make your money on a percentage of your profits, and I was deep in the red at the time). To say the least, there were many excellent reasons to be "reasonable", forget about my dreams, and quit. After 4 consecutive "failures to quit", I realized that I didn't quit because somewhere deep down I was hanging on to a dream, however remote at that point: that I could somehow be as successful as the other traders that I knew. At the same time I realized that I had hit rock bottom in that I couldn't even succeed in failing! Very tough times indeed... An interesting point to note here is that although my losses were starting to get very large, the people who were funding me as a trader kept me because I had one redeeming quality: EFFORT, and this helped build tenacity. Other traders who barely traded but had a fraction of my losses were cut much faster because they didn't put forth much effort. They were not willing to take losses and be bold/brave and fight it out; I was willing to take risks, and this saved me from getting cut faster than others. Slowly I began to reinterpret the constant humiliation I was suffering: perhaps the other traders were right about their "jokes" and there might be something in what they are saying that will help me get out of the red. I also realized that since I had failed at quitting (which was now the ULTIMATE failure), there was no further failure for me and that if I took baby steps they were surely to succeed (this translated into taking smaller trades/profits). Only after improving upon my abilities as a trader and channeling my energies appropriately did I succeed and earn everybody's respect as a trader (and you have no idea how this made me feel!). I quickly made enough in commissions to be trading my own account, and be successful as an independent trader onward. When I look back at those final months of 1999 (yeah that's right, I was losing huge cash at the end of 1999 when the entire market was going crazy UP!), there was more good than bad even when I was getting my ass handed to me. It's just that I was intentionally creating my own feedback (I'm right everybody else is wrong) instead of seeing the results I was getting (losses/insults) as feedback and information that would help me be successful. I kind of snicker every time I see somebody ask for feedback on their startup on YC.News only to end up justifying themselves by telling everybody why they did what they did when they get negative feedback, which is the feedback of greatest value. If somebody tells you how crappy your idea is, thank them that they even spent a few brain cycles considering your idea. The lessons I learned from this that are perhaps relevant to your questions:

\- Determine if you believe in yourself to succeed as an individual (I know this sounds odd, but for a moment just examine your thought patterns and your actions and see what message you are sending to yourself; do you listen to the voice that says you can't or are you paying attention to the feedback from your efforts and the results you are getting?)

\- Search deep down inside and see if the project you are working on is something you believe in or not. If you can't sell yourself, then you shouldn't bother trying any further...

\- ANY attention you get for your efforts is good attention. If you get LOTS of negative feedback, then be grateful - you've jumped the first hurdle of getting people to give a damn about what you are doing! :)

\- There is responsibility and accountability that goes with both success and failure. You need to be ready for both because they can be equally painful in equal ways. The amount of accountability that comes with success can be more unbearable than the accountability that accompanies failure. I personally know of some very talented people who enjoyed phenomenal initial success only to find just as fast that they were in over their heads. \- The more you resist the possibility of failure then you are less likely to recognize possibilities that will help you succeed. If you are afraid to fail, then most certainly you are afraid to succeed. This sounds counterintuitive but it's based upon the fact that fear makes your mind less supple and less responsive to the changes that will push you out of the game - or conversely it will lessen the impulse to jump on the opportunities you need to succeed. \- The results you get has everything to do with your users/market and less to do with you as an individual; it's sometimes hard to separate these two. See the other side of the equation and what side you are on before trying to solve it. Don't ever think you are above the feedback of your users...EVER! \- Don't have expectations (this is just setting yourself up for failure). Because you are starting out you may not know what is best to help you succeed - ESPECIALLY if you're lacking motivation. Keep in mind that whatever results you get from your efforts will lead to more possibilities (in the form of additional information).

\- Have some behavioral "context" within which to exercise discipline and structure. Seek to grow your efforts within this context. My context was my sleep schedule. It was a routine that was so ingrained that my drive had a laser focus. This might not work for some, but it worked for me. Finally, I will add that in my opinion failing hard and fast is MUCH better than failing slowly. The faster you know for certain something isn't going to work out, the sooner you can cut your losses and move on to your next idea. When you eventually succeed, you will look back at all the times you were quick to cut your losses and get to where you are...

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---

Please do NOT contact me asking for advice in trading/investing. This is a VERY personal thing, and it has everything to do with who you are, NOT with how much information you have, or which tools you use, or who you know.

</comment><comment><USER14> "Everyone has a plan until they get punched in the mouth"

\- Mike Tyson</comment>


Android fragmentation is a feature, not the big problem everyone says it is - <AUTHOR> http://vbsteven.com/archives/595

<comment><USER3> Like the author, I have been writing Android software for a while (nov 2009). However, I completely disagree with his conclusion.

When I think "fragmentation", device sizes and configurations are the least of my worries, although the tooling around this area is very poor and needs improvement. The real fragmentation issues are things involving bugs which are hard to work around, like

* Froyo having a number of NIO bugs (ByteBuffer.AllocateDirect & selectors) (which were fixed later on) * Samsung GPS driver not filling in Location.getTime() * HTC Desire and others having broken Bluetooth stacks

Or advice from Google like:

"Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases. For Gingerbread and better, HttpURLConnection is the best choice."

I have always found Android and its tools to be extremely buggy. Then take into account you are going to have to maneuver around all of these bugs not for one version of the OS, but essentially every version put out for the past 2 years. Many bugs are from Apache Harmony, a huge pile of turd, which is defunct.

Also, fragmentation comes in other forms entirely, like the Kindle Fire, which does not pass CTS and does not have all of the android APIs (I see the possibility of Google subsidizing a low cost ASUS tablet as a move against this existential threat).

Additionally, the newly published design guidelines are for ICS and above, but most developers will target Froyo-ICS. Its quite a challenge making an app which follows these guidelines if you are also targeting pre-ICS devices. So even the guidelines are "fragmented".

I'm really looking closely at how Windows Phone does. Its becoming more difficult to write non-trivial apps for Android unless you can afford a bunch of phones to test on, or use one of the testing services like Perfecto.

But there is potentially a startup opportunity here. Perhaps someone could create a database that lets you drill down, by API, to see which phones have issues. It would be great if lint hooked into this database and gave me a list of phones to exclude in the market, if I didn't feel like working around them.

<comment><USER4> I dissagree as I haven't had a lot of problems with the apps I've worked on. But maybe it's because of the APIs I've used, some of them are probably more solid than others, I never had to use NIO or Bluetooth.

As far as the design guidelines, there is a compatibility library that lets you use them back to 1.6.

<comment><USER5> But NIO, Location APIs, and in some cases the Bluetooth APIs are kind of important to the platform and used by most Android developers.

<comment><USER4> I have used Location without a problem, I don't know why you would ask the GPS for the time anyway.

<comment><USER6> Wifi only devices have no time source (Android doesn't include NTP) so a wifi only device can have drifted quite a bit.

</comment></comment></comment></comment></comment><comment><USER7> > As of march 2012, 92% of devices are running Android 2.2 (Froyo) and higher. > The

> Froyo feature set is a really good base line for most of the applications. I > challenge

> you to find a new feature in higher versions that you really need to have in > a general purpose app.

So, for "general purpose apps", whatever that is, Android 2.2 (which was launched 2 years ago) is great. 2 years is _ages_ in computer land and this is a huge issue, even though the author likes to downplay this because the 2 year old software works "just fine". Android is very fragmented and if you have to develop for 2 year old software still today, that's a big proof.

> Developer tools

This whole section can be skipped when developing for iOS. Big deal, there are tools to help you develop for the chaos that is the Android flora. Just because the tools exist doesn't mean it's easy to support all these different devices.

> Developers can provide different graphics for different screen sizes

I don't have the exact number on the range of Android screen sizes, but there's much more work to this than the author implies. Just because you can doesn't mean it's easy.

> There is an emulator and UI builder that can emulate any Android version, > screen resolution

> and pixel density combo

The ARM emulator is really _really_ slow. Maybe it's picked up speed with Android x86 but when I was developing for Android the emulator was almost unusable and basically everybody's advice was to go out and buy an Android device. This will get pretty expensive pretty fast if you need to emulate the range of Android devices.

> It doesn't matter if you prefer a large vs a small screen, a hardware > keyboard vs software

> input, a 1Ghz+ quadcore vs a 600Mhz single core, a device from an A brand vs > a Chinese

> copy or maybe you just want the best available phone for you specific > budget.

> There will be a device available for your needs. This is only possible due > to the so called

> "fragmentation".

IMHO, sure, some people prefer larger screen or a hardware keyboard. But the rest of this paragraph doesn't make sense. Who'd want a single core rather than quadcore? Who'd want a chinese knock off instead of a brand? This is both just a question of budget. So in reality, again IMHO, I think the "featureful" difference between Android devices is much less then is purported in this post.

Just one more thing, I'm not knocking on Android as such - variety is good and Android has some features over iOS and iOS has features over Android. But having developed a little bit for both platforms, Android is definitely very fragmented and harder to develop for.

<comment><USER8> For what it's worth, versions newer than android 2.2 do have features that are worth using. My personal favorite is hardware accelerated graphics. That really does make the phone's UI feel as snappy as the one on iOS. Then there's the support for multi-core apps (introduced in 3.0), resizable widgets (3.1), social API (4.0), calendar api (4.0), beam (4.0), low-level media streaming (4.0), media effects(4.0) .. and many many others. Android 4.0 is full of goodies.

<comment><USER9> My first Android "app" (actually, a runtime for HTML5 apps call Blossom[1]) only will run on ICS because its requires hardware-accelerated graphics and surfaces.

On iOS, I _could_ support all the way back to the original iPhone, but I'm actually requiring iOS 5 (that includes all three iPad generations, and the iPhone 3GS, 4, and 4S) mainly so I can use ARC and because people in the iOS ecosystem update so fast anyway.

[1] <https://github.com/fohr/blossom>

</comment></comment></comment><comment><USER10> The big problem is one of customer expectation. End users don't really care about which version of Android is which. They care, for the most part, about being able to run their favourite apps on a device.

When a customer buys an Android device, rightly or wrongly they more or less expect it to behave in the same way as their friend's. Even if their friend has a SG SII and they've just bought a ZTE or Huawei. After all, that's how things (more or less) work for iOS.

What a lot of operators have found is that when they flood their network with cheap, low end Android devices (which are not adequately explained as such), that many get returned. Many of these returns are 'No Fault Found' - <USER2> that there was no technical fault with the device at all, but it didn't meet the customers expectations.

The argument that it was a feature would work if there were tighter minimum hardware specs for running Android, but too often fragmentation means the Android platform being misused by being loaded onto poorly equipped devices.

</comment><comment><USER11> How can something that raises the costs of development be regarded as a feature?

It might not be a fatal problem, but it does raise the barrier to entry, and it does reduce profitability for apps that are more marginal.

<comment><USER12> The article clearly states it is a feature for consumers, not developers, a feature that is largely responsible for the success of Android as a platform, since consumers have a choice to pick what kind of device they like. It is relatively harder to develop for Android than for iOS, but it is nowhere near being as big of an issue as some are trying to portray it. Of course if you are, for example, a one man band developer, it will be very difficult to provide high quality native experiences on two different platforms, but that's a limitation of time and experience, not of inherent impossibility of any platform.

<comment><USER11> It's not a limitation of experience. Regardless of how experienced you are, it will still cost you more.

Higher development costs for apps is a problem for consumers as well as developers.

When developers complain about fragmentation they aren't complaining about the diversity of form factors and device capabilities.

They are complaining that these aren't cleanly abstracted away by the operating system, and that the delivery of updates is a mess.

 _OS Support for diverse hardware is a feature. Fragmentation is not._

Apple sidesteps this problem by not supporting diverse hardware.

Android could potentially solve the problem with better abstraction and a better software update process, but hasn't yet, so the costs are passed on to developers and consumers.

<comment><USER12> I agree in regards to a better software update process. I don't know how much the abstraction could be improved, since the diversity makes some things impossible to abstract. I should clarify I'm talking from a perspective of developing apps, not games (simple apps at that, as I started learning Android slightly more than half a year ago), so I haven't encountered the really difficult development issues that games developers stumble upon so often. What I have learned so far, however, has helped me plan out each project better. What in the beginning seemed an issue that will double the amount of work (and maybe even was so on the first project), ended up being solved with maybe 5 to 10% more effort and thought on the second project.

Yes, either way you look at it, it is more work, but with experience it has become more or less marginal for me. Although it could also be that once you accept something as unchangeable fact, you adapt expectations and it no longer represents a source of frustration :). Who knows!

Edit: Reading my post, I realised how ridiculous my claim of experience is based on working on Android for less than a year, especially without any other previous programming experience, but I hope it's still clear what I mean.

</comment></comment></comment></comment><comment><USER13> If this fragmentation (or anything else) prevents them from fixing issue 3434 in a timely manner, my application will have to stay on iOS. It's that simple.

<comment><USER14> Well, since 3+ years is already untimely...

Have had 3434 and scads of other major issues starred since forever. :/ Every once in awhile, a comment will come in on one of them and I'll get excited...only to find that it's another "Me, too! Come on, guys!" post.

Throwing pennies in a fountain making wishes is what it all feels like.

</comment></comment><comment><USER15> I completely agree with the people who say that old versions of android not getting upgraded is bad.

But this screen size and hardware is different between devices is fragmentation and is bad is a bit bullshit. If that was so bad where are all the articles says OSX is fragmented and hard to develop for, it support a large range of screen sizes (11 -> 27 inch) and both semislow and super fast cpus (and now we are not even talking windows...).

<comment><USER16> There is a big difference in UI design for the mobile devices and for the desktop. On the desktop you can often specify the UI using automatic layout features and the result works. On mobile devices the limited screen estate forces you to weight every pixel and therefore the different screen sizes matter much more. Similar argument can be made about the performance – on desktop Macs the performance differences are not interesting for most regular apps, whereas on the mobile devices even a simple app can tax the machine to the point of not being usable.

</comment></comment><comment><USER17> Haha this is a great April Fool's article. The old "it's not a bug, it's a feature" joke.

</comment><comment><USER18> I agree. The "big problem" is the low-ish revenue due to poor app sales figures compared to iOS, and probably nothing else. You can blame it on the device's architecture, I'd rather put the blame on the business itself and the way it works.

"Fragmentation" is an engineering problem that we can iron out. Bad market performance is much more complex and something that's in large part out of our control.

<comment><USER19> that low-ish revenue you report is also there in the iphone platform as the overall aggregate iphone app sales masks that data point.

Now can we have a honest conversation instead of using the non-meaningful fragmentation word designed to start a non-conversation..

Its the same problem with code quality..code quality dramatically impacts sellability on both platforms..however we have a diss-connect as on android people want to blame Google Play market rather than the problem and on iphone peopel want to claim its something else because Apple never gets anything wrong..

ITS THE SAME EFFING problem FOLKS ON Both platforms!

Can we please remove our heads from our asses!?

<comment><USER20> No it's not, read the sales comparisons of apps that have both iOS and Android versions...the difference is quite striking.

<comment><USER21> The problem may just be that the business model that works on Apple's app store - direct sales - doesn't work as well on Android.

David Edery: "Triple Town did 67% of its iOS revenue on GooglePlay. Confirms what I'd heard: f2p games are probably the way to go on Android."[1]

Chris Pruett: "@djedery Indeed, Wind-up Knight is more profitable on Android than iOS."[2]

[1] <https://twitter.com/#!/djedery/status/185800787581091841>

[2] <https://twitter.com/#!/c_pruett/status/185802890688991232>

</comment></comment></comment></comment><comment><USER22> Nice try, Google :)

</comment><comment><USER23> I suppose all the different firewire cables on my macs are a "feature" of apple's fast development.

<comment><USER24> Either you don't really have a Mac or you've been plugging your hard drives to the video out.

FireWire has had a grand total of two different plugs.

<comment><USER23> my bad for not clarifying--yes it only has two. I meant to write video out, which has changed repeatedly. I've only owned macs--I love the operating system but think their obsession with dongles is crazy.

Really though, I think people knew the people I was making. So what's up with the downvotes? You don't agree with it, that's cool, just don't vote...</comment></comment></comment>


How Frank Buck Filmed His Tiger-Python Battle - <AUTHOR> http://blog.modernmechanix.com/2006/07/06/how-frank-buck-filmed-his-tiger-python-battle/ <comment><AUTHOR> I stumbled onto this youtube video: <http://www.youtube.com/watch?v=ZFCcvZFP6D8> and found the description of how the filmmakers worked (the submitted article) to be really fascinating. Particularly interesting were the technical comments by the cameraman about filming in the forest.</comment>


I Buy and Sell Domain Names AMA - <AUTHOR> http://www.reddit.com/r/IAmA/comments/dwuhu/iama_domain_name_buyerseller_ama/

<comment><USER2> My understanding of the domain market is this.

Regulators realised the best way to provide domains was to let the market determine their value and allow them to be traded at will (with respect for IP). So they wholesale at dirt cheap prices on a first-come first-served basis and people can then buy and sell them based on market value. Works for real estate so why not domains?

The problem derives from the initial price and the expectations that implants. Many expect a domain to cost $10. So when they are offered a price more than that, they are pissed off and blame the person selling it to them.

Nobody walks past a vacant block in a prime real estate location and goes "bastards, if they weren't squatting that land, I could snap it up". They know the land costs $x million and don't assume it should cost $10. However, because domains are a new real estate market and not every possible domain is out of wholesale, people base their expectation of price on the wholesale price.

Now, let's think of the alternative. Anyone who has tried to buy a top level domain for a country that heavily regulates the names would understand the pain of the alternative. It can cost hundreds or thousands for the wholesale price. You're required to own the trademark already (which adds additional cost for a new project) as well as have a registered company etc. I can think of dozens of my favourite projects/blogs which I'm sure don't have a company or trademark registered under that name. This system would not only be a pain for small business, it would stifle innovation on the web.

I'm not a domainer (I do own about a dozen though) and I get just as annoyed as the next guy when I come up with a name for a project and find some punk wants $15k for the domain. But then I think of the alternative.

<comment><USER3> > Nobody walks past a vacant block in a prime real estate location

Vacant blocks in prime real estate locations are taxed at their market value though, no? So if you've got that land sitting idle, and you're not collecting income from rent, nor using it yourself, you're going to lose money on it. This is an incentive to sell it to someone who will make money, or otherwise find a way to employ it more productively.

That said, I don't think I'd really like to see property taxes on domain names.

<comment><USER2> At first I liked the idea of market value based taxes and clearly a bunch of HN readers agree with the idea.

The biggest issue I see though is the implication for small projects.

For example, maybe in 1994 you snapped up _pizza.com_. You could have been using it ever since for a pizza price search engine which gets 100,000 unique visitors per month and earns you $5,000 per month. That's decent income, except the taxes on the domain's market value of $2.6 million[1] would be crippling. So despite using the domain in what most would think of as good way, you couldn't afford to have such a good domain. Now extrapolate this example for the thousands of sites that have a good domain name for a small project.

[1] <http://news.cnet.com/8301-10784_3-9912380-7.html>

<comment><USER3> Yeah, like I said, I ultimately don't think it's a good idea: it would add too much friction for the benefits.

</comment></comment></comment></comment><comment><USER4> Thanks Ohashi for posting this (I can see from the Reddit thread you are the OP/subject of the thread).

However on a meta point to everyone: I don't see what value there is in starting another, semantically forked, conversation about a reddit thread over here on HN. Wouldn't it be best to keep the conversation over there for the benefit of everyone, including those Reddit'rs who don't read HN?

<comment><USER5> 1) not everyone on HN reads Reddit

2) the discussion on HN tends to be higher quality than other sites, even Reddit

</comment></comment><comment><USER6> If domains were $100/yr each would you give up? Do you think it would kill other domainers?

<comment><AUTHOR> i might be pickier, but I would also charge you 10x more on sales to cover costs.

<comment><USER7> Do you think you would still find buyers for a 10x price? Or maybe you would only go out of business because costs would not be covered or revenue would not be enough?

<comment><AUTHOR> If everyone charged 10x the price (and they rationally would), then I think most businesses would have to accommodate. Some would go under, sure. You would probably see less liquidity and more sales force focus.

</comment></comment></comment></comment><comment><USER8> I think the solution to limit domain squatting is to set domain taxes in the same manner real estate taxes work. Charge 0.1%/year of the domain price. So if somebody wants to buy your domain for $10000 and you don't want to sell it, then the tax would be $10/year. That would make squatting domains without generating any income from them not profitable.

<comment><AUTHOR> People generally the income generating type of domain names (those investing in a lot of them). If it took a 10k offer to make me pay 10$ more, i'd sell my whole portfolio at 10k each and retire. it would be kind of awesome. :)

<comment><USER8> 1) It's $10/year vs $10K once. 2) If you prefer to sell your domain for the price buyer is looking for -- that's win-win situation. On the other hand if you want to keep that domain to yourself without using it -- then the tax ($10/year in that case) would help you to reconsider that. 3) If 0.1%/year tax is not enough -- it can be increased a little. E.g.: 0.2%/year.

</comment></comment></comment><comment><USER9> Can you give us a sense on the amount of revenue you make per year?

<comment><AUTHOR> xx,xxx, it's more than enough to live on as a single person, not enough to support a family probably (in a developed country)

</comment></comment><comment><USER10> First off, I am dismayed at all the people on reddit who are condemning you. Some people talk like they have some sort of God given right to the domain name they want. It also amazes that people believe a successful business starts with a domain name =|, but that's another argument.

My question to you is. Why do some squatters stay so anonymous there is NO way to contact them? Also, it doesn't make sense to squat on a domain name that does not get any traffic... If a squatter is sitting on a domain name that does not have any traffic, why won't they sell even to a low offer? Like, a $20 profit is a $20 profit right?

<comment><USER11> > people believe a successful business starts with a domain name

Domain names don't make or break a business, but they certainly help. Factors like name relevancy, and catchiness help draw visitors and create brand recognition.

<comment><USER12> Totally agree. If only google had been able to buy searchengine.com they'd have been much more successful. Or if socialnetwork.com hadn't been taken by an evil squatter then facebook might have really taken off.

If your business has real value, the domain name is not relevant at all. Look at the top startups. How many of them have "keyword rich" domains that are relevant to their business?

Of course you can argue that this is an effect of domain squatters, but I would argue that the fact they couldn't get their first choice of domain name has had no discernible impact on these businesses.

<comment><USER13> When Facebook started, it was just people, a couple pictures, their contact info, their classes, and a Wall. There was no messaging or News Feed. It really wasn't much of a social network at all compared to what it is today.

I would argue that some sites benefit from having a non-specific domain name. If Google had been searchengine.com, maps.searchengine.com and mail.searchengine.com seem a bit weird. Having a less specific name allows a company to pivot without changing its branding.

<comment><USER12> yep, totally.

Likewise if amazon had been called books.com they'd have a hard time diversifying into the huge repertoire they have now. The same's true of just about any popular site you care to mention. What does flickr mean? del.icio.us? What does ycombinator have to do with startups? etc etc etc.

<comment><USER13> Amazon is a much better example than the one I used.

</comment></comment></comment></comment></comment></comment><comment><USER14> I'm guessing it varies but how much of a domain name's value is in it's name vs it's history (how much traffic it's getting)?

What advice do you have for someone who is not a domain seller but has collected a couple domains that they no longer want but would like to sell them rather than just release them for someone else to profit from?

What is the most expensive domain name you sold? Back in the original .com bubble someone offered me (and I accepted) $10k for nonames.com. Would that domain go for that today?

<comment><AUTHOR> the history part is interesting, that can be one component of value. It's more SEO guys that look at that stuff - domain age, links, etc. Valuable names will get type in traffic (if we define value as type in traffic - and many people doing this do exactly that). That type in traffic is there because the name is good and doesn't disappear/change because of history. It can only be increased from that level because of history. In terms of valuation though, we all have our ways of thinking about it. There is a simple traffic value estimation, SEOs value certain factors, and many more ways to valuate domains.

as for selling, if you just want to dump there are 2 markets. reseller and end user. Resellers are domain investors, webmasters, people here at HN probably fit. People involved with web who will pay a small price. End users, pay a lot more and are generally companies. You can contact them offering it for sale, otherwise you just wait until they come to (this is what I do).

A lot of the deals I do are private, so I won't reveal the most expensive one. NoNames.com... beats me. No Name is a big brand though now right? Not sure if the domain predates the brand, but I would think they might be interested among other potential buyers. You would be in the clear had you registered it prior to their company.

</comment></comment><comment><USER15> Say someone has a site (blog or whatever) that has traffic, but few/no ads or other monetization. How do you estimate that site's value for resale purposes?

<comment><AUTHOR> First I would look at the niche, is it something with a lot of monetization options and/or high paying opportunities?

If so, I can look at similar sites, I can look at PPC bids, affiliate programs/conversions. I could see if competitors with ads are selling and see what sort of price/value they are offering (also checkout their media kits if they offer to see what people are paying).

It makes a difference if you're selling a website or a domain alone though. Domain only gets complex because the nature of the traffic matters hugely. Changing things dramatically will lose search engine traffic if that's the major source (toys.com is a good example of this).

</comment></comment><comment><USER16> The problem with domain brokers is trust. I simply don't see myself paying >1000 eur/usd without ever shaking hands in real life first. All the small brokers, no well established "brands" (at least for someone outside that line of business) don't help building the trust needed.

<comment><USER12> well, there's sedo.com, buydomains.com, quite a few established middle-men. A lot of small brokers too admittedly.

<comment><USER16> True, I once bought from sedo and it was OK at the time (I think it was about 300-400 EUR) but unfortunately not every domain for sale is offered by sedo (at a comparable price).

</comment></comment></comment><comment><AUTHOR> I answered a bunch of questions on the IRC channel and thought others here might be interested as well.

</comment><comment><USER17> What are your thoughts on the new .co (Columbia) TLD? Valuable (as an approximation of .com)? Safe (as in not going to cut off companies like Libya did to bit.ly recently)? Anything else?

<comment><AUTHOR> The value is in typo squatting co. No doubt about that. Lookup the .cm story (The Man Who Owns the Internet on Business 2.0 back when it was running - Kevin Ham). He wildcarded the Cameroonian DNS and caught all the typos. Since he didn't register them, he wasn't typo squatting either, everything was wildcarded. Brilliant business move, .co is the same thing in terms of opportunity. As far as riskiness, you never know.

</comment></comment><comment><USER18> _I Buy and Sell Domain Names AMA_

What does AMA mean?

<comment><USER19> Ask Me Anything</comment></comment>


Julia 0.5 Highlights - one-more-minute http://julialang.org/blog/2016/10/julia-0.5-highlights <comment><AUTHOR> Exciting to hear -- I have used Julia for prototyping, and have found it to be excellent for that:

In my experience there are still some rough edges as compared to the Python ecosystem (of course!), which together with the 0.x status make it impractical for many production situations. However it is fantastic for prototyping numerical code, the type system is a pleasure, and the JuMP mathematical optimization library is a gem. Being able to have fast code be "first class," as opposed to the impedance mismatch of dealing with numba/Cython, feels great and is a real boon for trying new things. Then, it is fairly straightforward to port the final solution to whatever production language you use (e.g., Python with a sprinkle of numba).

<comment><USER2> Really interested in why you would use a "faster" language in julia then move to a "slower" language like Python or R?

<comment><AUTHOR> Typically a mix of reasons:

\- Needing to interact with an existing codebase, and an existing developer base. If everyone knows and uses Python and only a few use Julia, it is too early to put Julia in production. If there are proprietary libraries, now may not be the best time to commit to porting them to Julia.

\- Language and ecosystem stability. I started something on 0.4, and with 0.5 there were a raft of deprecations. If the code will live several years, that's a support commitment with unclear value.

\- Library maturity. If I need to build a web app, read an Excel, read a CSV with dates _quickly_ , consume a SOAP endpoint, etc etc in Python -- no problem. With Julia I will mostly be fine, but am likely to run into _some_ cases that are not yet 100% there.

\- Most code does not need the extra performance, so once you have a fast prototype as a performance target it is often not that hard to hit similar performance with Python + numba/Cython.

Note for that last point: there _is_ a lot of value to not worrying about this in the exploratory stage, and getting a performance target (for later optimization) as a nice byproduct.

</comment></comment></comment><comment><USER3> TL;DR; This is a pretty big update. There are potentially breaking changes (e.g. errors when calling ambiguous methods). And there are significant performance improvements when dealing with functional-style programming (lambdas, closures, etc).

<comment><USER4> Errors when calling ambiguous methods are unlikely to be a big hazard – at least we haven't found them to be. Most ambiguous calls are very unlikely to actually occur, which is why that change makes a lot of sense.

The big breaking change is the array indexing one – that will very much require adjusting multidimensional array code.

</comment></comment><comment><USER2> 5 years ago I thought for sure I would be using Julia today. (I mostly use R) I have found that news tools have come into play that I haven't really felt the need for a faster language then R for my work.

I'm interested in people's everyday use of Julia and how it has impacted your workflow. I don't work with "Big Data" most of my data sets are bellow 100k in size. Anyone using Julia for medium and small data sets?

<comment><USER4> Not to be snarky, but we announced Julia in Feb 2012, which is less than 5 years ago. Unless you happened to be in the MIT class that used Julia in the Fall of 2011, you're probably overestimating how long you've been following the project.

If you're comfortable using R and the tooling and performance it offers, you should probably keep using it. Julia isn't just about big data, but it does tend to appeal to people who are struggling with problems that are sufficiently hard that their old tools left them in a world of pain. That pain may comes from size, complexity, CPU-intensiveness, or need for more language expressiveness (a hard thing to define). In particular, Julia offers a unique combination of productivity and speed for numerical work that can't be found anywhere else.

<comment><USER2> Okay 4.5 years :) I really was wowed by the promise of Julia and the road map you presented for it, great job by the way. I just am surprised I haven't picked it up yet personally. I have a feeling that my R ecosystem wouldn't be as strong as it is right now if it wasn't for the friendly Julia competition you have provided.

I guess I am seeking the one "pet project" that would get me to jump in and give Julia a test drive.

Thanks for all your work even though I don't directly benefit from your work.

</comment></comment></comment><comment><USER5> Congratulations! As a Rust user, I'm always happy to see new programming languages break into the field. :) However I am confused by this paragraph:

      > Julia's LLVM version was upgraded from 3.3 to 3.7.1.
      > [...] we're very happy to be back to using current
      > versions of our favorite compiler framework.

LLVM's current version is 3.9, is this a typo or are there problems that prevent Julia from being used with any release newer than 3.7.1?

<comment><USER6> LLVM 3.7.1 is a little less than 10 months old. Our RC period lasts for about 3 months, the start of which is the last point we'd have possibly upgraded LLVM. Upgrading LLVM is a little bit of a scary prospect for us since we find new bugs in every version (and fix them!), so though we considered moving to 3.8, 3.7 had been stable for a few months, so we didn't want to risk it. There's currently a PR to bump LLVM to 3.9 for 0.6, so I'd expect 0.6 to be released with LLVM 3.9.1.

<comment><USER5> Cool, mostly I was curious if the show-stopping issues you were seeing were actually fixed for good or whether 3.7.1 just happened to "accidentally" work. :)

<comment><USER6> Nothing accidental about it, it took quite a bit of work to fix all the issues we had ;).

</comment></comment></comment></comment><comment><USER7> I'll be honest, giant factor speedups are awesome, and I always look forward to writeups about the discovery process and such, but I'm of the opinion that the presence of those optimizations in recent history means the software is often many years from actual maturity and suitability for production usage.

Either way, looking forward to reading about where the optimizations themselves came from.

</comment><comment><USER8> Can anybody explain the remark about LLVM towards the end of the post? What were the difficulties of updating it, especially with respect the intermediate versions?

<comment><USER9> If you're really curious, you can follow some of the breadcrumbs through the "Activate LLVM 3.7" GitHub issue (which was originally started for version 3.5).

[https://github.com/JuliaLang/julia/issues/9336](https://github.com/JuliaLang/julia/issues/9336)

</comment></comment><comment><USER10> I love the detailed description of the changes made and the reasoning behind it. Great read, thanks.

</comment><comment><USER11> WRT julia's type system: I still don't get it. Is Julia dynamically or statically typed? Are type errors detected at compile time (or since it's jitted when loading a file) or at runtime (i.e. when the code is executed)? I personally don't see much use in just another dynamically typed language that gives me similar errors as R does.

<comment><USER4> Dynamic: [http://stackoverflow.com/questions/28078089/is-julia- dynamic...](http://stackoverflow.com/questions/28078089/is-julia-dynamically- typed/28096079#28096079)

Julia uses its type system for:

\- self-documentation

\- reduction of boilerplate manual type checking that litters libraries in dynamic languages

\- all those times you need to express the type of something, which happens especially frequently in numerical code

\- performance

In the future, some "type linting" could be built into the standard library since we can infer types for so much code, but it isn't the top priority.

</comment></comment><comment><USER3> I'm curious to hear from people who are using Julia on a regular basis. What's the UX like? I only looked at it briefly and was turned off by some things (1-based indexing comes to mind). But I really liked other things (multiple dispatch).

<comment><USER2> 1-based for statistics is a STRONG reason to use it. 0 based is ridiculous for a statistics program and the reason why I left Python. I understand for looping and the arras to be internally 0 but when doing statistics I should have to use two different index.

<comment><USER12> _1-based for statistics is a STRONG reason to use it. 0 based is ridiculous for a statistics program_

Could you elaborate on that? What about statistics do you feel makes it necessary to have 1-based indexing?

<comment><USER13> My flippant answer: "No one is ever assigned Patient ID 0"

It's mostly about expectations. Users of statistical software, who may or may not be programmers by inclination, use 1-based indexing. The program they came from uses 1-based indexing (R, SAS, Stata, etc.). When you talk about data, you rarely talk about the 0th observation. It's just a recipe for errors to have to code switch between 0 and 1-based indexing.

</comment></comment></comment></comment><comment><USER14> Why does the returned value (100, 100) consume 208 bytes?

<comment><USER15> The counter reports all heap-allocated memory, not just memory that persists after the function call, and the description in the post doesn't look quite right. The 208 bytes come almost entirely from calling the function from the global scope. Inside a function, there would only be 16 bytes of memory allocated on the heap, for the generator itself (which we desperately want to get rid of, but that is still WIP) and the return value would live in registers or on the stack.

<comment><USER16> > which we desperately want to get rid of

Would that be covered by [https://github.com/JuliaLang/julia/pull/18632](https://github.com/JuliaLang/julia/pull/18632) or is it a separate issue? I have some really ugly code that ought to be built out of nested generators, but I can't afford the millions of heap allocations.

</comment></comment></comment><comment><USER17> Is there anything like Julia, but with strong typing and pure FP?

addendum: read 'static' for 'strong', please

<comment><USER18> That depends on what "like Julia" means. It's not a functional language, so the short answer is "no". Given that it lacks a true static type system and supports macros it's philosophically LISP-like; notably the Julia compiler includes a sizeable chunk of LISP code. But it's also clearly _not_ a LISP.

<comment><USER4> I realize that your use of the phrase "functional language" seems to entail having a static type system and purity, but most people seem to consider Lisp to be the original functional language and it doesn't have either property. If one considers Lisp to be functional then it seems like Julia should be as well. Do you not consider Lisp to be functional? Real question, not a rhetorical one – I'm trying to assess where people fall on this terminology.

<comment><USER17> "Functional language" is ill-defined, hence my specific question about static typing and purity. I would really like to have a language for scientific computing that had good scalable performance as well as static types and referential transparency.

<comment><USER4> As far as I know, no such system exists. Strict static typing and numerical computing are, I suspect, more at odds with each other than they casually appear to be. The seemingly simple `+` operator is the most polymorphic and overloaded function-like entity in many static languages (and often can't be defined as a normal function for that very reason). And `+` doesn't hold a candle to the polymorphism of array indexing and slicing, which is pretty crucial for productive numerical work.

<comment><USER17> Thanks for your reply.

Someday, Haskell will get a good matrix library, and then I'll be happy.</comment></comment></comment></comment></comment></comment>


The future of cities is the Micropolis - <AUTHOR> https://medium.com/@baronmaximilianwilleford/the-future-of-cities-is-the-micropolis-dae02f4b233b <comment><USER2> I dreamed the future city. it was a giant pyramid where your yard was your neighbor's roof. and you took giant escalators up the inside of the building. And the inside was a giant atrium.

</comment><comment><USER3> As long as land is cheaper than construction this is a pipe dream.

<comment><AUTHOR> If you eliminate transportation costs and factor in lower taxes and energy costs, it may be a wash.

More and more people want to live in cities where both land and construction is expensive.

YC is trying to build new cities, and I was hoping to catch their eye here.</comment></comment>


Shunting-yard algorithm - <AUTHOR> https://en.wikipedia.org/wiki/Shunting-yard_algorithm <comment><USER2> My blog links to some runnable Python code for this algorithm, with tests:

 _Code for the Shunting Yard Algorithm_ [http://www.oilshell.org/blog/2017/04/22.html](http://www.oilshell.org/blog/2017/04/22.html)

[https://github.com/bourguet/operator_precedence_parsing](https://github.com/bourguet/operator_precedence_parsing)

It seems like there are 2 common algorithms for expressions: the shunting yard algorithm and Pratt parsing [1]. As best as I can tell, which one you use is a coin toss. I haven't been able to figure out any real difference.

They're both nicer than grammar-based approaches when you have many levels of precedence, like C.

But it doesn't seem like there is any strict relationship between the two algorithms, which is interesting. I guess there are other places where that happens, like there being at least two unrelated algorithms for topological sort.

Trivia: The original C compilers used the shunting yard algorithm. IIRC the source made reference to Dijikstra.

[1] [http://www.oilshell.org/blog/2017/03/31.html](http://www.oilshell.org/blog/2017/03/31.html)

<comment><USER3> _I haven 't been able to figure out any real difference._

The biggest difference is that Pratt/precedence climbing does not require manipulating an extra stack, but instead uses the normal procedure stack in the same manner as recursive descent. This leads to somewhat simpler code. I've seen far more uses of recursive descent/Pratt than shunting-yard.

<comment><USER2> I understand that, but I think it's mostly a matter of opinion ("somewhat simpler"). It seems like the code comes out the same length either way, and they're both linear time algorithms.

I can't imagine any case where a user will care -- it's an internal detail. Whereas there are places where a user would notice if you used a CFG vs. a PEG.

A long time ago, people might have been concerned about the recursive calls of Pratt parsing, but it seems like a non-issue now.

I do think Pratt parsing is easier to understand, but that might be because I encountered it first.

<comment><USER4> I first tried shunting yard without knowing what it was by mechanically translating the stack usage from a Pratt parser, so I agree.

The reason was that I'd extended it to handle a lot more unusual constructs, and at that point the recursive version got much harder to read.

It was part of a (ill advised, probably) attempt at using it to parse an entire C-like language, control structures at all. It worked, but it was painful to figure out all the precedence rules, and e.g. if I remember correct modelling if () {} else {} as operator "if" with operands (condition if-block else-expression).

The changes to allow weird prefix operators like that with multiple operands were otherwise reasonably straightforward, though, it was the precedence table that got really hard to reason about.

[I wish I still had the source; it was a fun, though very much dated, project, that allowed arbitrary inline M68k assembler in expressions (e.g. you could write "if D0.W == $1000 { }" to compare the lower 16-bit word of data register 0 to hex 1000), with "mentioning" the registers making the register allocator treat them as off limits for that scope]

<comment><USER2> I don't think Shunting Yard and Pratt are equivalent in that way -- i.e. replacing procedure calls with an explicit stack.

When I wrote "Pratt Parsing and Precedence Climbing Are the Same Algorithm", multiple people replied and suggested that the Shunting Yard algorithm is also the same, with the equivalence you suggest.

In particular the author of the repo Jean-Marc Bourguet also thought that. Then he implemented it and realized it wasn't true.

See this section of the README:

[https://github.com/bourguet/operator_precedence_parsing](https://github.com/bourguet/operator_precedence_parsing)

 _I had the mistaken impression that they were "just" replacing an explicit stack with the call stack of the implementation language but that was not clear enough from Andy's code. It was not clear because that's not the case. Compare Pratt's algorithm with recursive_operator_precedence.py, which is a recursive implementation of operator precedence, to see the difference. Pratt and operator climbing are really top down techniques: they call semantic actions as soon as possible, they don't delay the call until the whole handle is seen as operator precedence does. My current characterization is that they are to LL parsing and recursive descent what operator precedence is to LR and shift-reduce_

I think we had a discussion about an analogy LL vs. LR. Those are obviously not equivalent algorithms -- despite both being linear time, they recognize different languages.

I think in the Shunting Yard algorithm, when you parse 1 + 2 / 3, the 2 / 3 tree is made first. I guess that is somewhat true of Pratt parsing too for natural reasons of tree building. You build the tree when you bubble out of the recursion.

But it DECIDES that it has "led" for + before it decides it has "led" for /.

So in summary, Shunting Yard "decides" 2 / 3 first, where as Pratt parsing "decides" 1+... first. That's what I think anyway. I think you could probably make this rigorous, but I'm not sure.

I think of Pratt Parsing as LL(2) parsing for an operator grammar, although that's not technically correct because the precedence table is an extra piece of info outside the "grammar". You either lookahead 1 or 2 tokens, for null and led respectively.

So basically I think you could translate Pratt parsing to use an explicit stack -- but then you'd still be using Pratt parsing. The Shunting Yard algorithm is something else.

<comment><USER4> I believe you're right for the recursive version (though a recursive version of shunting yard makes very little sense), but this distinction largely evaporates with an explicit stack.

E.g. Pratt is basically writing a generic recursive descent component ("parse left; parse operand; parse right") and then passing down a precedence where you terminate the subtree parse. That's a large part of the appeal - it slots seamlessly into a recursive descent parser without looking "alien", and it was what I started with. It's nice because it is top down.

The naive way of making the stack explicit here is to "push" a fake stack frame when you would have recursed, and pop when you would have exited. But to do all tree of the parse_left/parse_operand/parse_right triple this way you then need to push additional frames to run those steps one after each other, and you end up with something really ugly. But if you trace the processing of those additional frames, what you will see then is quickly that you can drop them by just splitting the stack into operands and operators. Then you have shunting yard.

So you're sort of right that a naive translation of Pratt that retains the top-down nature of recursive Pratt is distinct from shunting yard, but once you simplify it the before/after distinction evaporates, as there's nothing in between to make the decision before/after.

I think the distinction is large enough that it makes sense to treat them as different algorithms, but the transformation is still mostly a mechanical exercise. Each step is fairly straightforward.

</comment></comment></comment></comment></comment></comment><comment><USER5> This algorithm is great.

I was working on a new metric alert evaluation system and built an expression parser for things like:

        system.disk.free{*} / 1024 by {host}

The naive approach to parsing will result in the wrong order of operations, since they'll just be done in the order they appear:

        x + y * z   =>   (x + y) * z

Rather than:

        x + (y * z)

As it should be. The shunting yard algorithm will rearrange the expressions.

After implementing it I noticed my results were different than the reference system... and that's when I discovered we did arithmetic wrong in the main app and had for years.

So I had to hard code a toggle for whether to do math properly :(. It's a sort of Hippocratic oath when it comes to these things... first do no harm, and even if it was wrong, people were relying on the existing functionality, and changing it would likely result in sudden alerts for folks.

In the end we did fix it in the main app, but you always feel kind of dirty writing code like that.

<comment><USER6> Just the other day I was thinking about how all this infix business is needlessly complicated and leads to subtle bugs and hard to understand code. Like every time I encounter an uncommon operator in some language I have to lookup its precedence. So much time wasted trying to satisfy this silly familiarity with math notation. Only imagine how much easier things could be if all infix operators were, for example, left associative and had the same precedence. No more parsing bugs, no implicit orders and behaviors to remember, consistent order, even more natural and familiar than the math notation allowing to focus on things that matter and forget about dealing with precedence and associativity.

<comment><USER7> I've always thought it would be cool to have a language where functions were tagged as distributive, associative, symmetric/commutative, and monotonic and the optimizer (and editor!) used these properties to determine optimizations or simplifications. Note that this would be for all expressions, not just arithmetical ones.

I vaguely recall hearing about some fancy C++ template based techniques for accomplishing this, actually, but haven't looked into it.

<comment><USER8> Swift has operator precedence levels, and you are free to use them for your own operators: [https://developer.apple.com/documentation/swift/swift_standa...](https://developer.apple.com/documentation/swift/swift_standard_library/operator_declarations)

</comment></comment></comment></comment><comment><USER9> I implemented this as a class assignment in Univac 1100 assembly language in the late 70s. I always thought it was a cool algorithm. I had an HP scientific calculator at the time and was a fan of RPN.

</comment><comment><USER10> It's a neat algorithm :) When learning Go I made an implementation of Shunting-Yard at some point: [https://github.com/DylanMeeus/GoPlay/blob/master/ExpressionP...](https://github.com/DylanMeeus/GoPlay/blob/master/ExpressionParser/Infix/infixparser.go)

As part of something else I was trying. As I was just learning Go at that point, the code is not that clean :D But AFAIK it did work. My memory is a bit hazy on that :)

</comment><comment><USER11> This is one of those algorithms that everyone should understand or memorize. I had variations of this algorithm in the coding interviews or coding challenges of 6 companies (!) my last cycle.

<comment><USER12> > This is one of those algorithms that everyone should understand or memorize.

Understand... perhaps; it is a fascinating algorithm. It's also not complicated at all.

Memorize? Perhaps for code challenges, interviews and special occasions like that... but I haven't found it to be useful enough to commit to memory because in order to parse truly arbitrary expressions, you need to remember much more than just the the shunting yard rules.

I say this as someone who authored a mathematical modeling DSL in grad school and had implement this algorithm to correctly parse arbitrarily complicated math expressions. I was deep in the weeds of this. But I don't think I would have been able to reproduce it from memory even during that time. (also, I had to implement a more general version of the algorithm that dealt with function composition, multi-argument functions, unary operators, special keywords like sum/product over sets, etc.)

Of course nowadays I'm so lazy that I just do "import asteval" in Python. The reason is that once you get beyond the simple operators, arbitrary math expression parsing can be quite hard to get right, and I prefer using something that's heavily tested with no unhandled corner cases.

<comment><USER13> A good way to rederive table-driven expression parsing on the spot is to start with recursive descent and notice how it makes a recursive call for every level of precedence, even the levels where "nothing happens" because there's no operator of that precedence level at this place in the input. Use the table to call the "right place in the grammar" directly. This works out to be the precedence-climbing algorithm.

I guess you'd get to the shunting yard from there by turning the remaining recursion into an explicit stack, but I haven't worked that out to check.

<comment><USER12> That sounds about right. I usually use this simple snippet as my starting point [1]. As you can see, to implement a working stack evaluator one has to do a little bit more than just handle infix operators.

[1] PyParsing Simple Calc - see the evaluateStack() function. [https://github.com/pyparsing/pyparsing/blob/master/examples/...](https://github.com/pyparsing/pyparsing/blob/master/examples/SimpleCalc.py)

</comment></comment></comment></comment><comment><USER14> Hah, a few years ago I learned Go by building a simple programming language (super basic with Lua-like syntax) and definitely used this article to help me. I made a slight modification so it could support functions with multiple arguments. Fun times.

[https://github.com/bhoeting/blast/blob/master/parser.go#L82](https://github.com/bhoeting/blast/blob/master/parser.go#L82)

</comment><comment><USER15> I was hoping for an algorithm that solves railway shunting problems. Anyone know of something that does that?

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

<comment><USER5> This is really interesting. Found: [https://www.researchgate.net/publication/225576076_Shunting_...](https://www.researchgate.net/publication/225576076_Shunting_for_Dummies_An_Introductory_Algorithmic_Survey)

I wonder what real railway yards do.

</comment></comment><comment><USER7> The original paper is a good read to get some insight into the thought process: [https://www.cs.utexas.edu/~EWD/MCReps/MR35.PDF](https://www.cs.utexas.edu/~EWD/MCReps/MR35.PDF)</comment>


Columbia MFA Students Demand Full Tuition Refund - <AUTHOR> https://www.columbiaspectator.com/news/2018/04/30/with-decrepit-facilities-and-missing-faculty-mfa-visual-arts-students-demand-tuition-refund/ <comment><USER2> > "It's almost criminal to endebt a student $100,000 to be a painter or a > performance artist"

I agree and will never understand the students, parents, and faculty who choose to support such a system.

</comment><comment><USER3> The source reporting can be found here: [https://www.columbiaspectator.com/news/2018/04/30/with- decre...](https://www.columbiaspectator.com/news/2018/04/30/with-decrepit- facilities-and-missing-faculty-mfa-visual-arts-students-demand-tuition- refund/)

Submitters: Please, always link to primary sources if possible.

<comment><USER4> Changed from [https://hyperallergic.com/440469/columbia-university-mfa- stu...](https://hyperallergic.com/440469/columbia-university-mfa-students- demand-tuition-refunds/), thanks

</comment></comment><comment><USER5> Columbia MFA programs are notorious for being cash cows. Everyone who does a little research understands this.</comment>


Ask HN: How to find problems to build a business around? - <AUTHOR> Whats the best, exact eay, to identify a problem that one can build a solution for which people would pay for? <comment><USER2> Well, there's a couple of ways. First, and easiest: copy someone's proven idea. Something you can do, you'd love to to, is proven to make money, and the margins work for you. Bonus: if you can do it better, cheaper, faster. This is the safest route.

Second, pick a problem you, your close family members, or your close friends have. A problem that's painful enough that they'd pay for, interesting (for you) enough that you can spend a few years solving, and practical enough that you can do it with the means you have today (i.e no investment). If it's a "new" idea, it's a lot of risk.

For most people, a small, niche, proven idea that makes money is good enough. It'll take a few years to try a bunch of experiments and see money, though. Grind it out...

</comment><comment><USER3> A fun way to poke around is to search twitter for the phrase "I wish there was a"

<comment><USER4> Some more variations

"I wish there was a " app. "I wish there was a " webapp. "I need a app". "I want a app".

<comment><USER5> Got some great ideas already.

[http://imgur.com/dTx9o7q](http://imgur.com/dTx9o7q)

</comment></comment></comment><comment><USER6> Get a job, preferably not in tech (but still doing tech), and spend months/years figuring out what works or doesn't work.

<comment><USER7> Could you elaborate on this one?

<comment><USER8> Seems quite straight forward, to find a problem worth solving - you need domain knowledge.

<comment><USER6> Yup. Business problems only rear their ugly heads after you've immersed yourself in the daily work AND if you reflect critically on what you're doing. This usually takes time because when you first start working you usually don't even know what you know or don't know.

</comment></comment></comment></comment><comment><USER9> subscribe to oppsdaily( [http://oppsdaily.com/](http://oppsdaily.com/) ) and nugget one ( [https://nugget.one](https://nugget.one) ) also pay them something so that the good service continues..

<comment><USER10> I did that a few weeks ago, but I think the "one email a day" format is really bad for such a thing, it's just too slow to find something that suites you.

It's probably a bit like dating.

I'm using dating websites since 2002 now, leaving one, joining another, using about 3-5 simultaneously.

I find like... 4 interesting women a year and only 1 in 2 years finds me interesting.

And most women I had relations with, I met outside of these portals.

<comment><USER11> Sign up to nugget paid and you get access to 350+ ideas for $20

</comment></comment></comment><comment><USER12> Take current trends, extrapolate and determinate:

-which business will vanish and how will today's customer migrate

-What are the currently growing company's hiring, and what is amiss to replace this jobs, yet again?

-What is missing in modern life, and how could a app re-engineer social-life and society to provide it? The last one is the most noble, but also the most tricky.

</comment><comment><USER13> I've been messing with Mechanical Turk a bit, getting a feel for the platform, as I have some ideas I could use it for. When I was in worker mode yesterday I saw a task that asked the question that oppsdaily seems to be sending out to people: "What problem do you face at work that software might be able to fix?"

Pay people for their ideas!

</comment><comment><USER14> There is no one way to do this. Everyone does it differently.

Keep in mind that finding a thing you can monetize does not mean it is a thing _you_ would be good at or that _you_ would want to work on for years. Yet, those two pieces are critical to the equation.

</comment><comment><USER15> Identify your own problems. The reason is you have a much better understanding of what _you_ and therefore your target user would want. Fixing someone elses problem requires working very closely with that person.

</comment><comment><USER16> I don't think you're going to find an exact, repeatable, cookie-cutter approach to this, because if there was one, somebody would already be using it (and they probably wouldn't share). But while there isn't necessarily _an_ answer, there are plenty of answers to be had, some of them trivially obvious.

So break it down... who do you think has problems? Well, businesses for one. So think about businesses. What do businesses need? Well, they usually need more customers. Or maybe they need to reduce costs. Or both. So think about how the technology you're familiar with could be used to help a business find more customers, or operate more efficiently.

Of course doing this in detail is going to be easier if it's a domain where you have personal experience, but if you don't, just come up with an idea, and then go talk to people about it. If you feel really strongly about it, maybe build a prototype to show off. But be careful of spending tons of time building something before you know if anybody wants it (note: I haven't always followed my own advice here. Also, never take advice from me.)

Another element is: read books. Lots of books. Preferably books about business (sales, marketing, promotion, operations, organization design, strategy, etc.) This will help give you the understanding needed to link technology with business problems like "find more customers" or "reduce costs". What you read in books will always be somewhat non-specific though, so you have to - again - loop back to "talk to people. Lots of people."

If a particular industry interests you, read up on it specifically. Subscribe to the trade journals in that industry, and go to the conferences and trade shows that people in that industry go to. Talk to people there.

Read _The Four Steps To The Epiphany_ by Steve Blank.

Use LinkedIn to find people to connect with and talk to. Favor having actual conversations with people over doing surveys using SurveyMonkey or the like.

If you do enough of all this, at some point, you'll probably come up with a pretty good list of possibilities.

Note that while this is pretty _simple_ , it's not _easy_. People won't return your phone calls or emails, or will agree to meet you and then not show up. You'll come up with what you think is a great idea, then start looking around and find that 375235028372512.7 other companies are already doing something in that space. Or you'll fall in love with one of your ideas too early, spend a ton of time building it, and then find out that that A. nobody wants it AND B. 375235028372512.9 other companies already built something similar. Etc., etc., etc. Don't get discouraged, just keep plugging. Read this essay by pg: www.paulgraham.com/die.html

</comment><comment><USER17> This may be shocking to HN readers but go offline. Crazy idea, right? Join a business networking group, talk to people, and put yourself out there.</comment>


The Value of Being Transparent, Especially When It's Hard - <AUTHOR> http://blog.statuspage.io/the-value-of-being-transparent-when-its-hard <comment><USER2> The links in this article go to some very good case studies on getting the correct tone for downtime status updates.

However, I found the most interesting link the one about open salaries [1] - are there any other businesses doing similar things? I'd be inclined to consider it a very strong mark in their favour as a workplace.

[1] [https://open.bufferapp.com/introducing-open-salaries-at- buff...](https://open.bufferapp.com/introducing-open-salaries-at-buffer- including-our-transparent-formula-and-all-individual-salaries/)

<comment><USER3> Good question -- I personally don't know of anyone else who is doing the whole "Open Salaries" thing. Does anyone else?

<comment><USER4> Ironically, I think all government agencies have open pay scales and everyone knows exactly how much everyone else makes.

<comment><USER5> Open pay scales are a start, but non-transparent salaries can easily hide in there if all you have is pay scales.

You need two things for actual salary transparency:

1) Everyone's actual salary is accessible - as in, the actual amount they're paid each month, the transaction. This way everyone can _know_ that there's nothing unfair hiding in there.

2) The reason why everyone's salary is what it is is transparent and accessible. Otherwise, the unfairness moves to how people are assigned to different salary bands. "John got assigned to Salary Band E3 because he plays golf with the boss" should not be a possible scenario. If it is, you don't have transparent salaries.

Compensation isn't just made up of numbers, it's made up of explanations too.

<comment><USER6> I think this level of detail is pretty good, even though it doesn't have specific transactions necessarily:

[http://seethroughny.net/index.php?cID=375](http://seethroughny.net/index.php?cID=375)

AFAIK this is compiled by a non-governmental organization however.</comment></comment></comment></comment></comment>