Re^10: Does Perl Have a Business Plan?

in reply to Re^9: Does Perl Have a Business Plan?
in thread Does Perl Have a Business Plan?

Sorry for answering with a certain lag, contrary to popular belief, I'm not just busy babbling around, but actually do something. ;-)

Machine generated source code is crap

For a certain definition of "crap" - yes. If your sole definition of "being crappy" is readability/maintainability, then you are right. In this limited context. If you extend this view by e.g. "performance", "development time", you get different - if not contrary results.

Normally, maintainability of computer generated code is waived, because it's ... COMPUTER GENERATED ... and should be easily generated again if required. E.g. after your input data have changed, or you improved/fixed your generator/converter.

What we could talk about would be if the effort writing a Perl5 to Perl6 converter would outweigh the effort writing the 100 to 500 useful CPAN modules from the start. Plus of course the unknown number of bits and pieces of Perl5 code out there people would like to be able to migrate with low cost (think ROI).

So I'll restate my opinion in more specific terms: machine generated source code intended for human consumption, understanding and maintenance ... is not yet within the capabilities of programming to make a descent fist of.

I never stated that maintainability, readability would be an a priori requirement or concern of such a code. My point was (besides making clear that this converter is feasible), that this converter would give Perl6 adopters in spe with the generated code at least a quick, low/no cost migration path. I mean hey, what if it would convert that legacy Perl5 library no one ever wanted to touch and it would work? Albeit being still unreadable/unmaintainable? I see no loss there only gain.

It isn't going to happen any time soon. It would (will?) be just another side project that will go nowhere and ultimately be a waste of resources that would be better served by assisting the Perl6 team getting a Perl6 compiler & VM working. Sorry, but that is my conclusion. (Note: What you and others do with your time is none of my business.)

Well, I'm not surprised. Because you start from the wrong assumptions, then make right deductions, you still end up with the wrong conclusions. Without thinking more on the transition cost and being fixated on the "base technology", you are basically the prototype of the "pack of the hopeless" who actually do have hope to pull (or push?) Perl6 one fine day to a state where it will be happily adopted. I hate to crush motivations (you can easily escape that by positioning my opinion as invalid), but under these circumstances and with this mindset, the Perl6 project will fail.

What's even worse, you see a resource clash where there is none. People writing such a converter (actually the only thing I'm not sure about is if it should be written in Perl6 or Perl5) are not necessarily the people working on the VM and the compiler.

Sorry, but yes. It *IS* technicians that drive the adoption of programming languages.

:-D Sorry but no, this is what technicians tend to think. Technicians are responsible for the first 1% of the bootstrap process of a new technology. Building up the bare foundations. Almost everything else is actually not driven(!) by these people. Only modified.

But, if GO is so good, why do they need Dart? And if Dart is so much better; how long will GO persist?

Ehm... Go is being used at Google in production systems, Go and Dart target different application areas. While Go tries to be Googles C, Dart tries to replace JavaScript for good. I am not that interested in Go, because that is a real self-purpose language for Google, but I suspect Google has the power to push JavaScript with Dart out of the way. And THAT is an undertaking one should learn from. Also, because this process will take some time, it leaves opportunities for others. (hint hint)

Actually there is not much to comment for the rest of your post, because you virtually paraphrase my statements. (Evolution vs. "Revolution"?) But somehow indicate you do not see reason for Perl6 development to act accordingly. That puzzles me, but let's leave it as is.

Regarding Perl6 development, I have great respect for the people doing it. Very bright minds, doing bleeding edge technology. However, from the viewpoint of "regular" software development, the Perl6 project shows all signs of a failing software project. One of the most important signs is the self-delusion acompanying the development. You hear clearly wrong statements regarding as WHY it was started at all, you see clearly wrong priorities and adoption assumptions/hopes.

I can admit, I didn't contribute more to Perl6 than just installing it and trying it out here and there. Giving it my time and evaluating it. Attending - more often than not - disturbing talks when it was presented in the past 8 or 9 years. I do have the audio of the original "State of the Onion" speech from Larry Wall when he announced it - including drums.

For me, 42years old, 16years Perl, managing a company of ~70, mainly Perldevs, loving Perl, thinking it deserves better than it has now, being INTJ, pedantic, paranoid and what not ... it simply hurts, because it has now been 12 long years. It may take another 12 years until someone (with definite authority on that matter) says: "project failed". All that time and effort spent in it could be wasted. Maybe not all, threaded Parrot could happily live as a Perl5.80 or Python7 foundation, but I do not want to elaborate on that until we don't have a threaded Parrot.

You know what I heard in a talk about Perl6 - held by a Perl6 protagonist - at the GPW2013? "The biggest killer feature of Perl6 ... (grammar) ... may be the unique sales point for that language - which eventually may not even be Perl6 by then."

Good luck.

Thank you, the same to you! Actually I think the Perl6 troppers will need more of it than me, so fingers crossed, four-leaf clover, pigs and what not.

propaganda.pm - Not just another Perl Mongers Group.

Comment on Re^10: Does Perl Have a Business Plan?

