5 ms·
It saddens me that people advocating mainstream technologies describe "smart programmers" as unable to ship or make pragmatic choices. There is absolutely no ev
by valw 10y ago
It saddens me that people advocating mainstream technologies describe "smart programmers" as unable to ship or make pragmatic choices. There is absolutely no evidence of that. To me it just sounds like sore losers talking. I've never met anyone voicing that critic who had actually tried both approaches.
In my opinion, average-level programmers on critical projects with deadlines will quickly cripple your team's ability to deliver due to technical debt, and throwing 3x more of those easy-to-hire/fire men at it won't solve the issue.
I've chosen such an "esoteric" technology for my startup, because we had ambitious technical objectives, and it proved extremely beneficial - we would never have been able to deliver a system so robust so quickly with mainstream technologies (which I know because I've used those, so I'm in a position to make an informed comparison).
There are legitimate uses of both established and cutting-edge technologies, but from what I've seen the people who fiercely advocate mainstream technologies are more often reluctant to leave their comfort zone than making pragmatic, informed choices.
- taeric 10y agoIt is somewhat multifaceted. First, I have yet to see a wave of mainstream technology that lasted more than 2 seasons. Bonus points if it truly solved a problem that businesses have. (Note that this is distinct from solving programmer's problems.) Looking at my children in the corner playing pbskids, I am struck by how much more productive designers were with Flash and related technologies than they have yet to become with any of the current technologies. Second, I have yet to be involved with a major "mainstream" technology choice that did not crash and burn terribly. These choices have often ended in public disaster for companies. It has truly become amusing. Now, does this mean you can't make it work? Of course not. But, with the numbers as they are, realize that even at 1% or less... you actually aren't that unique in the world. But your experience still doesn't scale. (And I realize this last criticism can relate to me, as well. This is why I won't personally stone wall any choices. I do ask pointed questions about when we will get to focusing on customer's value. So long as we are answering that, I just don't care on the technology anymore.)
- ThePawnBreak 10y ago> First, I have yet to see a wave of mainstream technology that lasted more than 2 seasons. Is technology codename for web framework now? How about C, C++, Java, the JVM, Unix, OpenGL, Directx, Windows, .NET, Python? Aren't they also considered technologies?
- taeric 10y agoI'm torn. At face value, fair point. However, each of those has had a rocky road to success. At best. Oddly, the one that has had the most success is objective c and swift. And that is successful because it is the only game in that town. Despite people trying to make other technologies work. Compared with how many places failed by picking the new hotness. This definitely includes Java. It took a while before server side became a hit.
- dozzie 10y agoThis is precisely why it's such horrible word. How to compare C++, Unix, OpenGL, MS SQL Server, and TCP? Those all are thrown in the same bucket by calling them "technologies".
- ubernostrum 10y agoYou'll sometimes see Python people use not the word "smart", but the word "clever", with bad connotations. "Clever" programming, in this context, means valuing line/character count or showing off unusual algorithms or language tricks only the "clever" programmer knows, at the expense of clarity and maintainability. So, for example, the mundane way to square a number in Python would be: def square(n): return n**2 The "clever" way would be: from itertools import count, ifilter, islice s = lambda n: sum(islice(ifilter(lambda n: n % 2, count()), n)) The first one was clear, readable, easy to understand and maintain. The second one is tricky to read, requires some thought to work out what it's doing, and is written to show off knowledge of a slightly-obscure algorithm and the way to implement it in Python.
- noobermin 10y agoWhat you call "clever" seems more like "complicated".
- ubernostrum 10y agoYes, but there are people -- I've encountered them! -- who look on this as a way to show how "clever" they are, and consider it a good thing. It's like Perl golf take to an extreme. (admittedly, some of my co-workers and I have been known to golf our interview questions into ridiculous one-liners, but we do it for amusement value, not because we'd ever write production code that way)
- jordanb 10y agoIt's a reaction to the Perl community, which whom Python once competed. Perl programmers absolutely loved writing very clever "one liner" programs (look up Perl Golf). Python programmers therefore took pride in writing code that wasn't "clever."
- marxama 10y agoIt's an interesting problem. I always strive to write clear code, but clear and obvious code for me could be confusing, weird and "clever" to others. I joined a .NET shop two and a half years ago. At the time they were targeting the 2.0 runtime, so one of the first things I did was to include LinqBridge for all the Where, Select, etc IEnumerable extension methods. I'm used to functional programming so that kind of stuff is what I use all the time. Not everyone was familiar with it and got clearly confused, but they picked up quickly, saw the utility, and today everyone is onboard. So, I think there are two sides to it. Of course overengineering without considering understandability and maintainability should be avoided. But you shouldn't shun or even forbid language features because you don't understand them. I know of places where async/await are banned because the programmers cannot be bothered to learn how to use it. That's not what I think the programming profession should be about. C# regularly gets new language features, and I make sure to pick them up and use the ones I find useful. If someone thinks we shouldn't use some feature, I'm happy to have that discussion, and I will abide to what my team agrees to, but the reason better not be "because I don't understand this feature"!