|Pathologically Eclectic Rubbish Lister|
Re^9: Does Perl Have a Business Plan?by BrowserUk (Pope)
|on Apr 10, 2013 at 13:57 UTC||Need Help??|
As every (byte)compiler generates code, by your definition, ALL code on this planet is crap. Certain metrics applied, you are right. Can you imagine that in the 90ies, a very competent m68k Assembly/C guru told me about his observation, how the GCC already at that time, made surprisingly efficient machine code (using surprising register overflows) an assembly programmer probably wouldn't have thought of?
Chalk and cheese.
Yes. Modern compiler technology -- include JIT variants -- can produce some very efficient machine code. But a big part of why they can do so is because what they produce does not have to be read, understood or maintained by human beings. If you doubt this, spark up gcc or MSVC on a piece of moderately complex source code and enable /E /Ox /FAs (or the gcc equivalent) and try and relate the resultant optimised assembler back to the C sourcecode.
And if you find yourself thinking "That's not so bad!", then do the same thing with a piece of moderately complex C++ code.
The basic problem is that human beings can only juggle 4/7/8/? things in their short term memory at a time, but compilers can remember everything for as long as they need to.
Machine generated source code is crap
Having had to try and understand and maintain the output of three different sourcecode to sourcecode converters in my career -- albeit in the late 80's and the 90s -- I urge you to both canvass opinion of those with experience of them; and take a look around at the output of tools that generate source code. Take a look at the output from tools like FrontPage and Dreamweaver and even GUI click&paste IDEs like MSVC. The source code output is almost impossible to follow.
With all of those, maintenance *must* be done on the pre-translated input, not the output, otherwise changes are discarded, or the two diverge.
So, unless it is your intention that maintenance continue to be performed on the pre-converted perl5 code -- hopefully not; shipping Perl6 libraries in P5 and making every user redo the conversion is a complete non-starter -- then human beings are going to have to deal with the post-conversion Perl6 code. And that will inevitably be crap.
The very things that make computers so good at producing optimised machine code are what make them so bad at producing readable, understandable and maintainable source code. Take a look at some raw beginners Perl code -- there are good (bad) examples all over this site. Note the lack of structure; confusing ordering; bad naming of variables and functions; and the general lack of coherent flow of the code.
Now imagine computer generated variable names; functions/ & methods laid out according to some programmed ordering -- alphanumerically or worse -- rather than logically grouped according to human expectations; function bodies laid out with all the variables declared up front rather than in-line; statements ordered according to time-line requirements rather than human expectations of logical flow; long lines wrapped at arbitrary (numerically calculated) points rather than the structural requirements of the conditions or events they contain; multi-statement chunks of functionality ordered by how they come off a push-down queue, rather than logical flow as a human being might construct it.
What you end up with is working code that is not understandable or maintainable by human minds. And from experience I can tell you that is a disaster for both productivity and ongoing development for in-house-only projects. For widely disseminated libraries that will serve as examples to human beings trying to either evaluate or learn a new programming language it would be much worse!.
So I'll restate my opinion in more specific terms: machine generated source code intended for human consumption, understanding and maintenance -- as opposed to machine-read and executed, and never maintained machine code -- is not yet within the capabilities of programming to make a descent fist of. This is not due to any constraint that can be solved by throwing CPU cycles or clever algorithms at; because it comes back to our continuing inability to understand how the human brain works.
It is still impossible to categorise what lifts code from 'functionally complete' to 'intuitively good', much less great. Whilst we can teach new programmers to write the former; we have no way to teach them how to produce the latter. We (science) still have no handle on what forces and and processes allow the human brain to innovate. To make that leap from the step-by-step following of the recipe, to seeing the better, clearer, 'new' solution. And if we cannot categorise it; we cannot algorise it.
Computers can only do what they have been programmed to do; they cannot invent or innovate.
The bottom line is that your converter will produce perl5 idioms in Perl6 code. You may think it might be possible for the converter developers to program in boiler-plate Perl6 replacements for Perl5 idioms such that you will end up with half-descent Perl6 code; but it will not happen. At best, any such substitutions will only be possible at the individual statement level.
If you doubt this, consider the task of trying to convert the perl5 code snippets that implement (say) matrix multiplication -- as written by a dozen different Perl5 programmers -- to Perl6 using the hyper-operator syntax.
Try it out.
Ask the monks here, or your colleagues, to write a simple Perl5 function that takes references to two, 2D arrays and returns a reference to a third 2D array that is the product of the inputs. Then, when you get back their code, sit down and consider what would be involved in trying to program your converter to recognise all those disparate versions -- some using nested for loops; some map; some while; and the various combinations of those and more.
That is the level of task (and just one of many) that you would need to be able to solve in order for your converter/translator to be able to produce good Perl6 code. It is a task that is more complex than writing a Perl6 compiler from scratch and much harder than writing a VMI to run it on.
It isn't going to happen
Sorry, but that is my conclusion. (Note: What you and others do with your time is none of my business.)
The above was meant to be the end; but I simply cannot bring myself to let this go:
Aren't you aware how technic-centric your arguments are? How limited that view is? You really think it is the developer, the early adopter who is responsible for the adoption of a new technology? Oh man... Hint: Have a look how new programming languages like Go or Dart are being prepared for adoption. And LEARN for gods sake!
Sorry, but yes. It *IS* technicians that drive the adoption of programming languages.
Fanbois, Mommas&Pappas and Silver Surfers, have no interest in the languages in which the code that: feeds their TwitBook addictions; delivers their offspring's emails, baby/holiday snaps; or their on-demand TV programs; is written in. So marketeering to them is a bust.
And it isn't business management that drives the adoption of new languages. At least not until there is sufficient eveidence (in the business press and newsfeeds) that other managers and companies have already made the leap and run with if for long enough to make it a 'safe bet'. Managers resist risk -- and that means change -- at all costs -- until forced by weight of wider opinion, or their relative decline in revenue, market share or share price -- to accept the risk is manageable or impossible to avoid
Technicians drive early adoptions
It is technicians -- programmers -- that drive the early adoption of new programming languages -- often through stealth. Whilst in the later stages, programmers are drawn to new languages by weight of numbers -- what's hot right now -- in order for that to becomes relevant, you need to achieve that weight on numbers. And that means someone (and many someones) have to be first, and that is driven entirely by technical issues and innovations.
And yes. I have GO and Dart on my machine. I've played fairly extensively with the former, but it has fallen into disuse because it cannot do dynamically link modules (.dll/.so) and according to my conversation with one of the lead developers, it never will. Its a plan9 cultural thing.
I've only just started looking at Dart; and so far I fail to see anything there that leads me to believe that it is a major step forward over any of half a dozen existing languages. I'm still open to seeing where it will go, but I'm not rushing into making great efforts at this stage.
But, if GO is so good, why do they need Dart? And if Dart is so much better; how long will GO persist?
But, more worryingly, will either or both of them make it through next year's Google spring clean? Or the year after that? Belts are tightened, the competition is getting better, and the revenue growth from the Ompa Loompa's money machine -- on-line advertising -- is beginning to slow as competitors are beginning to catch up and purchasers are beginning to question their ROI. Google have been and continue to be ruthless in pruning their experimental projects; even those that have acquired a large, and often vociferous public following. (The latest casualty if there long running and widely used Reader service)
Basis for my conclusions.
So yes, I'm more than just aware of developments in new programming languages, I have been actively following along, acquiring, installing and testing them for the last 10 years or so. It is one of if not my main interest and I've been pursuing it vigorously expending a large percentage of my time on exactly that.
I've drawn three conclusions from my past 10+ years of investigating computer languages:
My point above is that whilst I am just one man looking from just one POV, my earlier response to you was not made up in the spot, but was the product of wide reading, extensive hands-on evaluation and a great deal of experienced thought over many years.
Whilst I make no claim for my conclusions being definitive, know that they are neither casually drawn, nor a simple regurgitation of those of others. I have no axe to grind nor anything to gain or lose from anything you do. Do not dismiss them, nor adopt them, lightly. Just factor them into your thinking -- or not -- when reaching your own.
s not so bad!h3
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.