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:anonymous inner classes

[Bazzargh]

Java's inner classes (anonymous or named) are not even first class! (Try coding an inner class that refers to a non-final attribute in its enclosing scope.)

This isn't quite right. First off, they are first class, and you can refer to a non-final attribute from a named or anonymous inner class. What you can't do is refer to a non-final local variable from an anonymous inner class.

The intended effect is similar to closures - variables referenced from the enclosing scope have the value when the closure was instantiated (see, e.g. Scheme) - except that unlike scheme, you can't modify the now-private copy. If you want a modifiable copy, you just make one, like so:

final finalFoo = foo; Object bar = new Object() { private myFoo = finalFoo; // myFoo now acts as 'foo' would if this was // *really* a closure. }

I'd agree that the construct sucks. I'd rather be in a language with closures myself.

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.

Many

[Apreche]

First off I like nothing more than automatic memory management. Being able to forget about pointers and malloc and all that garbage makes programming infinitely easier and faster. I only write in C or assembly when I really really need the speed or when I'm at such a low level that nothing else is possible.

Next I love ruby's block system, especially for stuff like this.

myarray.each { |e| puts e }

It comes in super handy for a ton of stuff. Especially when I'm doing XML.

Also, there is another thing that I first discovered in python

x, y = y, x

Save me a temporary variable, w00t.

Lastly, its not really a language feature, but in any object oriented language I love being able to serialize the objects. It's so simple to use pickle or any other serialization library and just write objects out to file or network. I never have to design a binary file format ever again. It's even better when you use Ruby and you can marshall objects into XML or YAML with a single method. Then you've got a human readable and editable file format that you can magically transform into objects again later. Super useful.

Re:Many

[PSUdaemon]

x ^= y
y ^= x
x ^= y

bitwise, no overflow worries...

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)

Dreamed-of feature

[Dr. Weird]

This is less of a favorite feature, and more of a feature I wish we had. What about having the representation of the language independent of the code itself? I think this will eventually happen and could really revolutionize things. I believe the inklings of separating 'physical' representation from the code were there in some languages like Algol 60 and CS work in the 1960's, but it never caught on (perhaps hindered by other features of those works?).

In a little more detail, suppose I write a C program. It will have lots of functions and conditionals with their "blocks" surrounded by braces.

But what if I prefer my "blocks" to be started and ended by brackets instead of braces. Better yet, what if I am tired of typing these and would like indentation to control this. Or whatever -- start end commands, if you like. The point is that these are minor sytactic idiosyncracies, and we all have preferences. Why not store the code in an underlying format (XML would be okay, were it not for the bulk of it)? As long as there is a one-to-one correspondence between all possible representations, you could view it however you want.

And so on for all syntactic features. Prefer "if-fi" construction to "if () {}"? Or "if ... then ..."? Better yet, really like Perl's "$_"? If you want it to be displayed like this, turn it on. Otherwise, say you don't like this feature, and it will automatically replace the "$_"'s (either implicit or explicit) with the variable to which it refers. Again, no problem.

At this point, I feel like I am repeating myself, but let me continue for a little bit. It would let each user have his/her personal favorite representation. We already let them control the colors of their syntax highlighting, lets take it a step further.

Hell, if you want to use a graphical viewer for those C programs, akin to LabView, go for it! Or (in my opinion) a much better graphical programming environment with a graph structure. The point is: you write it how you want and save it. It appears to another coder how he/she wants it to appear, but the content is exactly the same.

In short: why isn't this done? It seems like a spectacular step in unifying programming languages a bit, and letting each user tailor his preferences while maintaining compatibility. As long as there was simple one-to-one correspondence, the translation from physical representation to underlying code and back would be quick and fairly easy to handle. Are there any modern projects which attempt this? Or *any* which attempt it with some success?

On a somewhat related note, is it possible to put a "hook" to a comment in the code, and with the proper viewer have that comment displayed along with the code (say when you click the "hook", move your mouse over it, or drag the "hook" to a "comment box")? If this last paragraph doesn't make sense, please ignore it.

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.

Favourites

[E_elven]

Ruby blocks, lambda functions, lazy evaluation.

And C++ :)

C pointers and arrays

[Quill_28]

Just to confuse people do this:

main() {

int x;
int y[2];

x=1;
y[1]=10;

printf("%d\n", y[x]);
printf("%d\n", x[y]);
}

What will happen?

Re:C pointers and arrays

[ComputerSlicer23]

