I, Pencil (1958) - <AUTHOR> http://www.econlib.org/library/Essays/rdPncl1.html

<comment><USER2> [http://www.fee.org/library/detail/i-pencil-audio-pdf-and- htm...](http://www.fee.org/library/detail/i-pencil-audio-pdf-and-html) is the 50th anniversary edition with foreword and afterword, and audio and PDF versions.

</comment><comment> torrent-of-ions A nice read but I don't agree completely with the final paragraph. The invisible hand uses a greedy algorithm. It does take a mastermind to get close to any kind of optimal solution in many cases. We can't trust the invisible hand to provide healthcare to everyone, nor can we trust it to take into account external costs like pollution etc.

<comment><USER3> The invisible hand isn't in the business of making moral judgements external to those of the society in which it exists. If people wish to support each other's healthcare, then they're quite capable of doing so without any external assistance.

Regarding pollution, it's interesting to note that in America at least it was originally considered a tort (if someone harmed you by polluting, you could sue them). But various judges have, in the name of the 'common good' of industrialisation, eroded this right.

<comment><USER4> I think it's important to keep in mind that people acting to support each other's healthcare without external assistance is one of those things that government _is_. After all, European societies with solid health systems did not require external intervention by aliens or anything to do so. They just agreed that having such a system is a good thing, and the government happens to be a useful framework for implementing it (and keep in mind that a lot of healthcare-related stuff is actually private in Europe, depending on which country you're talking about).

Overall, "government vs. markets" is a false dilemma. Markets need rules, and to a large extent, the historical evolution of governments goes hand in hand with the evolution of markets. Your pollution example fits this observation nicely.

Another important point in the context of the original submission: A lot of discussion in society in this realm is confused about the centralization- decentralization and class/power structure axes. Those are largely independent, but people from all political backgrounds tend to muddle them up. [0]

The pencil story is a nice illustration for why completely centralized control of the economy would be a disaster. However, it is often brought into (mostly laypeople's) political economy discussions where it really has no place, because most such discussions are not about centralization vs. decentralization.

Most political economy discussions are (albeit usually in a hidden way) about class structure and power. Should there be a (necessarily tiny) class of capital owners who own and control the means of production and who, using this control, will be able to wrest for themselves a disproportionally large share of the economy's output? Or should power be distributed more evenly, along democratic lines?

Ownership, control, and (de-)centralization are largely orthogonal. To give a concrete example, one could easily imagine a functioning, decentralized economy in which companies compete in the market place much like they do in the Western world today; but with the important difference that companies are (as a rule) not anybody's property, and that decisions within the company are made through a (probably representative) democratic process in which every employees has one vote.

Such an economy would have vastly different distributive outcomes, but it would still be a decentralized economy that takes all the lessons of "I, Pencil" to heart.

[0] This is particularly annoying when people on the left do it. At least people on the right have a motive for muddling these things up.

<comment><USER3> There is however a link between centralisation and distributive outcomes in the sense that the former is necessary to ensure certain forms of the latter. If for instance the democratic companies in your thought experiment were somehow structurally less competitive in the market than companies led by a single CEO (I'm not suggesting this is the case, just using it to illustrate), then in a decentralised system the CEO-led companies would outcompete the democratic ones and naturally come to dominate the market.

It would hence not be possible to bring about the distributive outcomes of a market dominated by democratic companies without some centralised force capable of granting the democratic companies some advantage over the CEO-led ones.

In short, if a decentralised economy necessarily leads to greater concentration of wealth/power (again, I'm not suggesting it does), then people arguing for a more even distribution of wealth/power must necessarily also argue for a more centralised economy.

<comment><USER4> I liked your comment, thank you. I don't quite agree though, because I get the feeling that you're not really talking about centralization of the _economy_ , but about the centralization of _power_.

True, enforcing a decentralized economy in which company decisions must be legitimized by employees' votes requires a centralized power.

However, the same is true for almost every kind of economy that has any hope of functioning at all. For example, our non-democratic companies of today rely on workers not simply seizing the means of production for themselves. Why don't workers in, say, a car company not decide one day to shut out the owners? The most immediate explanation is that they have been conditioned by society not to do that. But it's important to keep in mind that our economy relies on the existence of a centralized power that would ultimately lock those workers up in prison if they decided to kick the owners out.

It's easy to miss this fact because of status quo bias, but ultimately, it seems that _every_ stable form of societal organization ends up relying on _some_ form of centralization of power.

This all comes to a head in your last paragraph. If the premise of that paragraph is true, then the people need not argue for a more centralised economy. They can stay with a decentralized _economy_ , but they must argue for some action by centralized _power_.

<comment><USER3> That's a good point. I think however that proponents of economic decentralisation would argue that it requires 'less' centralisation of power than economic centralisation (assuming centralisation of power can be quantified).

How is this so? Classical liberals argued that the fundamental duty of government was protecting its citizens' lives and property rights from each other and from foreign aggressors. This would largely take place through the courts: if someone attacked you, or stole your property, or rose up and took over your factory, you could sue them, and the State's only role would be enforcing the court's judgement.

This thus would lead to a relatively decentralised power structure, with most power lying in the courts via their interpretation of the constitution / 'natural law' (a bit like English common law) and the executive having relatively little influence.

From this it follows that arguments for any economic structure other than "an economy the structure of which is purely determined by what occurs when the State only protects property rights" necessarily require more centralisation of power, as the State would be required to do more than just protect property rights.

Assuming that by some intrinsic property that "an economy the structure of which is purely determined by what occurs when the State only protects property rights" is likely to be a more decentralised one, then arguing for a centralised one thus entails arguing for greater centralisation of power.

Of course, this ultimately depends on the exact form the property rights in question take, but I think it's reasonable to suggest that for any particular set of rights, a State based solely around defending those rights would involve less centralisation of power than one based upon ensuring the existence of a particular economic or social structure.

'Victimless crimes' are an example of this: they wouldn't exist in a purely rights-based legal system as there'd be no parties whose rights were violated by these activities, so such things as the immigration department and the departments required for the war on drugs simply wouldn't exist.

</comment></comment></comment></comment></comment></comment><comment><USER5> Political arguments aside, I think it's a beautiful description of how complex and interdependent our economy is.

</comment><comment><USER6> Here's the tl;dr version, animated, and with a fun soundtrack!

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

<comment><USER7> Or an even more tl;dr version

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

<comment><USER8> Exactly what I was thinking about as a I read the essay! I was disappointed when instead of being about how incredible it is that the cosmos can produce a pencil, it was about claiming that the cosmos can do it "without the government."

</comment></comment></comment><comment><USER9> Henry Petroski's excellent book The Pencil[1] uses the same subject to explore the history of the pencil's development into the common artifact we know today.

[1][http://www.amazon.com/The-Pencil-History-Design- Circumstance...](http://www.amazon.com/The-Pencil-History-Design- Circumstance/dp/0679734155)

</comment><comment><USER10> How It's Made: Pencils ([https://www.youtube.com/watch?v=b5uUV9z7hfg](https://www.youtube.com/watch?v=b5uUV9z7hfg))

</comment><comment><USER11> Came across a computing version once upon a time: [https://plus.google.com/+JeanBaptisteQueru/posts/dfydM2Cnepe](https://plus.google.com/+JeanBaptisteQueru/posts/dfydM2Cnepe)

</comment><comment><USER12> This was the first thing my Econ professor made us read. Best econ class I've taken.

</comment><comment><USER13> More submissions like this, please.

</comment><comment><USER14> This is, well, shallow propagandising guff. It promotes an agenda but diverts criticism with mythologising illusion.

Markets fail in various ways. Should we just let that happen? -- and just have 'faith' in the wonder of ' _freedom_ ' etc.? As Stiglitz says, a common reason why 'the invisible hand' is invisible is because it is not actually there.

<comment><USER15> Yes, markets should be allowed to fail. It is part of a very natural and successful process that has brought us to where we are. The same goes for governments. It's a trial and error process that goes back to the beginning of life. There is an anaology I really enjoy which relates the idea of saving economy and markets from the natural process of failing:

"In the 1970s the US developed a policy of forestry that espoused 100% prevention of forest fires; let's call it "fire is not an option". This policy resulted in the systemic suppression of small fires and eventually into very unbalanced forest ecosystems where fire is now not just an option, but a certainty of disaster. We now know that fire is a natural part of a forest's life-cycle. Without fire, the forest floor gets overgrown, making it a source for bigger and hotter fires. When fires break out in a "managed" forest where fires have been suppressed for years, they burn so hot they turn the ground to glass. Fires that were survivable by trees are now so destructive that they denude hills and wipe out the entire ecosystem. Our financial system has become much like a poorly managed forest, harboring within it the increasing probability of a systemic and destructive conflagration."

Just as no single person knows how to create a pencil, no single person, or group of powerful individuals, have any idea of the complexities that exist when deciding how to guide an economy. It's naive to think otherwise.

From: [http://antonopoulos.com/2014/03/02/failure-is-an- option/](http://antonopoulos.com/2014/03/02/failure-is-an-option/)</comment></comment>


Ask YC: Company Blogs - <AUTHOR>

I've been thinking about the obligatory "blog" link that goes on the front page of a new site.  I don't know if I should roll my own simple blogging system (my site is RoR) or use some canned engine that has more overhead, but is tested and reliable.  What do you guys think?  What has worked for you in the past and what are the pros and cons of each? <comment><USER3> For this sort of application I always recommend a hosted blogging service (wordpress.com, tumblr.com, blogger.com, etc) so that if something affects your servers, you still have a way to communicate with your clients//community.

<comment><USER4> Good point. Both arguments (mine regarding hosting your own blog, and yours) are quite valid.

I assume this means linking to it on your site. But if your server goes down, your users won't be able to get to it anyways, unless they have your blog address memorized or bookmarked.

Your site should never be allowed to go down for long, unless something major happens, in which case a backup plan is ideal. I would host my own blog, and if my server does go down, redirect the domain to a stable site with a brief explanation of what's going on, and then when every thing's back to normal post about it in the company blog.

<comment><USER5> Users will be able to find it, because if your blog is on a different domain, it will probably be somewhere on the first page of google results when you search for your company.

I would just keep the blog somewhere like wordpress because they will have a more fully functional blogging engine. Don't spend your time managing your blog software, spend it making your product better.

<comment><USER4> I guess the best way would be to have blog.yourdomain.com redirect to yourblog.bloggingwebsite.com.

</comment></comment></comment></comment><comment><USER4> Whatever you do, I would suggest putting it on your own site (a sub domain, like blog.yoursite.com) instead of a hosts (like companyblog.blogspot.com). It just feels more professional that way. There's a higher level of quality compared to the generic feel of a hosted blog.

<comment><USER6> I'd agree. If you're going to go to the trouble of writing a blog, you should own and control the domain.

</comment></comment><comment><USER7> Wordpress. Good developers create, smart developers reuse.

<comment><USER8> I contest. Sayings will only get you so far.

Would you disagree that plenty of smart developers create and plenty of good developers reuse?

<comment><USER9> GPP's phrasing seems to be non-mutex such that it explicitly does _not_ say that, e.g. "smart developers do not create"

Maybe a more encompassing way of stating the saw would be "while a good developer can create what is required, a smart developer will use what is provided"

</comment></comment></comment><comment><USER10> WordPress (and others?) is perfectly good. No point in wasting time reinventing the wheel (unless that's your kind of thing).

Throw together a template to match your company website if you want.

</comment><comment><USER11> This may be off-thread to some but I believe it is very applicable - <USER2> not the platform gives the blog value to your customers and customer developers.

For a great example, read <http://blogs.smugmug.com/don/> (one of my favorite blogs in terms of technical and personal communication)

</comment><comment><USER12> We made a blogspot blog in about 10 seconds. <http://tipjoys2cents.blogspot.com/>

I'm going to roll my own semi-blog that will be a bit different style.

With comments by disqus, almost any home brewed site can act like a blog.

<comment><USER13> Maybe it's just me, but I don't take Blogger blogs seriously, at _all_.

<comment><USER12> Why not? The text I want to publish gets pushed out to the page.

Extensibility of other platforms means little to me, as the more interesting features I'd need to implement myself.

<comment><USER12> <http://paulbuchheit.blogspot.com/>

<comment><USER14> lol. i was about to mention that site :)

</comment></comment></comment></comment></comment><comment><USER15> I would use blogspot and a custom subdomain. As aaroneous said the blog will keep up if your servers go down, and also you will save headaches and time that you can use on growing your product.

The only problem I've with blogger is their template system, I simply don't like it.

</comment><comment><USER16> Hosted wordpress has worked out for us. Customization is limited-- and no JavaScript widgets of any kind are allowed.</comment>


Sinful Robot [NSFW] - <AUTHOR> http://www.sinfulrobot.com/

<comment><USER2> Congratulations! You have finally prompted me to register for HN, after over a year of lurking, in order to post the following comment:

Please put a NSFW notice on this title - or, if it's not feasible to do so, remember to put NSFW in similar future titles.

Otherwise, intriguing idea!

<comment><AUTHOR> Sorry about that.

</comment></comment><comment><USER3> I'm certainly intrigued to see what commercial opportunities the Oculus Rift opens up. It seems like it might finally be the device to kick off the whole immersive-VR-without-feeling-sick market.

Sex will be an interesting one although in the rather digitally stylized forms we can see on this site, the target audience would be rather specific..

</comment><comment><USER4> Intriguing concept, but for those of us in offices an NSFW notice would not go amiss.</comment>


55000 pieces of wolfram alpha feedback first mover advantage - <AUTHOR>

Do you think that with considering the feedback rate, that wolfram alpha will get a huge first mover advantage after a few iterations of feedback have been implemented? <comment><USER2> In what field is it a "first mover"?</comment>


The Music Industry Shouldn't Be Able to Cut Off Your Internet Access - <AUTHOR> https://www.eff.org/deeplinks/2016/12/music-industry-shouldnt-be-able-cut-your-internet-access <comment><USER2> I thought this "cut off your internet" thing had died circa 2007 with the draconian, yet endearingly-condescending "three-strikes-you're-out" push from the record industry. In a world where internet access has long since become a basic requirement to function in civil society, how is this still a conversation?

<comment><USER3> You can just switch to another ISP!

<comment><USER4> I literally can't switch. I live in one of the biggest cities in the world, and the ISP's here have carved it up into neighborhood level monopolies. I have one option.

<comment><USER5> I much prefer the UK model. BT Openreach wire up the infrastructure and take care of the telephone exchanges, and then ISPs compete to provide their services on the lines. To be fair, they have been slow rolling out fibre into rural areas, but most exchanges now have a choice of 10+ ISPs for prices equivalent to $25 a month.

Why aren't you all protesting about being tied into such oligopolies? America is supposed to be about free markets and open choice.

<comment><USER6> > Why aren't you all protesting about being tied into such oligopolies?

To be fair, you've just replaced a oligopoly with a monopoly.

Openreach is a government-controlled monopoly, but US telecom is heavily regulated too. Both charge what the government lets them.

As you point out, rural support is a lot less if no one can recoupe infrastructure expenses. The UK has 5x the population density of the US.

So...you might be right, but it's not a clear-cut answer from basic principles.

<comment><USER7> Communications infrastructure naturally tends towards a monopoly - it makes very little sense for thirty different companies to run wires to your house, on the off chance that you'll choose them over a competitor.

The advantage of the Openreach model is that the last-mile infrastructure is treated like a public good. Anyone can lease bits of that infrastructure and everyone pays the same regulated rates. The system ensures that the monopoly is as small as possible, segregating out the stuff that's a natural monopoly from the stuff that naturally supports competition.

Thanks to Openreach, I have a meaningful choice over my internet service. I can choose dirt cheap service from a multinational, or I can pay a premium for specialist service. If my ISP starts doing traffic shaping or has lousy customer support, I can choose from any number of other ISPs.

<comment><USER6> > Communications infrastructure naturally tends towards a monopoly

Agreed, but suggesting "America is supposed to be about free markets" therefore it should have a monopoly isn't a compelling argument.

It should be a monopoly despite the normal free market model, not because of it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Yet in New Zealand they can :(

[https://en.wikipedia.org/wiki/Copyright_(Infringing_File_Sha...](https://en.wikipedia.org/wiki/Copyright_\(Infringing_File_Sharing\)_Amendment_Act_2011)

<comment><USER9> This law is sort of interesting. I don't think anyone came out particularly happy with it.

If I remember correctly it was sort of pushed upon us by US pressure so the legislators didn't really like it, it added extra work so the ISPs didn't like it, as a result of that the law has a $25 fee for administering a "strike" to someone, which the copyright holders don't like because they can't so blindly send out mass strikes. The strikes also expire after 9 months. And obviously the people don't like it either.

The maximum fine is capped at $15,000NZD (~$11,000USD) and the average fine in practice has apparently been around $500NZD (~$350USD). As of 22 November 2013 17 people had got their three strikes and received their fines[1]. I wonder what the total is now.

Re actually cutting off your Internet access though, I'm not sure. Thing is, that was temporarily in there and was later removed, as Section 92A in the Copyright Act. You can see it marked as [ _Repealed_ ][2]. But then section 122B seems to say your Internet can still get cut off. Maybe someone can shed some light on that one.

[1] [https://www.lawsociety.org.nz/lawtalk/lawtalk- archives/issue...](https://www.lawsociety.org.nz/lawtalk/lawtalk- archives/issue-832/infringing-file-sharing-two-years-on)

[2] [http://www.legislation.govt.nz/act/public/1994/0143/latest/D...](http://www.legislation.govt.nz/act/public/1994/0143/latest/DLM345634.html)

<comment><USER8> It would seem that the ISPs had a significant compliance cost as well.

"On 23 July 2012, despite the policy intent of making the issuance of copyright infringement notices under the legislation inexpensive, Telecom New Zealand revealed that under the new regime, it had cost them $534,416 to issue only 1,238 notices - or approximately $438 per notice, although this cost figure is not evidenced by any audited breakdown. The copyright holders are required to pay a fee of $25 to have the notices issued"[1]

[1][https://en.wikipedia.org/wiki/Copyright_(Infringing_File_Sha...](https://en.wikipedia.org/wiki/Copyright_\(Infringing_File_Sharing\)_Amendment_Act_2011#Criticism)

<comment><USER9> I feel like Telecom may have been boosting the numbers a bit there to try and make the law seem extra bad for them; all they should really have to do is forward a letter.

<comment><USER10> If they didn't already have a database in place of which IPs assigned to which customers during which times, they'd need to set that up. Software dev isn't cheap. Maintenance isn't cheap. They need to write up a procedure on how to handle these notices. They have to verify they're valid (i.e. not just a prank or malicious action).

Compliance costs can add up.

<comment><USER8> Also never underestimate the costs incurred by sufficiently bloated bureaucracy.

<comment><USER11> You've worked for a university too?

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> This happened to myself and my housemate recently, this draconian practice is still alive and well in the USA. We have Service Electric, who uses PenTeleData as their provider, and I can honestly say they are the worst service imaginable.. I'd rather have Comcast.

Neither of us use torrents, we prefer streaming services that have everything we need. Regardless, our internet was turned off without notice two months ago. The most frustrating part was that they didn't tell us, it just went off.. so it took us nearly a day to figure out what was even going on. This included a dozen calls to the ISP trying to figure out what was going on, and the surprising part is that they didn't know! There's more to the story including absolutely most incompetent tech support I've ever seen, but a little over a day later we had it turned back on. We asked what we could do to avoid this in the future, and were told not to torrent.

Fast forward to a few weeks back, our internet turns off again. I call and find out that our internet has been cut off for 72 hours due to torrenting, which turned out to be a TV show. A TV show neither of us watches, so the circumstances are suspect.

When I questioned the operator about this, she flat out called me a liar, with no evidence to support her argument. When I suggested that we might cancel our service because of the poor treatment, she said go ahead. Of course, she knew that there are no other ISPs where we live (out in the woods).

So here we are again, our internet may get turned off permanently and without warning for no wrongdoing on our part. Rather strange times we're living in where scumbag companies can get away with this, ruining peoples lives so they can increase their own profits by 3.2%

Burn in hell, PenTeleData, I'm sure you're monitoring this as well.

<comment><USER12> Oh I'd forgot to mention that were were charged a $10 re-connection fee each time, in addition to being charged for the days when service was not available.

Basically any time they want they can take extra money from you and you have no recourse.

</comment></comment><comment><USER13> I wonder how Hollywood was taken over by lawyers in the first place. The plaintiffs in the Betamax suit are Disney and Universal.

<comment><USER14> Actors and directors used to be owned by the studios. Contract lawyers are not a new thing.

<comment><USER13> I know that these lawyers has always existed.

</comment></comment></comment><comment><USER15> Some routertrojan, erecting a local, for mortals invisible, town-wide tor-net should be enough to end this madness.

</comment><comment><USER16> As long as you don't use your internet access to commit illegal actions, they won't cut anything off.

<comment><USER17> Um...no. If RIAA thinks you did something wrong, even with flimsy evidence, they can still come after you. Should be easier to convince Comcrap to shut off your Internet than get a judge to agree.

[http://www.mediapost.com/publications/article/117419/judge-r...](http://www.mediapost.com/publications/article/117419/judge- rules-that-riaa-had-right-to-sue-woman-wrong.html)</comment></comment>


Germany: US ambassador Grenell should be expelled, says FDP deputy leader - <AUTHOR> https://www.dw.com/en/germany-us-ambassador-richard-grenell-should-be-expelled-says-fdp-deputy-leader/a-47975156 <comment><USER2> Read this DW article, and then this Newsweek [1] article on the same, and then finally one from Breitbart [2].

Aside from the typo in the Breitbart article towards the end, I feel like reading from both vantage points gives a clearer picture of the overall situation.

Without the desire for any flaming, I am honestly curious what people think.

[1] - [https://www.newsweek.com/germany-trump-ambassador-brat- failu...](https://www.newsweek.com/germany-trump-ambassador-brat- failure-1368713)

[2] - [https://www.breitbart.com/national- security/2019/03/19/germa...](https://www.breitbart.com/national- security/2019/03/19/germany-furious-u-s-ambassador-calling-out-low-defense- spending/)

<comment><USER3> Honestly, I don't understand why the U.S. is basically still responsible for the defense of Europe 75 years after the end of World War II. I think we should withdraw all our troops and equipment in a controlled drawdown and let the Europeans figure out how to protect themselves from Russia.

I have nothing against Europe, but I also think they have the capability to defend themselves. It would have the added benefit of making U.S. intervention in the Mideast more cumbersome, which might mean fewer wars.

Also, as an aside, some criticism is warranted imo. It's more than a little ridiculous that the UK spends more on defense than Germany.

<comment><USER4> I don't think the U.S. wants Europe to figure out how to protect itself, or to create a European Union army/navy/air force.

It's another geopolitical block, one that could theoretically challenge U.S. dominance, what with almost equivalent GDP and levels of development and a greater population.

<comment><USER2> GDP is the same, but I would guess they spend significantly less on defense and significantly more on social programs than the US, and fairly unlikely to want to switch that around.

 _In 2016, the EU 's 28 Member States earmarked €200 billion of public expenditure for 'defence'. This is equivalent to 1.3% of GDP. This is much less than the amount spent on social protection (expenditure equivalent to 19.1% of GDP in 2016), health (7.1%) or education (4.7%), but higher than public spending on recreation, culture and religion (1.0%), environmental protection (0.7%) and housing and community amenities (0.6%)._ [1]

By comparison; _US defense outlays amounted to 590 billion U.S. dollars in 2017, which was about 3.1 percent of the U.S. GDP._ [2]

[1] - [https://ec.europa.eu/eurostat/web/products-eurostat- news/-/D...](https://ec.europa.eu/eurostat/web/products-eurostat- news/-/DDN-20180518-1)

[2] - [https://www.statista.com/statistics/217581/outlays-for- defen...](https://www.statista.com/statistics/217581/outlays-for-defense-and- forecast-in-the-us-as-a-percentage-of-the-gdp/)

</comment></comment></comment></comment><comment><USER5> As if the Vassal state can demand anything ...</comment>


Social networking sites: do not pry, says online community - <AUTHOR> http://www.guardian.co.uk/uk/blog/2009/mar/25/myspace-twitter-facebook-monitoring

<comment><USER2> The beauty in social networking sites is that they seem to police themselves. When people see things that disturb them, the point it out to their peers, and if that garners interest, it goes to the site managers. A prime example are "hate pages" that sometimes make it onto MySpace. The community polices and reports the misuse and the page is removed. I don't see any reason for the government to regulate another aspect of our lives...

<comment><AUTHOR> I just got asked (today) to join a Facebook group called "Will Not Pay For Facebook. We are gone if that happens." Curious to see how popular the sentiment is, and how it pans out...</comment></comment>


Italy and the euro zone: That's all, folks - <AUTHOR> http://www.economist.com/node/21538161?fsrc=scn/tw/te/ar/thatsallfolks <comment><USER2> "Between 2001 and 2010 Italy's unit-wage costs soared and its economy grew by less than any other country in the world, except Haiti and Zimbabwe."</comment>


Making an RPG in Clojure - <AUTHOR> http://briancarper.net/blog/making-an-rpg-in-clojure-part-one-of-many

<comment><USER2> Great stuff. I'd just like to add that working with Clojure+OpenGL has gotten a lot simpler with Zach Tellman's Penumbra, <http://wiki.github.com/ztellman/penumbra/>. Penumbra is well integrated with Leiningen so getting an OpenGL app up and running now takes a matter of minutes if not seconds.

I've been porting the Nehe tutorials to Penumbra and it's been ridiculously straightforward. Being able to update OpenGL on the fly via REPL is also really great fun, especially if you're used to the slow and tedious nature of OpenGL programming with pretty much everything else, <http://github.com/swannodette/clj-nehe>.

<comment><USER3> I've just posted an example of using Penumbra to create a simple game: <http://news.ycombinator.com/item?id=1141556>

</comment></comment><comment><USER4> This is one of the best articles I've read for a while. Really interesting insights into the writers thought process while coding.

</comment><comment><USER5> I've played around with making a strategy game in Java/Scala. It was surprisingly easy to work with. I didn't take it too far but performance was adequate (for a 2D, turned based game).

Anyone with experience making a "real" game in Java. I know <http://www.freecol.org/> is built in Java.

Just wonder why it's not more popular for indie/casual games. Does performance degrade that much?

I'm do mostly C# but I wanted to try the JVM for cross platform deployment.

<comment><USER6> I'm writing a Java-based game ( plug: <http://www.metalbeetle.com/spaceexploration/> ). Performance can be very tricky if you want a good screen resolution, and there's lots of gotchas, like having to make sure that you force your sprites into the right colour space for your screen.

On the plus side you get a reasonably fast, garbage-collected language to write your game in.

<comment><USER7> Looks great! I'll definitely be giving this a try.

</comment></comment></comment><comment><USER8> Also useful is 'line of sight' algorithm so the character can 'see'. Basically, you cast out rays of light (in 8 directions or 360 if you want to be really accurate), and when the light beam hits a solid object (a wall, for instance), you stop casting the ray.

All the non-solid objects encountered (eg, grass, tiles) are noted as 'visible'.

What you get is that the character (NPC or human) can see through windows and open spaces, but not through walls. Re-scan every time they move.

</comment><comment><USER9> I like how he said that when the code didn't suck he would release the source, so really we'll never get that code. Wish he'd put it on a git so others could just commit to it.</comment>


A Letter to 37signals - <AUTHOR> http://dear37signals.com/

<comment><AUTHOR> This is my cover letter for the UI design position at 37signals ([http://37signals.com/svn/posts/2925-hiring-were-looking- for-...](http://37signals.com/svn/posts/2925-hiring-were-looking-for-another- ui-designer-to-join-our-team)). View in Safari for the best experience.

<comment><USER2> best of luck! :)

I can't help but think that if your first claim is that you "can design for almost any platform", the experience should be "best" across all major browsers.

<comment><AUTHOR> I designed for the most capable browser (in this case Safari) and then made sure it still worked well in all the others. If Firefox and IE had support for 3D animations then it would look "best" in every browser.

Perhaps I should have said for an extra visual treat use Safari.

For more on this theory of web development you should checkout Hardboiled Web Design by Andy Clarke (<http://hardboiledwebdesign.com/>)

</comment></comment></comment><comment><USER3> doesn't work in chrome, letter is blank.

<comment><AUTHOR> Thanks for letting me know. It works well for me in Chrome for OSX (11.0.696.71), also tested on Windows 7. What version are you using it on?

Thanks for providing some more info.</comment></comment>


Exceptional results: error handling in C# and Rust - <AUTHOR> https://ruudvanasseldonk.com/2015/06/17/exceptional-results-error-handling-in-csharp-and-rust <comment><USER2> > I have written plenty of C# code that deals with exceptions, and it is a > pain to do it correctly. Apart from null, it might very well be the biggest > design mistake of the language.

In user code (as opposed to framework code), Typed Exceptions are overrated.

Let's take these two cases:

1\. End-User: Doesn't care if the Exception is a ParseException or an InvalidVersionException. Exception("Invalid number") and Exception("Version should be higher") is just as good enough for a message. Basically, for the end-user, the app crashed and that's it.

2\. Programmer: Will have to open the debugger or check the code anyway.

I get it that it's useful in some cases, when you wanna send back some structured data to the caller. But in the vast majority of cases, the plain Exception class and Stack Traces suffice.

<comment><USER3> Agreed. I rarely need a typed exception. The purpose of the exception is to say "Stop doing what you were doing, and head up the stack until you find a point where the work can recover from this and carry on."

Generally speaking, that point doesn't care why the bunch of stuff five levels down went wrong. It just wants to report the error, and then either carry on with something, or let the user know what the problem was and decide if they want it to carry on.

Very occasionally, the actual type of the exception is useful. But mostly I just don't care about typed Exceptions.

<comment><USER4> So this is more akin to panics, where you don't really care about handling the error but rather want to stop dead in the tracks. But take something like .NET's SocketException, which contains a SocketErrorCode property; you may very well want to take different action depending on the type of error this is. This may be as simple as changing the text of the error shown to user (with suggestions on how to fix), but could also be some code based recovery that takes different action depending on the type.

</comment></comment></comment><comment><USER5> The author is painting a pretty bad picure of C# error handling that isn't close to reality.

In reality, you would never call uint.Parse and let the exception bubble up, you'd call uint.TryParse and handle the logic for failure in the method. There is almost always a way to write your code so it doesn't throw exceptions. I'm working on a pretty large C# codebase for a SaaS website and by doing "find in all files" the keyword "catch" I came up with 174 references. For hundreds of thousands of lines of code, we have had to manually catch and handle exceptions only 174 times.

<comment><USER6> imho the author paints a very accurate picture of c#. exception handling remains a mystery to many programmers and is a constant source of errors.

error handling in general is hard to do; to have good, what i would call, "error partitioning"\- catching errors/exceptions where they can be fixed is difficult- regardless of exceptions.

perhaps you got your error handling right and don't need more catch clauses, but if I was you I would investigate :)

<comment><USER7> Bad programmers write bad code in general, so basing your opinion of C#'s error handling system on their use of it seems unwarranted. Exception handling does not remain a mystery to many programmers, just many bad programmers. Aside from that, the author is a contributor to Rust so I suspect there could be some small amount of bias here.

> ...catching errors/exceptions where they can be fixed is difficult...

What's difficult? When your program is about to do something like say open a file - if you don't want an exception to be raised from that code, you wrap that code in a try...catch. In the catch block, you take corrective action.

The very simple bottom line with error handling in .NET apps is that you handle/log/notify the user at process and thread entry-points like _main_ and _AppDomain.UnhandledException_. Other than that, you use a try...catch block.

<comment><USER8> It's a bit of a reach to sling accusations of bias. The Rust project makes it trivial for people to contribute, so anyone with even a passing interest in the language can become a "contributor to Rust" in seconds. If you try and disqualify all of the 1,000+ Rust contributors from writing blog posts about the language, then you most likely also disqualify everyone qualified to write about the language from writing about the language. :P

<comment><USER7> I didn't sling an accusation, I said "I suspect there could be some small amount of bias". If I were accusing, I would have said "this person _is_ biased.". Despite what you say, I still think the suspicion is valid.

<comment><USER8> That's fair, although I suspect that your suspicion of bias may be biased due to your usage of C#. :)

<comment><USER7> The irony here is that people on HN do judge you if you live mostly in the C#/.NET world, but you're arguing against my suspicion of people who contribute to Mozilla.

Do you think it's a far stretch to say that people who actively use open source languages and libraries and contribute to Mozilla projects are much more likely to be biased against anything that Microsoft does?

<comment><USER8> You're still leaping to conclusions, you're just trying to justify it behind a veneer of persecution. I'm a Rust contributor and I think C# is a fantastic language; it's my dream to tempt Anders Hejlsberg away to Rust. :P I'm also typing this from a Windows 7 netbook, my sole computer, though I'm looking to upgrade to a Surface once Windows 10 is here. We have several former Microsoft employees in our ranks and one of our core contributors is currently interning at Microsoft. It is possible to be critical without there being a hidden agenda!

<comment><USER7> It is possible, just not probable. You're an outlier.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Huh, author even uses exceptions as a part of normal workflow, instead of checking if "previousVersions" list is empty before calling Min on it he instead catches InvalidOperationException. I don't want it to look like an ad hominem argument, but... Anyway, C# authors had Java in sight when designing the language and after some contemplation they didn't include checked exceptions in the language. And their main argument is that in the vast majority of cases ignoring the exception and allowing it to propagate further up the stack is exactly what you want to do, simply because there is nothing you can do about it but to log it and tear down the entire object graph or write an error message to the user.

<comment><USER10> > propagate further up the stack is exactly what you want to do

This is an important point imo. It is actually one of the ways you can describe to a non-programmer why it can be so hard to write typcial desktop software which never ever crashes (as in 'unhandled exception' dialog): _huge_ amounts of time would be wasted to figure out for each and every single statement what can go wrong and how to handle it. Seriously, I've been at meetings where more time was spent on discussion on how to deal with/present to the user some obscure once-in-a-lifetime error than on actually fullfilling requirements.

<comment><USER11> I have a desktop app that has a single exception handler at the event loop. It's amazingly robust. That file you're trying to save is locked? Network location went away? Doesn't matter. It displays the error in a dialog box (so you know what went wrong) and returns the user to the app. Whatever operation they were doing, they can just try again. Any cleanup is performed automatically and the application, without really any effort, is always in a stable state.

That's how exceptions are supposed to work. The wack-a-mole attempt at ensuring you "handle" every case is wrong.

The problem, in my opinion, is that most programmers have been so brain damaged by Java that anyone exposed to that way of programming can't see how exceptions are supposed to work. Java not only makes you try/catch/declare everything but also makes you use exceptions for non-exceptional operations. A perfect storm.

</comment></comment></comment><comment><USER12> Good post. Not capturing a stack trace is a Rust specific thing -- this is easy to do in Scala, for example, and still maintain the benefits of monads + algebraic data types. I'm sure Rust will get similar utilities with time.

The main issue I have with this technique is the higher mental overhead when getting started. That goes away with a bit of practice.

<comment><USER13> Scala gets stack traces automatically from the JVM though, along with much of its debugging support. The Rust team will have to do this all by themselves, being a natively compiled language and all.

<comment><USER14> You can get stack traces on panics by running with RUST_BACKTRACE=1.

I don't know that it makes much sense on Error objects though, there's no requirement that they're even able to store backtraces, and collecting backtraces any time an error object is created would be really expensive and would make the runtime a dependency of errors.

<comment><USER13> Most VMs put most of the overhead of stack creation at where the error is created, so it usually works out fine (throw is expensive, everything else is cheap). Stack traces are usually dependent on whatever debug symbols are loaded, so in the CLR you'll get huge blank spaces if an exception propagates through some dynamically generated or even native code.

Just printing stack traces is a distraction though. The only thing that is required that on an exception, the entire stack above the the exception site can be inspected in the debugger.

<comment><USER14> That's a completely different concern, and it only makes sense on panics, not any time an Err result is created.

<comment><USER13> And how do you tell where an error originated without a panic being called? Is the programmer expected to just instrument the their code to put the panic in as soon as possible? Anyways, this is a well-known problem with monadic error handling, and one of the main reasons it doesn't get more widespread adoption.

</comment></comment></comment></comment></comment></comment><comment><USER15> I love monadic error handling too, but not for the reason that the author cited.

The fact that you know exactly what errors a function can throw is not an unique feature of monadic errors: in Java, you are required to explicitly list exceptions that a function can throw (checked exceptions), and you must handle every exception when calling the function.

The real feature of monadic error handling is that error handling become _composable_.

Imagine that you want to write a function that accepts three character-encoded integers and that you want this function to return the first integer it successfully parsed.

With exceptions, you will probably use a _parseInt_ function with a type similar to:

        fun parseInt(String) -> Int throws ParseException

And you will write the function like this:

        fun getFirstInt(String a, String b, String c) -> Int throws ParseException:
            try:
                return parseInt(a)
            catch e1:
                try:
                    return parseInt(b)
                catch e2:
                    return parseInt(c)

Now take a language supports algebric data types (like Haskell, Rust, Scala or OCaml). The _parseInt_ function will probably have a type similar to:

        fun parseInt(String) -> Result<Int, ParseException>

You will probably define a simple operator to manage the pattern _if it fails, try that instead_ before implementing the _getFirstInt_ function. Lets call this operator _< |>_ (it's its name in Haskell):

        fun operator <|>(Result<r, e> left, Result<r, e> right) -> Result<r, e>:
            match left:
                Ok(r)    -> return Ok(r)
                Error(e) -> return right

With this operator, _getFirstInt_ could be implemented as simply as

        fun getFirstInt(String a, String b, String c) -> Result<Int, ParseException>:
            return parseInt(a) <|> parseInt(b) <|> parseInt(c)

I think that the fact that you can write you own error handling operator is the killer feature of monadic error handling (and monadic programming in general). It makes the enforced handling of errors really painless (while it's like hell in Java where every exception must be handled).

It's almost impossible to create this kind of operators with exceptions because they are not a return value, and thus can't be handled in expression. With monadic error, handling operators are just plain old functions.

<comment><USER14> Just a note, Rust's error handling is not monadic because Rust doesn't have monads because it doesn't have HKTs, I guess we could call it "reified" though.

<comment><USER16> Actually it is. Rust Option and Result types implement .and_then(), which is equivalent to bind. They are also equipped with many of the other things you'd expect of a monadic types.

The thing is, Rust's type system is currently incapable of expressing an GENERAL monadic trait/interface, which it would be, if it had HKT. (That would allow implementing all the additional monadic util methods as trait default implementations, and having generic functionality applying to any monad.) Hopefully we get there someday.

</comment></comment></comment><comment><USER17> Both exceptions and results are important for software architecture. The lack of the former leads to an oversimplification of interfaces in languages with only the latter. The author hit upon an example that is probably better written using results. But guess what? A C# programmer would write it that way too. See the TryParse methods found all over the C# standard library. On the other hand, what would a Rust programmer do to handle an out of memory situation? That would be too pervasive with the result approach so it has been culled from all interfaces. Also, nullable reference types are a separate issue.

<comment><USER8> The point that you're glossing over it that Rust forces you to acknowledge the existence of errors, either by working with Err types or by using .unwrap() to terminate the thread in the event of an error. The existence of both Parse and TryParse in C# indicates a trend of allowing to errors pass silently by default, which ultimately results in surprise runtime failures.

      > On the other hand, what would a Rust
      > programmer do to handle an out of memory
      > situation?

Let's ask MSDN what a C# programmer would do:

 _" This type of OutOfMemoryException exception represents a catastrophic failure. If you choose to handle the exception, you should include a catch block that calls the Environment.FailFast method to terminate your app and add an entry to the system event log"_

[https://msdn.microsoft.com/en- us/library/system.outofmemorye...](https://msdn.microsoft.com/en- us/library/system.outofmemoryexception%28v=vs.110%29.aspx)

<comment><USER17> I'm not glossing over it, I said that this is better written using results.

Complaining about the existence of Parse is like complaining about the existence of unwrap in Rust.

C++ (another systems language) is probably a better comparison for out of memory.

<comment><USER8> Moving my ninja edit down here into a reply:

On modern systems it's not possible for an application to know when memory has been exhausted, because of virtual memory and overcommit ([http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6](http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6)). The system will happily tell your process that memory is available even when it's not, and relies on the OOM killer to free memory by force when necessary. The only context in which an application can reliably detect OOM is when that application is the kernel itself.

Fortunately, Rust has a stripped-down version of the standard library, called libcore, that exposes features which don't require allocation and thus don't have to worry about OOM. This profile is perfectly usable for writing kernels, and could also be used to write an alternate kernel-specific stdlib which make it possible to handle OOM.

      > Complaining about the existence of Parse is like
      > complaining about the existence of unwrap in Rust.

This is mistaken. Complaining about Parse would only be like complaining about unwrap if unwrap were the implicit and default behavior. Parse throws implicitly, but unwrap doesn't get called implicitly. The fact that the possibility is impossible to accidentally overlook is an enormous and crucial difference.

<comment><USER17> Overcommit is just one configuration on Linux, it is a good default, but there are domains where you would disable it.

How is Parse any less explicit than unwrap ?

<comment><USER8> Parse is less explicit than unwrap because the following C# code is legal:

      uint foo = uint.Parse("3");

But the following Rust code is not legal:

      let foo: u32 = "3".parse();  // error: mismatched types

It's impossible to use the return value of parse as though it's a u32, because it's not a u32. You can't accidentally add it to some other number or use it to index an array, because it's the wrong type entirely. You invariably must acknowledge the possibility of failure, and if you're okay with terminating your thread in the event of an error you can do this via an unwrap:

      let foo: u32 = "3".parse().unwrap();  // just fine

Rust's parse is even more explicit than C#'s TryParse, because even with TryParse it's possible to forget to check the return value:

      uint foo;
      uint.TryParse("Hello", out foo);  // this compiles and runs!

And it's not just about string parsing. The overarching point here is that not only does the compiler protect you from errors that you know about, it also brings your attention to errors that you didn't know about. The OP has a great example in that it's very easy to forget that the `min` method on vectors can fail if that vector is empty.

Finally, this assurance extends in the other direction as well: knowing that libraries are architected to make errors explicit via return types means that if I don't get yelled at for not handling a return type, then I have peace of mind knowing I'm not overlooking anything. This is somewhat analogous to the considerable assurance given in knowing that types aren't implicitly nullable.

Now, if you're looking for something that can still go wrong, there's a better example then OOM: dividing by zero in Rust will implicitly panic. So while it's unlikely that a library author will use unwrap in their code (there's a strong culture against Rust libraries causing panics), it's possible that a library author could accidentally cause a panic by dividing by zero.

<comment><USER17> Both Rust and C# provide throwing/failing interfaces for parsing, it's just that Rust's is written:

        let foo: u32 = "3".parse().unwrap();

and C#'s is written:

        var foo = uint.Parse("3");

Both require familiarity with the stdlib (Parse throws, TryParse doesn't, unwrap fails).

I agree that TryParse is worse than Rust's ADT approach, but that's a different issue, much like nullable references. The author is asserting that results are superior to exceptions and I am asserting that no, that is just a bad application of exceptions. Additionally, I am asserting that without exceptions, you limit what programmers are willing to propagate through their interfaces because errors become viral.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> "Can this method throw? Should I catch a PathTooLongException here? And while the .NET framework is documented to remarkable detail, this is rarely the case for third-party libraries or in-house code. At the bottom of the call stack, you just have to assume everything may throw. "

Isn't this true for all languages in one form or another? Go and Rust have "panics" Any code might fail exceptionally, stack overflows and out of memory conditions come to mind as relatively common ones.

The difference here is that C# treats more kinds of things exceptionally than Rust or Go. This seems to have more to do with Rust and Go ability to more easily return multiple types from a method/function and a philosophy of opt-in vs opt-out on handling an error.

I am used to C#/javascript so exceptions with try catch are very natural to me. Writing robust programs always involves handling everything one way or another. Even out of memory conditions can be handled and recovered if your always thinking that everything can throw.

The null issue is interesting, I like null, I like undefined with null even better in javascript. I always seem to need to encode something has no value or something was never even set vs picking a valid value as a special "no value" i.e. int.MaxValue or whatever. The only thing I would change in C# and javascript is null lifting object.property should not throw if object is null same with foreach over null object. They are adding the ?. for that but you need to explicitly do it, NullReferenceException is far to common in C# from those two situations explicitly. I belive Objective-C did some kind of null lifting where sending messages to null objects don't throw.

<comment><USER12> The issue is this:

Things will go wrong. Some subset of things that can go wrong are things you want to do something about (e.g. file doesn't exist -- maybe prompt the user for a different file). The remainder are things you don't want to deal with (e.g. out of memory -- in most cases this is very rare so you're ok to just crash).

You want to arrange your program in such a way that you _must_ deal with the errors you want to deal with. Your code won't compile if you don't. That is what this technique brings.

More here (though you probably won't understand many of the terms if you haven't used a modern FP-inspired language before): [http://underscore.io/blog/posts/2015/02/23/designing-fail- fa...](http://underscore.io/blog/posts/2015/02/23/designing-fail-fast-error- handling.html)

<comment><USER11> > You want to arrange your program in such a way that you must deal with the > errors you want to deal with.

Which would be fine but there is no way to do that without also having being forced to deal with the infinite errors you don't want to deal with.

<comment><USER8> If you don't want to deal with an error then you unwrap it, which will terminate your program just as well as an unhandled exception would. The salient difference is that you can't accidentally unwrap something, whereas you can accidentally forget to handle an exception.

<comment><USER11> The set of exceptions that can be handled is vanishingly small. With exceptions you should be catching exceptions very infrequently and in key places. Talking about accidentally forgetting to handle an exception at a method-call site completely missed the point. That's not how one should code or think about coding when using exceptions.

</comment></comment></comment></comment></comment><comment><USER11> I started to think about everything that's wrong with the authors code example and the more I got into it the more I realized the entire problem is wrong.

"Our goal is to write a function that takes a list of previously released versions and a user-provided version string, which then returns the parsed number or reports an error."

A function named CheckNextVersion should never even raise an exception because it _expects_ bad input. It probably also shouldn't double up as the ParseNextVersion function as well. But I understand the author wanting to combine these operations and conveniently get an error message out that can be displayed to the user. But as a damning example of exception handling, it's just bad design.

So even if we accept the design, his method is horribly over-thought with regards to error handling. Either it should catch within it's body all potential exceptions and raise a single InvalidVersionException or it should catch nothing and the code above should catch everything and display the message to the user. All the work catching and rethrowing different exception types adds no value given the purpose of the method.

</comment><comment><USER11> I find the opinions presented in this article are far too common these days in completely misunderstanding exceptions.

"The consequence, when you want to write robust software in C#, is that you have to keep an MSDN tab open at all times. Can this method throw?"

First of all, assume every method can throw. Just do it. It's either true or could be true in the future when someone changes that method. Maybe it doesn't use the network today but tomorrow it calls out to a webservice. So all methods throw. And forget knowing what exceptions they might throw. That's an implementation detail and we want to hide implementation details.

"Should I catch a PathTooLongException here?"

No, you shouldn't. What are you going to do any differently with that than you would FileIsLockedException or NetworkIsDownException or HarddriveIsCorruptException? You wouldn't do anything differently. Show the user the ErrorMessage in the dialog and allow them to restart whatever operation was in affect. Let them choose a shorter path, close Excel, plug their Ethernet cable back in, or whatever. Trying to play wack-a-mole is a fools errand. Put MSDN away, you don't need it.

<comment><USER19> > No, you shouldn't. What are you going to do any differently with that than > you would FileIsLockedException or NetworkIsDownException or > HarddriveIsCorruptException? You wouldn't do anything differently. Show the > user the ErrorMessage in the dialog and allow them to restart whatever > operation was in affect. Let them choose a shorter path, close Excel, plug > their Ethernet cable back in, or whatever.

I don't think this approach works in general. Server software, at least, needs to automatically handle all these different failure modes in potentially unique ways.

<comment><USER11> If you are aware of particular situation, you can handle it. If you aren't aware of a particular situation at best you log the problem and skip the operation. That's pretty straight forward and is still the same approach.

For example, I might just catch every single Network exception, log it, add a timeout, and retry the operation. I'm not playing wack-a-mole and I don't care in the handler which of the thousands of methods called in my operation actually raised the exception.

The point is one should _not_ be looking at what exceptions the methods throw but instead what exceptions can be handled. One set is very large the other set is very small. This applies equally well to server software.

</comment></comment></comment><comment><USER20> Interesting case is that Rust's cmp::max() doesn't support floating-point numbers, because maximum is undefined for Inf and NaN.

For floats there's partial_max() which returns Option<f32>.

It makes sense, but it never crossed my mind before that a simple max() function can fail.

It's also PITA to error-check such a simple thing, but somewhat surprisingly there's also f32.max() that works on garbage-in garbage-out principle.

</comment><comment><USER21> I have building a toy language and about this I have wondering if is better to think in errors exactly with normal values.

So, my functions are ALL like this:

      fun sample= StdOut(Str) | StdErr(Int) do
        if GoodLuck() do
          return "Yeah!"
        fail 1

ie: fail is exactly like return, is just a way to split between Ok values and Err values.

If the client wanna catch them:

      result = sample() # Get the Ok value. if the Err value is returned, then trow like in exceptions

      result != sample() # Get the Err value, not trow

      result, err != sample() #Get both

What do you think?

<comment><USER14> > I have building a toy language and about this I have wondering if is better > to think in errors exactly with normal values.

That's exactly what Rust (to keep with TFA) does. Result is not really special, its core is just

        enum Result<T, E> {
            Ok(T),
            Err(E)
        }

> What do you think?

That the code doesn't make sense, the result and the error should be exclusive propositions, why would you get both a result and an error when the function should return either one or the other?

<comment><USER21> > why would you get both a result and an error when the function should return > either one or the other?

Is modeled like unix IO (with stdin/out/err). Anyway, I think, a function/call get a value or a exception, so why not be more explicit about that?

<comment><USER14> > Is modeled like unix IO (with stdin/out/err).

Those are used for IO or user signaling, not error reporting (that's the process's return status, stderr may be used to augment it with a cause, unix utilities are centered about the status signaling correct/incorrect execution).

> I think, a function/call get a value or a exception, so why not be more > explicit about that?

It's fine to be explicit about it (again that's what Rust does), the problem is your example isn't really explicit about it, and the second sample is downright weird. It's like Go except even more screwy.

edit: in an other subthread you mention following dynamically typed languages, if we go with that and assume no type support it makes slightly more sense, but the logic is still screwy: assuming the second snippet is a function which doesn't have a result (so it can only have an error) it should use the same system as the third snippet, the faulting assignment (first snippet) is the one which should use a different syntax.

And then there'a the question of what semantics you get when not assigning but just nesting expressions.

An option might be to attach the decision to the call instead (kinda like Swift) e.g. the result of a regular function call would be either `error` or `result, error` (with the language enforcing that one of result and error must be nil) but by "banging" the function the error is raised instead of returned. So you'd get something along the lines of:

        # no result, possibly an error
        err = foo()
        # a result or an error
        result, err = foo()
        # no result, panics in case of error
        !foo()
        # a result or panics in case of error
        result = !foo()

the language would enforce that either the error fetched or the function is bang-ed, so

        foo()

would be illegal, because it neither receives the error nor raises on error.

Not sure that's great, but it might be workable.

<comment><USER21> Yep, as I have think, is more or less like you say.

>if we go with that and assume no type support

Wonder why is harder with a type system (I say follow the syntax, not the type system of julia/python... so I wanna be as static as possible, or at least try)

<comment><USER14> > Wonder why is harder with a type system

A type system doesn't make it harder, it makes it pointless: when you have a good type system sum types[0] are a safer and all around better solution.

[0] possibly, in some cases, polymorphic variants [https://realworldocaml.org/v1/en/html/variants.html#polymorp...](https://realworldocaml.org/v1/en/html/variants.html#polymorphic- variants)

<comment><USER21> Ok, was a big mistake to show the idea with this on-the-fly-invented syntax this way (because: I still not settle on it), I just try to convey the idea not the implementation.

I wanna build a F#-like type-system with sum/products ([https://www.reddit.com/r/fsharp/comments/30ywjy/question_how...](https://www.reddit.com/r/fsharp/comments/30ywjy/question_how_implement_a_subset_of_f_in_f/)) for my language, and be the result of the function already a Result<T, E>, without the user need to annotate it manually. So, I'm thinking in the kind of development that happened in reactive library but as a intrinsic model of the language.

Of course, I'm a total noob in this area, so still researching about this!

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I'd love it if some Rust insiders could comment on how Rust _might_ implement the stack trace feature (assuming they did decide to implement it). Perhaps a trait such as "GeneratesStacktrace" that can be implemented with "Derives"? And the stack trace is only available in a Debug build when you compile with the appropriate flags?

<comment><USER8> I've barely given it any thought, but one approach would just be to modify the try! macro to dump a backtrace to stderr when an Err is encountered in debug mode. The backtrace itself could be generated the same way that they're generated for C++.

</comment></comment><comment><USER23> Whilst some of the issues with C# are valid, it's totally possible to do monadic error handling in C#, I wrote an entire library to facilitate that [1]. In fact the big win of monadic error handling is the composable nature of monads:

Here's a function that throws an error on odd numbers:

        Try<int> Number(int x) => () =>
        {
            if( x % 2 == 0 )
                return x;
            else
                throw new Exception("Any exception");
        };

Here the monadic computation succeeds, and 'res' holds 1000:

        var res = match(from x in Number(10)
                        from y in Number(10)
                        from z in Number(10)
                        select x * y * z,
                        Succ: x => x
                        Fail: 0);

Here the monadic computation fails, and 'res' holds 0:

        var res = match(from x in Number(10)
                        from y in Number(9)
                        from z in Number(10)
                        select x * y * z,
                        Succ: x => x
                        Fail: 0);

If you don't want to use it in a LINQ expression then you can just say:

        var res = Number(10).IfFail(0);

There's also mention of the null problem, which obviously is a major problem with the language (and framework), but it can be tamed somewhat with Option<T> and TryOption<T>:

        TryOption<int> Number(int x) => () =>
        {
            if( x % 2 == 0 )
            {
                if( x > 10 )
                    None;
                else
                    return Some(x);
            }
            else
            {
                throw new Exception("Any exception");
            }
        };

Here the monadic computation succeeds, and 'res' holds 1000:

        var res = match(from x in Number(10)
                        from y in Number(10)
                        from z in Number(10)
                        select x * y * z,
                        Some: x  => x,
                        None: 0,
                        Fail: 0);

Here the monadic computation fails, and 'res' holds -1:

        var res = match(from x in Number(10)
                        from y in Number(9)
                        from z in Number(10)
                        select x * y * z,
                        Some: x  => x,
                        None: 0,
                        Fail: -1);

Here the monadic computation also fails because a None is returned, so 'res' holds 0:

        var res = match(from x in Number(10)
                        from y in Number(20)
                        from z in Number(10)
                        select x * y * z,
                        Some: x  => x,
                        None: 0,
                        Fail: -1);

So as you can see, using monadic error handling is doable in C# with the right tools. It certainly takes a bit more discipline from the programmer, but it's definitely worth it. It also makes your code declarative. A function that looks like this:

        TryOption<string> DoStuff();

... clearly declares that the function may: Succeed, return 'no value', or fail. So you should deal with all 3 possibilities. In contrast, this doesn't give that information to the programmer:

       string DoStuff();

[1] [https://github.com/louthy/language- ext](https://github.com/louthy/language-ext)</comment>


Ask HN: How do you get technical mentorship? - <AUTHOR> I'm a recent grad and have been working on small startup teams. With the pandemic, it's been kind of a ping pong because funding has fallen through a few times. I work with subject matter experts but they aren't the technical mentors I've had in prior roles (someone who can review my code, provide meaningful guidance on systems design, etc). I am lucky to have a group of mentors I've cultivated over the years. But it's harder to find technical mentorship - not necessarily day to day but on a rather frequent basis. How do you all find technical mentorship? Open to answers from anyone/everyone who would like to share. <comment><USER2> I've had mentors and I mentor quite often. Mentors want to bounce their ideas off someone. You have to be curious enough to add more to their ideas and skilled enough to criticize it.

Criticism is where the sweet spot falls IMO. You have to criticize a mentor to a point they learn from it, but not where they think you have much to learn. Some mentors and students also tend to be stubborn and don't accept any criticism.

Technical mentors are hard for this reason. Technically superior people tend to be so good at something that it's muscle memory. Recent grads tend to not only struggle, but they stay in groups that reinforces bad habits. There are some unusual habits - like how Paul Graham uses lines of codes as a metric for work done, which doesn't click well with newbies. This creates a knee jerk contempt in the student, and the mentor as well.

So normally, you want to look for a mentor who's just a few years ahead of you. You don't necessarily want to meet the best programmer, but more a big sister figure who's worked in a company for 5 years maybe.

<comment><AUTHOR> Thank you for this insight. I definitely see the value in someone a several years ahead of me - I sought this in college as well. I see your advice is tailored to a larger firm - what about when I'm the sole "developer" in a small team. How can I reach out externally?

<comment><USER2> Actually, I meant it as a small team or solo. Most of my mentor relationships starts with someone saying a clever thing on Facebook/Twitter/HN, a radio show, a random community, someone who wrote a book I learned a lot from, a tech talk somewhere.

It's similar to dating. Everyone prefers to be passive and matched to someone, or just bump into someone serendipitously. But it's easier to just muster the courage to talk to the next person on your mind. And they usually get flattered when asked for help as well, as long as it's not Bill Gates or anyone too far above your level.

Speaking of Bill Gates, there's a bit of anecdote from the Bill Gates documentary. At one point he met with Buffett and Buffett just kept asking questions like, "Why couldn't IBM beat Microsoft?" Bill was waiting for someone to ask him a question like that but nobody ever did. That's how mentor relationships are formed.</comment></comment></comment>


Want to write some code? Get away from your computer - <AUTHOR> http://blog.rtwilson.com/want-to-write-some-code-get-away-from-your-computer/ <comment><USER2> I find I solve the trickiest problems in one of three places: Walking my dog, taking a shower, and laying in bed trying to fall asleep. I find that stepping away from the keyboard, and my programming environment entirely, allows me to let go of all the basic assumptions I hadn't even realized I'd been making.

<comment><USER3> This is often repeated by a lot of people, but I think it might be affected by a bias. Perhaps we notice more when we solve problems away from the keyboard because we are not supposed to be working then. Perhaps we selectively label those the trickiest even though we solve many more problems staring at the monitor trying really hard.

<comment><USER4> There is certainly some confirmation bias going on in these reports, but I must say I sometimes find walking away from the problem for a short while (looking at something else, taking a relaxed lunch instead of eating at desk, just nipping out for a few minutes of fresh air, or just chatting to a colleague about something related or otherwise) can work wonders.

Sometimes a relevant idea will just come to me while I'm away (I carry a pencil and bit of paper for such occurrences, as it is very annoying to get back to my desk and forget the beneficial train of thought!), sometimes I'll hit the problem from a slightly different angle when I get back and find success that way.

I think mainly the difference is usually stress. Forcing your mind to think about a particular problem can drive you into a mental rut in which you think the same things over and over and get nowhere, getting more irritated at your lack of getting anywhere as time goes on which creates more stress and makes matters worse. At times like that inspiration is less likely to strike (or be recognised when it does). Having time to ponder a problem, consciously or otherwise, can be very fruitful.

This fits in quite nicely with the idea that the sleep pattern we've evolved is as much about rearranging what we've learnt and experienced while awake as it is about anything else (like the brain's DBA taking time to run DBCC REINDEX on everything so our thinking is more efficient the next day). It also tallies with the fact that some of the most successful people I know are generally more relaxed (and not just because they are more comfortable due to earlier success) than myself!

</comment></comment></comment><comment><USER5> _One of the best lessons I learnt from my first boss was: "when your code doesn't behave as expected, don't use the debugger, think."_

Can't entirely agree. I'm not a grizzled programmer, so sometimes when I'm coding for microcontrollers the debugger winds up teaching me about some new quirk in architecture. It's often something I was aware of (endianness, some of the finer details of addressing) but had not yet actually dealt with in person.

<comment><USER6> It drives me nuts when people 'fix' things by making the symptom go away without understanding what causes that symptom in the first place.

<comment><USER7> When used correctly a debugger will help you unravel the root cause of a problem, I don't see using one as a route to just fixing symptoms.

<comment><USER8> A poor developer uses his tools to cover up the symptoms. A good developer fixes the root cause. The ability of the good developer to fix the root cause quickly and efficiently is bounded by the quality of their tools. If you want to claim that a good developer will find it no matter what, fine, but don't tell me the developer with better tools won't be able to do it _faster_ ; it's almost the definition of "better tool". I find it very strange how people just write off using a debugger, ever, for any purpose, and think it labels them as a _better_ developer, as if a carpenter who refuses to use a plane under any circumstances is thus a better carpenter for resisting the temptation to easily-smoothed wood. (The fact that a plane is good for more than that is deliberately part of my point.) It isn't the best solution for every problem and I certainly don't reach for it directly, but when you need it, you _need_ it.

<comment><USER9> The root cause of every problem is that I don't fully understand my code. A debugger can only show you what the code happens to do in one particular scenario. The fear is that people are doing that and fixing only obvious mistakes as a substitute for static analysis and diligent review of the code leading to a correct model in their head of how it would handle _any_ scenario. It's like declaring a bridge to be sound because you could successfully send one truck across.

<comment><USER8> "Doctor, it hurts when I do this." "Don't do that."

That fact that _other_ people can misuse a tool is a really stupid reason to not use it yourself. I've had great success in using debuggers to identify which assumption I was wrong about when the code did something unexpected. If you're _so awesome_ that you never make bad assumptions about your code... you're probably not pushing yourself hard enough. Perhaps that's your job's fault. I'm pushing myself to my limits in my job, and I'll take all the help I can get.

</comment></comment></comment></comment></comment></comment><comment><USER10> This is good mostly for algorithms but for system software (drivers, a lot of different technologies involved) is impossible because issues are outside of your control, without debugging you'll lose 100x of time.

<comment><USER11> Agreed -- the author of the post is talking about writing or debugging algorithms; coding is the stuff you need your computer for.

</comment></comment><comment><USER6> In many ways the responsiveness of the machine can work against you. Back when the Amiga was a hot machine to work on there were two compilers Lattice C and Manx C, Lattice was the one sanctioned for development and it took a long time to compile and link, Manx on the other hand compiled really really fast. A number of developers discovered that the fast compiler had a weird effect of making it easy to try lots of things quickly, rather than contemplating what you needed to do next.

Then recently Randal Munroe published an XKCD cartoon on attention deficit management [1] which when I saw it, it really resonated with this same experience. Basically by slowing things down, quality improved. Clearly there is a fundamental principle here somewhere, something along that lines that there is an ideal pace for development (perhaps unique to each individual) where going faster or slower than that ideal negatively impacts quality.

[1] <http://xkcd.com/862/>

<comment><USER12> I find that fast compile turnaround helps me stay engaged with the problem. Even a 30 second delay gives me time to get distracted by one of the temptations that surround us all. The ironic result is that I sometimes actually think _less_ about what I'm doing when I have to tolerate these delays. Ideally, when I catch myself doing this, I make myself stop and think, but sometimes I'm tired and lack the patience.

On the other hand, in a fast-turnaround environment like Lisp, I can make three stupid mistakes in about a minute, and when I realize I'm thrashing, I still have all the context in my head to figure out what I should really do.

</comment></comment><comment><USER13> There's a rich history of research into the nature and methods of problem solving (Polya et. al), the role of unconscious (e.g. walk away from the lab/tools) and so on. The more intractable the problem, the more it required being able to walk away from the tools (see anecdotal history about discovery of the structure of benzene for example).

The experience of "coding", with its quick feedback loop hypnotizes people into an unproductive leash. The nature of the problem, the language and tools either help or exacerbate.

My experience is that most hard problem solving needs at least three approaches - I paraphrase them as 1. Zoom Out, 2. Zoom In 3. Zoom away. Debuggers aside, I found that program construction in interpreted languages (my work was in Lisp) supported with a good toolset and modularity in design, allowed productive zoom-in, zoom-out whereas programming in "edit/compile/debug" languages even with the toolset and modularity required "zooming away" more often. Could be that the context switching cycle of edit/compile/debug is a cognitive tax that really hampers hard problem solving or when things are not working as expected.

</comment><comment><USER14> "Step Away From the Computer" or "Hammock-driven Development" by Rich Hickey (author of Clojure): <http://clojure.blip.tv/file/4457042/>

<comment><USER15> Thank you for this. Can't wait to start reading the book he recommended, <http://en.wikipedia.org/wiki/How_to_Solve_It>.

 _Marvin Minsky said in his influential paper Steps Toward Artificial Intelligence that "everyone should know the work of George Pólya on how to solve problems."_ \- Wikipedia

</comment></comment><comment><USER16> Hardly news for anyone who's been a developer for a long time. I generally solve my dev problems wandering around London. This has the added bonus of when I've sorted out the problem in my head, I'm at a location I've never been before and have the chance to find a new restaurant/pub. Win/win.

</comment><comment><USER17> I was told years ago by an older developer that "90% of code is written away from your computer"

I adhere to this adage and find it to be true

</comment><comment><USER18> While you can get the benefit of clarity by stepping away from the keyboard for a while, I've found the best return is from test-driven development. TDD forces you to think about what you're trying to achieve before you try to solve the it. The thing I took exception to in the post was:

> 5\. Make small change to the code on the off-chance that it might solve the > problem

Whether practising TDD or trying to formalise the problem on paper (or in your head), this is not the way to write code. Programming is not a random search problem.

These days, I tend to only step away from the keyboard when I'm losing my bearings for where I am in the big picture. Usually, that's when I'm "making small changes to the code on the off-chance that it might solve the problem"… this means I don't really know what the problem is.

<comment><USER19> Please re-read.

"It's very easy to slip into the mindset of:"

His point is that the procedure that he gives (in particular step 5) is the wrong one.

</comment></comment><comment><USER20> Maybe someone could make paper based IDEs, like notebooks that have columns to trace variables, rows for declarations at the top... Edit: terrible idea, just look for a suitable jotter in the stationary sections.

<comment><AUTHOR> What an interesting idea... _puts on list of things to do sometime_

</comment></comment><comment><USER21> I have a personal project I've been working on for years, mostly in pen and paper.

Every once in a while I'll get motivated and start coding it up. I'll start to think "I didn't think I could do it that way when planning it on paper, but I can't remember the reason...I'll just see what happens."

A few hours later I get to the "oh yeah..." part.

Funny thing is, that works both ways. Sometimes no matter how much you plan, if you just start coding you get the positive "Oh yeah!" moments that wouldn't have happened on paper.

</comment><comment><USER22> +1. I've found that thinking hard and long about most problems before coding them results in less buggy (sometimes even no bugs!) code. I remember my friend telling me that his dad had to stand in line and wait literally days to execute code on a computer (using punch cards) and they had all the time in the world to write the code, but very little to execute it. One mistake during execution and they would have to wait a few days for their turn, delaying the results that they were seeking.

I try to emulate this environment (by not compiling/running code) and trying to tell myself that I really should get a large chunk of thought (followed by relatively bug-free code) down before I let the compiler/interpreter in. This discipline has helped me a lot imho.

<comment><AUTHOR> Yeah my Dad has told me similar stories. In fact, I'm finding a similar thing now when I'm using the university supercomputer. I don't have to submit using punched cards anymore (thank goodness) but I do have to submit jobs to the batch queue and give them an estimated time the job will take to complete. This impacts the scheduling of the jobs, so if I submit a job and say it'll take 12 hours to run, then it is unlikely to start for a while. This gives me another reason to check the code very carefully, or I wait overnight and find that my code crashed after 2 seconds with a silly error!

</comment></comment><comment><USER23> Why is the write test -> code -> run test -> code -> run test -> etc. circle being derided? Given that your test cases are stringent enough, it should be fine.

If you did indeed write good test cases, then that's a prime indicator that you understand the problem you're solving well. Try test first programming, it's trickier than it sounds at first. In my opinion, it is too easy to get caught up into coding something (especially with languages that have large amounts of boilerplate, such as Java) and lose perspective of what you're actually trying to do. Writing test cases beforehand forces you into thinking about what you're actually doing.

</comment><comment><USER24> This is mentioned in the pragmatic programmer [1] book as deliberate programming, as opposed to programming by accident.

[1] <http://www.pragprog.com/the-pragmatic-programmer>

</comment><comment><USER25> Having a baby caused me to transition to this style for personal projects. I spend a lot less time in front of the computer now and when I do it's for shorter times.

I've found this approach does give a better result and eliminates false starts. When I'm at the computer now I have already thought through what I'm going to do completely and writing the code is just a minor detail.

</comment><comment><USER26> While I do agree that stepping away from the computer helps for getting started or when you're stuck, I am more in line with people using CSS rather than Photoshop for prototyping. As the author wrote, converting thought to code is fairly easy, so by writing as I think, I free my mind from containing all the stuff I thought out already.

</comment><comment> d135-1r43 I have a piano standing next to my PC. The most productive days are those on which I play/compose/improvise the most…

<comment><USER27> I have always had one or more musical keyboards by my desk, and I agree that there is a correlation between musical and software inspiration. However, I think in my case both forms of inspiration are derived from the same cause, rather than one causing the other. I'm still working on discovering that common cause.

</comment></comment><comment><USER28> I can't begin to express how much more productive and clearer I think when not behind the computer.

I do most of my outlining away from the computer, with pen and paper. UML is your friend! <http://en.wikipedia.org/wiki/Unified_Modeling_Language>

</comment><comment><USER29> Agree. Some of my best coding and problem solving was done when I was pacing around my office while playing with a stress ball. Sitting in front of the computer is my least productive spot for solving problems. I code best when pacing around, in the shower, or driving...

</comment><comment><USER30> Is it really true that many real-world programming tasks require this level of thought and dedication?

Honest question, I'm a student and none of my school/pet projects have been difficult enough that stepping away from the computer was beneficial. Only puzzles have been hard enough.

</comment><comment><USER31> For myself it goes one of two ways, I can actually write the layout on a text editor or I like to go to the park when hardly anyone is there and just walk around. It takes my mind off the problem, thus leading to a solution I never thought I would have gotten.

</comment><comment><USER32> I love chalkboards, they are the best coding instrument since the abacus, true fact.

</comment><comment><USER33> I find when going to sleep is the best time to code like this. No distractions.

<comment><USER28> And in the shower!

<comment><USER33> Yep, shower too!

</comment></comment></comment><comment><USER34> I think this article would be better titled "Want to write some code? Get away from Visual Studio".

<comment><USER35> Perhaps better titled get away from the IDE. Every IDE has exactly the same capacity that he's ranting against.

This is a rant against write, run, debug, repeat, not visual studio.

Even Notepad++ has run in it.

<comment><AUTHOR> Exactly :-) (It so happens that I was using Eclipse anyway...)

</comment></comment></comment><comment><USER36> 100% agree, I write my best code in the shower, as I'm getting ready for work :)</comment>


South Korean group BTS became the world's biggest boy band - <AUTHOR> https://edition.cnn.com/2019/06/01/asia/bts-kpop-us-intl/index.html <comment><AUTHOR> I find it fascinating that the band members all have an "associated emoji". The logical evolution of nick names in a text messaging world.</comment>


What I Love About Wordpress Plugins - <AUTHOR> http://meta.discourse.org/t/what-i-love-about-wordpress-plugins/5697 <comment><USER2> As a wordpress administrator, I detest plugins.

There's no isolation. If a plugin breaks or is slow, the whole of Wordpress breaks or is slow(er).

That's not entirely their fault. Every PHP application that runs in a shared hosting environment is stuck with the same unsolvable stability / security problems:

* Shared login to the database means and plugin or theme can see any data on any table

* Single-process structure ensures that a single glitch halts the world

* Serial execution means a slow plugin can choke a site

And so on and so forth.

I still believe that when web apps are targeted at VPSes a lot of this pain will go away. Imagine if plugins ran as jailed processes and communicating by message queues. If a plugin faulted or didn't meet the render deadline, its input would simply be skipped and life would go on.

A man can dream.

<comment><USER3> Some of this is inherent to the nature of plugins that alter the guts of a large program—look at the issues Firefox has had. At best Wordpress could rewrite itself to be insanely parallel _just in case_ a plugin in any particular area is slow, but that's a whole lot of work, the result is harder to maintain, and PHP isn't particularly amenable to it.

<comment><USER2> As I said, they are constrained by the general LAMP architecture. You _can't_ make it more parallel, you _can't_ make objects more independent.

> _the result is harder to maintain_

This I disagree with.

</comment></comment></comment><comment><USER4> I have to disagree with the filters. Sure, it's convenient at first glance, but it turns into a nightmare. The filter functionality in WordPress leads to spaghetti code at it's worst. I don't want to think about how many times I've had to comb through a dozen plugins on a WordPress install trying to find some obscure, poorly written filter that breaks something in a very peculiar way.

I think the problem is that you're altering some global state with no knowledge of how others may be altering the same data, and the code itself becomes an entangled mess of callbacks.

</comment><comment><USER5> To be quite honest, I dislike GetText() quite a lot. Drupal re-implements it as t(), but it still is fundamentally lacking in context, which Drupal later had to add as a second parameter. The English word 'order' can be translated to »sortering« or »bestilling« depending on context in Danish.

I much _much_ more prefer MediaWiki's approach, by naming all message strings something related to their purpose, this often results in a name structure, that defines their grouping and purpose, takes up less space, and does not require context definitions, because it does per default.

As a result, you contain all your messages - per default at least - in a message file, such as this: [https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a...](https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=languages/messages/MessagesEn.php;h=c5dba69dc0dbe10af14991d83a7b515ee75642f5;hb=HEAD)

But each message can be altered, which is then saved in the database; if a message is not in the database, its default is used.

</comment><comment><USER6> Aaaaand of course there are downsides to every convenient feature.

Ability to install plugins directly from the admin interface? Instantly enable them without restarting anything? This is only possible because your plugins directory and everything in it is writable by the web server. In other words, any plugin can mess with any other plugin, or even WordPress itself. The only reason this doesn't happen is because you have yet to come across a malicious plugin.

WordPress plugins can do anything and everything. They are very powerful. Therefore, they should be treated with the same level of caution that any powerful yet relatively unrestrained program deserves. Like ActiveX controls on IE6 (shudder). You don't simply search n' download them for a test drive, unless you really really trust the competence and moral integrity of the author and the repository.

<comment><USER7> > Therefore, they should be treated with the same level of caution that any > powerful yet relatively unrestrained program deserves.

A friend of mine's mother routinely compromises his vps simply by installing themes which include the popular TimThumb (<https://code.google.com/p/timthumb/>) plugin. Through the plugin, it's easy for an attacker to install web shells etc.

This is true of many plugin systems, and RubyGems for example is not immune from this. The difference between installing a new gem however, is that as a software engineer or developer it's your job to have confidence in the security of the gem. With a Wordpress plugin, any user of Wordpress can easily install it, and sometimes it's the theme which includes the plugin.

<comment><USER8> The old Tim Thumb is vulnerable. The writer of tim thumb fixed that security hole though after the issue from what I read.

</comment></comment></comment><comment><USER9> The Ruby/Python fanboys might downvote me for this, but the author here states the biggest advantage of the PHP ecosystem in general: most popular software is unpack-and-it-works! And that on near every OS/server combination out there.

<comment><USER3> Why downvote? It's true, and we need to be stealing that somehow.</comment></comment>


Step-By-Step Tutorial on Linear Regression with Stochastic Gradient Descent - <AUTHOR> https://towardsdatascience.com/step-by-step-tutorial-on-linear-regression-with-stochastic-gradient-descent-1d35b088a843 <comment><AUTHOR> This is a supplementary material to the backpropagation demo found on [http://raiboso.me/backpropagation-demo/](http://raiboso.me/backpropagation- demo/).

Do let me know if you have any feedback!</comment>