I want to make up a program language and write some code for it. Maybe I can use ANTLR for syntax checking. What I want to know is what features of a programming language you like? I'll start with a few:


+6  A: 
  • Robust Macros (see: Common Lisp)
  • Perl/Ruby's regular expressions sugar
  • Continuations (though I'm still learning about them)
  • The ability to compile to native code with any/all required libraries included (I have a heck of a time distributing Perl or Lisp code to random people.)
I second macros. At least two of the bullet points in the original question could be implemented with full macros: templates and "compile time functions" (i.e. the purpose of a macro minus code output)
Chris Smith
+13  A: 


Otávio Décio
interesting... reflection is a nice feature; but seems not to be needed on dynamic languages. maybe it's just a hack to overcome some limitations of static languages?
Reflection allows you to do meta programming, where your program behaves according to your struct/class definitions. I use it a lot in C# and never thought of it as a hack.
Otávio Décio
Reflection combined with Attributes can be powerful, a classic example for me is a DisplayName attribtue on Enum members. When showing the enum to an end user pull the text from the attribute.
@[Javier]: if you look under the hood you'll likely find that your favorite dynamic languages rely on reflection to work at all!
Steven A. Lowe
@[Steven]: i'd say that it's more like the whole 'dynamism' of those languages can be thought as a pervasive introspection; but in fact it's just a simple case of using the same structures for your program and for the language.
+3  A: 
  • C# auto-properties (public int Foo { get; set; })
  • async { } in F#, that automatically makes closures for asynchronous code
+1 for properties in general. Sometimes we forget they aren't available in other languages. I'm looking at you Java.
Cameron MacFarland
  • closures
  • continuations
  • make dict.field syntax sugar for dict['field']
  • nicer dictionary constructor syntax (Lua is the best I know)

I must add that Python lists/dictionaries aren't so nice; I'd like to see them as a much more basic construct, and then higher-level ones (that would be roughly on par with Python's) built on top of them.

+1  A: 

For C#: Delegates and lambdas and on a close second: generics. Interfaces are really nice as well.

For Perl: Implicit variables which makes the plain vanilla cases really simple to implement and of course regexs.

C++: Const references.

Brian Rasmussen
+21  A: 

Lambda functions. More generally, making executable code a full-fledged object in the language as per Lisp.

Mark Brittingham
+1 Totally agree on that. Just started to dig in functional programming and am totally impressed how elegant they are and how they result in less bloat.
Helper Method
+3  A: 
  • Compile-time static type-checking (preferably Haskell-esque).
  • Arbitrary precision arithmetic as a language feature, not an afterthought.
  • Write Once Run Anywhere (Java-style)
  • Literal syntax for maps and lists (like Python, unlike Java).
  • Tuples
  • First-class functions.
Dan Dyer
i have mixed feelings on your list: i don't like static types, not even Haskells. arbitrary precision is great. portability is good, but java did it wrong. syntax for data constructors is important, but Python's isn't the best
+10  A: 
  • Deterministic destructors (as in C++)
  • Static type system with type inference (Haskell, ML, Boo...)
  • Built-in high level concurency support (Erlang)
  • Modules (Ada, Modula-2)
  • Ability to expose "C" interface to other programming languages (C++, Objective-C)
  • Type-safe containers (C++)
Nemanja Trifunovic
I'd vote different ways on these - some up (concurrency, modules, type safe containers), some down (C interface, deterministic destructors).
+4  A: 

Very long compile times, so I can drink more coffee.

Ideally, the compiler should have to use a web service to verify something in each module.

So should the debugger, there's nothing better than staring at the debugger for 10 minutes while it says 'downloading blahblah.c from'.

And limit namespaces to 4 characters so there's not so much typing. 2 characters would be better.

Oh wait, you said features I like. Nevermind.

Steven A. Lowe
long compile times - yeah: life was pretty relaxed, when we had to deliver our pack of punched cards to an operator and wait three hours to get the printout from our batch run...(I once dropped a pack with a chess program; it had no card-numbers in column 1..5; I had a lot of time then...)
+2  A: 

List Comprehension

+1  A: 
  • for each with nice clean iterators
  • functions as first class variables
  • dump complex variables to text with introspection
  • nice constructors for array, struct, map, etc.
+6  A: 
  • The ability to extend the language using built in structures.

  • Keep the core minimal and let the users evolve the language by adding various libraries on top.

For example, Smalltalk does not need the standard if/then/else construct in the language. IfTrue: is just a standard message the boolean object accepts.

Ruby carries Smalltalk's tradition but is less extreme in this case (e.g., you do have a built in if() construct but each() is a simple message replacing the traditional for loop).

Another example is the nice design of Scala.

can you give me a link to something that describes or example code for extending a language.
seconded, most nice languages (Lua, Lisp, Forth) are really small at the core but boundless. Even C is a case of a simplistic language with huge libraries, unfortunately the language itself can't be expanded so easily. OTOH, see Python (still nice even if huge) or JavaScript (small and ugly)

Static semantics for determining program halt given some parameter.

I could really use that. Lemme know.

Nicholas Mancuso
A language that solves the halting problem?
Well, as I tell my kids before xMas: you may wish whatever you like - but not all wishes will be fulfilled ;-)May I wish for another checker, which given my program tells me if that is what the customer wanted ?(better yet: writes the program for me ?);-)))
I guess my humor is too dry. I didn't think anyone could possibly take me serious.
Nicholas Mancuso
+2  A: 

