Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Honest question about Perl, Python and Ruby

by madM (Beadle)
on Feb 07, 2015 at 00:17 UTC ( [id://1115818]=perlquestion: print w/replies, xml ) Need Help??

madM has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks!

I would like to honestly ask you all what do you think about Perl, Python and Ruby. I personally like Perl but it seems that Python and Ruby are gaining ground really fast and "compiting" with Perl. Is Python or Ruby better/worse than Perl? or advantages of each Language?

I would like to ask your honest opinion since i know we are all Perl lovers here ;)

Thanks for your answers!
  • Comment on Honest question about Perl, Python and Ruby

Replies are listed 'Best First'.
Re: Honest question about Perl, Python and Ruby
by fullermd (Priest) on Feb 07, 2015 at 01:52 UTC

    Is Python or Ruby better/worse than Perl? or advantages of each Language?

    Apocalyptically bad languages rarely (though not never) get much traction. Spectacularly awesome languages usually (though not always) wind up being used.

    Most languages fall between the extremes. What determines their adoption winds up being a large pile of factors, but almost none of them can possibly be distilled down to "language is better/worse". Most deciding factors, really, can be succinctly, not-really-fairly, and totally-uninformatively lumped under "luck". And without contradicting those negative adverbs, also be not really untrue.

    There's nothing Ruby can do that Perl can't. There's nothing Python can do that Ruby can't. There's nothing Perl can do that Python can't. Even aside from the (also not untrue, but still silly) argument of "they're all Turing-complete", they're all "dynamic" and "interpreted" and "scripting" and other fuzzy-but-still-useful subdivisions of the landscape.

    What they are is different. They have different language structures, they have different community structures, they have different tendancies, they have different biases. They invite you to model problems and decompose processes differently, to express yourself to the compiler and to other programmers differently. You're not going to get a good description of those differences from anybody except somebody well-versed in all of them (which I'm not). And in fact, you really can't get it from anybody else either, since what will matter is how you relate to them, which is only partially determined by the language itself. It also varies depending on you (and for that matter, you-today aren't the same as you-5-years-from-now, so it's not even time-invariant).

    Do you (/your team) know one better than the others? Then that's the right choice. Do you have an existing codebase in one? Then that's the right choice. Does one have an excellent set of existing libraries for your problemspace? Then that's the right choice. Does one sound more interesting to explore, even (especially?) not knowing it, and you have the resources available to indulge? Then that's the right choice. Do you not care about any of that, and just want to pick the one that'll get you the most/best paying jobs? Then count up job listings and pick that one (and hope you project right for the appropriate future term).

    Do none of those apply, or provide definitive answers? Well, then obviously Perl is the right choice 8-}

[reply]

      I was so dreading what this thread would look like and I had no good comedy to add so I was keeping out. I’m back in to say this is a fantastic reply. All ++s to you.

[reply]
        All I know is: a good Fortran programmer can write Fortran in any language.
[reply]

      ++fullermd:

      Here's a virtual ++ since I can give the post only one real one. Well said.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

[reply]
      "... they have different community structures ..." That's the kind of thing I usually put emphasis on. Technical decisions are usually social decisions in disguise. Look around for local users groups, attend a few meetings, and see what kind of folks have been attracted to the languages, and see who you want to hang out with. You might also look at what different companies you're interested in are using, but there's limits to that reasoning (e.g. Google hires some really good perl programmers, they just don't let 'em program in perl.).
[reply]
        Technical decisions are usually social decisions in disguise.

        Now that’s a good pull quote.

[reply]

      Very well articulated :-)

      They invite you to model problems and decompose processes differently

      And this is why I think good developers don't limit themselves to any single language (even if they do have a preference)