As I recall, in C x[y] and y[x] are defined to be identical. I believe you can do 1[y] and have it work. That's because a[b] is must be identical to *((a) + (b)). I'm over using paranthesis intentional. Because addition of a pointer and a constant is communitive, either one works. Because (1 + y) is a legal, and returns a pointer it works.

Personally, I think it's a completely crappy thing. You should get an error telling you: "Attempting to use a constant like a pointer".

So it should print out "10\n10\n";

If that's an ANSI C complier: you should get a warning about no return in main, an illegal declaration of main, and an unknown function printf. You might get away with main, because I believe all functions implicitly return an int.

Kirby

Re:C pointers and arrays

[Quill_28]

You are correct. Thee compiler just sees memory.
The x could also be a double.

double x; won't change a thing

One another interesting thing:

the x[y] line compiled into assembly(using gcc non-optimized) will use less lines of code than y[x]

Optimized they use the same.

Learning this stuff actually gave me a much better understanding of pointers and arrays and their relationship in c.

Self-execution

[BollocksToThis]

My favourite thing is languages that can execute strings of their own code.

For example, clipper can do this via blocks:

cVar := &("{ || nVar += 43")

Python has the same thing via "exec":

>>> b
NameError: name 'b' is not defined
>>> exec "b=2"
>>> b
2

This means you can build up strings of code at runtime and execute them, or store field-specific database logic in another database table, and fetch it when needed.

C# is not quite so convenient - you have to build up a complete class and compile it, but it can all be done in memory at runtime so it's just a little more work. Clipper and python can both affect the current scope directly (which can be both bad or good, I suppose).

I believe ruby has blocks similar to clipper (probably better), but I don't use it, so I'm not sure. I also don't use perl, so I have no idea if it supports this...

Several:

[twem2]

Functions as first class citizens, that is functions can be returned from functions and provided as arguments as functions. The basis of the functional paradigm and it makes life much much simpler.
Pattern matching (some ML:)

fun has_a [] = false
| has_a 'a'::_ = true
| has_a _::xs = has_a xs;

Simple elegent functions requireing much less if_then_else's.

Automatic garbage collection and bounds checking: enables me to write the code to do the job, not the memory management.

Polymorphic typing: I can write general functions:

fun contains x [] = false
| contains x x::_ = true
| contains x _::xs = contains xs;

That will work with any type for which equality is defined.

These are the reasons I hate C for general programming. The most important thing is efficient algorithms, without them no amount of low level optimization will help. With good algorithms, functional languages are now normally at least as fast... (and much much easier to debug and even verifiable).

From non-functional languages, the object model is wonderful when used properly.
Smalltalk & co's complete environment is a nice feature.

I also have a soft spot for BBC BASIC with its speed, interactivity and simplicity. These are combined to allow windowed applications including at least one web browser and anyone can start programming simple programs (which is missing from most modern computers)

Then there's the specialist languages. They have all sorts of nifty features (Mathematica is a good example) but I wouldn't expect them in an everyday language.

Two words: string handling

[Fished]

This is not the issue it was ten years ago, but one feature I absolutely want tightly integrated into my language is robust string handling. I still like perl's best (although perhaps only because I know it best). It simply seems to be more tightly integrated into the language as a whole.

This "ask Slashdot" is a concurrent "cross-post"

[Paul Bain]

The poster, johnnyb, also asked this question on Advogato just a short time ago. It will be interesting to see the differences in the comments made there and the ones made here at Slashdot.

Hey, johnnyb, where else have you posted this question? When you get answers, will you analyze them and post your conclusions? It could be interesting.

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.

Perl's taint mode

[babbage]

In the current issue of ACM Queue, Marcus Ranum makes an interesting case for Perl's taint mode in his article Security: The root of the problem -- Why is it we can't seem to produce secure, high-quality code?:

Right now, the state of the art in software security is to pass your code through some kind of static source-code analyzer such as ITS4 or Fortify that looks for dangerous practices and known bugs. That's a great start, and, according to my friend Gary McGraw--chief technology officer of Cigital and author of several books on software security--who works with the stuff, it catches a significant number of potential security problems. But, as you can see, the compiler already knows a lot of what it needs to in order to make a good stab at determining what is being done wrong.