What I like about VB.NET:

  • Verbosity (I find the verbosity refreshing, and easy for interns to read.)
  • Active sentence like structure (even to the point of its potential "left-hand aligned" nature, where nearly any line of code can have a primary identifier on the left hand side that quickly identifies the very essence of what it does, such as the otherwise unnecessary "Call", "Dim" etc... statements.)
  • Obfuscation of most aspects of garbage collection, which downright spoils you when you have to go back to non-garbage collected higher level languages.
  • A good mix between potential for Rapid Application Development and powerful features previously denied to Visual Basic (such as multithreading).
  • The fact that it, in an overwhelming majority of cases, can perform all of the tasks that C# can perform.
  • The ability to better implement object-oriented designs (as opposed to VB6).
  • Easy and intuitive container objects.

What I like about VB6:

  • Utterly Rapid Application Development in a visual environment. Nearly any utility that I need to make quickly is still written in VB6 as a result, even after having learned Python. For "singular purpose" windowed programs that perform potentially complex tasks, VB6 can be extremely quick to write for.
  • Active sentence like structure (see above)
  • Verbosity (again, see above)
  • Even easier and even more intuitive container objects (even than VB.NET).
C# is, to some extent, VB.NET for people who hate the verbosity.
David Thornley
+4  A: 
  • S-expressions: completely uniform, unambiguous syntax.
  • Generic functions: which function gets called is not dependent on only the type of one of the call's arguments, but on all the involved types.
  • Support for functional idioms: functions as first-class objects, tail call optimization
  • I like dynamic typing, with the option to declare types at specific places for efficiency.
In other words: Just use Common Lisp. :)
Um, yes. But the way is the goal :)
I agree: having no syntax but pure semantics makes many things so easy.
+2  A: 

I like properties. They are just nice, simple things that make my life easier.

+2  A: 

My favorite is a real compile-time metalanguage like the one in D. C++ templates were a cool start, but having a full compile-time meta-language that supports simple constructs like tuples and static ifs natively without hackishness, and allows compile-time code generation via string mixins is unbelievably useful.

Learn Common Lisp and use macros for compile-time full-scale language.
David Thornley
+1  A: 

Don't forget for loops:-)

  • Anonymous delegates like in C#.
  • Currying and the other functional programming features.

Multiple interface inheritance and operator overloading in C#.

Edit: And how could I forget delegates. Delegates are awesome.

+7  A: 

I'm a big fan of variables. They're just the cat's meow for me.

Although variables are wildly popular, they don't exist in languages like Brainfuck.
Or FP (by Backus)

Generics, Easy data sync and manipulation.

Sara Chipps
can you explain this? Generics i assume you mean templates, dynamic variable or the auto keyword in a static sense. Easy data sync and manipulation i am clueless about

I like Objective-C's messaging system (borrowed from Smalltalk). Rather than calling a function of an object you send it a message instead.

[myObject saveToFile:"/tmp/test.txt/"];

[anotherObject asdfasdfasdfasdfasdf];

If an object doesn't respond to a message the runtime raises a trappable exception. In theory this doesn't have to be much slower than externally linked function calls.


PAGE_EXECUTE_READWRITE for fixing Microsoft's bugs.

Now why can't I have something similar in .NET?

+5  A: 

Give my carry/overflow flags back you damn HLLs... Oh wait, it is a machine feature not a language feature. Whatever, I still want them back...

I second this. Also, I want my high bits from doing a Nbit*Nbit ->2Nbit multiplication.
i LOVE carry/overflow. I always wished that a language would support those.
I am not sure if you really mean: transparent arbitrary precision arithmetic...

C# Object Oriented features would be on top of my list... Inheritance, overloading, generics, delegates, etc.

For the IDE, Visual Studio is pretty much perfect for me (intellisense, bracket highlighting, line numbering) except for the counter-intuitive Document Tab ordering (SDI) starting with Visual Studio 2005.

For MS Reporting Services (2005/2008), Microsoft should include a full blown editor for Reporting Services Code Modules, and while they are at it, allow languages such as C# to be used in addition to VB.NET.


It's funny for almost every feature I like, I can see a downside.

Duck typing is really nice, but it can sometimes lead to confusing method signatures (at least the way Python implements it).

C#'s lack of checked exceptions is nice, but the code isn't as self-documenting as Java checked exceptions. Unless you have a disciplined coder, you won't know some of the exceptions that the method may or may not throws at you.