[reply]
Re: Honest question about Perl, Python and Ruby (Comparing Programming Languages References)
by eyepopslikeamosquito (Archbishop) on Feb 07, 2015 at 04:41 UTC
[reply]
Re: Honest question about Perl, Python and Ruby
by graff (Chancellor) on Feb 07, 2015 at 06:02 UTC
    I've been programming in Ruby for a couple years now (after having programmed in Perl for over 15 years), so maybe I'm qualified to give some anecdotal testimony (which will basically confirm what fullermd said above).

    It seems like Ruby is a sort of middle-ground between Perl and Python: it actually borrows some idioms directly from Perl (including the command-line options that allow for really nice one-liners), and like Perl, it has a fairly strong (and seemingly popular) presence for web developers. But like Python, it's firmly and fundamentally object oriented.

    If you happen to deal a lot with Unicode (non-ASCII) text, you'll like Ruby v2, because utf8 character handling is there "by default" - just open a file and read or write text in any language without further ado. (Opening a non-text file in binary mode is no harder here than in any other language.) Once you get your head around using (and chaining) method calls on objects, the code can become relatively compact compared to Perl.

    Alas, it doesn't necessarily make the code any more easy to read or write, if you haven't memorized the relevant facts about all the various objects, or grasped the finer details of syntax and punctuation. (I'm tempted to refer to some patterns as "syntactic gristle" as opposed to "syntactic sugar.") The core documentation for Ruby is okay (not as clear or complete as Perl's, but not bad). Third-party module documentation typically stinks, if there's documentation at all. (A lot of Ruby module developers seem to think that "look at the source code" should be all the documentation anyone will ever need.)

    Yes, there is a place where you can search for freely available Ruby modules that do useful things, but it doesn't hold a candle to CPAN in terms of breadth and ease of search, and some of the "nearly core" modules (covering things like database connections and XML parsing) have documentation that seems unduly maze-like to the newcomer. And then there's the occasional clunker, like the "zip file" module with a really bad memory leak. But maybe it's just a matter of time - Perl has been around somewhat longer. (Then again, Perl has had really good documentation since the early days, and subsequent developers have been following a well-established good example. Ruby's start-up and subsequent developers, not so much.)

    Apart from having a user community that appears to be better at sharing, documenting and peer-reviewing code, Perl has a notable advantage for doing arbitrary data structures (HoAoH in Ruby is not so easy). Of course, it may just be that Perl seems better to me because after all these years, I've gotten really used to it.

    Lately, when I have to do quick, one-off things on the command line, I find that some tasks are easier in Ruby, and other things are easier in Perl, and I choose accordingly.

    (updated to fix a typo)

[reply]

      Perl has a notable advantage for doing arbitrary data structures

      I wonder if this advantage is due to autovivification or are there other reasons? AFAIK, autovivification is unique to Perl. A simple illustration of autovivification in Perl vs Ruby (taken from this old golf node) is: 

      $z[ 0][ 8] = 'o';
$z[ 1][11] = 'o';
$z[ 3][14] = 'o';
$z[ 5][15] = 'o';
$z[ 7][14] = 'o';
$z[ 9][11] = 'o';
$z[10][ 8] = 'o';
$z[ 9][ 4] = 'o';
$z[ 7][ 1] = 'o';
$z[ 5][ 0] = 'o';
$z[ 3][ 1] = 'o';
$z[ 1][ 4] = 'o';
print"@$_\n"for@z;

      [download]

      To emulate the Perl test program above in Ruby, you might try: 

      z=[]
(z[ 0]||=[])[ 8] = 'o'
(z[ 1]||=[])[11] = 'o'
(z[ 3]||=[])[14] = 'o'
(z[ 5]||=[])[15] = 'o'
(z[ 7]||=[])[14] = 'o'
(z[ 9]||=[])[11] = 'o'
(z[10]||=[])[ 8] = 'o'
(z[ 9]||=[])[ 4] = 'o'
(z[ 7]||=[])[ 1] = 'o'
(z[ 5]||=[])[ 0] = 'o'
(z[ 3]||=[])[ 1] = 'o'
(z[ 1]||=[])[ 4] = 'o'
puts z.map{|i|(i||[]).join" "}

      [download]
      Note that, because Ruby does not autovivify, you must manually create the empty lists -- using the || operator in the test program above. Note further that 0 and "" evaluate to true in Ruby, so the Ruby || operator is closer to Perl's // "defined or" operator than its || "or" operator.

      Update: As noted in brian_katzung's necropost reply below, you can autovivify nowadays in Ruby using his XKeys Gem. Some links:

[reply]
[d/l]
[select]

        You can autovivify in Ruby with my XKeys Gem.

        require 'xkeys'
z = [].extend XKeys::Auto
z[0, 8] = z[1, 11] = ... = z[1, 4] = 'o'

        [download]

        And

        node_info = {}.extend XKeys::Auto
