Favorite Programming Language Features?

johnnyb asks: "I'm curious what everyone's favorite programming language features are. I'm looking for both the general and the specific. I'm especially looking for features that few people know about or use, but are really useful for those who do know about them. What are your favorite programming language features?" "A couple of examples to kick off the conversation:

• Continuations
  
  Continuations are very interesting, because they can be used to implement a number of flow-control features such as exceptions, coroutines, cooperative multithreading, and are better at modelling web interactions. This is a more general feature, but most people use these in conjunction with either scheme or ML.
  
  
• Tuple-returning
  
  It is a huuuuge time-saver when languages like Perl allow functions to return tuples. Instructions like '($a, $b, $c) = $sth->fetchrow_array()' is a wonderful thing.
  
  
• The flip-flop operator [Perl's '..' operator]
  
  Another perlism that I just think is cool. Read more about it here.
  
  

Okay, on to yours!"

Comments

anonymous inner classes

[notyou2]

I think's java's concept of anonymous inner classes is simply superb... it enables runtime aggregation of small objects while preventing you from having to create hundreds of named external helper classes to implement the behavior.

It's certainly not an unknown feature, but I couldn't live without it.

Re:Speed and RAM

[sfjoe]

I feel the one of the strongest features of Java (or any language) is a standardized documentation feature (i.e. javadoc) and "readability". Being able to easily understand what another developer's intentions and "gotchas" are is invaluable. Perl, for example, can be obtuse without even trying very hard.

.. and now, 50 rebuttals from the Perl crowd.

Favourites

[E_elven]

Ruby blocks, lambda functions, lazy evaluation.

And C++ :)

Python's indentation syntax

[mkcmkc]

Like probably most people, I hated Python's blocking-by-indentation syntax for the first few weeks. The column restrictions kind of reminded me of FORTRAN.

But after the adjustment, I've truly grown to love its spartan clarity and simplicity. I can hardly stand to look at the redundant brace-littered syntax of Java, C or Perl now.

Mike

Generic programming

[LoveMe2Times]

The ability to do generic programming ala Boost is a great feature. Higher level languages are all about better abstractions, and generic programming is the best abstraction mechanism we've seen in general use since OOP. While OOP lets you encapsulate behavior and abstract over interfaces, generic programming lets you abstract over *form*. The significance is in the coupling. Generic programming allows much looser coupling between the writer of the generic library and the user of the library. A nice example is a generic "find" function:

template <typename I, typename V>
I find(I begin, I end, V val)
{
for (I it = begin; it != end; ++it)
if (*it == val)
return it;

return end;
}

And here, you have captured the essence of a linear search. To understand what's going on, first know that I and V are arbitrary types that are inferred (at compile time) from the values you pass when you actually call the find function. For the generic find function to work, there are only a couple of restrictions on these types:

1) I must be incrementable.
2) I must be dereferenceable.
3) You must get from begin to end in a finite number of steps.
4) The type you get when dereferencing I (I's value type) must be comparable to V.

Because of this, you can use the same find function to search through arrays, lists, vectors, maps, sets, strings, streams, and more, even though none of them inherit from each other or implement a common interface in the OOP sense.

Additionally, there's no complicated syntax for the user of the library:

int myarray[10] = {1, 1, 2, 3, 5, 8, 13, 21, 34, 55};
int* p = find(myarray, myarray + 10, 8);
if (p == myarray + 10)
cout << "8 was not found." << endl;
else
cout << "The value of p is " << *p &lt&lt "." << endl;

The great thing about abstraction is that it avoids duplication. Avoiding duplication lets you test/debug/prove correct once for greater reliability. Once you wrap your head around this simple example, you'll be surprised how deep the rabbit hole goes.

Re:Dreamed-of feature

[wayne606]

Why in the world would any programmer care about whether they write "if { }" or "if ... fi", etc? I don't see the big advantage in indulging one's personal preferences about syntax. It's not like every person's brain has a completely different way of reading a program that makes it significantly easier to understand a unique brand of syntactic sugar...

Sure, you can develop in your own special IDE that gives you your unique syntax. But don't you ever look at code together with other programmers who might have different preferences? Don't you ever view code published in magazines and on web sites that can't pretty-print to your specification? Training yourself to strongly prefer some kind of private language is not a very good idea.

Re:Many

[Albert Y.C. Lai]

So then the perfect language is one where all the real programmers have done all the work for you, and you're just a little script monkey.

To that I answer by quoting Dijkstra: "if we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent': the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." (EWD1036, page 11)

And so for example even your 10-line, 40-token launcher is too long; its information content can be expressed succintly as "new Webserver(80)" or even "Webserver 80" in any properly designed language.

When electronic calculators came out, accountants did not say "the calculators do all the arithmetic for you, and you are not a real accountant" (or did they?) Similarly for spreadsheet. The reality is, each time they are relieved of a chore, they find a more worthwhile thing to spend their time on, such as analysing various what-if scenerios, which had been intractible until the advent of spreadsheets --- a fine programming language in its own right. I now quote Asimov on the general idea: "The Machines are only a tool after all, which can help humanity progress faster by taking some of the burdens of calculations and interpretations off its back. The task of the human brain remains what it has always been; that of discovering new data to be analyzed, and of devising new concepts to be tested. ... I notice that capable men are still at a premium in our society; we still need the man who is intelligent enough to think of the proper question to ask." (The Evitable Conflict, can be found in I, Robot or other collections)

Textual vs. graphical representations

[Anonymous Brave Guy]

We use graphical interfaces for a lot of things, we should use them for programming.

SCREW the text editor based programming.

I think this is one of those rites of passage all experienced programmers probably go through. At some stage, your experience of different languages gets to the point where you understand that the underlying concepts transcend the syntax of any specific language. A natural next step, particularly if you've seen the sort of parsing graphs used by compilers, is to assume that throwing out the "awkward" text syntax in favour of some whizzy graphical scheme will make things much easier. Some people have even done PhDs on this subject.

Unfortunately, when you try it in practice, you find it's not nearly as clear-cut as you thought. Like all that nasty, unnecessary punctuation found in many programming languages, it turns out that using a concise, precise text format is often far easier both to read and write than any graphical alternative. What can be done in one line of regex in Perl takes a whole screen of graphical representation via flow charts and state machines.

I wish you luck in your exploration of graphical alternatives, but I'm afraid the odds are pretty heavily that after a while, you'll come full circle, and understand that all that nasty "bracket crap" is there for a reason, and has survived for decades because that reason is sound.