use Perl

• Not to be a pain... (Score:1)

  by GAVollink (5690)

  You are almost describing what Sun wanted Java to be back in 1996 - and it almost made it (oddly, the Java infrastructure is in place - and fairly ubiquitous [ though not totally ] but gravely underutilized due to lack of speed).
  • Re:Not to be a pain... (Score:1)

    by GAVollink (5690)

    In fact the closest we have to a utilized ubiquitous environment is (I hate to say this) Flash. Flash is available on all major platforms - and with it's extreme ease of installation across the board (especially on Firefox/Linux) - it's become the rich-media technology of choice for web.

    But - that's where we are - not where we need to be. I haven't read enough about it - but is this what folks want Parrot to become?
    • Re:Not to be a pain... (Score:2)

      by ziggy (25)

      Hm. Can you do a big honkin' server-side app in Flash?

      What David describes is one environment where you sit and write code on the server, and have some of it executing server side, and some of it executing client side.

      It sounds vaguely like what Java promised in 1995, but the mindset back then was to write monolithic apps that didn't need installers (or upgrades, or patches), and used old-style clunky GUI toolkits. What David and I are talking about are things like Gmail, Flicker and Google Maps, wher
      • Re:Not to be a pain... (Score:1)

        by GAVollink (5690)

        See, pain... Thus my subject line.

        Just as content and layout are different (or should be)... client and server are different.

        The rich-layout that enables an application to look fancy, _and_ quick - that's what I was driving at - but no, Flash itself doesn't have a server-side component.

        One of the primary reasons for the difference between client and server side computing (thus the context switching) is security. And to bypass security gets into the "sandbox" mentality (restrictive) or the opposite direc
        • Re:Not to be a pain... (Score:2)

          by ziggy (25)

          Just as content and layout are different (or should be)... client and server are different.

          Well, yes. And no.

          As you sketch it out, security and sandboxes are something of a red herring. Sure, you don't want to ship ActiveX controls about (or whatever Microsoft is shipping this week). But web apps as we know them today are just server-side apps that ship text from web servers. Except that the text is HTML (or XHTML, or XML + CSS, or ....) that melds instructions to display content and communicate
  • Java and lack of speed (Score:2)

    by bart (450)

    Java infrastructure is in place - and fairly ubiquitous [ though not totally ] but gravely underutilized due to lack of speed).

    I disagree. Java isn't slow. But Java is slow to start up in a browser. For most pages, it's just unacceptable. Even a small applet takes 1/2-2 minutes to launch, if Java wasn't already running.

    Flash, OTOH, is a quick starter, typically taking only the time to actually load the "applet" even on broadband. Hence, the threshold to use something using Flash on a web page is
    • Re:Java and lack of speed (Score:2)

      by ziggy (25)

      I saw a first person shooter in Flash (or the moral equivalent) pop up on del.icio.us recently. It's certainly a really cool way to push at the edges, but somehow I doubt that's going to lead to the next Gmail, Google Suggest or Google Maps. ;-)

      Things like 10x10 are going to be taking the web in a different direction. Interesting in its own right, but not the kind of application development I'm trying to describe above.
    • Re:Java and lack of speed (Score:1)

      by GAVollink (5690)

      Like my momma always says, "Slow is as slow does".
• To be a pain (Score:1)

  by quidity (1296)

  Why, exactly, would one want to use just the one language... I'm quite certain that the best mini language for user-interface generation isn't the same as the best language for user-scripting, and isn't the best language for back-office transaction processing.

  Now, the best glue between each of them...
  • Re:To be a pain (Score:2)

    by ziggy (25)

    That's a good point. Web interfaces aren't moving away from HTML/XML/CSS/etc. any time soon. You could call that a language if you wanted -- especially compared to some of the alternatives (e.g. writing UIs in Java against SWT.)

    But when you look at the structure of the AJAX model, you've got some XML munging at the server, and some XML (for all practical purposes) munging on the client. The server is typically written in Perl, Python, PHP, Ruby, Java, C#, or Befunge, and the interactive bits on the cli
    • Re:To be a pain (Score:2)

      by Dom2 (2981)

      JavaScript is probably a whole lot better for XML munging than most other choices, assuming that E4X [ecma-international.org] actually gets deployed in any sensible fashion. As usual, it's a lot easier to deploy to a server.

      -Dom