node_info['list', :[], 'name'] = 'new node' # :[] means next index
#  {"list"=>[{"name"=>"new node"}]}

        [download]
[reply]
[d/l]
[select]
      If you happen to deal a lot with Unicode (non-ASCII) text, you'll like Ruby v2
      Is that so? The last time I looked at Ruby, even the simplest things (like "Я".downcase()) didn't work. Not to mention full casefolding, properties, normalization, collation... there were some slow, 'pure Ruby' libraries... it was pretty bad. Is it improved now? I kind of got an impression that Japanese dislike Unicode because it makes their alphabet look like Chinese or something (but maybe it's a false impression that says more about me then about the Japanese).
[reply]
        Thanks for pointing that out. I stand corrected. (To their credit, this is one case where the ruby docs are clear: "... Note: case replacement is effective only in ASCII region.") Oh well, room for improvement there.

        Update: FWIW, a ruby user can do "gem install unicode_utils", and then do things like: 

        #!/usr/bin/env ruby

require 'unicode_utils'

puts UnicodeUtils.downcase("Я")  # aka "\u042F", "CYRILLIC CAPIT
+AL LETTER YA"

        [download]
        It's clunky, but it works. (I wish the "code" tags here would allow a letter like "Я" to appear as such.)
[reply]
[d/l]

      I do about equal amounts of Perl and Ruby (neither as the core of what I do to eat) and generally agree with what graff has posted above. I stay away from Python because of the indentation thing, but I suspect I'm going to have to deal with it more soon. I probably wouldn't do a lot of Ruby if it weren't for Rails (and the various good and bad that comes with it)-- it's an easy way to get a site up fast, and Spree is easy to set up a store with and easy to modify, particularly if you're only doing it infrequently but want to do some non-standard web store things. If I need a quick hack for something, I go to Perl first (or C if I need a low level language).

      As far as CPAN vs various Ruby gems, there's no comparison. Not only does CPAN have incredible depth and ease of finding useful modules, but they play very well together. I can't remember the time I tried to do something and had a conflict between module versions in Perl, but it seems like gem dependency version conflicts show up any time you try to do anything.

      The prevalence of conflicts in Ruby gems is also a symptom of another major difference- Perl (at least 5.X) is a much more stable language as far as things like syntax and structure. The Ruby community (or parts of it) seem to fall prey to the "ooh, this is a cuter syntax, lets deprecate the old one!" a little too easily, and when you get forced into upgrading your Ruby you tend to have to go fix up a bunch of things that have been dropped since you last touched the code. It might be good job security for some people, but I mostly code because I need to get stuff done and I don't want to have to go back and rework stable code because someone decided to change the hash syntax.

[reply]
Re: Honest question about Perl, Python and Ruby
by RonW (Parson) on Feb 07, 2015 at 01:23 UTC

    My main coding language is C. Perl is my "Swiss Army Knife" coding language. Before I encountered Perl, I used a combination of awk and shell scripting to accomplish what I would now use Perl to accomplish. Being experienced with C and awk, Perl "felt" kind of natural to me, despite being a little strange. Using Perl made it easier to create and maintain tools that help me get my main work done.

    Ruby seems ok. But I've only used it for a few projects where Ruby was already being used, so I have very little experience with it. I do find it more "comfortable" than Python (but not as comfortable as C and Perl).

    Python is easier to read, but, in my experience, not actually easier to code in. Python has a big trap: Indentation. Program structure in Python is controled by indentation. The reason this is a problem is because the indentation you see in your editor might not be the same as what Python sees. With Python code, any time spaces and tabs are mixed, there is trouble waiting. Best to use only spaces and make sure your editor does not compress spaces in to tabs. Alternately, use only tabs and make sure your editor does not expand them.

    I've used many coding languages for various reasons. Personally, I'm most comfortable with C and Perl. When I have a reason, I sometimes choose a different language. When I have to, I can handle other languages.
