Who will win the battle for control of the web?

Discussion in 'Perl Misc' started by ccc31807, Nov 29, 2010.

  1. ccc31807

    ccc31807 Guest

    Just finished reading 'Who will win the battle for control of the
    web?' It's a worthwhile read, and can be found at:
    www.pcpro.co.uk/features/363175/who-will-win-the-battle-for-control-of-the-web

    Executive summary: "A series of critical breakthroughs – massively
    increased bandwidth, the demand for rich media, cloud computing, the
    advent of wireless connectivity and the rise of mobile devices – has
    created the foundations for the next generation of rich internet-based
    apps." Five contenders: (1) Adobe, (2) Microsoft, (3) Apple, (4)
    Google, and (5) HTML5 will vie for the top spot, and each has both
    strong points and weak points, and at this point it's a real
    melee."The only safe prediction is that there will be plenty more
    twists, turns, alliances and battles to come before the war is finally
    decided."

    Reactions from the Perl community?

    My take is this: The core competency of the web is content, not eye-
    candy. Perl's strength lies in delivering content -- it's the
    Practical Extraction and Reporting Language after all. Perl excels in
    connecting data stores to web based interfaces and manipulating the
    data to produce information and for delivery to end users, but does
    not even compete with the eye-candy apps. I can see the use of Perl to
    dynamically spit out HTML, CSS, JavaScript, SVG, ?ML (including Flex),
    and occupying a strong position underneath the five contenders (with
    the probable exception of Silverlight, which can leverage .NET apps).
    I could even see Perl being used to generate eye-candy directly, like
    JavaFX, but without the sexiness of Flash, Android, iOS, etc.

    Does Perl have a stake in the battle for control of the web? If so,
    what is Perl's position?

    CC.
    ccc31807, Nov 29, 2010
    #1
    1. Advertising

  2. ccc31807

    ccc31807 Guest

    On Nov 29, 12:11 pm, Tad McClellan <> wrote:
    > HTML5 is not a company.
    >
    > What is it doing in this list?


    The article to which I referred evaluated five technologies with
    respect to delivering RIAs. HTML5 isn't a company, but might prove
    itself a competitor to Flash in the future. I didn't write the
    article, and I didn't pick the technologies -- I thought that it was a
    reasonably good read IF you are interested in the topic, and wondered
    how Perl fit into the picture, if at all. Is Perl totally irrelevant
    to this discussion?


    > > "The only safe prediction is that there will be plenty more
    > > twists, turns, alliances and battles to come before the war is finally
    > > decided."

    >
    > Why are there quotation marks around that?


    Because it's a direct quotation from the article.

    > Where are you quoting it from?


    www.pcpro.co.uk/features/363175/
    who-will-win-the-battle-for-control-of-the-web

    I'm not trying to pick a fight. I don't like Flash, Silverlight,
    Objective C, iOS, Android, JavaFX, or RIAs in general. I think the WWW
    is a great way to deliver information, and frequently write HTMLized
    interfaces to databases and functionalities. I got my start in IT with
    the web, two decades ago, and I'm just trying to figure out how what I
    do fits into the world that this article describes.

    Do you have anything to say about this? (This isn't intended to be
    disrespectful, I would be interested to know your thoughts, if you
    care to post them.)

    CC.
    ccc31807, Nov 29, 2010
    #2
    1. Advertising

  3. On 29 nov, 17:37, ccc31807 wrote:

    > [...]
    > Does Perl have a stake in the battle for control of the web? If so,
    > what is Perl's position?


    IMHO Perl has already lost that battle years ago. Perl is a USA thing
    by and for dinosaurs; it makes me think of George Bush.

    PHP is the server scripting language of the web, and has proven it for
    ten years now: international, global, community driven, fresh air,
    modern.

    --
    Bart
    Bart Van der Donck, Dec 6, 2010
    #3
  4. ccc31807

    Dave Saville Guest

    On Mon, 6 Dec 2010 09:25:00 UTC, Bart Van der Donck <>
    wrote:

    > On 29 nov, 17:37, ccc31807 wrote:
    >
    > > [...]
    > > Does Perl have a stake in the battle for control of the web? If so,
    > > what is Perl's position?

    >
    > IMHO Perl has already lost that battle years ago. Perl is a USA thing
    > by and for dinosaurs; it makes me think of George Bush.
    >
    > PHP is the server scripting language of the web, and has proven it for
    > ten years now: international, global, community driven, fresh air,
    > modern.



    --
    Regards
    Dave Saville
    Dave Saville, Dec 6, 2010
    #4
  5. ccc31807

    ccc31807 Guest

    On Dec 6, 4:25 am, Bart Van der Donck <> wrote:
    > IMHO Perl has already lost that battle years ago. Perl is a USA thing
    > by and for dinosaurs; it makes me think of George Bush.
    >
    > PHP is the server scripting language of the web, and has proven it for
    > ten years now: international, global, community driven, fresh air,
    > modern.


    Did you read the article?

    WRT Flash, Silverlight, and the others mentioned, PHP is in the same
    position as Perl, except PHP is much less capable than Perl.

    I raised the possibility of using Perl to generate RIAs, and got a
    quick answer from Sherm and Tad: even the thought is off topic for
    Perl.

    If you want to develop rich internet applications, you might as well
    forget Perl, which is just as well suited to developing RIAs as a cast
    iron frying pan ... or so they say. They are probably right, at least,
    they won't get an argument from me.

    CC.
    ccc31807, Dec 6, 2010
    #5
  6. On 2010-12-06 19:09, ccc31807 <> wrote:
    > On Dec 6, 4:25 am, Bart Van der Donck <> wrote:
    >> IMHO Perl has already lost that battle years ago. Perl is a USA thing
    >> by and for dinosaurs; it makes me think of George Bush.


    I have no idea why Perl should be a "USA thing". It seems to be alive
    and well in Europe, and from people who attend more conferences than me
    I hear that the community in East Asia is especially vibrant.

    >> PHP is the server scripting language of the web, and has proven it for
    >> ten years now: international, global, community driven, fresh air,
    >> modern.

    >
    > Did you read the article?
    >
    > WRT Flash, Silverlight, and the others mentioned, PHP is in the same
    > position as Perl, except PHP is much less capable than Perl.
    >
    > I raised the possibility of using Perl to generate RIAs, and got a
    > quick answer from Sherm and Tad: even the thought is off topic for
    > Perl.
    >
    > If you want to develop rich internet applications, you might as well
    > forget Perl, which is just as well suited to developing RIAs as a cast
    > iron frying pan ... or so they say. They are probably right, at least,
    > they won't get an argument from me.


    You are confused about the difference between server-side and
    client-side programming. For "rich internet applications" (make one
    cross on the bullshit bingo card) you typically need both.

    You need code which runs in the browser. That means that there needs to
    be an interpreter for that code in the browser, and that limits you to a
    handful of options: JavaScript, Flash, Java, ... unless you can convince
    your users that your site is worth installing yet another plugin.

    You also need code which runs on the server. Here you can use anything
    you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...

    Note that the overlap between client-side and server-side languages is
    small: Java is about the only language which was popular for both,
    but these days Java applets seem to be exceedingly rare (except for
    remote management stuff). JavaScript OTOH seems to be quite unpopular on
    the server despite a number of implementations. Flash on the server?
    Never heard about that.

    So for you almost always need two languages: One for the client-side
    (typically JavaScript), and one for the server. There is no reason why
    one should "forget Perl" on the server: It is just as well suited for
    that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
    its pros and cons, but I don't see anything in any of them which would
    make it unsuitable for the server side of an AJAX application.

    hp
    Peter J. Holzer, Dec 8, 2010
    #6
  7. ccc31807

    ccc31807 Guest

    On Dec 8, 7:47 am, "Peter J. Holzer" <> wrote:
    > You are confused about the difference between server-side and
    > client-side programming. For "rich internet applications" (make one
    > cross on the bullshit bingo card) you typically need both.


    No, not confused about server/client side. From the article: "Each of
    the big three computing companies – Microsoft, Apple and Google – has
    its own radically different vision to promote, as does the world’s
    biggest creative software company, Adobe." Yes, Flash and JavaScript
    is interpreted in the browser, as is Java, and .NET relies on the MS
    runtime, but that isn't the end of the story. You can write Flex using
    notepad, run it through the Flex compiler, and produce Flex files. You
    can also produce XML files that will run in a browser, not only XHTML
    but things like SVG.

    Maybe I'm confused about RIAs. Roughly, I see RIAs as something like
    an interactive TV, e.g., the iPhone apps. My question was what role,
    if any, Perl can play in creating RIAs. I don't have in mind a Perl
    module to spit out Flash movies, but leveraging Perl's strengths in
    the RIA arena.

    > You need code which runs in the browser. That means that there needs to
    > be an interpreter for that code in the browser, and that limits you to a
    > handful of options: JavaScript, Flash, Java, ... unless you can convince
    > your users that your site is worth installing yet another plugin.


    Which you can't outside of a particular need. (Yesterday I installed
    Scorch, the Sibelius music reader, to read some files, but I was
    highly motivated to do that.)

    > You also need code which runs on the server. Here you can use anything
    > you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...


    > Note that the overlap between client-side and server-side languages is
    > small: Java is about the only language which was popular for both,
    > but these days Java applets seem to be exceedingly rare (except for
    > remote management stuff). JavaScript OTOH seems to be quite unpopular on
    > the server despite a number of implementations. Flash on the server?
    > Never heard about that.


    Server side Perl emits files, which can be HTML files, PDF files, GIF
    and JPEG files, ASCII text files, and so on. Can Perl generate a file
    that will produce a rich internet experience for the user, i.e., in a
    browser?

    > So for you almost always need two languages: One for the client-side
    > (typically JavaScript), and one for the server. There is no reason why
    > one should "forget Perl" on the server: It is just as well suited for
    > that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
    > its pros and cons, but I don't see anything in any of them which would
    > make it unsuitable for the server side of an AJAX application.


    I just mentioned two, Flex and SVG. And yes, you can use Perl to emit
    JavaScript to enable dynamic functionality for the end user, whether
    you call it AJAX or just plain old JavaScript.

    Seems to me that, in this brave new world of internet enabled devices
    everywhere, that Perl needs to evolve or else become a niche language,
    rather than the 'glue of the internet.'

    It also seems to me that the Perl community is oblivious to these new
    developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
    surprise me to see a new PM that will produce something like this, but
    I think it will come from a new generation.

    CC.
    ccc31807, Dec 8, 2010
    #7
  8. [I note that we may have use a different definition for RIAs. For me
    these include AJAX-based web-application, indeed I was thinking mostly
    of them. But Wikipedia distinguishes between RIAs, which require the
    user to install extra software (plugins, runtime environments, etc.) on
    their PC and AJAX which uses only browser-builtin facilities. In recent
    years there is little which can't be done with Ajax, and I think Ajax
    will take an ever-larger piece of the cake and Flash and co will lose
    ground]

    On 2010-12-08 16:38, ccc31807 <> wrote:
    > On Dec 8, 7:47 am, "Peter J. Holzer" <> wrote:
    >> You also need code which runs on the server. Here you can use anything
    >> you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...

    >
    >> Note that the overlap between client-side and server-side languages is
    >> small: Java is about the only language which was popular for both,
    >> but these days Java applets seem to be exceedingly rare (except for
    >> remote management stuff). JavaScript OTOH seems to be quite unpopular on
    >> the server despite a number of implementations. Flash on the server?
    >> Never heard about that.

    >
    > Server side Perl emits files,


    No, it emits HTTP responses. A "file" is something on a disk (or similar
    storage device), an HTTP response is a message in a communication
    protocol.

    > which can be HTML files, PDF files, GIF and JPEG files, ASCII text
    > files, and so on. Can Perl generate a file that will produce a rich
    > internet experience for the user, i.e., in a browser?


    Same as any other language. You get an HTTP request, you process it, you
    send an HTTP response. All of this is completely independent of the
    language, except that you may find libraries and frameworks which are
    more or less suited to the task at hand.

    I don't understand what you mean by "a file that will produce a rich
    internet experience". You can of course create any file from Perl. But
    for some it would be foolish: If you want a .class-file, you use an
    existing Java compiler, you don't write a new Java compiler from scratch
    in Perl (But you might write a Perl compiler which emits Java byte code
    in Perl). If by "a file that will produce a rich internet experience"
    you mean a single file which contains the application and can be put on
    a server and downloaded by the browser, then that consists mostly of
    code (which has to be written), auxiliary data like icons, animations,
    sounds, text, (which has to be produced) and a bit of packaging around
    that. There's is not much room for a server-side programming language in
    producing such a file: When the programmer is finished, its static
    (although the programmer may of course use scripts to automate the
    creation of some of its parts). The server side programming language
    only comes into play, once the browser downloads the file and starts
    executing it: Then the application will "phone home" and request data
    which may be delivered by a piece of Perl talking to a database, for
    example.


    >> So for you almost always need two languages: One for the client-side
    >> (typically JavaScript), and one for the server. There is no reason why
    >> one should "forget Perl" on the server: It is just as well suited for
    >> that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
    >> its pros and cons, but I don't see anything in any of them which would
    >> make it unsuitable for the server side of an AJAX application.

    >
    > I just mentioned two, Flex and SVG.


    SVG is just a vector graphics format. You can of course produce SVG from
    Perl, there are modules for that (or you could just hand-code it). It
    isn't a programming language - for dynamic stuff in the browser it is
    usually combined with JavaScript.

    Flex is, AFAICS, mostly a development framework for Flash. It is
    possible that the applications generated by that framework can only talk
    to server-components sold by Adobe (like LiveCycle Data Services). Then
    you're locked into your cozy little Adobe world and can only use what
    Adobe provides. But if does talk standard protocols, then again it
    doesn't matter whether the server side is written in Java, Perl, PHP or
    Erlang.


    > Seems to me that, in this brave new world of internet enabled devices
    > everywhere, that Perl needs to evolve or else become a niche language,
    > rather than the 'glue of the internet.'
    >
    > It also seems to me that the Perl community is oblivious to these new
    > developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
    > surprise me to see a new PM that will produce something like this, but
    > I think it will come from a new generation.


    Again, you haven't provided the slightest reason why you think so.

    hp
    Peter J. Holzer, Dec 8, 2010
    #8
  9. ccc31807

    Keith Keller Guest

    On 2010-12-08, ccc31807 <> wrote:
    >
    > Seems to me that, in this brave new world of internet enabled devices
    > everywhere, that Perl needs to evolve or else become a niche language,
    > rather than the 'glue of the internet.'


    I'd think that the ''glue of the internet'' would be used in many more
    places than just serving HTTP requests.

    --keith


    --
    -francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information
    Keith Keller, Dec 8, 2010
    #9
  10. ccc31807

    ccc31807 Guest

    On Dec 8, 1:41 pm, "Peter J. Holzer" <> wrote:
    > > Server side Perl emits files,

    >
    > No, it emits HTTP responses. A "file" is something on a disk (or similar
    > storage device), an HTTP response is a message in a communication
    > protocol.


    My bad, I spoke informally and take your point. Maybe I should have
    said 'stream' which when written to a filehandle becomes a file, and
    when written as a response to an HTTP request gets sent out to the
    requester.

    > I don't understand what you mean by "a file that will produce a rich
    > internet experience". You can of course create any file from Perl.  But
    > for some it would be foolish: If you want a .class-file, you use an
    > existing Java compiler, you don't write a new Java compiler from scratch
    > in Perl (But you might write a Perl compiler which emits Java byte code
    > in Perl). If by "a file that will produce a rich internet experience"
    > you mean a single file which contains the application and can be put on
    > a server and downloaded by the browser, then that consists mostly of
    > code (which has to be written), auxiliary data like icons, animations,
    > sounds, text, (which has to be produced) and a bit of packaging around
    > that. There's is not much room for a server-side programming language in
    > producing such a file: When the programmer is finished, its static
    > (although the programmer may of course use scripts to automate the
    > creation of some of its parts). The server side programming language
    > only comes into play, once the browser downloads the file and starts
    > executing it: Then the application will "phone home" and request data
    > which may be delivered by a piece of Perl talking to a database, for
    > example.


    Yes. You will have to read the article -- I was responding to it, and
    my context was that of the article. Quoting therefrom: "A series of
    critical breakthroughs – massively increased bandwidth, the demand for
    rich media, cloud computing, the advent of wireless connectivity and
    the rise of mobile devices – has created the foundations for the next
    generation of rich internet-based apps." Notice the words NEXT
    GENERATION.

    The technologies considered are very different:
    *Flash - "Today, more than 75% of web video is delivered via Flash and
    more than 99% of internet-connected desktop computers can view Flash
    content, according to Adobe."
    *Silverlight - "Crucially, Microsoft has also created a lightweight
    subset of the full WPF specification called Silverlight and a cross-
    platform, cross-browser Silverlight player that developers can target
    primarily using C# or Visual Basic."
    *Apple - Targets internet enabled devices, like phones and tablets, on
    top of iOS, and really constitutes a category apart from our usual
    concept of Wintels running browsers.
    *Google - "But the strongest performer of all in terms of rising
    market share – with a staggering 886% year-on-year growth in Q2 2010 –
    and the new US smartphone market leader with 34%, is Google Android."
    *HTML5 - ... and all the rest of the open universe, including CSS and
    JavaScript.

    Obviously, these are very different technologies, using a variety of
    tools: proprietary frameworks, C#, VB, Objective C, iOS and Android,
    targeting different types of devices: computers, phones, pads, and who
    knows what else. Not to mention that a number of these rely on Java
    and even C and C++.

    > > Seems to me that, in this brave new world of internet enabled devices
    > > everywhere, that Perl needs to evolve or else become a niche language,
    > > rather than the 'glue of the internet.'

    >
    > > It also seems to me that the Perl community is oblivious to these new
    > > developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
    > > surprise me to see a new PM that will produce something like this, but
    > > I think it will come from a new generation.

    >
    > Again, you haven't provided the slightest reason why you think so.


    What's missing in the discussion? A decade ago, I was writing dynamic
    web pages tied to databases using Perl and CGI, basically rolling my
    own, building my own 'framework.' Today, I'm still doing the same
    thing, in another context, building graphical front ends to databases
    that run on users' browsers. A good friend of mine, working for a
    large employer, writes web apps using Flex (and swears by it) that I
    can't touch with Perl, unless I hand roll my own with AJAX type stuff.

    What's missing from this discussion is the role of Perl, and according
    to Tad, has so little to do with Perl that the entire discussion is OT
    in c.l.p.m. I don't suggest that anything written in Perl can rival
    Flash, or iOS, or Android, or the like. I also don't suggest that Perl
    has a place on the client (remember client side PerlScript?).

    You can produce a lot of good stuff using MySQL, R, and Perl, and I
    don't think this stack can be beat for statistical operations. What I
    am thinking is some sort of stack involving a database, Perl, and some
    other technology, might be able to compete head to head with some (if
    not all) of the technologies considered in the article.

    Quite frankly, I'm surprised that no one is talking about it.

    CC.
    ccc31807, Dec 8, 2010
    #10
  11. On 2010-12-08 21:41, ccc31807 <> wrote:
    > On Dec 8, 1:41 pm, "Peter J. Holzer" <> wrote:
    >> >

    >>

    [...]
    >
    > Yes. You will have to read the article -- I was responding to it, and
    > my context was that of the article.


    That article is exclusively about the client side. It doesn't talk about
    the server side at all. So it is almost completely irrelevant for perl,
    except that some proprietary technologies (Flash, Silverlight) may be
    more comfortable talking to a server side from the same vendor. However,
    the article is very clear that HTML5 is to be considered one of the
    major platforms, probably even the most important one:

    | There’s a surprising degree of agreement between all the experts we
    | spoke to that the best option for delivering a project is HTML5,
    | wherever possible.
    [...]
    | However, with enthusiastic browser support from Apple, Google, Adobe and
    | Microsoft, it looks safe to say that the HTML-based web will remain the
    | dominant internet platform, and that HTML5 will take it into new
    | territory.

    And Perl (on the server side) plays nicely with HTML5 (on the client
    side), so the answer for Perl programmers is to learn JavaScript (if
    they don't know it already) and write hybrid Perl/JavaScript
    applications. Probably nothing new for most web programmers, since - as
    I pointed out earlier - there were always different languages on the
    client and server side.


    >> > Seems to me that, in this brave new world of internet enabled devices
    >> > everywhere, that Perl needs to evolve or else become a niche language,
    >> > rather than the 'glue of the internet.'

    >>
    >> > It also seems to me that the Perl community is oblivious to these new
    >> > developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
    >> > surprise me to see a new PM that will produce something like this, but
    >> > I think it will come from a new generation.

    >>
    >> Again, you haven't provided the slightest reason why you think so.

    >
    > What's missing in the discussion?


    A sense of how things fit together. You are throwing operating systems,
    programming languages, SDKs, content formats, client- and server-side,
    etc. all together, and the result is just a big mess with strange
    conclusions.

    > A decade ago, I was writing dynamic
    > web pages tied to databases using Perl and CGI, basically rolling my
    > own, building my own 'framework.' Today, I'm still doing the same
    > thing, in another context, building graphical front ends to databases
    > that run on users' browsers. A good friend of mine, working for a
    > large employer, writes web apps using Flex (and swears by it) that I
    > can't touch with Perl, unless I hand roll my own with AJAX type stuff.


    Well, why don't you? Or use one of the gazillions of existing Ajax
    frameworks? If you refuse to do any client-side programming you can't
    complain that your apps don't look as nifty as those by people who do
    client-side programming (and with a tool which is specifically intended
    to produce eye-candy to boot).


    > What's missing from this discussion is the role of Perl, and according
    > to Tad, has so little to do with Perl that the entire discussion is OT
    > in c.l.p.m. I don't suggest that anything written in Perl can rival
    > Flash, or iOS, or Android, or the like.


    Nobody would write a browser plugin or an operating system in Perl. Perl
    isn't a systems programming language. Although I think Flash would hang
    my browser less frequently if it was written in Perl :).

    > I also don't suggest that Perl has a place on the client (remember
    > client side PerlScript?).


    All the stuff the article is about is on the client. If Perl doesn't
    have a place on the client (I agree with that) then there simply isn't
    any competition between Perl and these technologies.

    Perl has a role on the server. And by server I also mean cloud
    computing. Perl has had frameworks for distributing tasks across the
    network for a long time, maybe with cloud computing these will see more
    use.


    > You can produce a lot of good stuff using MySQL, R, and Perl, and I
    > don't think this stack can be beat for statistical operations. What I
    > am thinking is some sort of stack involving a database, Perl, and some
    > other technology, might be able to compete head to head with some (if
    > not all) of the technologies considered in the article.


    Doesn't make sense since none of the technologies considered in the
    article include a server or database part.

    What you would do is combine one of the technologies considered in the
    article (HTML5, most likely) with Perl and a database and build an
    application framework. Actually, I think quite a few people have already
    done that - at least always hear the web programmers I know (those that
    use Perl) about using Catalyst together with this or that Ajax
    framework.


    > Quite frankly, I'm surprised that no one is talking about it.


    Go to a Perl workshop and you will hear people talking about it.

    I think there are just too few web developers in this group. But then
    this group is about Perl, not about web development, and the questions
    relevant to web development are mostly not Perl-specific, so they
    wouldn't be on-topic here, anyway.


    hp
    Peter J. Holzer, Dec 9, 2010
    #11
  12. ccc31807

    ccc31807 Guest

    I agree with almost everything you say. I think the POV of the article
    was not server side vs. client side, or open vs proprietary, or
    applications vs operating systems, or traditional computers vs
    internet appliances. I think the POV of the article was providing
    users (what has been called) a 'rich internet experience.' Whatever
    that means, and I agree with you that it's more of a concept than a
    clearly defined term.

    On Dec 9, 2:22 pm, "Peter J. Holzer" <> wrote:
    > That article is exclusively about the client side.


    In a sense, but it also considers iOS and Andriod, which are operating
    systems, and the .NET platform, which allows development of
    applications in the traditional manner. It also doesn't mention Java,
    or the Adobe AIR, which I thought a little curious.

    > And Perl (on the server side) plays nicely with HTML5 (on the client
    > side), so the answer for Perl programmers is to learn JavaScript (if
    > they don't know it already) and write hybrid Perl/JavaScript
    > applications.


    Where does this leave Perl for the iPhone, iPad, etc.? I read another
    article in the last couple of days that speculated that the era of the
    'personal computer' was over. I think that rather than consolidating,
    the technologies are fragmenting. After all, we still have mainframes,
    and people still write COBOL, along with Objective-C, and all the
    Android apps. I'm not taking a position, and I certainly don't know
    the answer ... I'm really just musing (to call it thinking out loud
    would be too much.)

    > Nobody would write a browser plugin or an operating system in Perl. Perl
    > isn't a systems programming language. Although I think Flash would hang
    > my browser less frequently if it was written in Perl :).


    Perl brings things to the table that other languages lack.
    Specifically, I think Flash is over used and over abused. People who
    know Flash think in can do anything and everything, and I know some
    owners/stakeholders who insist on using Flash for everything.
    Considering all the different kinds of jobs, I believe that Perl has a
    lot more capability than Flash, but Flash gets a lot more press.

    > All the stuff the article is about is on the client. If Perl doesn't
    > have a place on the client (I agree with that) then there simply isn't
    > any competition between Perl and these technologies.


    Perl doesn't have a place on the client, but the work product of Perl
    surely does. For example, I have produced work using a combination of
    Perl and R which should be the envy of every Flash/.NET developer. If
    you need to dynamically analyze a mass of data and produce a PDF plot
    or graph, I honestly don't think you can beat Perl. The point is that
    the PRODUCT of Perl has a place on the client, not Perl itself (which
    agrees with your point.)

    > Doesn't make sense since none of the technologies considered in the
    > article include a server or database part.


    Part of the Rich Internet Applications consist content, think Amazon,
    eBay, Facebook, even Target, WalMart, and L.L.Bean. You are right,
    except all the eye candy without content is meaningless.

    > What you would do is combine one of the technologies considered in the
    > article (HTML5, most likely) with Perl and a database and build an
    > application framework. Actually, I think quite a few people have already
    > done that - at least always hear the web programmers I know (those that
    > use Perl) about using Catalyst together with this or that Ajax
    > framework.


    I hope that the number of those belligerents fighting the battle for
    the control of the web will expand. I would hate to see a monoculture
    of technology in this area. I also think that the capabilities of Perl
    can be used to advantage.

    Thanks for the discussion, CC.
    ccc31807, Dec 9, 2010
    #12
  13. ccc31807 wrote:

    > Quite frankly, I'm surprised that no one is talking about it.


    If you want lots of pointless and confused bloviation, maybe Perl isn't
    for you.

    Xho
    Xho Jingleheimerschmidt, Dec 10, 2010
    #13
  14. ccc31807

    David Canzi Guest

    In article <>,
    ccc31807 <> wrote:
    >On Dec 8, 7:47 am, "Peter J. Holzer" <> wrote:
    >> So for you almost always need two languages: One for the client-side
    >> (typically JavaScript), and one for the server. There is no reason why
    >> one should "forget Perl" on the server: It is just as well suited for
    >> that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
    >> its pros and cons, but I don't see anything in any of them which would
    >> make it unsuitable for the server side of an AJAX application.

    >
    >I just mentioned two, Flex and SVG. And yes, you can use Perl to emit
    >JavaScript to enable dynamic functionality for the end user, whether
    >you call it AJAX or just plain old JavaScript.
    >
    >Seems to me that, in this brave new world of internet enabled devices
    >everywhere, that Perl needs to evolve or else become a niche language,
    >rather than the 'glue of the internet.'


    Everywhere except the web browser is not a niche.

    --
    David Canzi | Life is too short to point out every mistake. |
    David Canzi, Dec 10, 2010
    #14
  15. On 2010-12-09 21:40, ccc31807 <> wrote:
    > I agree with almost everything you say. I think the POV of the article
    > was not server side vs. client side, or open vs proprietary, or
    > applications vs operating systems, or traditional computers vs
    > internet appliances. I think the POV of the article was providing
    > users (what has been called) a 'rich internet experience.'


    Users see only the client. For them the browser is the internet.


    > On Dec 9, 2:22 pm, "Peter J. Holzer" <> wrote:
    >> That article is exclusively about the client side.

    >
    > In a sense, but it also considers iOS and Andriod, which are operating
    > systems,


    They are operating systems for a specific class of client devices. You
    may or may not be able to run Perl on them (probably not on iOS, which
    is very much a "walled garden"; possibly on Android, which is much more
    open, although porting perl to Android might be a challenge; I do have
    perl on my phone, BTW, but I admit that I don't quite know what to do
    with it).

    > and the .NET platform, which allows development of
    > applications in the traditional manner.


    Yes, but the focus was on Silverlight. Reusability of components of and
    for "native" Windows applications was mentioned as an additional bonus
    (an important one, though - the Windows software market is huge).

    I do expect HTML5/JavaScript to break into the "native application"
    market.

    > It also doesn't mention Java, or the Adobe AIR, which I thought a
    > little curious.


    I'm not much surprised about Java. After the hype of the 1990s, Java
    applets have mostly vanished. There are a few niches where it is still
    very common (e.g. configuration and remote management interfaces), but
    apart from that it is mostly server-side now.

    Adobe AIR "enables ... to build web applications that run as standalone
    client applications without the constraints of a browser". As such it
    probably wasn't on the topic of the article which concentrated on web
    clients (with the somewhat curious exception of iOS/Android apps, but
    those share some characteristics of web apps, especially the easy
    access).


    >> And Perl (on the server side) plays nicely with HTML5 (on the client
    >> side), so the answer for Perl programmers is to learn JavaScript (if
    >> they don't know it already) and write hybrid Perl/JavaScript
    >> applications.

    >
    > Where does this leave Perl for the iPhone, iPad, etc.?


    In the cloud. You run your Perl programs in the cloud (well, for most
    services a single server will be enough, but it might even be cheaper to
    rent 0.02 CPUs) and provide a web interface or an App as the UI.

    > I read another article in the last couple of days that speculated that
    > the era of the 'personal computer' was over. I think that rather than
    > consolidating, the technologies are fragmenting. After all, we still
    > have mainframes, and people still write COBOL, along with Objective-C,
    > and all the Android apps.


    Yes. And that's one reason why I'm not particularly worried about the
    future of Perl. It won't ever be the one language that binds them all
    (it never was, all the talk about the "glue of the internet"
    notwithstanding), but neither will it vanish. The very fragmentation and
    heterogeneity of the landscape will provide places where it is the best
    solution. And if you are only talking to the rest of your environment
    via TCP anyway, the language has little impact on compatibility (I'm
    writing my part of a major application in Perl, my colleague is writing
    his in Java. Somebody else is writing a component in C# ...)


    >> Nobody would write a browser plugin or an operating system in Perl. Perl
    >> isn't a systems programming language. Although I think Flash would hang
    >> my browser less frequently if it was written in Perl :).

    >
    > Perl brings things to the table that other languages lack.


    True. And other languages have features which Perl lacks. It depends on
    the problem (and the programmer) which language is best suited for the
    task. Perl is well suited for an awfully wide range and I admit I've
    become lazy and implemented almost everything in Perl in recent years.


    > Specifically, I think Flash is over used and over abused.


    I see Flash almost exclusively used for movies (because it's the only
    movie player that 99% of the clients have installed) and for advertisements
    (including annoying "intros" for websites). Sometimes for games. Very
    rarely for whole websites where HTML/JavaScript would have been more
    appropriate. But I can't think of a single example which I would call an
    application.


    > People who know Flash think in can do anything and everything, and I
    > know some owners/stakeholders who insist on using Flash for
    > everything. Considering all the different kinds of jobs, I believe
    > that Perl has a lot more capability than Flash, but Flash gets a lot
    > more press.


    That's because Flash is flashy (pun intended). Perl does its job quietly
    on the server side and you don't see it. Can you tell that
    http://www.delicious.com/ or http://www.lacunaexpanse.com/ are written
    in Perl? Can you tell that http://gmail.com isn't written in Perl?
    Unless that stuff crashes and you see an error message, you can't. Also,
    Adobe has a PR budget and pays the press to write about their products.
    Perl doesn't (neither does PHP or Python or Ruby, BTW).


    >> All the stuff the article is about is on the client. If Perl doesn't
    >> have a place on the client (I agree with that) then there simply isn't
    >> any competition between Perl and these technologies.

    >
    > Perl doesn't have a place on the client, but the work product of Perl
    > surely does.


    That's what I'm saying. There isn't any competition between client-side
    technologies and Perl. You can combine both.


    >> Doesn't make sense since none of the technologies considered in the
    >> article include a server or database part.

    >
    > Part of the Rich Internet Applications consist content, think Amazon,
    > eBay, Facebook, even Target, WalMart, and L.L.Bean. You are right,
    > except all the eye candy without content is meaningless.


    Why "except". Exactly *because* eye candy without content is
    meaningless, you still need something on the server side. And that can
    be perl (or one of a hundred other languages).


    >> What you would do is combine one of the technologies considered in the
    >> article (HTML5, most likely) with Perl and a database and build an
    >> application framework. Actually, I think quite a few people have already
    >> done that - at least always hear the web programmers I know (those that
    >> use Perl) about using Catalyst together with this or that Ajax
    >> framework.

    >
    > I hope that the number of those belligerents fighting the battle for
    > the control of the web will expand. I would hate to see a monoculture
    > of technology in this area.


    For the client side I hope that there will be some very few standards
    (like HTML5) with lots of different implementations. Currently there are
    3 major platforms (IE, Gecko, Webkit) and a few minor players (like
    Opera). This is better than a few years ago. It probably won't get
    better: HTML5 is hugely complex and the days where a small company could
    write a browser within a few months are definitely over.

    > I also think that the capabilities of Perl can be used to advantage.


    We agree absolutely here.

    hp
    Peter J. Holzer, Dec 13, 2010
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. hg
    Replies:
    2
    Views:
    341
  2. Lesley Dyer

    The High Speed Battle Zoids, Dvd

    Lesley Dyer, Sep 29, 2009, in forum: C++
    Replies:
    0
    Views:
    303
    Lesley Dyer
    Sep 29, 2009
  3. Adrienne Boswell

    I finally won a pop-up battle

    Adrienne Boswell, Mar 28, 2010, in forum: HTML
    Replies:
    11
    Views:
    811
    Neredbojias
    Apr 28, 2010
  4. Krist
    Replies:
    6
    Views:
    698
    Arne Vajhøj
    May 7, 2010
  5. Mark Lawrence
    Replies:
    0
    Views:
    82
    Mark Lawrence
    Mar 1, 2013
Loading...

Share This Page