One really neat concept is embodied in the Perl programming language--tainting. The idea of tainting is that the interpreter tracks the source of data and turns off dangerous operations if they are called directly as a result of user input. For example, when you're running a Perl script in taint mode, it turns on a lot of error checking before passing user-provided data to certain system calls. When you try to open a file for write using a filename that is tainted data, it checks to make sure the directory tree ownerships for the target directory are correct and that the filename doesn't contain "../" path expansions. In other words, the runtime environment tracks not just the type and value of the data but also its origin. You can imagine how nice this capability can be for writing server-side code or captive applications.

Unfortunately, few programmers use tainting because it imposes an extra burden on the programmer, and it's sometimes difficult to figure out a secure way to get the job done. But what if we built tainting-type capabilities right into our runtime environments for C/C++? A simple high-value approach might be to modify I/O routines (read/write) to determine if they are connected to a socket from a remote system, and to do some basic checks on data coming across it, such as checking to see if the stack is altered across calls to certain functions following I/O.

Ranum is citing this as an example of a way that existing tools -- such as GCC -- could be enhanced in such a way that programmers using currently popular languages (C/C++) would have a better security safety net without having to be retrained in practices (like checking for buffer overflows) that while obvious are still under-utilized in most software. The whole article is interesting reading, but this remark about Perl's taint mode seems like one of the best concrete examples of a modern protective language feature.

Don't bash C++

[Chemisor]

> #1 Garbage collection. a.k.a. automatic memory
> management. Not very sexy, but by far the single
> biggest productivity boosting feature of any
> language. I hate housework. It is just a waste of time.

Garbage collection does not free you from memory management. It simply converts one kind of problem into another: namely it eliminates accesses of unallocated memory, but it creates memory leaks instead. The thing is, it is not always easy to figure out when you no longer need a block of memory. That's with garbage collection it is supposed to be good practice to "free" your pointers anyway, by assigning NULL to them. Why they can't just use STL containers instead, I don't know.

> #2 No pointers, no buffer overruns, no memory
> corruption. Related to the first point. Memory
> corruption is just so hard track down. You can
> keep your pointers

You won't have any memory corruption if you don't use arbitrary indexes to access your arrays. For example, when iterating over a container, you run your iterator from ctr.begin() to ctr.end(); no corruption possible. The other cause of memory corruption is using unverified data to directly access your arrays. That happens when you ask the user for a number and then use it to index; this is wrong in so many ways, I can't even begin to list them all. Verify your data, and you will not have any data corruption.

> #3 Stack traces. Not a language feature per se,
> but it takes a lot of the drudge work out of
> debugging.

#include
backtrace_symbols()

> #4 Python's 'for' loop for iterating over the
> contents of a list or array:
>
> for thing in myarray:
> mutate(thing)

#define foreach(t,i,c) for(t i = c.begin(); i #5 Dictionaries, a.k.a. associative arrays. It
> just makes a lot of problems much much simplier
> and faster to solve.

map m;

> Sure, most other languages
> have dictionaries available as a class, but when
> they are seamlessly built into the language you
> use them as easily as any other primitive '
> datatype.

You can use map as easily as any other primitive data type of the same category: as an array.
m["january"] = 31;
cout "january has " m["january"] " days" endl;

Don't confuse people

[Chemisor]

Just because you can write it that way, does not mean you should. Should you blame makers of underware for letting you put it on over your clothes? Just because Superman can do it, does not mean you should.

Re:This "ask Slashdot" is a concurrent "cross-post

[johnnyb]

Actually what I'm wanting to do, eventually, is write a book about great programming constructs people have probably never heard of, or don't understand well.

My last book took me 3 years to find the spare time to finish, so I don't suspect I'll have this done anytime soon.

I was originally going to just analyze scheme's features, but then I realized that many languages have features that need to be recognized, too. my original outline was going to be:

* Memory Management
* Symbolic programming - an intro to Scheme
* Functional Programming & Functional Programming Patterns
* Closures and higher-order functions
* Advanced Flow Control w/ Continuations
* Compile-Time programming 1: Macros
* Compile-Time programming 2: Partial Evaluation
* Compile-Time programming 3: C++ templates
* Lazy evaluation
* Lazy data structures

However, if I decide to open it up to other languages, I have no idea how I'm going to organize it or even how I will decide what to include.

Anyway, it was originally posted just to Advogato, but then I remembered that the only threads on Advogato that get any real response are flame-wars, which is sad because Advogato could be a real cool place. Then I thought "you know, this would make a good 'Ask Slashdot' as well. However, I don't expect the quality of responses on Ask Slashdot to be as good, although I expect there to be a LOT more of them.

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.