[reply]
Re: Honest question about Perl, Python and Ruby
by BrowserUk (Patriarch) on Feb 07, 2015 at 07:09 UTC

    I'm puzzled by what you hope to learn from the answers?

    I prefer Perl. I just can't get on with the significant whitespace and hanging indents of Python. Ruby seemed okay; but didn't seem to offer anything special over Perl.

    Since I knew Perl first; when I needed to get something done, it was easier and quicker to reach for the tool I knew than work out how to do it in one of the other two.

    And when I set out to learn Ruby -- Python was kicked into touch almost immediately -- I just found nothing that made it significantly better than Perl; and much that seemed awkward (or even, impossible without lots of extra effort) by comparison.

    Perhaps if I'd learnt one of the other two first my story would be different. (Though i seriously doubt I could have ever learned to like Python.)

    But quite how any of that helps you, I simply do not see?

    Try them all; pick the one you like best; or whichever seems to give you the best career opportunities.

    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". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
      Ruby seemed okay; but didn't seem to offer anything special over Perl.

      I learned Perl and Ruby at about the same time maybe 12 years ago because I had a problem that I wanted to solve and was poking around at what tools would get me going fastest. There were some useful Perl tools, so I started with that, then tried both Rails and Catalyst and kept getting hung up on getting Catalyst to install, while Rails was painless at the time. I have no idea how they compare today.

      At the time, I also thought that Ruby had a slightly cleaner object syntax (as a relative beginner at OO languages). Now I honestly don't even notice whether I'm using an OO interface to a Perl module vs a functional- I look through the docs and call things however they want to be called. The language has a lot of flexibility and I tend to just roll with it.

[reply]
Re: Honest question about Perl, Python and Ruby
by igoryonya (Pilgrim) on Feb 07, 2015 at 04:55 UTC
    I think, that Python and Ruby are good languages, but the first thing that I want to point out is that, if the language is more popular, doesn't mean, that it's better.

    For example, php, Visual Basic and Delphi are the most popular languages, because they are easy to learn and use. PHP, however is mostly, if not only, suitable for web projects. You can use it for standalone programs, but, it's difficult. Visual Basic and Delphi are the languages made for nonprogrammers or beginners. They are inflexible. It's easy to do simple programs, using them, but, when your projects grow, they crumble under their weight and there is a lot of bad quality code. For example, to do a simple procedure of justifying a text in a Visual Basic, took me almost 3 pages of code, while in perl, I did it in about 15 lines of code (about a half of the screen), that was more readable than in Visual Basic. The code from Visual Basic, Delphi and, to some extent, from php is very difficult to almost impossible to reuse on other projects.

    In comparison to other languages, Perl has an best regular expression power. Also, it has a difficult to learn, but the best unicode support. With Perl, you can easily build very complex data structures (nested arrays, code references, associate arrays (hashes), within arrays, within hashes etc.)

    Python, is object based from the ground up, while Perl has a support for object oriented programs. I like the mandatory documentation that you have to do in Python code. You can embed documentation in Perl programs, but it's not mandatory. I want to learn Python mostly, because it has a support in Paint Shop Pro, GIMP and Blender, gedit, gnome, etc., so I can automate things in those environments. There is a disadvantage, though, that there is no compatibility from Python 2 branch to Python 3 branch. Python 3, is pretty much a new language in comparison to Python 2. The abundance of Python 2 programs will not run under Perl 3.

[reply]

      Python, is object based from the ground up

      Are you thinking of Ruby? Quoting Matz from An Interview with the Creator of Ruby:

      Then I came across Python. It was an interpretive, object-oriented language. But I didn't feel like it was a "scripting" language. In addition, it was a hybrid language of procedural programming and object-oriented programming. I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python.

      I like the mandatory documentation that you have to do in Python code.

      Are you referring to Docstrings? In any case, I can assure you that documentation is not mandatory in Python. Even if it were, is it good and useful documentation?

      BTW, you can easily make documentation of your Perl modules "mandatory" by adding a test that uses Test::Pod::Coverage. As you might expect, this only enforces documentation coverage, not that the documentation is well-written.

      The abundance of Python 2 programs will not run under Perl 3.

      I wouldn't hold that against Python because the abundance of Perl 5 programs won't run under Perl 3 either. :)

[reply]

        I wouldn't hold that against Python because the abundance of Perl 5 programs won't run under Perl 3 either. :)

        And then what happened?

        Pretty much all perl written since 1994 will still run on perl today, python won't

        http://perl5.git.perl.org/perl.git/tags

        ...
