Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

What do you use as a language litmus?

by apotheon (Deacon)
on Jun 26, 2007 at 11:18 UTC ( #623362=perlmeditation: print w/replies, xml ) Need Help??

What qualities do you look for in a programming language? What are the positive characteristics you look for in a language that might make it more worth learning, or using, than another? What are the short, boolean questions you can ask to get a sense of these characteristics?

I speak of the qualities of a programming language in and of itself, qua programming languages, not their popularity or IDE availability (unless there's a quality of the language that makes IDE availability a characteristic of the language itself).

For instance, some of the things Perl taught me to look for in a programming language are:

  • first-class lexical closures
  • tail-call optimization
  • regular expressions (I may alter my opinion of regexen if/when I get around to learning more about pattern matching as an alternative).

I suppose what I'm asking for boils down to a list of "Can your language do this?" comparisons. I ask not because I have some kind of language advocacy agenda, but simply because I want to know what characteristics of language design people find valuable, and why -- and I'm always on the lookout for something new to learn about programming.

print substr("Just another Perl hacker", 0, -2);
- apotheon
CopyWrite Chad Perrin

Replies are listed 'Best First'.
Re: What do you use as a language litmus?
by Corion (Pope) on Jun 26, 2007 at 12:29 UTC

    I found schwern's list of things to consider when designing a new language quite good. Personally, the one "emergency" question is:

    Does the language have a string eval command?
    If so, then I can emulate includes, arrays, hashes, namespaces, closures and various other neccessary things through this. This is the most ugly solution to all these requirements, but if all else fails, having string-eval helps.

      Thanks for the link -- and for bringing up string-eval. That particular feature hadn't actually made my list before this, though primarily because (as I see now) I hadn't fully considered its implications for dealing with a paucity of important features. It's going in my list of language litmus tests now.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

Re: What do you use as a language litmus?
by talexb (Canon) on Jun 26, 2007 at 13:13 UTC

    An interesting question.

    My gut reaction is, "How easy is it to read the code?" I've just started investigating Drupal as a CMS, so that means getting into PHP. I've looked into the language before, and it seems simple enough, except without some of the groovy things that Perl does. I'm also looking into Python because my CTO mentioned that Red Hat is using it to build their distros. Again, the language reads like a simplified version of Perl.

    Since you touched on IDEs, I did just want to say that I used an IDE from Borland to do development in C many years ago -- but I'm now familiar enough with the language that I use every day (Perl) that if I get a syntax error, I almost always know what the mistake is -- I don't need a visual reminder of where to look. More useful would be an OO debugger, although I'm currently quite happy with the Perl debugger -- that's probably just my machine language background speaking.

    I 'get' OO -- but I've never used C++ or Java much; pure OO usually seems to be twisting reality to fit the language, rather than having the language do the acrobatics. Perl's OO layer is just that -- a layer, and not really built in. However, the hints I see occasionally about Perl6 suggest that it will be much more OO. That's OK -- as long as I can still get stuff done quickly and efficiently, I'll make the jump to Perl6.


    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      I think that code readability is of great importance, of course -- but that's more of a high-level goal of language choice, rather than an example of language choice criteria. For instance, one might say "no variable sigils" in answer to my question, with the explanation that the reason for that answer is to improve readability. One might also say "significant whitespace" for the same reason. Code readability is affected by a combination of such language characteristics, programming style, and the particular accent a given programmer lends to the language in his/her code.

      (Note that I make no judgments here about what effects variable name sigils and significant whitespace have on code readability. I only bring them up as examples of things people have suggested apply to code readability.)

      Regarding your commentary on OOP: Have you had a look at Ruby? Through all my encounters with object oriented programming, including the way it's accomplished in C++, Java, Perl, and Python, I tended to find that OOP was well overhyped. In Ruby, however, I have learned to love the stuff. It's by no means the only way to program, and there are times when it's probably entirely the "wrong" approach to even a high-level problem, but the object model employed by Ruby is subtly pervasive and quite consistent in a way that makes me realize that there's a lot more to OOP than I had previously thought. The problem is not that OOP isn't all that useful -- it's that most languages get OOP substantially wrong.

      With the usual caveats that I've never used Smalltalk or the CLOS, Ruby is by far the best OOP I've encountered. You may find it was worth looking into, while you wait for Perl 6. Quickness and efficient task completion are in no way hindered by the pervasiveness and universality of object orientation in Ruby.

      Speaking of which -- the ability to employ OOP techniques in a Ruby-like "everything is an object" manner is one of the things I include in my list of language litmus tests, at least when looking at a language for purposes of doing any object oriented programming.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

          For instance, one might say "no variable sigils" in answer to my question, with the explanation that the reason for that answer is to improve readability.

        Actually, coming from my C background, Perl sigils were a change for me -- sure, * means a pointer, but apart from that C doesn't have them -- but I quite liked them. Which will be a change going to Perl6.

        And thanks for mentioning Ruby -- that's the third language that I need to look into (in my spare time) in order to stay up to date on what's happening with the new languages. It'll probably be easier for me if I can draw a big chart showing how you do certain things in each of the languages. For example, a pop in Python takes things off the *front* of an array, not the back, like Perl. Not what I expected.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: What do you use as a language litmus?
by Joost (Canon) on Jun 26, 2007 at 20:02 UTC
    Lexical closures

    You already mentioned these :-) Closures are so incredibly useful I don't really want to code without them, but if I must, the language should at least support functions as a data type (i.e. C-style function pointers). Java-style object systems are a much too rigid on their own.

    Closures and its flexible object system are what make JavaScript a good language. Shame about the ugly syntax, though :-)

    Basically, anything that helps writing real functional code is a big plus.


    It's sort of a niche technique, but it's amazingly useful when applicable. See also the discussion at How implement AMB in perl?

    A "freestyle" type/object system

    I like perl's automatic type conversions. I like Ruby's strategy of duck-typing. I like C-style pointer casting. I even like the idea behind C++ templates. I don't like being restricted by the language.

    "Real (i.e. LISP-style) Macros"

    Anything that allows you to subvert the language itself is a good thing :-) Though it seems it's hard to implement unless the language syntax is extremely simple (this might not be a bad thing, I'm only just getting my feet wet with LISP, so it just looks more intimidating than it probably is :-) )

      It's not just the syntax that gets in the way with JavaScript -- it's the broken implementations and the short-sighted language definition (no direct system I/O, for example). It's a good language the same way Lance Armstrong would be a good athlete if he was was riding a circa 1980 banana seat bicycle designed for a ten year old girl in the Tour de France.

      Anyhow -- yeah, I agree, regarding "anything that helps writing real functional code", as long as it doesn't also get in the way of writing real useful code. I'm not saying that writing real functional code necessarily makes the code less useful -- just that I've seen some people do some really boneheaded things with language design for the purpose of rigidly adhering to some kind of design aesthetic.

      Thanks for the link about implementing amb in Perl, and the other commentary. I'll need to get significantly more well versed in things Lispy to really appreciate macros, I think, but one of the things I tend to look for in a programming language is duck typing or, alternatively, type inference. Thus, none of your suggestions really go amiss for me.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

