Favorite Programming Language Features

Posted 7 Jul 2004 at 19:05 UTC by johnnyb

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.

A couple of examples to kick off the conversation: 1) 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. 2) Tuple-returning It is a huuuuge time-saver that languages like Perl allow functions to return tuples. ($a, $b, $c) = $sth->fetchrow_array() is a wonderful time-saver. 3) The flip-flop operator Another perlism that I just think is cool. Read more about it here: http://www.perl.com/pub/a/2004/06/18/variables.html Okay, on to yours. What are your favorite programming language features?

Metaprogramming, posted 7 Jul 2004 at 19:56 UTC by chalst » (Master)

With things like continuations, higher-order functions, logic variables, etc. I value the expressivity that comes with them, but there are times that the inevitable assocaited runtime and its sometimes difficult to predict overhead are unwanted. What I find impossible to excuse is depriving the programmer of decent metaprogramming facilties. The C++ template system is probably the most widely understood facility, although it is underpowered by contrast to LISP/scheme macros (you can use them in a runtimeless language: Richard Kelsey's prescheme). The most underappreciated metaprogramming system, I think, is that of Prolog. The nicest neglected avenue I know of to layering high-level features on a runtimeless language was 'C. Alas, now abandoned and mostly unnoticed.

straightforward OO stuff, posted 7 Jul 2004 at 20:06 UTC by lkcl » (Master)

my favourites? honestly?

straightforward object-orientated inheritance. i love to think about where the common ground is, where the critical flux points are, and then to partition things off in ways that make the implementation and use of each component a heck of a lot simpler, so OO inheritance is at the top of the list.

operator overloading (although this isn't everyone's favourite because they tend to mangle its use by not THINKING. operator overloading should only be used in intuitive ways, e.g. for +, * etc on a vector class!)

i especially like, in c, using tables of function pointers to define an API (with the implementation being in a dynamically loaded library with only one published function, which returns a pointer to the table).

i definitely like python's use of indentation to indicate blocks of code. whilst that makes for minor inconvenience in having to think of ways to code around the lack of a repeat until construct and the lack of a do while, the "tidy" look enforced upon programmers by the indentation makes for much easier code reading: you _know_ what to expect.

definitely tuples. c and c++ are _such_ a pain in the arse having to code up a pointer to parameters or a structure or use references, instead of being able to return multiple results. the introduction of const was very fortunate but a little too late, there: at least in ADA they got it right by requiring that you specify IN, OUT or INOUT on the parameters. by not being able to return tuples, and by not having IN or OUT on the function parameters, you get no assistance from the compiler in validation of what parameters were thingied. you know what i mean :)

so, yes, ADA's IN, OUT and INOUT parameter clarification - not that i've _used_ ADA but [in] and [out] are in DCE/RPC where it is utterly necessary to have in order to save network bandwidth. python's import system, and the fact that you can overload it (!) to provide your own importing - e.g. from a database, on a per-server basis (!) as i once implemented for a remote server management system (!) uhm, i'm sure that there are more, but hey :)

named parameters, posted 7 Jul 2004 at 23:58 UTC by brondsem » (Journeyer)

I've only used smalltalk some, but it's named parameters (as opposed to ordered parameters) were nice. I think, however, that some functions are better suited to named and some better suited to ordered.

Mostly OO stuff, posted 8 Jul 2004 at 03:37 UTC by abg » (Journeyer)