21 years ago   perl-5a2    1994-Oct-07
22 years ago   perl-4.0.36 1993-Feb-05
23 years ago   perl-4.0.00 1991-Mar-21
24 years ago   perl-3.044  1991-Jan-12
25 years ago   perl-3.000  1989-Oct-18
26 years ago   perl-2.001  1988-Jun-28
26 years ago   perl-2.0    1988-Jun-05
27 years ago   perl-1.0    1987-Dec-18

        [download]

        https://en.wikipedia.org/wiki/History_of_Python

        Python 1.0 - January 1994
 Python 1.6 - September 5, 2000
Python 2.0 - October 16, 2000 
 Python 2.7 - July 3, 2010
Python 3.0 - December 3, 2008 
Python 3.4 - March 16, 2014

        [download]
[reply]
[d/l]
[select]
        Yes, I ment a docstring. I have a shallow introduction to python, so I thought, it was mandatory, but I've meant it as a plus anyway, since it will probably enforce the developers to document their programs better, then in other languages.
        I wouldn't hold that against Python because the abundance of Perl 5 programs won't run under Perl 3 either. :)
        Not a fair comparison, since, I was talking about a backward compatibility, but you are talking about older language, supporting programs, developed for the newer syntax, unless, you were joking.
[reply]
      As far as an "in between" language - What do you all think about Tcl/Tk?

      My perception that it is not too heavyweight; A little different syntax { Uses fewer special characters / operators } But not as widely used.

[reply]
      "... Perl has an best regular expression power. Also, it has a difficult to learn, but the best unicode support."

      I was just about to make that point. Python's regular unicode handling sounds like it's getting better, but they're regexps still don't deal with it very well. I'm not sure about Ruby, but some years back Matz went with an encoding agnostic approach... if I've got it right, encoding is an attribute of a string, which makes me wonder what happens if you concatenate two strings with different encodings, one unicode and one something else...

      (All of them, however, beat the current generation of Javascripts, which still use the completely obsolete UCS-2 internally...)
