Perl Popularity Lull
Perl Popularity LullThere's been a recent discussion on SlashDot (http://developers.slashdot.org/article.pl?sid=08/08/19/2335246) about PerlLanguage's fall from grace. It's now considered a "legacy" language by many corporations. While I am not a Perl fan, I wonder what this tells us about ANY current language. Perl's shortcomings are either fixable or a matter of personal preference. It's hardly COBOL.
[I think you underestimate how difficult it is to 'fix' shortcomings in any language while under pressure to maintain backwards compatibility. Be they technical or perceived doesn't much matter; it's difficult either way.]
If we let popularity contests dictate which languages come and go, then it just means we have to keep tossing out all our knowledge and built-up libraries every decade or so to starting over yet again. It's an ominous sign for other languages.
Ominous or not, it's been characteristic of the history of Computing since the beginning, nor is it necessarily a bad thing or we'd all be programming in Plankalkül and machine language. While it has allowed quite dire languages (some consider Perl to be one of them) to gain popularity or even precedence, it also ensures they'll eventually (mostly) fade away.
[Ah, it just means someone will need to come up with a language that can adapt to the fads of the decade while maintaining access to existing libraries. DotNet and Java (with its OtherLanguagesForTheJavaVm) and ExtensibleProgrammingLanguages are all potential approaches. But I've a feeling that periodically tossing out everything and starting from scratch is our current mechanism of dealing with TechnicalDebt that can't be paid within the current language or programming environment. For longevity, we'd probably also benefit from a programming environment that encourages (or at least supports) global-scale refactoring for OnceAndOnlyOnce (i.e. across a global set of projects). At the moment the pressure to maintain backwards compatibility harms even efforts to refactor library interfaces (which are essentially sub-languages). Something like a shared WikiIde with a powerful RefactoringBrowser may be appropriate for this goal, but we're pretty far from having either of those as of yet.]
Re: "need to come up with a language that can adapt to the fads" - We already have one: Lisp. But LispIsTooPowerful, which hinders its acceptance. Language ugliness enforces cultures and some consistency even if it's ugly consistency. Fads require something to rally around, and the oddities and ugliness become like ritualistic membership badges. Typing "self" over and over again makes one feel like they are "doing real OOP", and thus part of the in-crowd for example. (Oop does not necessarily require "self", it's just an artifact of a version of it that can become ritualistic and symbolic.) -t
People are finally starting to realize that Perl isn't a really maintainable language. What I mean by this is that the language does not help automate the process of writing maintainable code. I've seen Perl code that ranges from sheer beauty to horrid wickedness the likes of which would drive Cthulu insane. Considering that most programmers are highly lazy, guess which side of the fence most tend to write.
Meanwhile, other languages are becoming more popular because they help automate writing maintainable code. Some BondageAndDiscipline is a good thing, particularly as:
1. the number of engineers contributing to the project increases, and,
2. the scope of the project widens beyond the understanding of a few core engineers.
PythonLanguage offers this B&D in the form of significant whitespace and providing better core constructs to build reusable code. Java provides this in the form of a (mostly) unambiguous grammar (as evidenced by the monumental number of refactoring IDEs for Java, versus nearly nothing for C/C++) that, while verbose, is unquestionably supportive of automation. That is why these languages are more popular today than ever before.
In any engineering discipline, personal preference never enters into the picture. While there are some notational differences between an electronics schematic diagram from USA to EU, the notation is very definitely standardized sufficiently to allow anyone to read and understand anyone else's schematic. Ditto for mechanical blueprints. Ditto for chemical formulae.
Programming languages, as a system of notation first and foremost, should not succumb to allowing personal preferences in the notation itself. Doing so introduces ambiguity in the language which results in unmaintainable programs. This is precisely why macros are frowned upon in most professional engineering circles.
Changing a language (system of notation) to something better suited for your programming task should never obsolete legacy code, provided a common ApplicationBinaryInterface? is used. This is why ComponentObjectModel and CommonObjectRequestBrokerArchitecture have succeeded so well -- they provide a common ABI for components and libraries written in widely disparate languages. Yes, there is a subtle performance hit, but in practice it's not that big a deal. This is also one reason why C took off -- its ABI is stupid-simple to support.
So, who cares if Perl is considered legacy? Suck it up and move on. This doesn't mean you have to discard all your Perl code, but it does mean that you might need to use Perl's FFI if you want to talk to other components written in other languages. While it might complicate matters some, it is a solved problem, and it should not stop someone from moving forward with new projects in new languages.
While I agree that BondageAndDiscipline languages may help when you get large unmotivated teams, personal preference *does* matter if software engineering is mostly about psychology and suffers DisciplineEnvy. In most cases, good developer(s) will be more productive with a dynamic language than a BondageAndDiscipline language [Source?!] {countersource? you rude hypocrite [Asking me to provide a counter-source to your invented statistics about "most cases" is ShiftingTheBurdenOfProof, and marks you a fraud.]}. BondageAndDiscipline are what you need when stuck with PlugCompatibleInterchangeableEngineers conditions due to politics and motivation problems. While it does happen and may be beyond one's control, that does not mean that dynamic languages are inherently or globally "bad", just that they don't fit the current social-political environment of an organization. --top
It is, in fact, the artistic (note: I didn't call you folks unmotivated!) who prefer dynamic typing. You have the artsy programmers, and the engineer coders. I am an engineer. My notation requires precision and correctness throughout, the same as any mechanical or electrical engineer. I am designing code to solve a problem unrelated to programming as such, code which will be maintained by others long after I've left the project.
Can such things be done with dynamically typed languages too? Sure they can, via coding standards, mandatory code reviews, and attempts to formally verify a program via HoareTriples? (with or without unit tests), et. al. (After all, there are no enforced checks that states a resistor can only be drawn at 0 or 90 degree angles; that "limitation" is merely common convention!) But, that's a lot of human investment, and human investment is expensive and error-prone at all levels. I prefer automated type checking, because it gives me precision and a standard method of communicating broad invariants about the program, which often are all that's needed.
Let's now look at the nature of projects we see on the web today. Compared to the 90s, when Perl was in its heyday, the complexity of software being developed today is so great that no single developer can grasp everything. Project managers have only the vaguest idea of how their own projects actually work. Customers who use the products are only aware of, maybe, 20% of the feature set offered. Etc.
Thus, as the number of people who are required to complete a project goes up, the need for precise syntax, precise semantics, precision in notation goes up concomitantly, perhaps even geometrically. These things are precisely what statically-typed languages like Java and C# provide. That's why they're gaining in popularity. They offer all the "write once, run anywhere" convenience that Perl offers, while still affording developers precision of notation that you just can't get in Perl. Or Python for that matter (much as I love Python!). BTW, I predict Python will suffer a fate similar to Perl in the not-too-distant future, precisely for similar reasons.
Go back to simple systems, where two cowboy coders in PJs on Saturday evenings/early mornings can understand and install a web e-commerce solution doped up on Jolt Cola, and yeah, Perl could be argued superior. Those days are over. It's time to grow up and realize the importance of notation, its impact on programmer productivity, and even how it impacts the management of resources from a fiscal point of view. This has nothing to do with interchangable programmers; indeed, the specific choice of language is more to do with that. I'd go with Java if you're looking for plug-n-play coders, but would choose Haskell or OCaml if I were more interested in the best of the best.
Labeling dynamic programmers as "cowboys" is a superficial personal attack. Cowboy coders are those who use mass copy-and-paste. Well-written dynamic code is like good writing: choose words carefully and compactly that compliment each other so that you have a clean and flexible design. That is not coboy-ing, but crafting thoughtfully. --top
Please cut and paste the very words where I call dynamic language coders 'cowboys.' As of 2008 Aug 25, no such text appears in anything I have written. I did call them artistic, but not cowboy coders.
What I did say, however, was this:
Go back to simple systems, where two cowboy coders in PJs on Saturday evenings/early mornings can understand and install a web e-commerce solution doped up on Jolt Cola, and yeah, Perl could be argued superior.
Do you see the difference? I'm not calling anyone who actually uses a dynamic language a cowboy coder here. The subject of the sentence refers to PROJECT COMPLEXITY as it relates TO PERL (BY NAME!). The last I checked, Python isn't Perl any more than Smalltalk or Lisp are. I apologize for the bold-face and yelling, but it appears nothing short of that would get the point across.
As you've been caught attempting to deliberately goad me into an argument I never started, I now am obligated to, henceforth, delete anything you say on this page which doesn't directly contribute to the topic at hand. You've been caught, my friend.
Chewing me out instead of fixing your poor writing style. Typical: always deflecting off to somebody else. Without some measure of "complexity", this won't go far anyhow. Web apps can often split big projects up into lots of little ones that feed off the same data set. Whether it has 10 web pages or 1000, each little area can still be relatively independent, sharing libraries where appropriate.
I happen to work in such an environment, as you describe, now, with large federations of largely independent services spewed across several hundred servers, all talking to a single database backend. All of these services were first written in Perl, by the original software engineers who founded the company. Now, most are written in Java. Why?
Even today, we are finding we need to rewrite the remaining Perl scripts into Java for improved maintenance, exactly as I described, for precisely the reasons I described. My claims are backed by real-world experience on real-world projects at scale, with real-world software engineers who, frankly, all prefer to use other languages, myself included. Here's a viable definition of "complexity" for you: when it takes more than one engineer to fully understand the project under maintenance, it's complex. Thus, it stands to reason, that the greater the number of engineers necessary to maintain it, the more complex it is. This is something which is tangible and is measurable, and is remarkably accurate. The codebase I currently work on is fairly well written (it could stand some improvement of course), but yet still requires 20+ engineers to maintain it. For any desired user-story that someone needs to add code for, it typically involves the effort of 5 engineers, 4 of which are needed to just explain how the affected code works in sufficient detail to complete the task. Although we do practice the principle of NoCodeOwnership?, God help you if an engineer who last worked on some module hasn't looked at the code in more than one release cycle. Human memory is quite fallible! Worse, if said engineer no longer works there, you're right screwed then. That is complexity.
I can't stand Java. Why would I advocate Java over something else if I don't like it myself? But, I must remain objective. The reality is that Java's success in the world stems from a unique combination of features that few other languages have possessed, plus a sizable dash of luck. We are now finding that maintenance of our Perl scripts is taking more time than actually contributing new functionality to the codebase. Measurable evidence, based on project velocity, clearly demonstrates that Java development is now (it wasn't always) faster than Perl development (though, something tells me, you'll still find a way to ask WhatIsObjectivity?). Even I have often considered rewriting my Python codebase into Java on more than one occasion.
And, you did attempt the first deflection, while I stayed rather explicitly on topic throughout. Go ahead and blame me for poor writing style, if you wish. I've certainly made mistakes in my prose before. But, not this time. In this case, you've been called on attempting to alter the fundamental thesis of my argument, and attempting a one-sided, skewed debate thereof, twice. I simply called you on it the second time, is all.
How are us, the readers of your anecdotes, going to know if its just poorly written Perl, or there is an *inherent* maintenance defect to the language itself? Maybe you are just not smart/skilled enough to write good Perl. The possible gap in your head is not the fault of the Perl language. We can't rule it out gappy-headed-ness without details. I'd like to see actual representative Perl code samples that are not cleanable without switching languages. Again, I am not a Perl fan nor a Perl expert by any stretch, but I'm highly skeptical it contains inherent flaws of the type you speak of.
Look at the facts. Perl's popularity is waning. Complexity of services rendered to customers is going up. While I admit that correlation is not causation, I think the evidence stands on its own merits. I work in just one company, but the effect is being observed industry-wide. Any gaps in my head cannot account for that. I mean, you are essentially asking, "How can us, the readers of your anecdotes, really be sure that I'm typing on a real keyboard? We can't rule out that its existance is by virtue of the collective will of the Platonic society! Just because you don't believe in my keyboard's existance doesn't mean others do not!" The whole premise of your counter-argument just doesn't make any sense.
I cannot provide you samples of our Perl code here without breaching NDA, so your question is loaded. Nice try, though.
But it's difficult to separate changes due to fads and hype versus changes due to merit (or lack of). I'd guestimate about 50% of all software-related technology church is related to mere faddism. Further, Perl as a scene lacked a "culture of maintainability" out historical habit. That culture tainted its name dearly. If car brand X is a favorite of teens who abuse it by doing donuts in the desert, that may mean that used X cars are more likely to be beat up. However, it says almost nothing about the original manufacturing quality.
Point taken; but, historical evidence provides no other significant correlation that can be traced to draw such a conclusion as I have. We'll just have to wait and see, I guess. The problem is, of course, nobody will be able to determine the actual causes.
As far as NDA, you don't need to give actual code. Pick 3 common patterns of problems in the code, and then create dummy application portions for a similar but not identical field. If most of the problems are in "computer space" instead of an industry (domain), such as CRUD handling, then the domain won't matter much anyhow.
This strikes at the heart of the matter -- I cannot give such a dummy application, because such a dummy application, by necessity, is a dummy application -- a huge gloss-over of the inherent complexity of the problem we are attempting to solve. In order to properly convey the nature of the problem we're trying to solve, I have to break my NDA. I'm sorry, I'm not going to do that. These applications are in no way simple CRUD programs. CRUD modules can be written in anything with relative ease. The stuff I work with -- no way. This is core business logic stuff.
I didn't equate "crud" with "simple". Interfaces can potentially be quite involved. But I would say some of the more complex biz logic tends to be "pushed to" the DB in the better larger apps I've seen and/or worked with. About 80% of the computation is done via SQL and the other 20% via imperative code that makes extra adjustments. Anyhow, you are not offering any usable or dissectable information about why Perl doesn't allegedly scale. In essence, your anecdotes don't scale.
The last I checked, one could not perform a fourier transform of an audio stream, or a wavelet analysis of an image, using any kind of database I'm familiar with. I'll just leave it at that.
That's a solved and mostly isolated problem. Complexity that gums up production systems *generally* comes about from the multiplicity of interactions and interrelationships, not the volume of number chomping per se.
RE: "Maybe you are just not smart/skilled enough to write good Perl."
[I don't believe the ability to write 'good code' matters on the subject of maintainability as much as you seem to believe does. Good, maintainable code can probably be written in most GeneralPurposeProgrammingLanguages. Of greater relevance is how difficult or easy it is to write maintainable code, and the level of skill and wizardry and insight into the language required to do so.]
[On one extreme, a language can make even tossed-together last-minute one-off programs reasonably maintainable, portable, efficient, etc. BadCodeCanBeWrittenInAnyLanguage, of course, so you could still create obtuse, obfuscated, unmaintainable code if you tried... but your typical 'average' code unit would be reasonably maintainable, and you could expect that much from the hypothetical 'average' programmer. On the other extreme, with such things as many EsotericProgrammingLanguages, the language fights you every step of the way. To have maintainability, you'll either need to sacrifice other features (portability, performance, runtime modularity, etc.) or you'll be forced to juggle while dancing on a high wire just to keep all the features at the same time. In such languages an 'average' programmer, even one following YagNi and DoSimpleThings, will end up with WriteOnlyCode or everything ExtremelyInterstrangled into a BigBallOfMud because the LanguageInhibitsRefactoring, and attempting to come up with something more maintainable (without negatively impacting other features) will require a great deal of care and foresight.]
[PerlLanguage isn't quite so bad as SnuspLanguage, but it (and especially its TIMTOWTDI culture, its unusual use of context, and its obtuse regexps) do tend to result in the average programmer writing a great deal of fragile WriteOnlyCode that isn't comprehensible to maintainers (often even the person who wrote it in the first place). PerlLanguage doesn't make it impossible to write good, maintainable code, but it does unnecessarily make doing so more difficult than it could be.]
[While you can blame people's "gappy-headed-ness" for not being RealProgrammers who can easily juggle performance, portability, modularity, etc. while dancing on a high wire called 'maintainability', doing so improves neither the language nor its popularity nor the maintainability of its actual codebase. For certain, it wouldn't be a rational way of thinking for a LanguageDesigner looking to improve on a language.]
Without specific code to compare, this is merely more anecdotes, of which there is already a glut of on this topic.
[Nothing I stated here is an anecdote; it is all logic and reasonable inference.]
[As far as proof of the above principles, it is pretty trivial to prove that SnuspLanguage is more difficult to maintain than PerlLanguage for a plethora of cases; even a small change (e.g. adding a single operation) can require moving large amounts of code in two dimensions, and there is no support at all for function composition or decomposition. When it comes to existential statements, such as "some languages are harder to maintain than others", the trivial case is a total and complete logical proof of the statement.]
[Given that the some languages are harder to maintain than others, you cannot logically assume that any two languages have identical maintenance characteristics. I.e. your current behavior of assuming that Perl has identical maintenance characteristics to other languages until proven otherwise is the irrational, illogical behavior. The logical behavior is to assume nothing and reject any such assumption. If you were to observe more pairs of languages and features, you'd even come to the conclusion that the opposite is true: you should assume no two distinct languages have identical maintenance characteristics until evidence for the opposite is true. However, I'm not going to insist you accept that conclusion.]
[Anyhow, your insistence that code examples be provided doesn't seem very well considered to me. Your implied belief is: "having specific code to compare will help me make a better conclusion." But this isn't a logical belief unless you are also assuming (on faith?) that you'll somehow be able to see the emergent maintenance properties of the whole language just by observing a few small point-samples of code. Given the relative and probabilistic nature of 'ease of maintenance', such an approach would be highly subject to confirmation bias. What you 'see' can't be trusted. I trust myself and my language design experience more, and I wouldn't even trust myself to be able to 'see' the difference in just a few code examples.]
[Adding to the problem of code samples is the relative strength of hindsight and the lack of context, the former of which would tempt us into picking at the example and blaming the programmer for 'gappy-headed-ness' also known as 'lack of perfect foresight', and the latter of which would essentially be us failing to recognize all the forces influencing the programmer (time constraints, interfacing with other people's code, etc.). The issue of context, especially, is important; the 'maintainability' of code in a language depends heavily upon the code with which it interacts and the other desired emergent features and NonFunctionalRequirements, none of which are visible when looking at a code sample.]
"Emergent" properties are even more difficult to rely on because they are easy to be tainted by sums of bias and personal preference. This is one reason why economists have difficulty forecasting better than an observant garbage collector. Code analysis isn't perfect, but its much better than merely anecdotes. And it may answer "why" instead of just "what".
[You over-generalize. Some emergent properties are difficult to measure, and doubly so with only partial information. Others are not so difficult. Some of them I'm even sure you know well enough by maxim: a chain is only as strong as its weakest link, and armor is only as good as the biggest hole in its mesh. In any case, language analysis is a better approach to discovering properties about a language than is code analysis. Not only do you have access to the whole language definition, but it will answer "why" instead of just being a meaningless point of code in an infinite space.]
By the way, if you had to assign a percent of problems caused by lack of compiler-time-checking and caused by difficulty in reading/grokking code, what percent would you assign to the mix, based on your anecdotal observations?
--top
[I suppose you're really not grokking me. I told you before that "a personal observation about statistical tendencies not made with real numbers in controlled circumstances is just so much hand-wavy speculation". Not only is the scope of one person's anecdotes too limited to make conclusions, but such things as confirmation bias also tends to interfere. It's even worse when the anecdotes haven't been recorded in a journal. You may be happy with waving your hands and inventing statistics on a public, intellectual forum like WikiWiki, but I am not.]
[In any case, your question is nonsense. How do you, percentage-wise, compare two entirely different kinds of problems? Problems caused by lack of compiler-time-checking are of a kind generally known as 'bugs'. Problems caused by difficulty in reading/grokking code are more often of the kind known as 'I can't figure out how to fix the bug without rewriting the whole piece of code'. It isn't as though I could rationally attribute a bug that just happens to be found in ungrokkable code as being "caused by" the code not being readable.]
You seem more interested in arguing about who is the least rational instead of shedding light on "what's wrong with Perl". I don't want to argue about arguing, I want something more *specific* about "what's wrong with Perl", and I'm sure most readers do also (all one of them :-) If what you have presented so far is the sum of your evidence, we can call it a day and move on and let stand what's here.
[The information you want and the information that you can logically and rationally infer from the data are often two different things. If I tell you that a vehicle has been in a severe accident and is totaled, you can't tell me about the condition of its headlights. If I tell you a ship is sinking, you can't tell me whether it is doing so because it struck a glacier or a coral reef. If I tell you Michael Phelps is losing, you can't tell me it's because he's ill. Nonetheless, all of these can be observed - an inductive approach to information gathering that takes lots of small clues (light, shadow, tilt against horizon, texture, timing) to infer a reasonable and rational conclusion. The clues are not the problem. They are only symptoms of it. The reason I call you irrational is that you illogically argue that you must know the *specific* problem before you'll acknowledge there is one. Logic doesn't demand it. Why do you? Based on collective anecdotes I can say with a great deal of confidence that people find Perl to be relatively unmaintainable compared to competitor languages. Still reasonably, based on consistency among complaints, I can say that the reason for this maintenance problem likely has something to do with the dense regexps (which seem to be difficult for most humans to parse), unusual use of context, and maybe the heavy use of sigils. But an inability to be *specific* happens to be completely irrelevant to my argument. All that matters in the above discussion is that evidence shows Perl more difficult to maintain and that 'gappy-headedness' of individuals doesn't seem a likely cause (not given the vast array of intelligent people who have worked with Perl and still acknowledge the problem).]
One does not have to use things like reg-ex in most of their Perl code. Wouldn't it make sense to stop using the problematic features of Perl in existing code for new parts rather than starting over from scratch? Java has bad features or styles also. And why couldn't you give examples of "unusual context" and sigils causing problems?
[See ContextSensitivity for a discussion on unusual use of context. A common saying to those learning Perl is that "until you learn context, your life will be miserable". And if you want examples of overuse of sigils causing WriteOnlyCode, you need only look at APL or InterCal; see TheProblemWithSigils for discussion. In any case, it seems you are once again asking for examples immediately after I got through discussing why they aren't nearly as useful (for making good conclusions) as you seem to think they are. Obviously I am not getting through to you.]
You insist very very hard that I accept your anecdotes at face value. I am sorry, but I won't. If that makes me a bad person, then I am guilty and shall fry in anecdote-rejection hell. Anecdotes are evidence, but weak evidence.
[I insist very hard that you accept collective anecdotes (not my anecdotes) as being more than 'mere' anecdotes. You're sorry, but you won't. It seems you don't even comprehend the distinction. You'll probably be condemned to being an ignorant stick in the mud who is incapable of sensory synthesis. Anecdotes are individually weak evidence in the same sense that individual pieces of a jigsaw puzzle are weak evidence for the whole picture. The more you put together, the clearer and more obvious the picture becomes. Anecdotes collectively are very powerful evidence for whatever common substance they possess. Neither our eyes nor collective anecdotes are completely reliable - you can't immediately rule out conspiracy or illusion, though you can look for evidence of such things should you have reason to believe them likely - but they are both completely rational sources for building high-confidence information for making useful conclusions. Heck, we define "empirical" and "science" based on observations made ultimately through sensory synthesis. If you accept science at all, you cannot rationally reject the idea of synthesizing weak evidence into strong evidence.]
Your presentation your anecdotes is also weak. Beyond the anecdotes themselves, you offer very little *supporting* evidence around them. I only know what you type on the page, I cannot read your mind. If you don't communicate your experiences well, there is not much I can do.
[I suppose self-education and doing your own research never occurs to you. I expect you to come into any argument having already educated yourself on modern state of affairs; to do anything less is negligent of your duty to provide reasonable argument. I don't plan to present the anecdotes to you; they are readily available should you do a little research of your own.]
For one, it's not my job to provide evidence for YOUR claims. Second, I do talk to others, and their anecdotes often don't match yours.
[It is your job to know what you're talking about. This entire discussion you've been waving your hands and saying stuff like "maybe the other guys have counter-anecdotes" and "often other people's anecdotes don't match the ones you've read". You say this without actually looking. Look. Your 'hypothetical' evidence ain't worth crap, and your tendency to present it is proof of your negligent ignorance.]
When writing on this wiki, you need to *assume* there are multiple readers (even if we scared them off in practice). The readers want to see your evidence. All you have offered is militant anecdotes. That is all the reader sees here. What have you offered the reader beyond personal anecdotes?
[All you've done is wave your hands and said I've only offered anecdotes. Since you're not paying attention, I haven't actually offered any. I've told the people I think the evidence stands for itself... all they need to do is go look at the anecdotes (e.g. run a few google searches) and examine consistencies between them. I'm confident in this in the same way that I wouldn't present a massive amount of evidence to show the sky to be blue. The answers are out there; you don't need to look hard to find them. If you actually cared, you'd have already looked. Since you don't actually care, you're just trolling.]
You are hand-waving your "evidence" off to Google. Thanks for nothing. I do see a lot of complaints about the culture of Perl, but nothing concrete inherently wrong with the language. If you wish to claim that the culture problem alone is sufficient to discontinue Perl, I won't necessarily disagree.
[As usual you "see" what you choose to see. If you want to see a lot of complaints about the maintenance issues of Perl, go look. If not, then stop trolling. It isn't as though you actually understand what other people are saying anyway; I've certainly not said anything about discontinuing Perl. It has strengths to go with those weaknesses. In your favored sense, it matters how the customer 'weights' maintenance vs. rapid one-off string and shell operations.]
Your proof is on Google, and mine is on Alpha Centauri. If you reach A.C. and my evidence is not there, I will give you $5,000. (Offer expires on 1/1/2030.)
[I see some difference in accessibility, there. How's about you just give me the money to reach AlphaCentauri? and bring your proof back to us Earthlings. Can't promise I'll get it, though. ;-]
[I also insist that code examples are overrated. They're too easy to pick apart with our advanced hindsight and lack of context. When presented in a situation such as this one (regarding such relative issues as 'difficulty' to make 'more maintainable') they're likely to be either too contrived or too simplistic (since you can't fit a LargeApplication into a WikiWiki example). Your dependence on them isn't irrational so much as ill considered.]
Yes, they are overrated. But so are anecdotes. If I had to grade them evidence-wise, I'd give anecdotes a "D" and code examples a "C+". A's and B's would be nice, but none have come yet. --top
[Code samples are fine evidence of certain claims (in particular, existential claims... i.e. "it is possible to do XYZ in language L"). So, while you continue to invent grading systems along with your invented statistics, you should keep in mind that grading code examples across the board is stupid and that grading them in this situation without demonstrating or proving them useful is hand-wavy and baseless.]
Anecdotes are even hand-wavier and baseless-ier than code examples. I am tempted to use the "H" word.
[Individually, perhaps. Collectively, no. Make a distinction.]
You and yourself = collectively?
[The user stories I looked up and the people I interviewed = collectively. Damn if that doesn't prove you aren't listening.]
Indirection doesn't improve the value of anecdotes much. Evidence-wise, you are still the bottleneck. If you want a lesson on "proper" survey techniques...
[Indirection does not improve value. Quantity and independent opinions, however, is a different matter.]
[And evidence-wise, I'm telling you it's readily available for you to get your own. I'm not stopping you therefore I'm no bottleneck; you're free to make progress without waiting on me.]
RE: "Some BondageAndDiscipline is a good thing . . . In any engineering discipline, personal preference never enters into the picture."
[Your assumption that eliminating "personal preference" in notation and syntax somehow equates to or requires BondageAndDiscipline languages doesn't seem readily justifiable.]
External Links
See Also: DynamicLanguagesAndLargeApps
EditText of this page
(last edited November 10, 2009)
or FindPage with title or text search