On Thu, Mar 6, 2014 at 7:38 PM, Levi Pearson <levipear...@gmail.com> wrote:
> I think that by grouping "zealots" and "academics" together, you show > that you don't appreciate the connection between the reality of > programming and its foundations in academia. It's a really bizarre > phenomenon, and I see it much more in my programming-trained > colleagues than in my EE-trained colleagues. > > Academics was a generalization, but they tend to be the only other people with critical analyses of progamming languages other than "I HATE IT!" I actually consider myself an academic; I'm substantially more studied than most of my peers and have the stockpile of journals and articles to prove it. The problem that I've seen firsthand from multiple other academics is that they forget to balance what they learned with getting the job done. I know this will sound anecdotal, but I promise it's not the only experience like this. After 3 months on a relatively simple project, one of my academic peers produced a 300+ page document on his design for the architecture of the program. I was able to design, program and document the program in just 2 months. My program didn't have the level of abstraction or orthogonality that his might have, but it turns out that those things weren't needed because the program hasn't changed since. I'm not saying that academics can't be hard workers and do wonderful things. I do see their role in this world of technology that I love. I've just seen enough of them in the real world that I tend to generalize. Perhaps you've seen fewer of these people, or I just have a bad sample set. Being critical of PHP's syntax or approach to a standard library often isn't a substantial motivator to using a language in the real world. It's important in academia because it progresses our understanding of languages and computers. Their critical eye will produce better languages in the long run, but won't do much to win over people who need a language now that has been vetted and the tools are available to mitigate the risk factors associated with it. > I am not talking about "new and sparkly". The "new and sparkly" stuff > is often just rehashed "old and broken" stuff without a lot of real > benefit, and it pays to look deeply into things before adopting them. > Trendiness is no better than clinging to old, broken ways. But there > are plenty of old, good and proven ideas that we are completely > failing to take advantage of. And there are all sorts of old ideas > that were simply impractical before now. They mostly *aren't* new and > sparkly, which is why the trend-hoppers never quite seem to get them, > and continue flitting about on the whims of fancy. > > I'm surprised you didn't put in a plug for Haskell here. :) > What astounds me is that people say stuff like, "we know all the > risks, we don't make make mistakes and do stupid things like those > other people" and continue to use their old broken tools that they > know are put together by sub-standard engineering. Witness the > unceasing security flaws that are uncovered in critical packages on a > regular basis. Clearly, the remedies are not well-defined enough! Or > all these macho programmers are not actually following the disciplines > required to use thier unsafe tools safely. > You seem to have some language up your sleeve that none of us have? What all-mighty web framework are you using that is without flaw and has no security patches? This is common in all languages. This is common to all new-comers in the field. These mistakes can even be caused by the smartest of us. All the Erlang people are eating crow right now with the Whatsapp hack. To suggest that one language is inherently more secure seems a bit short-sighted. There will always be dumb programs or smart hacker or in very unfortunate circumstances both. > I hate to break it to you, but programming is *hard*, and human beings > are *really bad* at it. You are too, and so am I. We need all the > help we can get from good tools, because we suck at gettign all the > details right all the time. We get lazy or tired or just plain > unlucky, and errors skip past our notice. Now, I have no idea what > you do, or what sort of risk analysis you do at your job. Maybe it's > perfectly sound analysis, and your PHP code is always flawless (aside > from the flaws baked into the PHP interpreter itself, of course) and > you're really deriving some benefit from PHP that you wouldn't get > from some better tool. There are definitely reasons to use poor tools, > regrettable though it is. But there are no good reasons to call poor > tools anything other than poor tools, or to be apologetic about their > flaws. You don't have to like your tools to use them well; in fact, > you will probably use them better if you don't convince yourself you > like them. :P > > You say poor tool, I say tomato. That works better spoken than written. :) I think the tools are there for PHP and they are good ones. Where the language suffers, additional tools and frameworks have been made to compensate. The same can't be said for other more obscure languages and web technologies. Again, I don't really use PHP nowadays, but it's one of the few that major source code analyzers support besides Java and .Net. These do a great job of finding issues (especially junior level issues) that front-end penetration tests or black box tool can't. Since we are so bad at programming, it's nice to have tools that tell you where you were bad and PHP has those tools. I can't say that our PHP applications are 100% secure. I am confident though that they are at least as secure as the other applications I've written in languages that you would probably consider superior. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