Re: What do you use as a language litmus?
by princepawn (Parson) on Jun 26, 2007 at 15:34 UTC
    I recently posted a similar question to comp.lang.misc. Basically, I am studying the J programming language.

    It is a successor to APL and is remarkably concise. It is also a highly functional language. It has computer language counterparts to English parts of speech such as noun, verb, adverb, gerund, and conjunction. Besides concise operators, there is one concept, called verb rank, which went through more than 10 years of development and research to develop. It has a long history of development. I will now give a small taste of each of my overview statements.

    descriptive, not proscriptive

    In a descriptive language, it is convenient to describe a macroscopic action as opposed to proscriptive, where you must do each little part. I spent a good amount of time dabbling in Factor, a stack-based language before getting exasperated with the proscriptive nature of it. I had to continually focus on manipulating a stack as opposed to focusing on the problem at hand.

    J is descriptive in a number of ways, but I will only go over one that is necessary to read the next section. It has to do with a concept called "verb trains"... In most languages, a series of functions implies function composition. In J, two functions in series applied to data gets rewritten like so:

    (f g) data => data f (g data)
    which means that f is a binary function which will take the pure data and the result of g data and operate on that. ... here we must note something else....

    a brief aside

    J verbs (functions) are monadic, dyadic, or ambivalent (meaning they have implementations for both monad and dyad cases). The monadic case looks normal:
    fn data NB. function applied to data "NB. is comment in J"
    but the dyadic case is just like in English sentences where you have Subject Verb Object:
    5 + 5 NB. 5 adds_to 5 5 , 6 NB. 5 appended_to 6 4 { 1 2 3 4 5 NB. 4th element_of the_list_12345
    So when you see
    (f g) data => data f (g data)
    the data f (g data) is Noun Verb Noun and is not like in perl where a function taking two arguments would have both nouns to the right of the verb.
    What this means is that the common operation of copying data before operating on it, and then using the original and modified data on another function is highly descriptive.

    Now three verbs in a row is called a fork. So

    (f g h) data => (f data) g (h data)
    And that's what you need to know for the next section

    highly concise

    J took the judge's prize in the 1998 ICFP programming contest. It ran faster than 17 compiled C entries. And is "astoundingly brief" --- only 113 lines and only contained one loop thanks to the fact that all operators have implicit looping capabilities.

    Check out this J code to average a list of numbers:

    avg =: +/ % #
    +/ means to insert + between each member of a list... and the neat thing is that / is an adverb that can be applied to any verb. so / is a function which takes a verb as a function to produce a new verb!

    % is simple. It divides 2 numbers

    # is simple. It counts the number of elements in a list

    So remember that a train of verbs gets rewritten? So basically what we have is

    (+/ data) % (# data) (sum-of data) divided-by (number-of-elems data) results in average

    the rest of J

    Well, I'm a bit tired, and I havent really given a balanced overview like I meant to. Personally, I'm addicted to J and keep coming back for more. The J Bibliography is a great place to read on the origin of ideas behind APL and J as a certain way of looking at programming which puts conciseness at a premium. In particular see:
    Falkoff and Iverson, The Design of APL, 1973. Falkoff and Iverson, The Evolution of APL, 1978. Iverson, A Personal View of APL, 1991.

    Also Ken E. Iverson memoriam page has plenty of insight to APL and J language culture.

    It's a very different language. And it will make you think differently, but I am enjoying my time with it.

    The Cons

    The cons about this language is the small community and lack of enterprise-ready deliverables/libraries. For instance, they are just now trying to get parsing of multipart form data to work properly.

    Now even though the community is small, you can check the mailing list archives to see that there is a tremendous amount of activity amongst the small userbase.

    Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality
Re: What do you use as a language litmus?
by bart (Canon) on Jun 27, 2007 at 11:35 UTC
    I care more about the writeability of a language, than of the readability.
    • How easy is it to start a new function? How much "junk" do you have to write as a basic framework for any addition?
    • Can I remember how to do it right easily, or does it pretty much require to copy/paste a boilerplate for the code before starting?
    • Can I express what I want easily without having to jump through too many hoops? This mostly boils down to: what kind of stuff can I pass as parameters?
    • If I change my mind ever so slightly, do I have to rewrite a lot of code just to fit the change?
    • How tricky is it to get it right?
    And, last but not least: how fast does it run?

    Needless to say, for me, Perl scores highly on all these points.

      I think it's telling that I've never heard of a "read-only" language. The implication I draw from this is that readability is dependent upon writability: the extent to which a language is writable is an upper bound to its readability. So, yeah -- writability is of pretty significant importance objectively, I think, as well as subjectively.

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin

Re: What do you use as a language litmus?
by perrin (Chancellor) on Jun 26, 2007 at 21:15 UTC
    Mature support for a debugger and profiler. Mature database libraries. The rest is all negotiable.
Re: What do you use as a language litmus?
by Anonymous Monk on Jun 28, 2007 at 00:25 UTC

    One thing I find rather useful is for a language to behave as expected. By this, I mean that if does not do odd things such as redefine operator precedence (see APL) or have odd restrictions, such as preventing one from casting an integer to a float.

    What I want in a language are a sensible syntax, a reasonable set of arithmetic and logic operators (why, O Kernighan, doesn't C have an exponentiation operator?), a sensible method for passing data to and from subroutines, and the ability to link in libraries, especially those written in other languages.

    I view regex as a feature that could be added, not something that needs to be intrinsic to the language, such as tail-call recursion or closures.

    I've really not mucked around in languages other than imperative languages, so I can't comment on languages in any of the other families, such as Ocaml, Lisp, etc.

    The one syntax feature I tend to dislike is for whitespace to be used for something other than token separators; in some languages, such as JCL, two, vs one, blank can completely change a statement's meaning. I also tend to dislike languages, like APL, which use a very non-standard character set.

    Perl has passed my test; APL hasn't. I've been forced to use JCL, and still bear the scars. Two languages I would really like to learn are Ruby (got to love the name) and Lisp (good thing I can touch type; Lisp would wear out the markings on the open and close parenthesis keys).

Re: What do you use as a language litmus?
by vrk (Chaplain) on Jul 31, 2007 at 10:40 UTC
    1. First-class closures
    2. Most common idioms are easy or trivial to do

    Anything else is negotiable. First-class closures were already mentioned in the OP, and by the second, I mean what Perl has got mostly right: sometimes you can even manage with a one-liner. Of course, how this is actually done depends on the language. Perl is bent towards text processing, thus regular expressions and many other features are easily accessible and embedded into the language core.

    A good example of the opposite is Java. No matter what you want to do, you always have to create at least one class. There are no exceptions to this, no common case optimizations. The "main" function of the program is the most common function, as unless your program is a library (and even then, you might use the main function in testing!), your program will have the main function. In Perl, your program source code is, by default, the main function, unless you explicitly direct the program flow elsewhere. In Java, you have to:

    class Somesuch { public void main(String[] arguments) { ... } }

    That is, you always need to declare a class, even when it's completely useless, and you always need to explicitly name the variable where you want to put the command-line arguments, and you always need to explicitly declare the main function.

    Another common-case optimization in Perl is the lexically bound implicit (loop) variable $_. In Java, C, C++, and awfully many other languages, you always need to declare the loop variable, even though when you write a loop, the most common case is that you are looping over some data structure and you need to access the contents inside the loop body. In C++, for example, using indexing:

    std::vector<Data> myArray; /* Time passes... */ for (int i = 0; i < myArray.size(); i++) { process(&myArray[i]); }

    or iterators:

    for (std::vector<Data>::iterator i = myArray.begin(); i != myArray.end(); i++) { process(&*i); }

    In Perl, of course:

    for (@array) { process($_); }

    or even

    process($_) for (@array);

    (Granted, the latter C++ example uses iterators, but still, it's an awfully verbose way to do a very common case in programming.)

    The examples are not the best, but when such mentality pervades the language design, I steer clear.

    print "Just Another Perl Adept\n";

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://623362]
Approved by GrandFather
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2019-12-12 03:56 GMT
Find Nodes?
    Voting Booth?

    No recent polls found