What if you did a Poe's Law version of this? That is, try to create the most contrived parody of a solution to FizzBuzz possible, but one which still fools at least 50% of interviewers into thinking it's a legitimate response.
I'd love to see a branch of this with your suggestion, though... and maybe a script that would automatically generate a file structure that reflect the namespace of serious business with which one is interviewing. You know, for fun ;)
That's great, but we're here to make fun of "Enterprise" programming and anything associated with it. Now you come along and give us this simple example that works.
I bet it would still be better in Javascript or Ruby because those are the only two languages that I know and everything is better as a web app anyway.
I met some c# guy who did the whole enterprise thing in his version, but it wasn't tongue in cheek at all.
in my head I went, this is why the whole ms enterprise stack sucks balls. the sad part is that they actually think it's good to abstract away something really simple.
EDIT: removed the link, sorry for offending you dude
"in my head I went, this is why the whole ms enterprise stack sucks balls."
Brilliant. So, if some random programmer built some way-over-complicated Javascript solution, would you think that the entire web platform "sucks balls"?
"the sad part is that they actually think it's good to abstract away something really simple."
Who is they? Microsoft, this random c# guy or all c# programmers? If you answer anything but "random c# guy", I'd like your evidence please.
Also, let's see some of your code please. Not fizzbuzz. I wanna see some of your real life code.
The problem isn't random programmers, it is a culture and tool ecosystem which says that this is the right way to do things. If it were just one random programmer, there would be nothing to complain about.
If some guy decides to write his website in his own dialect of Visual Basic, that isn't really being inflicted on anyone but his employees. The deeply-nested StrategyFactory stuff is an infection which worst affects languages like Java and C# (recruiters call it "OOP") because those communities do not strongly reject it.
Why do JAVA, C# (and the like) IDE's have such complex feature sets? Is it not a reflection of the complexity that those ecosystems require for maintaining your code?
Which feature set? The core of these IDEs is a debugger that is highly integrated with a text editor. Is there a problem with that? IDEs often show me the files that are in the project. Another common (core) feature is code completion. Also, integration with common source control systems. Too complex yet?
You didn't mention XCode. Why not? It has all of those features. So, it must be the non-core feature of IDEs that makes one seem complex and the other not. Which features are you talking about?
I concede you make a good point. Most of the features you listed I end up using via command line rather than it being integrated directly in my editor. Maybe part of what i see as complexity is just my cheese being moved. However, and correct me if im wrong, IDE's are more popular with "powerhouse" OOP languages in general. I always thought that it was because navigating these types of projects with just a simple text editor was too cumbersome without the editor being aware of context.
so overcomplicated javascript is not overcomplicated?
i just started working on microsoft enterprise garbage. ever had to deal with sharepoint, dynamics?
even microsoft developers say you're doomed when you're being put on a sharepoint project.
I just codereviewed code for 2 different dynamics contractors. Both highly recommended by microsoft. both of them had high levels of abstractions, but the end result was tightly coupled anyway.
Their javascript was written the same way. The real joke of it was that I had never done anything of the likes.
Want some of my real code from many years ago? go through mplayer/ffmpeg
Say what you want about the culture but I've found MS's stack to be quite good with the right team. It's got some great features. LINQ in particular springs to mind.
There are plenty of terrific systems built atop that stock. StackOverflow is implemented in ASP.NET, for instance.
dude! microsoft is not just enterprise. they have the biggest r&d lab with some really awesome shit going on.
linq is made by the haskell guy. well the haskell guy was a microsoft guy. but you get the idea. it did not grow inside of the .net enterprise culture. it grew outside of it. I never had any qualms about c# as a language. but that's also not what we're discussing.
just like f# is wonderful. but it too did not grow inside, but outside. they're being really smart about tying it into the enterprise as much as possible therefore guaranteeing it's future though.
Your comment offends me, but on a light note, for every 1 developer doing the enterprise overengineering crap, there is a dozen of us C# guys who are doing the opposite where I work.
No. I honestly want to see some of this great code that I keep hearing about.
It's just hilarious to me when people think their shit doesn't stink and so I rub their faces in it.
Have you seen the code for Node.js? It's fucking disgusting. Yet everybody around here can't get enough of it. Seriously...I'd love to see how some of these developers would deal with enterprise requirements. I think the problem is that they just don't understand that business is chaos, it's not like building some pie-in-the-sky single-purpose social media application.
It's quite common in these parts to be honest to piss on .net/Java 'enterprise' code.
Many of the folks here haven't seen what kind of systems banks and other big companies work with, so they have this little start-uppy world view with tests and orm's and the like, where vulnerabilities in their software are touted as 'the price to pay for being agile', so it is very hard for them to understand some of the practises in big companies. Now sure, I've seen some bad code in there as well, but I also seen a lot of bad code in Rails projects (heck, before the idea of fat model skinny controller, most of rails programmers had controllers the size of the moon, then cam fm-sc and now models are enormous, but in rails 4 we will have concerns which I'm sure will result in same clusterfuck, and the interesting thing is, before fm-sc, rails folks said 'yeah, controllers are supposed to be like that', then with fm-sc 'no no, it's like this now', and now we get to concerns and will be the hot topic, and they keep rewriting and rewriting and touting how .net/java devs don't know what they are doing, while these devs have code in production and still in development for decades (well, java at least) in systems they can't even imagine the complexity.
tl,dr: stop assuming .net/java devs are shit and you are the best for using rails or python, chances are, you suck as much as them.
In all fairness, banks in general have shit security and willfully ignore good security practices. I can configure my Facebook account to have better security than most banks.
No, C# best practices look nothing like this. I have no idea what happens in Sharepoint land or deep in the enterprise and MS Office stacks, but the core of .Net is not over-engineered to this level. Factories, FactoryFactories, and XML-configurable dependency interjection frameworks are nowhere to be seen.
never having been in such a situation, I wouldn't know, but this is the first time i'm hearing of people putting java within the package name (for something that's not part of the java namespace)
I haven't actually seen java in package names, but I can easily imagine the conversation where some over-planning architecture astronaut decides that the project may need code in another language in the future (without bothering to worry about if that language even uses Java style packages) and so they better make a directory that is specific for the Java code so they can keep the other code separate, if they need to add more languages in the future.
I've not seen it directly in the package names, but I've definitely seen project hierarchies with source/java even though no other languages were used (or going to be used, for that matter).
This is how I learned Java in software engineering. Simplistic if/else logic transitioned to enterprise madness. It left a bad taste for most of us in the program.
If you are a teacher in this position, provide fleshed out source/examples of enterprise software/requirements and have the students extend the functionality. Using minimized examples to prove the concept leads to rebellion/disgust.
I can't tell if some of the obviously missing patterns are accidental or just representative of that usual type of code with all of the wrong patterns and none of the right ones.
Ha! You think any enterprise IT shop is going to trust an open-source product like Subversion with their mission-critical source code? It would be in Perforce or MS Team Foundation Server.
Sometimes they don't have a say. I've worked with several large fortune 500 companies who use SVN, regardless of how much the IT Department objected to it.
Eh, Perforce is too pleasant if we are really embracing enterprise; makes it too easy to do sensible things like use a git client. No, it has got to be SVN for maximum pain.
Besides the "modern" VCS's, I've used SVN, CVS, Perforce, and done both manual patch management and patch management with Quilt. I am sure there are some VCSes out there I would hate more than SVN if I used them, SourceSafe I'm sure, but I would honestly use any of those others I just listed before SVN again. Yes, I consider SVN to be a devolution of CVS.
This is terrifying. It's like a docu-horror flick for programmers. I actually felt depressed, anxious, frightened, and dispaired going through that code.
"One-liners lead to unclear code that has too much responsibility crammed into too little space. It's better to do less per line and keep the code readable. This changes the very complex and ambiguous operation <= into two separate, easily understood operations < and ==."
Last week my colleagues and I realized that the official, Zend-provided, XML-based communication system that allows our PHP middle-end to talk to our RPG-based backend doesn't allow you to return any character string that includes a less-than symbol.
One of our routines returns a SQL string.
Sometimes SQL strings contain less-than symbols.
After much handwringing and an official bugfix that fixed nothing whatsoever, we decided on the next-best solution: all instances of `where foo < bar` must be generated as `where foo != bar and foo !> bar`. I shit you not, that is a not-greater-than operator.
I may sound frustrated, but I'm not. We all had a good laugh at the workaround and got back to work. This sort of thing is sometimes known as "job security".
Where is the Spring dependency injection stuff? You can't just hard code all your Factories in FizzBuzz.java, you need to specify everything using XML so you can switch Factories without going through a recompilation.
Exactly. No Spring, no Maven...I mean, come on. Plus, I'd like to see some Camel routing defined for sending my crucial FizzBuzz results to various endpoints.
Oh yeah, and what about when I want to run scheduled FizzBuzz? Obviously I need Quartz, which requires...more XML!
Let's not get into the necessity of making a FizzBuzz OSGi bundle - we'll tackle that in the next iteration.
I've often wondered - is it the language that spawns this or the mindset of the developer (or both?)
I see this primarily in Java or .NET shops - massive layer upon layer, code generation, factories, classes, etc. - when a simple architecture would be best. Why do we get these insane things to begin with? What's going on?
It feels sort of like premature scaling (what if we have millions of programmers - we need more abstractions!) combined with misuse/misapplication of design patterns.
You'll never* see stuff like this in Ruby on Rails, JavaScript, Python projects, etc. I'm curious how one goes from a simple, elegant program to over-engineered monstrosities.
Part of it is "customers want it", part of it is because people are taught "abstraction is good", rather than "abstraction can be useful".
So folks abstract everything, because they don't stop to think about whether it makes sense.
You know, just in case the day comes when they need to send requests using carrier pigeons instead of TCP. They never stop to think whether "in a world where we need carrier pigeons, would this app be useful anyway?"
Have to agree there... but without having to support/supplant multiple systems simultaneously, or in support of rigid testing, it doesn't make much sense.
In the former case, it's usually easier to rewrite than write a new, compatible abstraction... in the latter, with simpler more custom interfaces, testing can be smoother than a lot of frameworks for these things.
I wonder too. I write a very atypical brand of Java (I like to think of it as "unencumbered Java"). I sometimes even use public fields instead of accessors (o, the heresy).
My best guess would be that you often need to refactor you code to include some of the patterns showcased in the repo (factories, for instance). So developers try to future-proof their project by using those patterns everywhere. This is obviously a terrible idea.
Now for the bitchy part, why does no one ever speaks about the good sides of Java?
So developers try to future-proof their project by using those patterns everywhere.
Something I've seen a lot (and been guilty of myself) is trying to fix the problems of past projects in new projects before they crop up.
A better solution is to not be afraid of refactoring (tests help here) so you can solve the problems when they become a problem, not create complication before.
> Now for the bitchy part, why does no one ever speaks about the good sides of Java?
Cause at some point most of them got tired to preach about Java and continue to do great work vs worrying what other people think.
Look around: NetFlix, Yammer, Twitter, Google are all using Java to power either their infrastructure or apps. Nobody blogs about it because "It Works" ;)
The rest blogs how they keep jumping between wagons :P
this joke thing isn't really about Java as a language though. its about a very weird/bad and surprisingly common design anti-pattern. Java was used to do this joke because its utterly typical for this type of work, but certainly you can have this kind of disgusting enterprisey garbage in just about any programming language.
nobody makes jokes at the expense of well written Java software because its well written. we all know that the language is perfectly fine, and in alot of ways quite good, when it is used by sensible engineers.
I almost feel like, as a programmer, you can get "calibrated" to a certain level of architecture or designed-in flexibility, and then any time you have to code something "lesser", you end up adding architecture and boilerplate until it looks like the things you're familiar with.
Look at the HTML5 IndexedDB API, for example: obviously designed by someone "calibrated" to coding web browsers, not someone calibrated to doing web scripting.
I agree with you. It seems like Java programmers at enterprise ignore Cohesion vs Coupling tradeoffs. Every class and abstraction they write is so tightly coupled which causes issues when debugging or just trying to figure out how to add a feature enhancement without writing more classes. Working as a software engineer, it sucks looking at a 1000 lines of code to do something simple that can be done in 10 lines elsewhere --> means that OO is not the right way to go about things sometimes.
And partly a correlation between the type of company that chooses a "proper", statically typed, "enterprise ready" language and the type of company that hires "safe pair of hands" programmers who value predictability over getting stuff done.
Must be the mindset. I've seen plenty of straightforward, well written C# code with none of this garbage. I'm sure it's the same with Java. And you would see plenty of Ruby code written in this kind of style if Ruby was popular in enterprise software development.
I agree with that. For example, Azure storage is pretty straightforward and simple to use [1]. Or LINQ, which is part of the .NET framework and is beautifully simple to use.
they don't contain more information. they contain more explicit declarations of that information. dynamically typed languages leave that information hidden because it is inferrable (or irrelevant).
When the programmer is the one that has to be doing the inference you refer to, there seems to be a good argument that the speed advantage you refer to is only apparent in programs small enough to conceptualize in their entirety.
indeed. Scala's type inference system is truly beautiful. lets hope it catches on and becomes a widely adopted feature of the next generation of languages.
If you want to see a really beautiful type inference, take a look at Hindley-Milner. Not only is it global (it infers all the types in your program) but it's also surprisinlyg simple--it's basically just a straightforward constraint satisfaction problem.
In particular, take a look at how it has been extended by real languages, especially OCaml. OCaml has some very cool sub-typing features but manages to maintain global inference, unlike Scala. (Largely by choosing structural rather than nominative sub-typing.)
So some languages have had better type inference for longer than Scala has been around.
It's environmental, largely driven by a) the need for cost certainty, and thus the susceptibility of non-technical management to the allure of the Bag Of Magic Beans sales pattern (see also: the fungibility of skilled work fallacy); and b) the need for risk abatement in large organizations.
I've always found it most useful to think of this sort of garbage as an effort to hedge against terrible communication. Sure, it's likely to be a load of blood sweat and tears spent on useless tangential silliness; but one time in a hundred, the plastering of abstraction over ill-definied abstraction will allow a team to anticipate one step ahead in the chain of ever-shifting requirements, and thus, earn back a few hours and a tiny shred of dignity.
Nobody really likes this crap. But the life of the mean programmer is a grim one, indeed. Ultimately, the problem is that nobody really knows how to write software.
Not to defend the indefensible, but why not make a couple of discussion points...
If you have a huge application and a high staff turnover you want to minimise the amount of information in your developers' heads. Strictly architected code can do this to some extent, and can go some way to reducing need for that other 'enterprise bane' - documentation. This is less of a problem in a startup type environment were you can find out about a particular piece of code by walking over to the kid that wrote it and having a chat.
Code generation (mentioned elsewhere on the thread) is another example of something that is less necessary in a small environment. Matching an enum to the contents of a database table or whatever can be done by convention to begin with, but it's less practical if your development team is spread across three timezones. Better to invest the time in letting computers do the work.
It all comes down to testability. In statically typed languages like C# and Java, it's very hard to test a class in isolation without abstracting hard links between classes, segregating interfaces, inverting dependencies and so on.
You can write "simple" systems in those languages that have the code purity you're looking for, but they won't be very testable.
In the dynamic languages you mentioned, you have duck typing and testing is a walk in the park.
From what I see it is usually well intentioned but not exceptional developers trying to write "good code".
They know some sort of abstraction is called for, but they end up picking abstractions which are actually a net negative for code complexity, rather than a positive. If you have enough of these developers then it devolves into code very much like the OP.
There is also a resistance to large refactorings which "clean house" of these sort of abstraction errors in enterprise teams and a lack of developers with the skill (and balls) to do it. So this cruft tends to accumulate.
If you are new to an organization, do you rock the boat and fight for code-reviews for nice looking code, or do you bite your tongue and and write enterprise code to make everything go smoothly, from an administrative standpoint? You are not going to be scolded and forced to defend yourself for the enterprisey code, even if it ultimately was the wrong choice.
Then angularJS dropped. Now we see it there as well.
[disclaimer: I am programming a service in angularJS for the client and SpringMVC for the server. My code looks exactly like this. I cry myself to sleep every night.]
Honestly, I'm not sure where it comes from... I tend to bypass/rip out this kind of obfuscated crap from projects wherever possible... "Microsoft Enterprise Library" is about the bane of my existence... I've only seen two projects in the 11 or so years of .Net development where it was a good use case.
Lately, for smaller one-offs, utility scripts etc.. NodeJS is my tool of choice. Even where it isn't the fastest choice, it tends to be one of the easier choices without going to a language the rest of the systems don't use (JS is used on the web, so web devs need to know it anyway)...
God... this is particularly painful because I remember first seeing this in a thread on boards.4chan.org/g/... and now, several months later, here it is on hacker news.
* provision one ec2 instance per number to check
* assign numeric order based on uptime in msec using zookeeper
* serve result via json
* render it on the client.
print(type("",(),{"__call__":
lambda self, start, end:
[(n, (lambda x: ("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else ""))(n))
for n in range(start,end+1)]
})()(1,50))
170 comments
[ 5.7 ms ] story [ 268 ms ] threadWhat if you did a Poe's Law version of this? That is, try to create the most contrived parody of a solution to FizzBuzz possible, but one which still fools at least 50% of interviewers into thinking it's a legitimate response.
I'd love to see a branch of this with your suggestion, though... and maybe a script that would automatically generate a file structure that reflect the namespace of serious business with which one is interviewing. You know, for fun ;)
class F{public static void main(String[]a){for(int i=0;i++<100;)System.out.println((i%3>0?"":"Fizz")+(i%5>0?i%3>0?""+i:"":"Buzz"));}}
I bet it would still be better in Javascript or Ruby because those are the only two languages that I know and everything is better as a web app anyway.
[0] https://plus.google.com/u/0/111011776153281260419/posts/GWdk...
I met some c# guy who did the whole enterprise thing in his version, but it wasn't tongue in cheek at all.
in my head I went, this is why the whole ms enterprise stack sucks balls. the sad part is that they actually think it's good to abstract away something really simple.
EDIT: removed the link, sorry for offending you dude
Brilliant. So, if some random programmer built some way-over-complicated Javascript solution, would you think that the entire web platform "sucks balls"?
"the sad part is that they actually think it's good to abstract away something really simple."
Who is they? Microsoft, this random c# guy or all c# programmers? If you answer anything but "random c# guy", I'd like your evidence please.
Also, let's see some of your code please. Not fizzbuzz. I wanna see some of your real life code.
If some guy decides to write his website in his own dialect of Visual Basic, that isn't really being inflicted on anyone but his employees. The deeply-nested StrategyFactory stuff is an infection which worst affects languages like Java and C# (recruiters call it "OOP") because those communities do not strongly reject it.
Can you please name some tools and tell us how they say this is the right way to do things?
You didn't mention XCode. Why not? It has all of those features. So, it must be the non-core feature of IDEs that makes one seem complex and the other not. Which features are you talking about?
Eclipse, Netbeans, Maven, JUnit, JLog
J2SE libraries - pretty much all of them
Apache libraries
Hibernate
J2EE libraries
The list is endless
Even Google App Engine manages to be way more convoluted in Java than in Python or Go, it's not even funny
Furthermore - does this really help the argument that "the whole ms stack sucks balls" or even "the whole java stack..."?
[1] edited from Netflix. I use Netflix all the time, too!
I don't write java code like that as well (and I don't use swing) but sometimes is unavoidable due to the ways the libraries are structured.
i just started working on microsoft enterprise garbage. ever had to deal with sharepoint, dynamics?
even microsoft developers say you're doomed when you're being put on a sharepoint project.
I just codereviewed code for 2 different dynamics contractors. Both highly recommended by microsoft. both of them had high levels of abstractions, but the end result was tightly coupled anyway.
Their javascript was written the same way. The real joke of it was that I had never done anything of the likes.
Want some of my real code from many years ago? go through mplayer/ffmpeg
edit: as pekk said the problem is cultural
There are plenty of terrific systems built atop that stock. StackOverflow is implemented in ASP.NET, for instance.
linq is made by the haskell guy. well the haskell guy was a microsoft guy. but you get the idea. it did not grow inside of the .net enterprise culture. it grew outside of it. I never had any qualms about c# as a language. but that's also not what we're discussing.
just like f# is wonderful. but it too did not grow inside, but outside. they're being really smart about tying it into the enterprise as much as possible therefore guaranteeing it's future though.
I'll take C# over Java any day. Hands down.
It has its warts, sure, but it's night and day. I can't pin it down, but the C# libraries seem much more natural to me.
Of course, if the team culture is not good, it's going to be messy, either in Java, C#, Python, etc
Also, I'll be waiting to see some code that you think is great.
It's just hilarious to me when people think their shit doesn't stink and so I rub their faces in it.
Have you seen the code for Node.js? It's fucking disgusting. Yet everybody around here can't get enough of it. Seriously...I'd love to see how some of these developers would deal with enterprise requirements. I think the problem is that they just don't understand that business is chaos, it's not like building some pie-in-the-sky single-purpose social media application.
Many of the folks here haven't seen what kind of systems banks and other big companies work with, so they have this little start-uppy world view with tests and orm's and the like, where vulnerabilities in their software are touted as 'the price to pay for being agile', so it is very hard for them to understand some of the practises in big companies. Now sure, I've seen some bad code in there as well, but I also seen a lot of bad code in Rails projects (heck, before the idea of fat model skinny controller, most of rails programmers had controllers the size of the moon, then cam fm-sc and now models are enormous, but in rails 4 we will have concerns which I'm sure will result in same clusterfuck, and the interesting thing is, before fm-sc, rails folks said 'yeah, controllers are supposed to be like that', then with fm-sc 'no no, it's like this now', and now we get to concerns and will be the hot topic, and they keep rewriting and rewriting and touting how .net/java devs don't know what they are doing, while these devs have code in production and still in development for decades (well, java at least) in systems they can't even imagine the complexity.
tl,dr: stop assuming .net/java devs are shit and you are the best for using rails or python, chances are, you suck as much as them.
See, easy to over generalise.
Edit: And amazingly just 12 minutes ago: https://news.ycombinator.com/item?id=5395645
Great parody.
There's also src/main/resources, src/main/webapps, and possibly other dirs that can go in there that aren't other languages.
If you are a teacher in this position, provide fleshed out source/examples of enterprise software/requirements and have the students extend the functionality. Using minimized examples to prove the concept leads to rebellion/disgust.
How ironic. This covers so many enterprise programmers with locked down Windows PCs.
https://github.com/Mikkeren/FizzBuzzEnterpriseEdition/pulls?...
The potential for more funny is great here.
Change <= to < and ==
"One-liners lead to unclear code that has too much responsibility crammed into too little space. It's better to do less per line and keep the code readable. This changes the very complex and ambiguous operation <= into two separate, easily understood operations < and ==."
One of our routines returns a SQL string.
Sometimes SQL strings contain less-than symbols.
After much handwringing and an official bugfix that fixed nothing whatsoever, we decided on the next-best solution: all instances of `where foo < bar` must be generated as `where foo != bar and foo !> bar`. I shit you not, that is a not-greater-than operator.
http://pic.dhe.ibm.com/infocenter/dzichelp/v2r2/index.jsp?to...
I may sound frustrated, but I'm not. We all had a good laugh at the workaround and got back to work. This sort of thing is sometimes known as "job security".
Long story short: bureaucracy.
Oh yeah, and what about when I want to run scheduled FizzBuzz? Obviously I need Quartz, which requires...more XML!
Let's not get into the necessity of making a FizzBuzz OSGi bundle - we'll tackle that in the next iteration.
I see this primarily in Java or .NET shops - massive layer upon layer, code generation, factories, classes, etc. - when a simple architecture would be best. Why do we get these insane things to begin with? What's going on?
It feels sort of like premature scaling (what if we have millions of programmers - we need more abstractions!) combined with misuse/misapplication of design patterns.
You'll never* see stuff like this in Ruby on Rails, JavaScript, Python projects, etc. I'm curious how one goes from a simple, elegant program to over-engineered monstrosities.
* Hardly ever. I haven't in > 7 years.
So folks abstract everything, because they don't stop to think about whether it makes sense.
You know, just in case the day comes when they need to send requests using carrier pigeons instead of TCP. They never stop to think whether "in a world where we need carrier pigeons, would this app be useful anyway?"
"Object-oriented abstraction is going to change everything."
"Yeah, abstraction is good."
In the former case, it's usually easier to rewrite than write a new, compatible abstraction... in the latter, with simpler more custom interfaces, testing can be smoother than a lot of frameworks for these things.
My best guess would be that you often need to refactor you code to include some of the patterns showcased in the repo (factories, for instance). So developers try to future-proof their project by using those patterns everywhere. This is obviously a terrible idea.
Now for the bitchy part, why does no one ever speaks about the good sides of Java?
'Code to use, Refactor to re-use'
A better solution is to not be afraid of refactoring (tests help here) so you can solve the problems when they become a problem, not create complication before.
Cause at some point most of them got tired to preach about Java and continue to do great work vs worrying what other people think.
Look around: NetFlix, Yammer, Twitter, Google are all using Java to power either their infrastructure or apps. Nobody blogs about it because "It Works" ;)
The rest blogs how they keep jumping between wagons :P
nobody makes jokes at the expense of well written Java software because its well written. we all know that the language is perfectly fine, and in alot of ways quite good, when it is used by sensible engineers.
Look at the HTML5 IndexedDB API, for example: obviously designed by someone "calibrated" to coding web browsers, not someone calibrated to doing web scripting.
And partly a correlation between the type of company that chooses a "proper", statically typed, "enterprise ready" language and the type of company that hires "safe pair of hands" programmers who value predictability over getting stuff done.
There are thousands of things one might want to do in the future, and many managers "prepare" for each and every change they can conceive.
So do good, high-level statically typed languages, i.e. the kind with type inference. Like Scala or ML.
In particular, take a look at how it has been extended by real languages, especially OCaml. OCaml has some very cool sub-typing features but manages to maintain global inference, unlike Scala. (Largely by choosing structural rather than nominative sub-typing.)
So some languages have had better type inference for longer than Scala has been around.
I've always found it most useful to think of this sort of garbage as an effort to hedge against terrible communication. Sure, it's likely to be a load of blood sweat and tears spent on useless tangential silliness; but one time in a hundred, the plastering of abstraction over ill-definied abstraction will allow a team to anticipate one step ahead in the chain of ever-shifting requirements, and thus, earn back a few hours and a tiny shred of dignity.
Nobody really likes this crap. But the life of the mean programmer is a grim one, indeed. Ultimately, the problem is that nobody really knows how to write software.
If you have a huge application and a high staff turnover you want to minimise the amount of information in your developers' heads. Strictly architected code can do this to some extent, and can go some way to reducing need for that other 'enterprise bane' - documentation. This is less of a problem in a startup type environment were you can find out about a particular piece of code by walking over to the kid that wrote it and having a chat.
Code generation (mentioned elsewhere on the thread) is another example of something that is less necessary in a small environment. Matching an enum to the contents of a database table or whatever can be done by convention to begin with, but it's less practical if your development team is spread across three timezones. Better to invest the time in letting computers do the work.
You can write "simple" systems in those languages that have the code purity you're looking for, but they won't be very testable.
In the dynamic languages you mentioned, you have duck typing and testing is a walk in the park.
They know some sort of abstraction is called for, but they end up picking abstractions which are actually a net negative for code complexity, rather than a positive. If you have enough of these developers then it devolves into code very much like the OP.
There is also a resistance to large refactorings which "clean house" of these sort of abstraction errors in enterprise teams and a lack of developers with the skill (and balls) to do it. So this cruft tends to accumulate.
If you are new to an organization, do you rock the boat and fight for code-reviews for nice looking code, or do you bite your tongue and and write enterprise code to make everything go smoothly, from an administrative standpoint? You are not going to be scolded and forced to defend yourself for the enterprisey code, even if it ultimately was the wrong choice.
Writing "enterprise" code is "safe".
[disclaimer: I am programming a service in angularJS for the client and SpringMVC for the server. My code looks exactly like this. I cry myself to sleep every night.]
Lately, for smaller one-offs, utility scripts etc.. NodeJS is my tool of choice. Even where it isn't the fastest choice, it tends to be one of the easier choices without going to a language the rest of the systems don't use (JS is used on the web, so web devs need to know it anyway)...
/fizzbuzz.js/ for(var i=1;i<=100;i++)console.log(!(i%3)&&!(i%5)?'FizzBuzz':!(i%5)?'Fizz':!(i%3)?'Buzz':i);
Or, in other words, the place that makes that kind of architecture won't allow the developers to touch anything that's not Java or .Net.
It is done in node.js with the latest something.js fad that provides event-driven async MVC interfaces in Coffee script or something like that
Also, they will have 100% code coverage (thanks Uncle Bob) but will fail at launch since nobody bothered to test it for more than one user.
;)
Tempted to send this to my Java colleagues.
[(n, (lambda x: ("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else ""))(n)) for n in range(1,51)]
print(type("",(),{"__call__": lambda self, start, end: [(n, (lambda x: ("fizz" if x % 3 == 0 else "") + ("buzz" if x % 5 == 0 else ""))(n)) for n in range(start,end+1)] })()(1,50))