Approaches that become popular and highly publicized definitely impact everyone else's work in that field. Teams decide to migrate to those approaches, discarding others, based on perceived popularity, shallow impressions, small amounts of experimentation. Often, this is all we have to go on. But team members who have an intuition that the approach may have more problems than are first visible now have a choice, to either silently go along with the new decision, or to document their reservations. The anger is an issue though. It's a product of when you perceive a waterfall of hype crashing over your own perception of better judgment (please note: perception. subjective viewpoint). It's worth it to try adjusting those perceptions since anger doesn't really get you anywhere.

Couldn't agree more.

We're all aware of the Internet Hype Machine. We've all been duped by it before. Heck, my big project today consists of frantic backpedaling from an overly hasty decision, prompted by the IHM, to use SQLite in a project that had no business being based on SQLite. We should all be open to hearing criticism about choices to use X or Y technology.

-But- if you start by saying, "You're so stupid," then the person you're talking to will start by thinking, "You're such a jerk." And nobody really pays much attention to the opinions of people they think are jerks.

Socratic method for the win. Keep asking questions until THEY come the conclusion that what they were thinking was a dumb idea.

That works, but I think it's overkill. Generally the "don't argue like a jerk" method is sufficient.

And if you aren't good at it it's easy to come off as condescending. Thereby also causing you to be written off as a jerk.

Socrates was smart. He was also executed for being irritating.

No, he was executed for "advocating for new gods and against the gods of the city" (that was the actual charge).

You know, much alike someone insulting Mongo, Rails or Node in certain communities... (or Java, CL etc in others).

Also for corrupting the youth.

Again, much like Mongo, Rails, and Node. :)

Do you think?

People need to understand that decisions should be made based on the team's current skill set. If your team is comprised of Java developers, time shouldn't be wasted on researching node.js; rather they should focus on how to leverage their Java knowledge with Scala. It frustrates me to hear people falling for the hype machine and falling hard when they could have easily avoided by asking themselves two questions: what's the path of least resistance to shipping our product out the door, and what's the opportunity costs relative to alternative paths?

Good point. I think a lot of people who build commercial software have rather limited choice in which tools they use. They can choose how to use those tools and what to advocate publicly. If the hype about something forces me to use deficient tools, I will be angry it and vocal about it, because I care.

Eh.

It's not limited in scope to someone else's work. I have done a decent review of a number historical computer science papers, I can confidently point to a number of things that have been pointlessly reinvented over the years at least once, if not 2-3 times.

It's like, why are people using these really bad technologies (node for instance)? There are are solid and advanced technologies that have done all these things, been tested, used, and developed over a long period of time, without the limitations of this newness and lack of features/testing/experience.

As a stupid example, a tracing simulator describing variable usage and coverage were commercially available for Fortran in the late 60s. I haven't heard of similar systems for C or C++ in my casual reading on C and C++. Perl has spent years working towards something that is starting to look a good deal like Lisp in Perl 6.

For node.js and golang and other asynchronous & message-based languages/platforms, see occam.

Why can't we look into the 70s and build new technologies instead of reinventing the same ones over and over again? That's why I get a bit miffed about new stuff that is the same as the old stuff, except Now For Modern Computers/The Web/Mobile/blah.

>>Perl has spent years working towards something that is starting to look a good deal like Lisp in Perl 6.

Good example of your point, this is one of the things frustrating me in life.

Most of the scripting languages have long been working on becoming larger subsets of Lisp. They still mostly haven't gotten close in e.g. efficient compilation.

But sure, it would be cool if the Perl 6 e.g. really implemented a good macro system without sexpr functionality. Something to look forward to.

I really don't understand how the Lisp people failed taking over the world. (Sigh, I should have helped instead of being sidetracked after univ. :-( Maybe I should start looking into Perl 6 development.)

if its your company's people choice, and thus that impacts you directly, you're actually doing life right.

Amen - I quickly learnt node.js to build http handler for the callback element of a tool I am building using authority labs - for what we need its the dogs nuts.