[reply]
Re: Honest question about Perl, Python and Ruby
by CountZero (Bishop) on Feb 07, 2015 at 08:02 UTC
    I personally like Perl but it seems that Python and Ruby are gaining ground really fast and "compiting" with Perl.
    So what? Even if Python or Ruby "gain ground" according to whatever metric someone has invented, that does not say anything about the quality of Perl or of the other languages. I use Perl because it gets the job done: correctly, reasonably fast and efficient and it comes with a vibrant and friendly community. 'Nuff said!

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
[reply]
Re: Honest question about Perl, Python and Ruby
by Preceptor (Deacon) on Feb 07, 2015 at 17:17 UTC

    Python is more popular these days, by some measures. I don't think that's really any sort of meaningful trend. I think the core reason is to do with first languages.

    Python is more like Java, where Perl is more like C. The rise of Python I would surmise is correlated to the rise of Java. It's certainly true that a lot of the criticism I hear of Perl is that it inherit C's tendency towards making obfuscated code really easily. I can't really dispute that - there's some really amazing examples of inscrutable code out there. (My personal favourite is this one: http://www.perlmonks.org/?node_id=118799)

    Of course, I also counter that assertion by pointing out that you can write bad code in any language. A good programmer doesn't. And for that, Perl is actually pretty good - you can write idiomatically good code that's very clear... if you care to.

    I wouldn't say there's a winner or loser in this holy war. Python gains popularity, but Perl isn't going anywhere any time soon. Most things are starting to become API driven, so as long as you scripting language can speak to the internet, parse JSON and XML then anything else is a matter of personal preference.

[reply]
Re: Honest question about Perl, Python and Ruby
by Laurent_R (Canon) on Feb 07, 2015 at 11:37 UTC
[reply]
Re: Honest question about Perl, Python and Ruby
by LanX (Saint) on Feb 07, 2015 at 15:34 UTC
    I'd be interested to see the answers you got on Pythonmonks and the monastery of Ruby...

    Cheers Rolf

    PS: Je suis Charlie!

[reply]
Re: Honest question about Perl, Python and Ruby
by QM (Parson) on Feb 10, 2015 at 10:23 UTC
    Having done lots of Perl, and recently a good speck of Python...

    I think the popularity of Python is due to its rigidness. Since it's easier to write inscrutable Perl programs than Python, and Perl is much more TIMTOWTDI, I can see many new programmers struggling to parse Perl, even well written Perl, while they have little trouble parsing Python, even bad Python. Perl's misplaced reputation for write-only doesn't help. But somehow Python's meaningful whitespace doesn't cause the same problem? (I thought "we" learned our lesson with whitespace in make? Oh wait, was Python entrenched before that lesson was fully realized.)

    That isn't to say that they can understand one better than the other, because it's the larger constructs that the story hangs on. It's hard to beat a good abstraction hierarchy, and judging by may samples in the wild, it's hard to create one too.

    I recall from my university days, comparing Fortran, Pascal, and C. Pascal was a "teaching" language, so had all the rails up. As such, it was fairly easy for a CS newbie to get somewhere, with a book and a compiler alone. Pascal was popular in industry where engineers with little CS training had to write complicated software. Pascal still had the full rails up. One of our systems actually had a Pascal interpreter written in C, because the C compiler was free, but the "customer" wanted Pascal for the non-literate engineers. (Of course, it had none of the features unique to Pascal, such as sets, and did not have pointers. Even though it was for testing silicon chips, and sets of pin names and numbers would have been useful.)

    -QM
    --
    Quantum Mechanics: The dreams stuff is made of

[reply]
      Pascal was a remarkably bad language that had tremendous amounts of computer-industry hype going for it for a number of years. Consequently programmers of a certain age (such as myself) are nearly immune to hype-- the latest and greatest uber-cool languages are sometimes useful, but often just a pain in the ass (like, say, Java?).

      If you want to understand why Perl is so loosey-goosey, you need to understand how badly programming in Pascal sucked. The one is a reaction to the other.

[reply]
Re: What/which is better/worse about Perl, Python and Ruby
by Anonymous Monk on Feb 07, 2015 at 00:45 UTC
[reply]
Re: Honest question about Perl, Python and Ruby
by grondilu (Friar) on Feb 08, 2015 at 12:22 UTC

    My two cents : Perl is old, python is boring, ruby is weird.

[reply]
      s/old/mature/; of course!
[reply]
[d/l]
Re: Honest question about Perl, Python and Ruby
by sundialsvc4 (Abbot) on Feb 07, 2015 at 13:28 UTC

    This immovable status quo also means that you will encounter a hodgepodge of languages ... most commonly these days, the three you mentioned plus PHP and JavaScript ... in any existing project that you might encounter in the field.   Since rewriting is simply “starting over,” and refactoring is almost a euphemism for the same thing, you are quite stuck with needing to know multiple languages without picking favorites.   Whatever dress the grand dame wore to the ball, is the same one she will leave in.

    You can try valiantly to introduce a new language into an existing system or “shop,” but the end result is simply that you’ve added yet-another one.   And, a very critical issue is raised thereby which is often overlooked:   libraries.   Unless the libraries in two different languages merely “wrap” the same .so or .DLL, they probably are not exactly identical in their implementation therefore behavior.   Two parts of the “same” system are actually apples vs. oranges, and the surprise-deficiencies of a library in one language vs. another can wreck a project, even when the custom-source that has been written is genuinely(!) “–er.”   Another compelling reason to stick with the beaux that you know, even if it occasionally requires liquor or deodorant.   (With regards to it, and/or with regards to you ...)   ;-)

    And the situation on mobile devices is much worse, because the market is split between several aggressively-competing vendors, each with their own proprietary platform, each based on different languages.   “Cross-compiler” solutions aren’t standardized, some are ill-funded, and then there are the folks who simply want to turn a mobile device into Flash or a thinly-disguised HTML website.   This dissipation of focus and therefore effort will never end.

    So, go ahead ... have your preferences.   (Perl’s a great language to prefer.)   But meanwhile, learn as many programming tools as you can, because you will need them all.

[reply]

Back to Seekers of Perl Wisdom

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?

www.com | www.net | www.org
Node Status?
node history
Node Type: perlquestion [id://1115818]
Approved by Athanasius
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? • Last hour • Other CB clients
Other Users?
Others having a coffee break in the Monastery: (1)
As of 2024-04-18 23:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found