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

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.

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.

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

[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.

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.

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.

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.