What features do you wish were in common languages?

Question

What features do you wish were in common languages? More precisely, I mean features which generally don't exist at all but would be nice to see, rather than, "I wish dynamic typing was popular."

Answer 1

To start things off, I wish the standard for strings was to use a prefix if you wanted to use escape codes, rather than their use being the default. E.g. in C# you can prefix with @ for a raw string. Similarly, Python has the r prefix. I'd rather use @/r when I don't want a raw string and need escape codes.

Answer 2

I like some of the array manipulation capabilities found in the Ruby language. I wish we had some of that built into .Net and Java. Of course, you can always create such a library, but it would be nice not to have to do that!

Also, static indexers are awesome when you need them.

Answer 3

I wish there was a self-reversing assignment operator, which rolled back when out of scope. This would be to replace:

type datafoobak = item.datafoobak
item.datafoobak = 'tootle'
item.handledata()
item.datafoobak = datafoobak

with this

item.datafoobar @=@ 'tootle'
item.handledata()

One could explicitely rollback such changes, but they'd roll back once out of scope, too. This kind of feature would be a bit error prone, maybe, but it would also make for much cleaner code in some cases. Some sort of shallow clone might be a more effective way to do this:

itemclone = item.shallowclone
itemclone.datafoobak='tootle'
itemclone.handledata()

However, shallow clones might have issues if their functions modified their internal data...though so would reversible assignments.

Answer 4

I guess the most obvious answer is Lisp-like macros. Being able to process your code with your code is wonderfully "meta" and allows some pretty impressive features to be developed from (almost) scratch.

A close second is double or multiple-dispatch in languages like C++. I would love it if polymorphism could extend to the parameters of a virtual function.

Answer 5

I've often thought that "observable" would make a great field modifier (like public, private, static, etc.)

GameState {
   observable int CurrentScore;
}

Then, other classes could declare an observer of that property:

ScoreDisplay {
   observe GameState.CurrentScore(int oldValue, int newValue) {
      ...do stuff...
   }
}

The compiler would wrap all access to the CurrentScore property with notification code, and observers would be notified immediately upon the value's modification.

Sure you can do the same thing in most programming languages with event listeners and property change handlers, but it's a huge pain in the ass and requires a lot of piecemeal plumbing, especially if you're not the author of the class whose values you want to observe. In which case, you usually have to write a wrapper subclass, delegating all operations to the original object and sending change events from mutator methods. Why can't the compiler generate all that dumb boilerplate code?

Answer 6

I'd love for more languages to have a type system like Haskell. Haskell utilizes a really awesome type inference system, so you almost never have to declare types, yet it's still a strongly typed language.

I also really like the way you declare new types in Haskell. I think it's a lot nicer than, e.g., object-oriented systems. For example, to declare a binary tree in Haskell, I could do something like:

data Tree a = Node a (Tree a) (Tree a) | Nothing

So the composite data types are more like algebraic types than objects. I think it makes reasoning about the program a lot easier.

Plus, mixing in type classes is a lot nicer. A type class is just a set of classes that a type implements -- sort of like an interface in a language like Java, but more like a mixin in a language like Ruby, I guess. It's kind of cool.

Ideally, I'd like to see a language like Python, but with data types and type classes like Haskell instead of objects.

Answer 7

I'd like to see single-method and single-operator interfaces:

interface Addable<T> --> HasOperator( T = T + T)

interface Splittable<T> --> HasMethod( T[] = T.Split(T) )

...or something like that...

I envision it as being a typesafe implementation of duck-typing. The interfaces wouldn't be guarantees provided by the original class author. They'd be assertions made by a consumer of a third-party API, to provide limited type-safety in cases where the original authors hadn't anticipated.

(A good example of this in practice would be the INumeric interface that people have been clamboring for in C# since the dawn of time.)

In a duck-typed language like Ruby, you can call any method you want, and you won't know until runtime whether the operation is supported, because the method might not exist.

I'd like to be able to make small guarantees about type safety, so that I can polymorphically call methods on heterogeneous objects, as long as all of those objects have the method or operator that I want to invoke.

And I should be able to verify the existence of the methods/operators I want to call at compile time. Waiting until runtime is for suckers :o)

Answer 8

I'm a big fan of closures / anonymous functions.

my $y = "world"; 

my $x = sub {  print @_ , $y }; 

&$x( 'hello' );  #helloworld

and

my $adder = sub {
    my $reg = $_[0];
    my $result = {};
    return sub { return $reg + $_[0]; }
};

print $adder->(4)->(3);

I just wish they were more commonplace.

Answer 9

Things from Lisp I miss in other languages:

• Multiple return values
• required, keyword, optional, and rest parameters (freely mixable) for functions
• functions as first class objects (becoming more common nowadays)
• tail call optimization
• macros that operate on the language, not on the text
• consistent syntax

Answer 10

Lisp style macros.

Multiple dispatch.

Tail call optimization.

First class continuations.

Answer 11

Call me silly, but I don't think every feature belongs in every language. It's the "jack of all trades, master of none" syndrome. I like having a variety of tools available, each one of which is the best it can be for a particular task.

Answer 12

I'd like a language that was much more restrictive and was designed around producing good, maintainable code without any trickiness. Also, it should be designed to give the compiler the ability to check as much as possible at compile time.

Start with a newish VM based heavily OO language.

• Remove complexities like Operator Overloading and multiple inheritance if they exist.
• Force all non-final variables to Private.
• Members should default to "Final" but should have a "Variable" tag to override it. (This may require built-in support for the builder pattern to be fully effective).
• Variables should not allow a "Null" value by default, but variables and parameters should have a "nullable" tag that indicates that null is acceptable for that variable.

It would also be nice to be able to avoid some common questionable patterns:

• Some built-in way to simplify IOC/DI to eliminate singletons,
• Java--eliminate checked exceptions so people stop putting in empty catches.

Finally focus on code readability:

• Named Parameters
• Remove the ability to create methods more than, say, 100 lines long.
• Add some complexity analysis to help detect complicated methods and classes.

I'm sure I haven't named 1/10 of the items possible, but basically I'm talking about something that compiles to the same bytecode as C# or Java, but is so restrictive that a programmer can hardly help but write good code.

And yes, I know there are lint-type tools that will do some of this, but I've never seen them on any project I've worked on (and they wouldn't physically run on the code I'm working on now, for instance) so they aren't being very helpful, and I would love to see a compile actually fail when you type in a 101 line method...

Answer 13

Type inference. It's slowly making it's way into the mainstream languages but it's still not good enough. F# is the gold standard here

Answer 14

More powerful templates that are actually designed to be used for metaprogramming, rather than C++ templates that are really designed for relatively simple generics and are Turing-complete almost by accident. The D programming language has these, but it's not very mainstream yet.