Good question, btw. After spending a few years doing Python work, I really, truly miss simple structures like dictionaries and lists in other languages. (VB, with it's promise and subsequent botching of same, is particularly heinous in this regard) If I have to write another set of linked lists, I swear I'll start shooting machines.

in other languages. (VB, with it's promise and subsequent botching of same, is particularly heinous in this regard) If I have to write another set of linked lists, I swear I'll start shooting machines. Garbage collection , for that matter

, for that matter Simple IO, type conversion (especially for dates), and polymorphism are day to day things that a language should do well.

are day to day things that a language should do well. Named parameters are good for maintainability, predictability, and readability, but a PITA to write code for. And yet, I still love C, which does none of this.

I love the way that BCPL deals with the dangling ELSE porblem. For the uninitiated, this is the problem of IF a THEN IF b THEN c ELSE d - does the ELSE d belong to the first IF or the second one? Many languages take the approach of IF a THEN b [ ELSE c ] FI; i.e. has a terminator for the IF. BCPL takes the approach that you have a choice of verb: either you can say IF a THEN b or you can say TEST a THEN b ELSE c. i.e. IF may not have an ELSE; TEST must have an ELSE. That is all.

Data types, posted 8 Jul 2004 at 14:02 UTC by Platypus » (Journeyer)

I'll cast another vote for built-in data types like lists and dictionaries. It seems like such a small thing, but it makes a huge difference in the tedium level of programming for a wide variety of tasks. Besides being able to slice and dice them and initialize them inline (unlike what you get with mere operator overloading) they make it trivially possible to return multiple values from a function. Second favorite would be exceptions. Sure they can be (and very often are) abused, but limiting the code for an error to the place that detects it and the place that handles it, without every intervening level needing to propagate error codes (meaning that you can't use the error code for something else, which is particularly annoying without the capability of returning a list) can make code much more readable.

I don't see designing a programming language as analogous to building a white-box computer: picking lots of components and sticking them together. My favorite programming languages all express a coherent view of programming, and implement that reasonably cleanly. That said, one of the features I'd vote for is integration with other languages, particularly low-level ones like C. The most important programming these days isn't building monolithic apps, but rather modules that exist in a larger ecosystem. I've been particularly happy with writing modules for CPython. To a large extent, combining C and a dynamic programming language creates an aggregate language. I think it makes sense to consider the quality of this language. Are the semantics well defined? Can a debugger reasonably trace across langauge boundaries? Is the build process straightforward? In practice, the answers to these questions are often disappointing, but I don't think it has to be that way.

Destructors, posted 8 Jul 2004 at 18:46 UTC by ncm » (Master)

Only one language I know of makes it possible to encapsulate resource management. (Many otherwise-powerful languages fake it as well as they can using "with-foo" macros, but that just doesn't go very far. They build into the runtime astonishingly complex apparatus just for managing memory, and leave all other resources to be managed manually, little better than must be done in C.) Therefore, my vote goes to destructors. "Object-oriented" features -- most particularly, virtual functions -- turn out to be of secondary importance, and I would like to see if they couldn't just be moved into the library. (Certainly they shouldn't be anybody's default!) Explicit support for "thunking", and tail recursion, delegation, and programmed conversions, along with powerful generics to tie it together, might suffice. While we're at it, we should list language features we hate. I hate default automatic conversions and other invisible bug generators. I hate features or semantics that work on built-in elements but cannot be made to work the same way for equivalent user elements. I hate shovelware features that don't earn their keep, or that make it easier to do what shouldn't be done at all, or that make it impossible to implement more valuable features, or that make implementations unavoidably slow. I hate features that make it easier to solve trivial problems, but that make it even harder to solve hard problems. I hate core language features that could just as well be implemented in the library, particularly when trying to do that exposes a language design failure. I hate most those features that the language designer didn't understand, but put in broken so that code using them is even worse than code that doesn't. I hate ideology and haste.

auto type conversion, posted 8 Jul 2004 at 21:24 UTC by deekayen » (Master)

I like the the idea behind the auto variable type conversion in PHP.

Safe by default, posted 8 Jul 2004 at 21:57 UTC by guerby » (Master)

That means at least by default the language mandates array bound checking before access and allows for GC or reasonablu foolproof memory management. C and C++ both fail this, and we get insecure software all over the place. Hopefully most other languages pass the check, and they do gain a lot of mindshare: a few years ago at work everyone was talking C++, now they're talking Java, C# and scripting which is good news, C/C++ is totally legacy. Another feature I see has a must-have is a free software implementation with commercial support available. Having a real standard and a freely available validation suite also helps. I believe Just In Time compilation and dynamic languages are the way to go. I'm more functional in my approach, that excludes your typical "OO" program with state changes all over the place. At work I use Ada with paid Ada Core Technologies support and Python, no support yet don't know if it exists since I started one month ago. Laurent

general, posted 9 Jul 2004 at 01:06 UTC by mslicker » (Journeyer)

Formal definition

I find important formal syntax and semantics. A language specification should not be written just for implementers but also users of a language. You should know precisely what sentences are valid and their precise meaning. Focusing on a consise readable specification may improve the language as well. Simple syntax and semantics

I think 1. implies that a language be simple to define as well as understand. Classic games have this property "minutes to learn a lifetime to master", programming should be fun and game-like. Extensible

I like the idea of that a simple core can be extended to suit different tasks. There is an unlimited number of "features" (semantics) one might want to implement, putting all of it (or much of it) in the core makes a language more difficult to learn, and potentially cumbersome to use.

Language Features, posted 9 Jul 2004 at 07:51 UTC by nymia » (Master)

Not sure exactly what features belong to the language, the example seem to be saying features of the runtime as well. I would imagine the article was asking about features that a language provide are the following:



Declarations - Pascal and COBOL reminded me of how storage should be explicitly stated at the earliest possible opportunity. Code written this way tend to look cleaner and easier to read. Expressions - C++, C# and Java are definitely the winners for this one. Personally, I prefer simple/basic expressions that do type coercions by default. Sort of like Basic with a twist of Pascal. Data Types - I'm a big fan of user-defined types, mostly found in object based environments, though. I'd prefer grouping related identifiers and then putting a big label on top of it.



Runtime Features I like most:



A facility for externs. Automatic conversion when marshaling types. PInvoke, eat your heart out. A fully-working-breathing-living DOM! Runtime Features I like most:

interactivity, posted 9 Jul 2004 at 14:23 UTC by mwh » (Master)

Mainly because noone's said it yet, I'll drop in a word for interactivity and introspection. Other than that, well, a lack of cruft, a sense of letting me get on with whatever it is I want to be doing. I agree with ncm's condemnation of automatic coercions and the like.

oh, and..., posted 9 Jul 2004 at 14:24 UTC by mwh » (Master)

having a good and healthy community! Not exactly a "programming language feature", but very, very important.

My Favourite Features, posted 10 Jul 2004 at 17:20 UTC by shlomif » (Master)

Here's a roundup of some of my favourite programming language features. These are basically Perl features that I miss in C or in Python; Haskell features that I miss elsewhere; Matlab features that I miss elsewhere, and perhaps other random bits and pieces. Garbage Collection (or Managed Programming) - Joel Spolsky believes that managed programming is the ultimate productivity booster and I believe he has a point. The ability to allocate any amount of data and not to worry about cleaning it up is a huge improvement over C's malloc() and free(). Garbage Collection proper (i.e: one that can handle reference cycles well) is also something very desirable, that does not yet exist in Perl and many other back-ends. Nested data-structures. In Perl I can initialize a complex data structure in one command, and also handle them very well. In C, it is practically impossible. Multiple return values (like you said). Here documents. The <<"EOF" ... EOF (where EOF is user-speicified) is something I miss in Python, and exists in Perl. I know that it makes the tokenizing harder, but it's still a great feature which saves a lot of headaches. Perl's last LABEL and next LABEL. Enables you to manage nested loops easily. Java has absolutely no way of doing it, because it even lacks C's goto. Lexical scoping and closures. Defining functions inside functions, returning the inner functions which remember the enclosing scope's state. Groovy. Regular expression operations with a convenient syntax. Perl programmers tend to use regexps to do many things that don't really require them, because of their convenient syntax. That was one thing I was criticized for in FreeNode's #python. Some of Haskell's paradigms like accumArray . Bindings for the operating systems services, like files, sockets, etc. (heavily missing in Scheme and Common Lisp). foreach . Unlimited (capacity-wise) strings, arrays, dictionaries, etc. Matlab's bulk operations on tensors. That's just the things off the top of my head. There may be more.

shlomif: Here documents. The <<"EOF" ... EOF (where EOF is user-speicified) is something I miss in Python, and exists in Perl. Do you know Python's triple-quote? Perl's last LABEL and next LABEL. Enables you to manage nested loops easily. Java has absolutely no way of doing it, because it even lacks C's goto. Hmm? Java has break LABEL and next LABEL, they work exactly like Perl's last and next.

Old school view, posted 11 Jul 2004 at 19:44 UTC by ksb » (Master)

I love C's mix of features. The language can be described as 4 parts (the C implementation langauge, the C pre-processor, the C library, and mechanical code generators). C's operator set is only missing "min" and "max" (maybe spelled ?< and ?>). And C's control structure is only really missing the 'else' on loops (like Python). C's has some nits (like x = a/*pb; being half a comment), but these are mostly well-known and easy to find. In fact some of the "weak spots" (viz. varargs) in C make it more useful. Thank about this: the most often reused function ever coded is printf; it is in every smart device built in the last 25 years. Tools like rpcgen, flex, bison, give the C programmer a huge turbo (as CPAN does for perl programmers). That's why every other programming language I see is writen (itself) in C.

The most important feature available in any language is that it not assume that it knows more about what I'm doing than I do. The only language (that I've done serious work in) that has never hit me with "you can't do that here" is C. Of course, this also assumes that I better actually know what I'm doing. I'll leave it to others to offer opinions on that. From a wider perspective, if I chose a language that embodied what I feel is the key element of a language, I'd probably go with SQL (yes, I know a lot of people think it stands for "Scarcely Qualifies as a Language"). I see it as the closest attempt yet to express a pre-existing theory of information handling (set theory in this case) in a complete and consistent way for use with digital technology. In my opinion, the existence of computers doesn't negate the value of several centuries of logic and research on the hows and why's of information management. Other languages have borrowed heavily from the past, but it tends to be rather piece-meal. SQL is the only language that explicitly builds on that tradition. (In the interest of disclosure, I'm actively involved with the Standards Council of Canada, and was part of the group that provided the National contributions for SQL:2000, but I think my reasons for choosing SQL go beyond that) Having said that, I think the best possible language is the one that's most appropriate for the programmer's need. If it lets you do what you need to do and doesn't inflict pain on you in the process, how bad can it be? Cheers.

Ternary operator, posted 14 Jul 2004 at 22:03 UTC by jds » (Journeyer)

By far, my favorite feature in a language is the perlesque Ternary Operator. I dunno where it originated, but I sure like it: Instead of: if (condition) then $x = 1 else $x = 2 endif The ternary operator allows you to say $x = (condition) ? 1 : 2. I like its conciseness. -J

Reply to tjansen, posted 29 Aug 2004 at 13:08 UTC by shlomif » (Master)