Replies are listed 'Best First'.
Re^11: Does Perl Have a Business Plan? by BrowserUk (Patriarch) on Apr 12, 2013 at 12:02 UTC
If your sole definition of "being crappy" is readability/maintainability, That was not my sole definition. What is the point in moving to a new version of a language, if the libraries you need to do anything productive are written in the old version and the new compiler runs them half as fast as the old one? What is the purpose of re-writing a language if it has to be bug compatible with the old one? What is gained by writing the new version -- adding all the new features and facilities; cleaning out all the old anomalies, disorthogonalities, historical detritus and cruft -- if the libraries required to make productive use of it, not only cannot take advantage of those f&fs, but also force you to add back support for everything that you were trying to get rid of? (Who would buy a Bugatti Veron if they were required to employ a man with a flag to walk in front?) I never stated that maintainability, readability would be an a priori requirement No. I did. Without maintainability of the generated code, the migrated code can never evolve. Everyone using it will be stuck in transition, requiring two sets of tools (+the translator); two sets of skills for tracking down bugs -- do they originate in the pre-translated code or are the introduced by the translator; or are they in the in the new compiler/VM. The idea is a nonsense. a quick, low/no cost migration path. There is no purpose in migrating if all you get from the exercise is what you have now without it. Is is cost for no benefit. A make-work exercise. Technicians are responsible for the first 1% of the bootstrap process That sounds an awful lot like you just agreed with me, and then dismissed it without reason. Without the first layer of bricks, the wall doesn't get built. But it goes (metaphorically) deeper than that. You need foundations. And it isn't business managers, or marketeers, or HR or money men that go out looking and downloading and appraising and providing feedback to new languages. It is technicians. If language development had been left to business managers, we'd either all still be using COBOL; or every IT business, finance house, government body and conglomerate would be using its own proprietary languages for commercial advantage and/or security reasoning. Technicians may need the sign off from business and money guys to adopt new languages for production -- and that is probably a good thing :) -- but they need a very clear and undeniable technical & business case before they will ever get that sign off. And the technical case must come first; and must be sufficiently technically compelling to gain their interest in the first place. Without it capturing the hearts and minds of the technicians first. new languages are still-born. (The rare exception are the military with things like Ada. But that is a one-off thank god.) Well, I'm not surprised. Because you start from the wrong assumptions, then make right deductions, you still end up with the wrong conclusions. Right back at yer. you see a resource clash where there is none. Not a clash, just a waste that could be redirected to better use. But it is your time and money and your decision. Once again. Good luck. 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.	[reply]

Replies are listed 'Best First'.

Re^11: Does Perl Have a Business Plan?
by BrowserUk (Patriarch) on Apr 12, 2013 at 12:02 UTC

If your sole definition of "being crappy" is readability/maintainability,

That was not my sole definition.

What is the point in moving to a new version of a language, if the libraries you need to do anything productive are written in the old version and the new compiler runs them half as fast as the old one?

What is the purpose of re-writing a language if it has to be bug compatible with the old one?

What is gained by writing the new version -- adding all the new features and facilities; cleaning out all the old anomalies, disorthogonalities, historical detritus and cruft -- if the libraries required to make productive use of it, not only cannot take advantage of those f&fs, but also force you to add back support for everything that you were trying to get rid of? (Who would buy a Bugatti Veron if they were required to employ a man with a flag to walk in front?)

I never stated that maintainability, readability would be an a priori requirement

No. I did. Without maintainability of the generated code, the migrated code can never evolve.

Everyone using it will be stuck in transition, requiring two sets of tools (+the translator); two sets of skills for tracking down bugs -- do they originate in the pre-translated code or are the introduced by the translator; or are they in the in the new compiler/VM. The idea is a nonsense.

a quick, low/no cost migration path.

There is no purpose in migrating if all you get from the exercise is what you have now without it.

Is is cost for no benefit. A make-work exercise.

Technicians are responsible for the first 1% of the bootstrap process

That sounds an awful lot like you just agreed with me, and then dismissed it without reason.

Without the first layer of bricks, the wall doesn't get built. But it goes (metaphorically) deeper than that. You need foundations.

And it isn't business managers, or marketeers, or HR or money men that go out looking and downloading and appraising and providing feedback to new languages. It is technicians. If language development had been left to business managers, we'd either all still be using COBOL; or every IT business, finance house, government body and conglomerate would be using its own proprietary languages for commercial advantage and/or security reasoning.

Technicians may need the sign off from business and money guys to adopt new languages for production -- and that is probably a good thing :) -- but they need a very clear and undeniable technical & business case before they will ever get that sign off.

And the technical case must come first; and must be sufficiently technically compelling to gain their interest in the first place. Without it capturing the hearts and minds of the technicians first. new languages are still-born.

(The rare exception are the military with things like Ada. But that is a one-off thank god.)

Well, I'm not surprised. Because you start from the wrong assumptions, then make right deductions, you still end up with the wrong conclusions.

Right back at yer.

you see a resource clash where there is none.

Not a clash, just a waste that could be redirected to better use. But it is your time and money and your decision.

Once again. Good luck.

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.

[reply]

In Section Meditations