Ironically both of my issues here can be solved by better documentation, but whenever you rely on a programmer to document more, there are always going to be people who won't.

James McMahon
+1  A: 

This is a bit radical: everything should be an object. Even integers and dates!

.NET Nullable Types are a step in the right direction. I know there are performance reason to use Value Types but why not give them the special designation and make int? datetime? the default and use int# and datetime# for the real value types.

Christopher Edwards
+6  A: 

LINQ! Probably one of the most useful features I've seen implemented.

Plan B
nice as it can be, it belongs to a library, not to the language core. now, having it as standard from the start sounds great...
kind of hard to draw the line on this one: the .net languages have language extensions introduced just to use the LINQ stuff (from c in Customers select c, etc.)
I don't really understand why people think LINQ is so revolutionary. I try, I really do, but I rarely seem to find an appropriate situation to use it.
James Jones
+1  A: 

The ability to "design by contract" (as in Eiffel, while I'm a C, C++, C# programmer, by the way).

No more assert left to the programmer ! Hey, for each and every method, you have to tell the compiler :

  • What are the invariants in input (eg. : 0 <= x <= y )
  • What should be your initial object state (eg. : xyz is not null)

No assert, all is already build in the language. Great great great ! Take a look at this if you can.

+1  A: 

Single Assignment to variables. Some languages have it by design, like Erlang. Other languages don't enforce it but you can make use of it. When writing Java code almost all local variables, and a fair share of instance variables, can usually be declared "final". Do it and your code will be more clear and much easier to understand for others.

+2  A: 

I like languages which make constructing functions quick. If you compare the overhead in Java to the overhead in Forth, you can understand why people write so many functions in Forth.

A very trivial example:


public static int add2(int input) {
  return input+2;

and in Forth:

: ADD2 2 + ;
yeah, but who would write an extra function to add 2 ?Things look different when things are non-trivial (I wrote an nroff-like text-processor in forth once... I guess, I spent 80% of my time deciphering which value is at which stack position...)

Whenever I am not using Perl, I miss this:

my $var = findSomething() or die "Can't find something";

Throw an exception if findSomething() didn't return anything. Simple and concise.

Mathieu Longtin
+1  A: 

I'll mention just one feature, because I think it's overlooked in almost all language design: good support for programming with discriminated unions, including a case statement that operates by pattern matching. F# or Standard ML would be good models.

Norman Ramsey

Having a compiler run ten times faster is at least ten times better than having ten new features.

Norman Ramsey
and you can spend 10 times longer writing it too.
George Mauer

For C++ this is the RAII idiom. And const references of course.


QT style signals/slots.

Proper value types like C++ has.

  • Seamless first-class macros - R6RS
  • Multimethods - Common Lisp, Dylan
  • Encapsulation on module level rather than class level (you need this for multimethods) - Common Lisp
  • Well-designed multiple inheritance - Eiffel, OCaml
  • Clear separation of contract (interfaces) and implementation (classes) - Sather, OCaml
  • Following from the above: clear separation of inheritance and subtyping - OCaml
  • Design by contract - Eiffel
  • Effect typing - ?
Pavel Minaev
  • ?: Operator
  • Anonymous types
  • Object initializers, and collection initializers (C#)
  • Extension methods
  • yield keyword
What do you mean by Object initializers, and collection initializers? is this c++ styled constructors? \
nop Object initializers let you assign values to any accessible fields or properties of an object at creation time without having to explicitly invoke a constructor more details :
Don't forget the `??` operator.
Joey Adams
+1  A: 

Features that let you store data in one place and use it throughout a program. You can just change it in one place and have that effect the entire thing.


  • Constants
  • Inheritance
  • Modules
+3  A: 

Look hard at Haskel, Modula2, Modula4 and even Pascal.

Many of the new languages (I am a fan of Python) are fragile because they are too free with data.

Languages like Fortran can be well supported by compiler optimizations. C, C++ are much harder to optimize safely.

If you want the program to be correct, fast and robust the language needs to tight and unambiguous.

Python is marvelous in how it grafts well tuned and well crafted "C" code into the libraries.

+3  A: 

Without a shred of doubt, Garbage Collection. Every time I have to code something in C++/C, I realize again how big a life saver it is.

Without it, I just waste so much time one the meaningless tasks of:

  1. Allocating memory
  2. Remembering to deallocate memory
  3. Thinking about the concepts surrounding memory in my modules (ok, so this module allocates the memory, this other module releases it, etc).
  4. Thinking about how memory allocation works in outside modules (i.e., understanding that to call a Win32 API function, I need to call once with the flags set to telling me how much memory I need to allocate for strings, another time with flags saying I want the string).
  5. And of course, debugging all the endless mistakes that I'm sure to make.

Every other high-level feature I like would just not be possible without Garbage Collection freeing the burden of memory-management.

Edan Maor