Wall Street exports boomed with 'fools' born to buy debt   - <AUTHOR> http://www.bloomberg.com/apps/news?pid=20601109&sid=a0jln3.CSS6c&refer=home

<comment><USER2> This is fascinating. It helps explain why the savings rate in the US has gone down so much since the 1980s. People didn't suddenly become financially irresponsible. There was _demand_ for debt, because it was the raw material debt-backed securities were made of. So companies were working much harder to convince consumers to get into it.

Incidentally, though no doubt debt-backed securities will be demonized for a while, I suspect they're useful with proper regulation. Market crashes often turn out to be due to the appearance of some new economic phenomenon that people get over-excited about initially, causing a boom-bust wave, but which in the long term turns out to be good.

<comment><USER3> There's nothing inherently wrong with debt-backed securities. They can be a very healthy part of an economy. Variations of debt backed securities have been around for centuries.

The real problem is the maturity mismatching, which in this case was fraudulent.

Here's how it works:

I put cash in a money market fund. The fund promises me that it only invests my money in very safe short term debt, It promises I can get my money back at any time, on demand. The Sentinel money market fund - to pick a random example - promised that 50% of its investments were overnight loans.

The trouble is that Sentinel lied. It turned out that 80% of their holdings were in long term bonds, and only 8% were in overnight loans. The average maturity date of their holdings was an astounding _32 years_. Other money market funds had their money invested in securitized student loans, mortgages, corporate bonds etc.

When you mismatch maturities like this, it becomes a license to print money. The fund accepts my investment. It then loans my dollar out to someone who wants a mortgage. That person pays the builders of the home, who then deposit the money back in the money market fund. The money market fund then loans the money back out again. The cycle keeps repeating, like a great big money printing machine.

This manufacturing of money is what caused gold prices, oil prices, stock prices, and real estate prices to take off over the past five years. More dollars floating around chasing the same quantity of assets causes prices to rise. It also explains the rise in consumer debt. With high inflation and low interest rates, borrowing lots of money is rational. This also explains why the financial industry was responsible for 50% of all American corporate profits in 2006.

At some point, some event causes depositors in the money market fund to get spooked. Perhaps information comes out that a money market fund has too many defaulting loans. The CFO of a VC backed startup is counting on that money to meet payroll in the next few months. He can't afford to accept any risk, nor any delays in redemption. So he decides to withdraw from the fund immediately. Except the CFO of many other companies have the same idea. The money market fund does not actually have the money to pay them. All the fund has is a bunch of IOU's saying, "we will pay you back with interest in 30 years." But the CFO's need the money now, not 30 years. The money market fund is forced to liquidate the IOU's for pennies on the dollars. Everyone loses their shirt. Worse, many businesses were counting on the low interest rates created by maturity mismatching. As people withdraw from money funds, the loan market dries up, and debt financed businesses start to go bankrupt.

This hardly is some "new economic phenomenon". Maturity mismatching has been at the heart of every single systematic financial crisis in the history of the Anglo-American financial system. The most notorious case was the Great Depression.

In the current crisis, the last step - the liquidation of the money market funds - has not happened. That's because Ben Bernanke is a student of the great depression, and recognized what was happening. When the bank run on the money markets began a few months ago, he decided to guarantee all the money market funds with full faith and credit of the government. He was basically saying, "We know that financial industry has been counterfeiting for decades. Unfortunately, now everyone is holding these counterfeit notes, including good, solid businesses. So instead of considering these bills counterfeit and allowing to a financial apocalypse, we're just going to consider these notes legitimate legal tender."

<comment><USER4> Vanguard sends me a report containing all the securities involved in my money market funds (which, by the way, have prevented me from losing anything in the late stock crash). Are you saying that these reports (or reports like it) are commonly fraudulent?

<comment><USER3> In the case of Sentinel, it was in their investment objects and allowed investments ( see this article for more info - [http://seekingalpha.com/article/44695-duration-mismatch- at-s...](http://seekingalpha.com/article/44695-duration-mismatch-at-sentinel) ). If you paid close attention to what they were actually investing in, you might have seen that the prospectus wasn't telling the right story.

In all honesty though, I don't think people would have invested that much differently had they known. People are so used to FDIC insured bank accounts, they don't realize that maturity mismatching in an uninsured account will always lead to bank run. Of course, because of the perception that the government was going to insure the accounts, the government actually did have to insure the accounts. So no one has actually lost money in the money market funds. It was all paid for by the inflation tax.

</comment></comment></comment></comment><comment><AUTHOR> _"... Securitization was based on the premise that a fool was born every minute, Joseph Stiglitz ... told a congressional committee on Oct. 21. Globalization meant that there was a global landscape on which they could search for those fools -- and they found them everywhere ..."_

What he left out was the bit where _"I know more than you do"_ \- instead of the essential financial transparency of banks, finance is supplied by non- regulated sources. Where the risk history of where the finance was coming from is removed. To end consumers, all this meant was cheaper finance. It doesn't mean _"fools"_ could be found everywhere. It means the real risk was externalised. You can read the results here ("Mortgage Meltdown", ABC, 4Corners, 2007 ~ <http://www.abc.net.au/4corners/content/2008/s2389716.htm> )

The Structured Finance industry today is what the Junk bond market was the '80 ~ [http://en.wikipedia.org/wiki/Junk_bonds#Debt_repackaging_and...](http://en.wikipedia.org/wiki/Junk_bonds#Debt_repackaging_and_subprime_crisis)

</comment><comment><USER5> The problems did not arise from demand for debt, rather the dealers' reaction to demand for higher yields on debt. The instruments which have been problematic were specifically designed to provide a higher yield with the _appearance_ of risk commensurate with lower-yield instruments. These were backed by credit that was pimped out to people who could never possibly pay it back and then obfuscated in a package that the buyer was very unlikely to critically examine.

You are right, debt-backed securities have a future; but fraudulent securities do not. This is not a new economic phenomenon -- lies and fraud are as old as mankind.</comment>


Mitigating the HTTPoxy Vulnerability with Nginx - <AUTHOR> https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/ <comment><USER2> > The vulnerability was mentioned on the NGINX mailing list in July, 2013, by > Jonathan Matthews.

Wow, that is long ago. Why isn't this mitigated earlier? The attack is very simple.

<comment><USER3> It gets worse

[https://httpoxy.org/#history](https://httpoxy.org/#history)

March 2001 - The issue is discovered in libwww-perl and fixed. Reported by Randal L. Schwartz.

</comment></comment><comment><USER4> There are mentions of Python... Does this affect WSGI applications, in particular, uWSGI?

AFAIK, uWSGI somewhat resembles but doesn't emulate CGI (unlike how FastCGI works), and WSGI application's `environ` parameter isn't related to `os.environ`, so it should be safe. But I may be mistaken here...

<comment><USER5> I don't know about uWSGI, but here is what it says at httproxy.org

\----

Python code must be deployed under CGI to be vulnerable. Usually, that'll mean the vulnerable code will use a CGI handler like wsgiref.handlers.CGIHandler

This is not considered a normal way of deploying Python webapps (most people are using WSGI or FastCGI, both of which are not affected),

<comment><USER6> btw, the reference FastCGI C library libfcgi also alters the environment to emulate legacy CGI and may also be vulnerable (haven't checked).

</comment></comment></comment><comment><USER7> NGINX should have really applied for a CVE instead of pretending that they are immune.

<comment><USER8> But Nginx _isn 't_ vulnerable. All Nginx does is proxying the HTTP headers. It is the applications that run behind Nginx that may be vulnerable depending on how they set/use environment variables.

Saying Nginx is vulnerable is like saying that the Linux kernel is vulnerable to heartbleed.

<comment><USER6> I think the CGI "standard" is to be blamed.

Whoever the f*ck had the briliant idea to alter the environment variables of a server child process through incoming HTTP headers should have his browsers environment variables altered by the servers responses.</comment></comment></comment>


Cannabalt for iOS now open source - <AUTHOR> https://github.com/ericjohnson/canabalt-ios

<comment><USER2> Game License:

       This game's Content is proprietary and protected by
       national and internation copyright and trademark laws,
       and may not be publicly distributed for free or for profit
       by anyone but the copyright owner.

GitHub Terms of Service:

       By setting your repositories to be viewed publicly, you agree to allow
       others to view and fork your repositories.

<comment><USER3> Content(assets) is different from code(source files).

<comment><USER4> It looks like both have been put under github.

<comment><USER5> It's possible to release code and media under more than one license simultaneously.

</comment></comment></comment></comment><comment><USER6> For such a simple game, Canabalt has some non-obvious tuning: <http://blog.semisecretsoftware.com/tuning-canabalt> I love such attention to detail.

<comment><USER7> This is an absolutely inspiring post. I've been thinking about the game mechanics (actual game mechanics :P) for a game I've had in mind for a few years now, and this is huge inspiration. Thanks for linking it. Sadly, I haven't found that many posts like this in the past.

</comment></comment><comment><USER8> Clarification: The engine is the only thing that is FOSS (i.e. everything in the flixel-ios directory. [https://github.com/ericjohnson/canabalt- ios/tree/master/flix...](https://github.com/ericjohnson/canabalt- ios/tree/master/flixel-ios) ) The rest is proprietary[1].

[1]: [https://github.com/ericjohnson/canabalt- ios/blob/master/GAME...](https://github.com/ericjohnson/canabalt- ios/blob/master/GAME_LICENSE.TXT)

<comment><USER9> No; in fact, the game images and sounds are not _free_ , but everything is open source and available for looking at (except the high scores code, which they left out to prevent cheating (explained in the blog post)).

<comment><USER8> Big difference between open-source and free, at least as you mean it. As the Readme says:

"The code contained within the 'flixel-ios' folder is licensed under the terms of the MIT license."

which allows redistribution. The next paragraph says:

"All other source code remains copyrighted and licensed by Semi Secret Software, LLC under the original terms. See the Game license (filename "GAME_LICENSE.TXT" in this archive) for more details. With the exception of code contained in the 'flixel-ios' folder, _you cannot redistribute our source code from the original game._ You can use our source code for personal entertainment or education purposes."

So, the code in flixel-ios is FOSS (you can redistribute it,) but the code _outside_ of that directory is source available _only_ (no redistribution.)

Edit: Proprietary software is "...computer software licensed under exclusive legal right of the copyright holder. The licensee is given the right to use the software under certain conditions, but restricted from other uses, such as modification, further (re)distribution, or reverse engineering.

"Closed-source software, or software distributed without its source code, is proprietary."

</comment></comment></comment><comment><USER10> I await a fork that lets me, you know, _win_.

</comment><comment><USER11> It appears to be an iOS port of the Flixel game library for Flash: <http://flixel.org/>

<comment><USER12> That makes sense, since Canabalt was first developed for Flash, then ported to iOS. Adam Saltsman is the author of the Flixel API as well as the Canabalt games.

</comment></comment><comment><USER13> Interesting, I'd comtemplated writing a similar game using <http://anscamobile.com> which is lua, but looks and works a lot like actionscript.

Now there will probably be a dozen other similar games though. ;-)</comment>


How to run a successful developer user group - <AUTHOR> http://www.sektor5.at/2014/11/how-to-run-a-successful-user-group/

<comment><USER2> Your website is really bad for low screens. The static (WHY?!) header and footer take about 30% of mine. And there is no visual distinction between them and the content. Last but not least, the text is uncomfortably huge. I like to see more than 10 lines of text on my screen, I am neither a child nor sitting 10 feet away.</comment>


Ask HN: How many daily visits to HN? - <AUTHOR> Are there some stats on how many daily users visit Hackernews? <comment><USER2> This is a starting point, without exact figures: [http://www.alexa.com/siteinfo/ycombinator.com](http://www.alexa.com/siteinfo/ycombinator.com)

<comment><USER3> I like how it drops down at the beginning of the year when people make new year's resolutions but then climbs right back up.

</comment></comment><comment><USER4> [https://www.similarweb.com/website/news.ycombinator.com#over...](https://www.similarweb.com/website/news.ycombinator.com#overview)</comment>


Catalan leader opens door to secession from Spain after vote - <AUTHOR> https://uk.reuters.com/article/uk-spain-politics-catalonia/catalan-leader-opens-door-to-secession-from-spain-after-vote-idUKKCN1C60Y6 <comment><USER2> From my narrow viewpoint provided by a few news outlets, it seems to me that Spain is handling this wrong at every turn.

Good grief, declare the vote invalid/ineffective or whatever, but let them vote. Censoring the web, apps, arresting political dissenters, blockading polling places, violent altercations with riot police.

All because people want to vote.

Spain is proving themselves to be a country worthy of seceding from.

<comment><USER3> > All because people want to vote.

No, they voted the very same referendum, but non-binding, in 2014 without problems. But this time they wanted to make it binding despite warnings from the gov that it's illegal as per the Spanish constitution.

<comment><USER4> If it's illegal per Spanish constitution, they can't make it binding. That's like I hold a vote in my house that I won't pay taxes anymore. Not paying taxes is illegal, so the vote result is of no legal consequence, but if police would show up and beat me up for having the vote, that would still be a gross violation of my rights. I think Spanish government shot itself in the foot massively here.

</comment></comment></comment><comment><USER5> Hmm... The question of taxation. Independence Day. Sound familiar?</comment>


What software would you use to write this? - <AUTHOR>

I am about writing a book and i would like to know the best software to use, something that would enable me include images, graphs and figures and finally generate a PDF. Pls Microsoft Word is excluded. <comment><USER2> LaTeX is the 'best' way to go. If you on Linux try the Kile , a excellent gui interface tool to LaTeX which does not impose any special structures onto your project. You are still free to arrange you LaTeX files as you wish.

Get yourself a decent intro to LaTeX book, Lamport's is the 'standard' , but other titles are very good as well.

LaTeX user guide and reference ( 2nd edition) : Leslie Lamport

LaTeX Notes, practical tips for preparing technical documents : J.Kenneth Shultis

LaTeX for everybody : Jane Hahn

are all useful reference to have handy.

BTW: I've used Tex & LaTeX since 1989 across various platforms, and have shifted all my projects without any 'conversion' problems because all LaTeX files are plain text. Most , if not all, other document handling tools use their own file formats.

Remember TeX is a document language so you have to write your text as plain text and it is 'compiled' into you printed document, it is not like using Word or OpenOffice. But once learnt Tex/LaTeX will prove useful forever !

<comment><USER3> I would second this recommendation. Learning enough LaTeX to typeset a whole book effectively will take some doing, but the effort is well worth it.

Apart from dragoncity's recommendations, these are also good places to start:

[edit: rather than clog this thread with a ton of links, I've decided to put them all in to a separate page which you can view here: <http://paste.pocoo.org/show/159346/> ]

</comment></comment><comment><USER4> Reading the other comments and responding, much of TeX (I don't know LaTeX - my Ph.D. was written in plain TeX) and HTML are interconvertable, depending on what you're doing. It depends a lot on the kind of book you're writing, whether you need equations, fancy layout, etc. If it were, say, a novel, I'd still go for the wiki. Then put tags for the linear arc through the narrative, and side pages for notes to yourself.

On the other hand, if it's a technical work then you might need something more high-powered. My book was quite technical, but I still used a wiki and embedded images from MimeTex for the equations. Exporting to HTML and using htmldoc worked a treat.

I'm technical, I did a lot of support work, I didn't use a tool "out of the box," but I could tweak it to do some unusual stuff.

YMWV. How much customisation are you willing to do?

</comment><comment><USER5> Academics from mathematical fields tend to use LaTeX. One way to compile a PDF is with pdflatex, which can import .png, .jpg, and .pdf images. This means you'd need to be able to get your vector images into .pdf format conveniently. This tends to be easy on traditional Unixy systems. I believe on osx too(?).

Many theses and textbooks are typeset with LaTeX. I used it for my PhD thesis. Advantages include: a plain text source file, which can be edited in your favorite editor; easy cross-referencing that automatically updates; high- quality typesetting. Some things that are very easy in Word are harder to do in LaTeX: for example, it can be tricky to select fonts or customize other aspects of a standard style file.

<comment><USER6> Yes, I use Latex on my Mac Book Pro (Snow Tiger). Works very well.

<comment><USER5> I was really referring to the ease of making figures in the right format, as the poster made a particular point about including figures.

When I used to use MikTeX on Windows (8 years ago now) saving figures to .eps or .pdf from most applications was possible but a bit tricky. It often involved printing to file with the right postscript driver [1], then fiddling with bounding boxes and running through epstopdf. Most Unix graphics applications produce postscript and/or pdf pretty easily. I _think_ osx with its Qwartz stuff will too.

[1] e.g. Apple Color LW 12/660 PS with "optimized for portability" turned on.

</comment></comment></comment><comment><USER6> If you find Latex too daunting, take a look at Lyx. It works more like a WYSIWYG word proc without changing the Lyx/Latex concept of writing what you mean.

One huge win with Latex is that if your publication is formatted to, say ACM guidelines, and it gets rejected, it takes less than a day to convert to IEEE transactions guidelines. With a WYSIWYG word proc, even with extensive use of styles, it would take many days to achieve the same level of transformation.

</comment><comment><USER7> I think LaTeX, <http://www.latex-project.org/>, would be a good choice, been using it for a bunch of papers for computer science. It is pretty easy to get started with a simple template.

I can recommend MiKTeX as an editor for windows

</comment><comment><USER4> Dreadfully low tech, but I would use a wiki, then export to a single HTML page and use htmldoc. At least, that's what I did.

I look forward to seeing other people's answers.

</comment><comment><USER8> Open Office. It gives you everything you may need while writing and also option for exporting file to Pdf format. Main advantage its free(Open Source).

<comment><USER5> Like Word, it probably isn't the best tool for something book length. It's really designed for letters and short reports. It can be done; I know brave souls who have written theses with Open Office. I just wouldn't personally give up the stability and neatness of working with plain-text source.</comment></comment>


When to bring in the heavy hitters (2017) - <AUTHOR> https://mfbt.ca/when-you-should-bring-in-the-heavy-hitters-947f35cb96e6 <comment><USER2> There's only one real answer. It's when you're ready to be a big company. But not just because you _want_ to be a big company.

Heavy hitters (i.e. former executives of big companies) bring big company expectations. They expect to hire a big team. They expect that your product is ready to scale, and in B2B, ready to be packaged and sold down a channel. They expect that you know how to sell your product in a repeatable way, a way they can copy, optimize, and teach to new hires. They expect to move at a big company pace, and expect you have some semblance of big company processes.

These people, in general, do not know how to, and do not want to, live the kind of startup life you've been living -- the hours, the apparent chaos, the extreme frugality, the wearing of many hats. They won't love your product like you do. This will be a job for them.

Remember that they're almost always from big companies, but much less often did they help build those companies at the critical juncture -- the time before everything was working. The time before it was clear the company would succeed if it could just expand on what it was already doing.

These heavy hitters mostly expect that your company already works, fundamentally, and that you're hiring them to do more of it. If that doesn't sound like your company, you're not ready yet.

And if you hire these folks before you're ready, it will probably destroy the company. It's a one-way function. By their nature, they'll drive out your early hires and scale your costs. If your revenues don't scale comparably -- because you didn't actually have product/market fit -- then those heavy hitters and the teams they brought on will leave when they see the writing on the wall. Leaving you, alone, back at zero.

<comment> bjelkeman-again I have seen that happen with a $100 million s/w company. It was very depressing. Not only where the people they brought in thinking of themselves as "heavy hitters". They where also poor at their jobs. They wouldn't have done particularly well even if the company was ready to scale. That of course didn't help. It was sad.

<comment><USER3> Those were not heavy hitters then. They just convinced the board that they were. I've worked with many of these people. They are terrible.

<comment><USER4> What kind of people would you search for to retain to help sniff out red flags the board might miss in situations like this? I know that it's in the board's job description, but who can you hire as a sanity check for such a big decision?

<comment><USER5> Someone who has done it before at slightly smaller scale. To grow a business from $50m to $200m in five years hire someone who grew a division from $10m to $50m in five years, ideally at a company where not every division grew at that rate.

</comment></comment></comment></comment></comment><comment><USER6> I think you need senior _technology_ people from day one, if you want to build to scale, and you don't really want to pay to build everything twice _and_ pay for extreme server costs _and_ pay to migrate from the old to the new system.

Maybe this means something different than "Heavy Hitters". I've never run a huge company division; I prefer to work in a startup environment, and except for a short stint at Amazon, that's where I've stayed. But I have been able to step into small companies as an interim CTO and turn their technology from a mess that won't scale and that was written by junior developers into something that will scale cleanly from day one.

And I typically do this by throwing away most of what was there to begin with and rebuilding from the ground up. Most junior devs just don't have good architecture and design in their blood like a strong senior developer. Which means there's 2-3x extra work to prevent the current system from dying or failing during the transition process ("Changing the tires while driving at 60MPH").

If instead you have someone like me drive the project from the start, when the project is _finally_ seeing traction you can focus on adding features your customers are demanding and pivoting if necessary. And you don't end up hemorrhaging money by paying for 50x as many servers as you would need if you'd start with a strong architecture.

And the funny thing? Hiring a strong dev early on will likely get you to a working product much sooner than several junior devs, and you overall save money due to launching sooner. So it's a huge win. And a lot of the time, founders _are_ junior devs (I've been coding for 30 years; anyone with less than five years is junior, from where I sit, and a decade is bare minimum to be "senior").

But everyone wants to cut costs and hire the $10/hour developers, or the green developers fresh out of college. And now articles like this are being written that imply that you shouldn't even hire a "heavy hitter" until some vague criteria have occurred...

Well, good luck with that. You might be able to pivot and improve your technology in time. Or you might end up going the way of Friendster, pissing off your user base because your site keeps failing, and by the time you have it working reliably, they've all left. [1] Or maybe the fact that they left allowed it to work reliably? Hard to say.

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

<comment><USER7> As a sub-junior developer, how does one go about architecturing software to scale?

<comment><USER8> Part is just experience. You have to have seen enough different kinds of people and systems work together to understand what works and what does not.

I think another part is simply nomenclature. There's a joke about the only two hard problems in computer science: Cache expiry and naming things. It's a joke because cache expiry reduces to naming the keys correctly if you do it right.

Basically, if the different parts of the system don't have sensible names that represent what they actually do (and that there are, indeed, different parts of the system), then there's an architecture problem.

You have to have an effective metaphor for the way that you want the system to work, and the problems you want each part of it to solve, or nobody will be able to understand the entire thing.

I run into this often. People have a functional but struggling system designed with the "big ball of mud" pattern, where you just keep slapping gobs of code onto it until it does what you need, and then they want someone to come in and "do architecture" at it. This predictably fails.

So, there's your heuristic: if it has good names, and the pieces do what they say on the tin, you're on the right path. When something starts to have responsibilities that aren't under that name, you should move those responsibilities somewhere else and name them appropriately.

Edit: There's also a second-order level where you start to recognize the way that cross-cutting concerns happen in different areas and design a piece of the system to handle that concern in an organized way. You can probably think of a bunch yourself, but an easy example you want to handle earlier rather than later is logging, and another significant one is authentication

<comment><USER7> So a the goal is a bunch of people can have their claws in the code base and avoid this reaction [0], but not necessarily code optimization, just as long as everything is highly modular and works independently of other parts you're kosher.

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

<comment><USER8> Right, the lower level stuff you're still looking for (cleanly designed classes and methods, good testing, etc), but you can hit all those micro-level targets without having any architecture to speak of.

(the "pile of classes" design pattern, where everything calls everything else and there's no hierarchy or anisotropy to it)

The other heuristic, besides "names make sense", is ease of modification. When you come back into an area of the system, how painful is it to disentangle that piece from the rest and make a significant change? Is the functioning of the entire system tied together tightly enough to make that difficult? Are there good patterns to extend, or is every change invented from scratch?

</comment></comment></comment></comment></comment><comment><USER9> Reading this article I feel like I just got done talking to a C-.

Grand words with strong advice, but at the end I'm not sure if the topic point "when C-level?" is any more clear in my head.

I apparently need to be:

\- Tired, but not so tired I can't survive the C- interviews

\- Willing to delegate, but know what stuff is OK to let go

\- Honest

Yet these seem more like qualities I just need in hiring. I'm tired of, or not good at, doing X job. I'm OK with not personally doing X. I tell the truth and expect new hire doing X to give it back. If all 3: hire someone for job X.

The main version for C- still seems to be, "the VCs are becoming a huge thorn in my side" whether I admit they have a point or I just want them to calm down.

Perhaps I'm just far too cynical about C- value these days. "We're strongly pushing to accelerate our core strengths and metrics while increasing overall investor value."

<comment><USER10> We should get rid of this whole "C-" idea anyways. Comes from rigid social ideas about how to organize companies, that tends to push down the importance of product and technology roles in favour of giving more social power to roles that in practice actually contribute way less.

<comment><USER11> "Efficiency in Employee-Owned Enterprises An Econometric Case Study of Mondragon"

[http://journals.sagepub.com/doi/10.1177/0019793914564966](http://journals.sagepub.com/doi/10.1177/0019793914564966)

Just read this and it was pretty interesting. Appearently in the studied group of organizations, coops are about as efficient as capitalist businesses but without lay offs and extreme inequality. There was some lower job satisfaction possibly due to higher expectations. There was a small efficiency benefit in some customer service oriented organizations.

Try sci-hub if you don't have institutional access. ;)

<comment><USER12> Mondragon is run as a normal corporation, mostly. It's just named differently.

<comment><USER11> Can you elaborate? Some of that is treated in the linked article. They do comparisons between the coop, limited coop, and conventional portions of their sporting goods and supermarket chains.

</comment></comment></comment></comment></comment><comment><USER13> Interesting essay. I really resonate with the honesty point, when the CEO especially has honesty issues the whole enterprise can go to hell in fairly short order.

I have also been in these conversations where really it's the investors who want someone "with experience with these things" and the founding staff is being cajoled along. A couple of times this worked out to an advisory role at the board level. It lets the founder get advice without feeling compelled to take it, and it lets the board feel like they have access to another point of view that might let them see things they are missing.

The key though is that the executive team has to internalize that _they_ and not their engineers or sales or marketing people are holding back the company. That can be tough, especially if your CEO is short on self awareness.

</comment><comment><USER14> If you like this post, the rest of the blog is really good: [https://mfbt.ca](https://mfbt.ca)

A lot of insightful gems on how to be better at leading in tech.

Also, their new book: [https://www.amazon.com/dp/0995964300](https://www.amazon.com/dp/0995964300)

</comment><comment><USER10> Sorry, but I couldn't take a single actionable thing from that long rant... Lots of really mushy sentiment instead..

</comment><comment><USER15> 'Bring in the heavy hitters' strikes me as an odd way to phrase 'the investors have decided to take your company away from you and put someone else in charge who may or may not understand the business'.

Surely the correct way to react to that is to start by asking what you've done wrong, and whether you can fix it? If the investors are just being assholes for the sake of it, you've got a fight on your hands, but hopefully that's not the typical case.

Unless it's a case where you don't want to run a big company? But the article didn't seem to be talking about that.</comment>


Why you should Not use a web framework - <AUTHOR> http://checkedexception.blogspot.com/2010/04/why-you-should-not-use-web-framework.html

<comment><USER2> If you're judging frameworks by Struts then no wonder you think they're a bad idea. Try writing a webapp in Wicket some time. Pure bliss.

</comment><comment><USER3> A good developer can write her own framework. Tailord to the needs of the project.

But most people aren't good developers. :)</comment>


Michael O. Church: "Software engineers aren't a privileged set" - <AUTHOR> https://www.quora.com/Why-do-software-engineers-make-so-much-With-so-many-students-pursuing-careers-in-software-engineering-today-do-you-see-salaries-going-down-significantly-in-the-future-If-so-by-how-much/answer/Michael-O-Church?share=1 <comment><USER2> Heh... I love michaelochurch. I mean, I don't always agree with him, and sometimes he can be a little bit obnoxious / overly opinionated / whatever. But he's right on the money quite often; and you have to respect a guy who takes a principled stand, refuses to bow to popular pressure, and stands his ground.

I wish he still posted here on HN, but I think he either got banned, or just dropped off for some reason. :-(</comment>


Java Developers - <AUTHOR> http://nsainsbury.svbtle.com/java-developers <comment><USER4> I agree with much of the article (also as being a java developer for the last 17 years).

However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem:

Frameworks.

Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is at an all time high), and often code following 'best practices' handed down from academia/conferences/books that promote large abstractions which are often un-necessary.

It's similar to how C code would end up having pointers-to-pointers-to- pointers-to-pointers...

A whole generation (generalising/stereotyping, I know) is now coding, who have never grown up and learnt with basic logic gates and low-level code. The framework is the obvious choice because 'why would you want to write it yourself, if it exists' ?

(Ironically, many Javascript developers seem to be intent on re-inventing everything that's gone before, and it's somehow seen as innovation - <USER2> figure)

Grumpy old man ? Sure, I am. I'm also gladdened to see a recent upsurge in assembly language and other low-level coding, as this is what the world actually needs - less super-business-entrepreneurial startups, and more people able to actually solve _real_ problems and not just hipster entertainment.

<comment><USER5> Interesting! The most important difference between frameworks and libraries seems to be the "don't call me, I'll call you" pattern. Frameworks call your code, while libraries get called by your code.

It's easy to see why "don't call me, I'll call you" leads to unreadable code. A piece of code is readable if you can understand how it works, not just what it does, and a big part of "how it works" is figuring out the control flow. Inverted control flow makes code less readable, regardless of any other benefits it might have.

Viewed in that light, it's hard to see how moving to better languages like Haskell would solve the problem. Functional programmers pass functions around all the time, so a lot of functional "libraries" are actually frameworks that insist on calling your code in complicated ways, making it conform to very precise types required by the framework. There's certainly no shortage of abstraction in Haskell code. As a result, it seems that most Haskell programmers don't even try to understand the control flow of their programs, because it's almost impossible.

I wonder if we could have a principled approach to programming that discourages the "don't call me, I'll call you" pattern, and encourages code that you can simply read from top to bottom. Do this thing, then do that thing, then do the other thing. It would probably be unlike anything that exists in academia today.

<comment><USER6> > "don't call me, I'll call you" pattern

Just call it the Hollywood Principle [1], and ya, it sucks. Databinding frameworks like React go a long way in fixing this (and my own work [2] also).

[1] [http://en.wikipedia.org/wiki/Hollywood_principle](http://en.wikipedia.org/wiki/Hollywood_principle)

[2] [http://research.microsoft.com/pubs/211297/managedtime.pdf](http://research.microsoft.com/pubs/211297/managedtime.pdf)

<comment><USER5> I really like your work, but not sure that it lies on the right side of the framework/library divide. For example, to realize the full benefits of your approach, you define a new programming language with "no escape hatches". That's the most extreme kind of framework thinking!

My favorite post about libraries and frameworks is this one: [http://web.archive.org/web/20130810134741/http://an9.org/dev...](http://web.archive.org/web/20130810134741/http://an9.org/devdev/why_frameworks_suck)

> _Frameworks hurt sharing. I 'd really like to give you this fork Jimmy, but > you're gonna need a knife and plate to use it. The framework checks out all > your girlfriends for you, the framework won't let anyone dirty get through, > the framework will wait up until you get in, the framework will always find > out were you've been, the framework keeps you healthy and clean. Frameworks > embrace, extend and hold on to greedily._

<comment><USER6> We are not so much defining frameworks as we are new ways of computing. In that sense, it's not really something that will be ready tomorrow (or ever). I do use glitch as a library in C# for UI and compiler programming (hard to program very interactive UI and compilers otherwise), but that is with lots of escape hatches :)

<comment><USER5> Fair enough :-) Thanks for the pointers!

</comment></comment></comment></comment></comment></comment><comment><USER7> I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered.

I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc.

I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competitive market. So pluggable drivers for everything. Rather than build in say, one XML parser, instead let's build in a whole system to allow you to plug in any XML parser. As a result, it takes 4 lines of code to do what should work in 1 line. On other platforms, Python, Ruby, Go, et al, there is no such assumption that one needs an abstract interface to allow multiple implementation providers. You have an opinionated built-in implementation, or you use third party APIs.

This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc.

When really, you want to write: Document doc = XML.parse(...)

Enterprise developers copied the basic design of having provider lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator stuff.

Where I part company with the author is the total trashing of OO and the language. There are certainly lots of warts and things to complain about, but I haven't used a single language where I didn't have a boatload of things to bitch about.

I think you fall in love and there's a honey moon period with most languages, and then the beer goggles wear off after daily use and you see all the flaws.

<comment><USER8> You are bang on.

It reminds me of the opposite take that we've seen in browsers as of late. Eg. innovate with webkit specific extensions then standardize what works. Java meanwhile standardized conceptually useful concepts (Swing, Java Server Faces, etc), but the markets for pluggable Swing or JSF components never took off.

I think it's that under Sun's direction the intent was to create markets, e.g. a market for GUI components or web components, a market for server components (EJBs). At least in the case of server components, Sun made a lot of money by licensing J2EE servers. I suppose that was their motivation all along for forcing DocumentBuilderFactory's on developers.

</comment></comment><comment><USER6> > The OO craze has a part to play in this madness as well. More and more > developers are stepping back and realising that as a programming paradigm, > OO is actually pretty shit.

Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.

> Even today you'll still find a strong bias towards OO courses being taught > at the university level using Java, and the bias was certainly stronger 5 - > 10 years ago.

Because that's what people use to write real programs.

> The engineers at Google working on Android are too busy architecting grand > frameworks for solutions and not busy enough solving actual problems.

Because we all know, Google is known for hiring flakes who can't code or design real systems.

Worse is better means getting things done even if your tools kind of suck or your understanding of the problem isn't yet great. It leads to architecting and less than ideal solutions, but at least you ship!

<comment><USER9> > _OO actually works well for scaling complexity, much better than toy > immutable functions do._

Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled.

A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making the point any further: [http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_us...](http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_use_with_the_Abstract_Factory_pattern)

It is my fervent hope and wish that all programmers someday accept that there is no universal methodology, that FP and imperative and OO all have their place and their faults, and that it is OK to sometimes not use one of them somewhere.

<comment><USER6> If you get good at programming, you actually know when to apply these patterns (and many others not in the GoF bible).

And of course, I mix OOP and FP styles all the time, I'm not a purist by any means (a guy who does F# once commented on how FP my C# code looked).

<comment><USER10> > If you get good at programming...

This is a very important point (hopefully more "when" than "if"). I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.

<comment><USER11> _I 'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools._

This is one of the biggest problems with Java — and other "pure OO", "everything is an object" languages of the same style — particularly from a teaching perspective: when all you have is a class, every problem looks like an object.

If we present a language like Java as being the default, standard, safe option, how are new developers ever going to gain enough knowledge and experience to realise that their elaborate design with seven different classes in Java could have been replaced by a single 10-line function in Python, or a few short lines of Prolog, or a single query in SQL?

</comment></comment></comment></comment></comment><comment><USER12> A lot of these bloated patterns that got popular in the Java world have shorter, simpler alternatives when programming in a functional style. You often don't need multiple child classes to implement a template method if you can just pass a function to the constructor. You don't need a BananaFactory if you can just inject a createBanana function.

Remarkably many Gang of Four design patterns are unneeded once you can pass functions around. The C# world is now learning this: when C# 1 and 2 were popular, the ecosystem went right after Java in the kinds of boilerplate that the author describes. Now, many years of Func and Action goodness later, there's a large part of the community that codes way more to the point, and this part is growing. People who release C# libraries in 2014 with factories adapters and multiple layer inheritance hierarchies are laughed at.

Since Java 8, Java too has an accessible way to pass functions around. Not really functions, because Java, but in practice it works the same way. This means that there's nothing _technologically_ that's holding the Java community from making these improvements, too.

I hope it happens.

<comment><USER13> I don't think Android supports Java 8, though.

<comment><USER14> I thought there was some work to support Lambdas in ART?

<comment><USER15> There is a retro-lambda library that allows to write lambda expressions. It is compiled to jdk 6 compatible bytecode though.

</comment></comment></comment></comment><comment><USER16> I've always found that the people who write the AbstractFactoryFactorySomethingVisitor patterns are the people who read about design patterns and want to use them for the sake of using them, because they think it makes them better developers.

Instead they should learn about design _principles_ , and instead of thinking "which pattern should I apply here", they should be thinking, "what is the best way to create this code so that the basic design principles are upheld". You can start with SOLID principles and go from there.

The same happens with language features; when generics were introduced, everyone wanted a generic class for some reason when it's almost never needed outside of the Collections framework (bit of a sweeping statement but I hope you see what I mean).

In fairness, I don't think it's really Java's fault, only that it's been around long enough for there to be many more examples of this kind of thing. I've been working in Java for 15 years and C# as my day job for the last 3 - you can easily pick out examples in C# where the langauge has been abused: dreadful LINQ expressions where a simple for-loop would suffice (and be quicker), or multiple Events added to a class, ALL of which need to be hooked up by calling classes for it to be usable, so an Observer really would, actually, have been a better solution.

I've played around with functional programming and there are a lot of claims around how it forces programmers to write better code. I'm not sure how it's going to stop programmers abusing language features or the language characteristics, though. I may well be wrong about that and am happy to be put right by a knowledgable FP dude.

</comment><comment><USER17> I've been using Java for about 15 years and largely agree with the article. The verbosity of the Java language is definitely part of the problem, although that aspect is downplayed in his blog post. I agree with the author about the culture. Java programmers in general seem to be on some sort of design pattern frenzy, especially in the better known frameworks. It doesn't matter if you're writing a fancy framework or writing a trivial app to process a file, chances are you're going to see layer upon layer of over-engineering.

I switched to Scala a couple of years back and have never been happier. Only part of the improvement is due to the language the other part is not having to deal with Spring, builder patterns, and madness like AbstractSingletonProxyFactoryBean [1]. My impression has been that the typical Scala developer has had lots of Java exposure and has learned from their experiences.

[1] [http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...](http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

</comment><comment><USER18> I disagree with this, as a part time Java developer (I do C# most of the time). The points I disagree with:

1\. _OO is bad_. Every paradigm is bad if you misuse it. If you build deep abstractions then you will hang yourself regardless. Some very elegant and simple designs can emerge from OO code, but only if you think about the problems first. The majority of pain consists of forgetting to do that step. There is no magic bullet - FP has its own pitfalls as well as does simple procedural programming.

2\. _Everything looks like it 's written by an architect_. Well that's a broad generalisation and I'm sure some people titled architect would be sick at the association (considering they usually reduce complexity) but the problem here is that people aren't using the frameworks properly. Not joking but the last two or three Java web applications I've put together have virtually no code in them. It's just the domain model, the views and query encapsulations. Nothing else. The abstract factory factory factory factory crap isn't your problem. If you make it your problem, then you're just doing it wrong or not using the tools provided efficiently.

3\. _Android_. Android is abysmal (I've written a couple of things for it so far), but that's not because of Java but the fact that the Android API and versioning mess is a pile of unstable crap. It'd be nice if there were't so many exceptions.

If you're going to pick on Java, at least jump on: Idiotic code on the web, Glassfish being a right pile, view technology being foul, servlet container reloading, Swing/JavaFX or Eclipse...

<comment><USER19> Some of the complaints about the over-formal language is a matter of taste, perhaps, but it does grate and is not a new complaint (see also: the Kingdom of Nouns rant). However Java developers are learning (or migrating to Scala/Groovy/Clojure). And there is hope -- the Play framework, for example, is an example of Java done right (imho). Spring 4 is moving in the right direction.

<comment><USER18> I don't think it's a matter of taste. TBH I write very little of the code that is checked in to the source control. The IDE does all the boilerplate. I literally design the method signatures, define the access policy for the methods and fill in a few gaps here and there.

Play is not Java done right by any means. It's tightly coupled, has really poor documentation, breaking changes galore between major releases, deployment is trouble (compared to tomcat) and rather tied to Scala's API.

Java done right is picking some lego bricks that you stick together to get what you want and telling it how to wire them up.

YYMV but 99.9% of all problems are already solved off the shelf.

<comment><USER20> Ninja Framework is rather nice, I've found. I looked around for Java web frameworks lately and it seemed to be the one that balanced good documentation, features, simple configuration and so on to my liking.

<comment><USER18> Thanks - I will investigate this one.

</comment></comment></comment></comment></comment><comment><USER21> As the author said its not the languages fault. And if you know what you are doing then Java is clean, mature, performant, dare I say it enjoyable platform to use.

I think there also a generational conflict here. Java is a development environment that was born in the big architecture and 'development as enginerring' era of the late 90s. Spring was a reaction to the over engineered J2EE and now even Spring, the early liberator is considered over engineered.

Its our dad's language.

There is still a certain mindset from that era that was conditioned by the GOF and Universities and amaeteurs churning out developers but it is increasingly rare.

In fact I find Java is amongst the most interally introspective and disciplined in terms of coding taste and style.

I can almost guarantee if I look at another Java developers codebase that I can follow their code structure and style without too much effort. I'm not sure that would be the case for the large amount of very individualistic FP code being generated currently.

</comment><comment><USER22> I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, android, etc. I've used lots of frameworks like Spring and Hibernate. Although such frameworks often provides abstractions and encourages usage of design patterns, I've never really found my-self getting lost in their layers of abstraction, and I've can't really say I've come across any "AbstractAdapterFactoryProviderBean"-either.

I've also never found my-self working with a code-base I'd considered clean and highly maintainable. When code-bases becomes big and complex, they tend to get messy. It's hard, if not impossible, to maintain a complete view of the entire application at once - and this leads to different approaches at different times, and places in the code. Having multiple developers come and go, with various levels of skills, does not help either. Having some framework dictate the overall structure of the application limits the potential for to much diversity in the code, it also helps new developers get a grasp of the codebase if they have used the framework, or similar frameworks, in the past.

When I design a simple application, the flow is limited, and I don't need the abstractions - so I don't implement them. But when the system grows in complexity, and the concepts and logic starts to overlap, it becomes reasonable to implement abstractions. To layer the application into DAO, service, persistence layer, etc. To group common logic, and make abstract implementations. I could go on. Abstractions are good, but overuse is also not good - of-course, like everything else it's about finding the right balance.

<comment><USER23> I can say the same re your experience, but I kind of experience the same thing he links to with Gradle and really despise it. Handling the constant Groovy errors and Gradle errors, and spending my life digging through their docs for a language and a build system I couldn't care less about really depresses me when I'm a Java expert. Give me a stack trace and I'll have the problem fixed in five minutes with unit tests and UI automation tests done later that day.

But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.

</comment></comment><comment><USER24> Java hits a sweet spot of simplicity, platform stability, safety and performance. Also, its popularity in the enterprise is partly _because_ interchangeable, cog-in-the-machine low quality developers can be productive in it and not cause too many meltdowns. Thats an economic advantage! If you need lots of cheap developers for your IT department, good luck finding 15 Clojure and Haskell gurus.

I say that as a Java developer, btw.

<comment><USER25> Simplicity -- none, if talking about the resulting code.

Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past.

Performance -- poor, regarding memory consumption.

Indeed, the sweet spot.

> If you need lots of cheap developers [...]

Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. It's the same hard finding decent Java programmers as it is with Haskell, except that Java scares good devs away and Haskell attracts them.

<comment><USER26> _Simplicity -- none, if talking about the resulting code._

Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot.

 _Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past._

Bollocks. I challenge you to provide an example of a Java developer being sued for using the language.

 _Performance -- poor, regarding memory consumption._

Bollocks. Uses more memory than C, but no manual management. Sweet spot.

 _Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent._

Bollocks. In my experience, they're likely to be somewhat better skilled and educated. They're also far more likely to spend their time arse-ing around trying to implement an elegant, concise solution to problems which only exist because of not-invented-here syndrome, or because their language lacks as extensive a standard library.

As an example, I once worked on a Mac GUI app for a company - bog-standard, nothing fancy. I took over from a developer who had been trying to build this using Racket; this involved building a Qt-Racket interface, which involved magical automated parsing of C++ header files, which meant… basically, not delivering a product. Meanwhile, the Objective C build was done.

The point is, there's far too much focus and snobbery about what tools developers use. There are loads of languages out there; pick one that has a reasonable amount of support and fits the problem domain, and build simple, maintainable code. You can do that in any language.

<comment><USER27> > I challenge you to provide an example of a Java developer being sued for > using the language.

Google ? [https://en.wikipedia.org/wiki/Oracle_v._Google](https://en.wikipedia.org/wiki/Oracle_v._Google)

<comment><USER28> Google is not a software developer, rather a corporation that tried to work around paying for J2ME licenses.

</comment></comment></comment></comment></comment><comment><USER29> There is a lot of Cargo Cult programming going on among Java developers.

Why using a simple constructor when you can use the factory design pattern? Or why directly instantiating a logger using the "new" statement and the right arguments, when you can also configure it using xml files? Making use of design patterns and frameworks is professional, after all, isn't?

<comment><USER30> over the years, I developped a fiery hatred of XML configuration files.

<comment><USER31> and I'm starting to develop a fiery hatred for JSON configuration files. At least XML had standard support for schemas and querying.

</comment></comment></comment><comment><USER32> While I have seen what you describe, I am not sure if it is only specific to Java, and I have to admit that I enjoy working with the Java platform. There are things in the ecosystem that annoy me more.

We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared.

So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment.

Java build tools are insane.

To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too. At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place.

So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars).

A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler.

But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff.

Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons.

And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.

<comment><USER25> Programmers rarely see how their software is built and shipped. Those who have this opportunity rarely have their taste developed to see that external dependencies have cost associated. And it's not something specific to Java: I see the same in Ruby and Python.

It could give the perspective to programmers requiring from them that they always build their software on a freshly installed machine with no network connection.

<comment><USER32> That is why I don't understand the "enterprise" sticker they try to put on some Java stuff.

Building without network connection was a feature most of these enterprise "build tools" did not get right from the beginning.

Patching a dependency, rebuilding the affected chain and ship it back to the customer is something I still ignore how the Java ecosystem does with their native tools.

Probably they just do "mvn" in their workstations and .zip the output folder.

</comment></comment></comment><comment><USER28> Java is not the problem, enterprise architects are.

If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it.

So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues.

Anyone complaining about enterprise Java, just needs to go back a few decades to see what was being done in C, C++ with CORBA/DCOM, VB/Delphi, CLIPPER and tons of wannabe 4GL languages.

Any language that wins the hearts of enterprise architects will suffer the same pains that Java is known for.

I can already imagine a "Enterprise Functional Design Patterns" and similar books.

<comment><USER20> Ah yes, DCOM. That was truly the domain of the C++ enterprise architect! Today's AbstractProxyFactoryBean was yesterday's IDispatchProxy, IRPCProxyBuffer and so on.

What's scary is that big chunks of heavy industry are all standardised on it via OLE for Process Control (OPC).

<comment><USER28> Thanks to WinRT is it back!

</comment></comment></comment><comment><USER33> Disclosure: Long time Java programmer here (since 1996, previously worked many years with Smalltalk). Java Language and Java Virtual Machine are great, but Java Libraries are in many cases too complicated (using too much of "Gang of Four" patterns).

</comment><comment><USER34> Java combines OO with strict typing (unlike Ruby which has OO without the strict typing). As such, that particular combination leads to bloat and verboseness. See:

What did Rich Hickey mean when he said, "All that specificity kills your reuse!"

[http://programmers.stackexchange.com/questions/199217/what-d...](http://programmers.stackexchange.com/questions/199217/what- did-rich-hickey-mean-when-he-said-all-that-specificity-of-interfaces-cla)

Part of the answer given:

"If you have two entities { "name":"John" } of type Person, and { "name": "Rover" } of type Dog, in Java-land they probably cannot interoperate unless they share a common interface or ancestor (like Mammal, which means writing more code). So the interfaces/types here are "killing your reuse": even though Person and Dog look the same, one cannot be used interchangeably with the other, unless you write additional code to support that. Note Hickey also jokes about projects in Java needing lots of classes ("Who here has written a Java application using just 20 classes?"), which seems one consequence of the above."

<comment><USER35> > Java combines OO with strict typing [...] > As such, that particular > combination leads to bloat and verboseness.

It's bloated and verbose, because Java isn't very good at it, not because it's a fundamental issue of OO with types.

> in Java-land they probably cannot interoperate [...]

Ditto.

</comment></comment><comment><USER36> The proliferation of factories is not an indication of over-architecting something. It is a direct consequence of finding a balance between maintainability and the lack of first class functions (or constructors as first class functions).

If you have never had the need to introduce factories, I claim that you have not worked with a truly polymorphic system.

</comment><comment><USER37> I agree with the general sentiment of the article. I have used Java since the beginning and I have written many books using Java for the examples in the books.

I mostly use Haskell and Clojure (with little text utilities in Ruby) now, but I still do find that Java is sometimes the best language for some projects. Off topic, but Java 8 streams and inline functions made the language better.

That said, I no longer use Java in any sort of "standard" way. I stopped using getters/setters years ago in favor of public instance variables. I also write a lot of static methods ("functions"). Basically, I try to make my Java code as concise as possible.

I also have turned my back on large server side frameworks. For web services, embedded Jetty and a JSON library is often all the library support that I need.

</comment><comment><USER38> Blame the 90s : the Gang of Four design patterns book, UML, et al.

If you wrote code that did not abstract enough, such as not using factories, it was jaw-droppingly obvious to your colleagues that you were not good enough. FP and Scala owe the sheer verbosity of Java a lot for their current success :-)

<comment> cam- Java has been round long enough to have been influenced by whatever was the coding fashion of the time. You can see it in the core java libraries and the supporting frameworks. OO and GoF where probably the biggest fashions and you can document when a core library was written by the approach to it.

</comment></comment><comment><USER31> Wow there is a lot of bashing of the GoF patterns going on here. It seems like lots of people have a misconception about what patterns are. Patterns aren't a goal to meet with your software. They are common emergent solutions to standard design problems. The GoF didn't invent them, they just cataloged and provided a standard name for them.

So once we have a common name, shouldn't we use it? If I see a FooFactory, I have a pretty good idea what to expect in that class. So the problem with a FooFactoryFactoryAdaptor isn't that it is following GoF patterns or in it's silly name, it's that you have a solution that has at least 3 levels of abstraction. The patterns didn't cause that.

</comment><comment><USER39> Can't agree more.

The problem is not the language itself, rather who uses and whats the culture associated with it.

Java is mostly used in the enterprises, where unfortunately thest "architects" exists. Architects are nothing but people have grown out of the roles and in a way of organization recognizing the peoples talent. Most of the times the Architects are redundant.

Most of the cases use of Java is nothing but writing your business logic into the Java code.

Unfortunately, architect to justify himself would try to engineer a solution, which never needed engineering itself. and down you go in the rabbit-hole of oops and abstraction.

Unfortunately it will be pretty hard for Java to shake up this image.

<comment><USER40> Good architects play a vital role in the organisation especially if you have a sprawling set of agile teams that don't necessarily work together.

There are plenty of really tough integration, security, scalability and performance challenges that need someone who is across the entire stack from very top to very bottom. You rarely find developers who can manage it all and still find time to cut code.

</comment></comment><comment><USER41> The language has some very poor design decisions baked into it (read: no functions) but the biggest problem with Java is that it's the lowest common denominator enterprise programming language, and managers have used it to lower the bar in their attempt to commoditize programmers. As a result there are lots of Java programmers on the market, with low salary expectations, and the code they produce is of commensurately low quality. As Paul Graham put it, Java is a language you learn to get a job. Do you want all your company's code to be written in a language that your programmers only learned because they needed a job?

</comment><comment><USER42> Recently-graduated student here, middle-aged and with more than my fair share of life challenges under my belt. I fell in love with coding by accident, after half a life in the restaurant trenches. But one of the things you can learn in the trenches is the value of patterns, and the value of recognizing patterns. Over the years I've come to trust my instinct for recognizing patterns, hard-won as it was.

Java is swamped in an over-proliferation of verbiage. That is the first impression one has of the language in school: that it requires twice as much code to do anything. And that was, as well, my last impression, as they tried to prepare us for our entry into the world of enterprise computing by steeping us in a rolling, boiling stew of jEverything. Too many cutesy names in a programming language just felt WRONG, and I think my instincts have been borne out. Java is a mess to behold and to work in, and I am fantastically glad that I didn't get that first (Java) job I applied for, but instead got the second (ASP.NET) job.

Irony abounds, I know, but .NET seems streamlined and elegant compared to Java EE. Turns out, sometimes you actually CAN judge a book by its cover. And by the 1496 pages in that Java textbook, which, hysterically, serves as merely an introduction...

I don't know where I'll be in a few years, but I'm fairly certain I'll not be coding in Java.

</comment><comment><USER43> I for one appreciate the hard work that was Android and Java. I spent two years intensively self-teaching, primarily on Android before starting my developer job. Having to take in large, unwieldy systems with lots of moving parts was mind expanding. I could spend a night in the API, go to bed and wake up feeling smarter.

I haven't done any Android for my job (and just a little Java), but every time I have to design more than a self-contained python script, I'm grateful for the exposure to such complexity.

</comment><comment><USER44> Java can be really glad that there is Google with Android. Otherwise this language would be a strong enterprise focused language with very bad reputation on the end user side.

<comment><USER45> However - how many developers are turned off of being Android devs by the fact they have to use Java?

(and I know that probably many more are attracted because they already know Java but that's not my point)

<comment><USER46> I was turned off by a.) horribly slow speed of Android virtual machine b.) being hard to code for it with maven c.) I did not particularly liked their xml language for gui.

I would have to write mobile, I would use one of those languages that compile into both Android and iOS as much as possible.

<comment><USER47> Exactly. I personally think Java is fine. It's just that the development environment is much less nice than Xcode.

</comment></comment></comment></comment><comment><USER48> The dependency-injected style is great for mitigating side-effects and avoiding hard dependencies in code.

The problem is that it's a poor substitute for currying and composition.

<comment><USER36> I agree.It's good design in the disgusting veneer Java requires.

</comment></comment><comment><USER49> As a newly hired Java dev I can understand the problems that Java has with many levels of unnecessary complexity. However, I do not think it is right to simply say that all or even most Java devs are bad. First of all the definition of bad is relative to the person and secondly I would not agree in saying that they are all or mostly bad. People are usually trying to do the right thing and if that does not fit inside your ideals then it is bad?

I guess all I am saying is not the throw stones. No one is perfect and to bash a whole community today based a snapshot of what you have seen is narrow- minded, look for the good parts and focus on those at least. Teach someone to code well in Java, if you feel so inclined to say that you know better. I know that there is a lot to learn, personally. I currently do like Javascript and Python as well but I would never look down on Javascript, Python, or Java communities. They are all great in their own way and in many similar ways.

We all enjoy coding at some level, why does anotehr way of doing that have to be so worng?

</comment><comment><USER50> "Android - really the biggest reason today why anyone besides the enterprise guys cares about Java anymore"

This line just says - ignorance. Thee is a __*tonne of stuff in Java. And just because the majority of developers are low quality(what language does not have that?), does not diminish the interesting stuff that is going on with the whole platform.

</comment><comment><USER51> > "(...) OO is actually pretty shit (...)"

 _Relief washes over me in an awesome wave_ when I read this line.

No, no, I'm not attempt to mindlessly bash OO. But I've worked over the years with folks that put OO as some sort of holy rules. When arguing X vs. Y the discussion goes well until someone says "Y is wrong, Y violate {this} of OO", shit, when that little statement is made I know I'm lost. Because even if I attempt to show that in this particular case violating such principle is good, I am doomed to be considered a heretic, an outsider, and sometimes automatically a bad programmer.

I've tried to not thought of my self as an 'enlightened', but people kept acting as believers of such religion over and over that I could help myself sometimes. It's pretty much the feeling of being a philosopher teacher in mormon cult of something.

</comment><comment><USER52> As a relatively young programmer, I feel that I'm just now exiting this stage of over-abstraction and pursuing a "perfect" design. Perhaps it does plague many older programmers, but to me super object oriented programming was a sort of programming puberty. In high school, I would sit down to write a Java program and figure that I would have to construct this grand architecture where each class reused absolutely no code and fit perfectly in an abstraction hierarchy. Of course, I would quickly lose focus of business logic and write a gazillion SomethingSomethingRepresentation classes and get nowhere. It really hit me when I realized I had a file named Null.java :)

</comment><comment><USER10> So happy to read this, yes, yes, and yes.

Another big problem with Java to me is that the standard library and available frameworks are so massive, that there are thousands of ways to solve any given problem. This is bad, because only a handful of the solutions perform well, result in readable well-written code, and are efficient (from both a productivity perspective and resource utilization perspective). I'm not sure why, but it seems like many developers are almost trained to pick the bad ones. Perhaps the high level of abstraction enables the programmer to ignore the realities of the implementation?

</comment><comment><USER53> > More and more developers are stepping back and realising that as a > programming paradigm, OO is actually pretty shit.

It is sad to see such strongly-worded blanket statements. The author generalises his experiences with Java to entire OO. He doesn't, unfortunately, seem to realise that non-Java OO does exist.

Also, several lean Java frameworks exist, without deep class hierarchies and factories of factories.

Finally, OO is one of several possible ways to modularise and scale code and teams. FP is another. As languages like Scala have been demonstrating, it is possible to selectively blend features of both in fruitful ways.

</comment><comment><USER54> I'd much rather have a large application written in OO w/ Java then a functional only application. I have serious concerns about maintainability otherwise. This is of course assuming that we have good developers on either side.

Especially when the language in question is getting libraries and native features that pull in the good parts of other languages.

Blog posts like these make stupid generalizations.

I'd also like to say if 5% of the Java Developers are the good developers that would be factors more than 100% of the Clojure developers + 100% of the Haskell developers + 100% more than the F# developers.

</comment><comment><USER55> Having worked in the Java world for the past 8 years, I think the issue with the developers is that the work is boring and they want to solve some problem. Folk who work with Ruby (at least 2-3 years ago) were doing something interesting. It could be a simple CRUD app, but Ruby made it interesting. People wanted to be there. Java is not.

Instead, Java has a history of patterns for the sake of interest. Need to inject something in? Use a FactoryFactory. Most of what Java becomes revolves around having to do tedious CRUD apps for the enterprise that constantly change what they want.

</comment><comment><USER56> It will be interesting to see if Java8 inspires a fresh look at the design approaches used in the Java world. So many of those over-architected Java designs are trying to solve lack of flexibility and expressiveness in the language. There's an opportunity now to keep the good and move on from the bad ... it's terribly unfortunate though that it's not clear if Android will ever properly update from Java6 syntax. If it doesn't a large amount of the Java ecosystem is never going to move on from there.

</comment><comment><USER57> The real problem is developers not understanding Object Oriented programming. Many developers write procedural style in Java or any other OO language. So you get God classes, methods that are hundreds or thousands of lines long etc - I'm sure we've all seen those horror shows. It's just a lack of education coupled with a culture where there is no strive for technical excellence.

You need high quality developers in Java, just as you do in any other language.

It seems like the article's beef is with OO programming, not Java per se.

</comment><comment><USER58> While I do agree that java developers are often low quality developers. And than java frameworks are often bloated with Dependency Injection, Factories, Proxies etc...

I disagree that Android has the same problems. To me it looks like Android was actually written in lean-and-mean java. Ok its still Object Oriented. But for UIX interfaces, Object Orientation makes a lot of sense...

There are some areas in the android API that are indeed a bit bloated. And that is indeed inherent to java.

<comment><USER59> > While I do agree that java developers are often low quality developers.

That can be said for ANY language.

</comment></comment><comment><USER60> As the article states, this isn't a _general_ Java problem. Just a problem of people copy pasting horrible code suggestions (or design suggestions) off some vendor's tutorials.

Here's a blog post that shows how to make a game out of that madness we have gotten used to thanks to JEE / Spring

[http://blog.jooq.org/2014/04/01/spring-api- bingo/](http://blog.jooq.org/2014/04/01/spring-api-bingo/)

</comment><comment><USER61> Interesting read, explains well why I don't like to code in Java anymore. Most Java devs who go too deep in frameworks and complexity should try to build a small project in a very dynamic and concise tech. I always recommend Node.js for that, since you have to selcet the right module for every job, have to think it through and really understand what's going on, and can easily step inside the code if need be.

</comment><comment><USER62> I think the author is out of touch with modern Java development practices. Any decent Java developer would have got exposed to POJO based development[1] by now. [1]Expert One-on-One J2EE Development without EJB - Rod Johnson, 2004

These days even the much hatted EJBs are POJO based and lot easier to work with. Not to mention Lambda support in Java 8 and the hybrid approach of Scala, my favorite.

<comment><USER63> I think the commentator should read the article. The author does not once mention EJB. The problems he describes are endemic to all kinds of libraries and frameworks and are VERY much a part of most shop's interpretation of "modern" Java development.

</comment></comment><comment><USER64> I totally agree with the original poster. I picked up Java in the mid-90's for server-side dev. Grew to loathe it.

When Google announced an open-source OS for mobile - I was so happy. But ... Java. Broke my heart. Don't Google have any taste. At least Google could bless an alt-Java Swift-ish alternative like Kotlin, Xtend, AnythingButJava.

<comment><USER20> They don't really need to bless it, do they? Any JVM language that targets Java 6 should work.

<comment><USER64> Google have issues with Oracle. Why not bless an alt-Java and give developers a clear signal. The end game should be Kotlin or Xtend or ? -> Dalvik/ART. Cut out Java.

<comment><USER65> Dart for the win

<comment><USER64> Dart is interesting but a little too Jave-ery in both syntax and tools - <USER3> Editor is Eclipse based. Also, not sure how committed Google is long-term.

Google's issue is too many languages and runtimes: Go, JS/ES6/V8, Dart/DartVM, Java/ART, PaNcl, RenderScript.

With the Material/Paper UI Google have given dev's a consistent, elegant unified surface. But Google should also be moving in the direction of an (elegant) unification under the hood. Java and JS are 20 years old - but are at the core of Google's platforms - Android and Chrome/OS. But what - Kotlin, Dart, ES6/7?

</comment></comment></comment></comment></comment><comment><USER66> I think this code truly represents the essence of this article: [https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

</comment><comment><USER67> I actually have a different problem. Java developers that are IDE jocks and dont have any kind of understanding of what is happening underneath the API. Take these guys outside of the IDE and they dont even know how to compile the code.

</comment><comment><USER68> Great article, but I especially encourage you to read the one before it as well...

[http://nsainsbury.svbtle.com/leonardo-da- vinci](http://nsainsbury.svbtle.com/leonardo-da-vinci)

</comment><comment><USER69> For Android developers interested in building apps in Scala check out Scaloid: [https://github.com/pocorall/scaloid](https://github.com/pocorall/scaloid).

</comment><comment><USER70> I have been using Java for a really long time. I have never seen a "AbstractAdapterFactory" anywhere. Ever. Disclaimer: never did any J2EE BS.

</comment><comment><USER71> Good read - the bit about Android is spot on.

</comment><comment><USER72> "I'm an Android developer, stuck using Java. It's breaking my heart." Glad that I am not alone.

<comment><USER64> Definitely not alone.

At the Google IO Android Fireside Chat, a developer asked the Android team about using an alternative to Java for development - Scala in his case. Pretty much 'no' was the response. But don't Google have any taste. Kotlin or Xtend imo are lighter than Scala and would be good fits for Android.

</comment></comment><comment><USER73> well nothing convinces me like unsupported assertions and undirected insults. I now hate java as well.

</comment><comment><USER74> You can use Xamarin (C#, F#) for Android though, which will let you go multi- platform in future.

</comment><comment><USER75> I heard Kivy is getting more popular, that is if you like writing in Python.

</comment><comment><USER76> Not only Java. I die a little every time I see a PHP application trying to cargo-cult common Java overdesign patterns because "that's how 'Enterprise' apps are built".

</comment><comment><USER77> I've worked with java for 10 years now... I have seen some shit let me tell you.

</comment><comment><USER78> I second and third everything he said.

</comment><comment><USER79> One problem with Java is the 15+ years of bad taste. Design patterns are "revenge of the not-nerds". It's "I don't know what a monad is and don't care to learn, but I'm going to make _you_ feel the way I do when I see math by renaming the sine function to VibratorVisitorFactory."

Moreover, Big Software is generally a bad idea. There are occasions where large programs are a good idea, but the default should be small, composable units. Scripting and batch jobs aren't "baby coding". They should be the default _unless_ you need a long-running server process. _Most_ programs (over 90%) should be doing one thing and doing it well. The problem is that people don't code this way because it's better for enterprise managers' and architects' careers to say they oversaw gigantic, overarching software projects.

I've actually noticed that data scientists, while their line-by-line coding skills aren't as good as a professional software engineer's, are usually much better designers (and far better communicators) than Java engineers. Sure, R is janky and Python has ugly corner cases, but data scientists write programs to do specific tasks and generally are good at keeping code small (because they have a personal responsibility for the code-- if they can't read it, it's basically lost-- not experienced by "architects" who can hire maintenance engineers to clean up their messes). You don't see the enterprise "software for software's sake" problem.

The result of Big Software tends to be Java Shop Politics, as described here: [http://michaelochurch.wordpress.com/2012/04/13/java-shop- pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/) . It's not the fault of _Java_. It's just a bad way of writing software.

<comment><USER80> I've noticed that the combination of math and communication skills is pretty well correlated with producing clean designs and code. Data scientists probably have those skills more often than programmers, but I'd argue that it's the skills rather than the culture that account for the difference you are seeing.

</comment></comment><comment><USER81> Knock, knock. Who's there? Long pause ... Java!</comment>