What features must a language have?

views:

162

answers:

+2 Q:

What features must a language have?

I've been playing with Clojure recently and it got me thinking...

What are you looking for from a programming language before you will consider using it out of choice? What is it about a language that will make you take notice and look into it?

Things that immediately sprang to my mind are the tools available. I find having a very good debugger, profiler and possibly a REPL all make using a language more enjoyable.

+5 A:

It think I read this somewhere else before, but I agree 100%

make the stupid stuff easy
make the hard stuff possible

BioBuckyBall 2010-08-04 21:36:09

Are you thinking of "Easy things should be easy, and hard things should be possible." -- Larry Wall? I too agree, but admittedly, this is a ridiculously generic requirement.

delnan 2010-08-04 22:59:15

That must be it. Generic yes, but honestly so are the OP's example 'good debugger, profiler and possibly a REPL.' and most of the answers here :)

BioBuckyBall 2010-08-04 23:11:44

+3 A:

What are you looking for from a programming language before you will consider using it out of choice?

Turing completeness is necessary (though not sufficient) for me ;)

What is it about a language that will make you take notice and look into it?

Well, conciseness and readability are probably the two main factors for me. I like a rich type system too.

aioobe 2010-08-04 21:37:48

Wow, discriminating. ;)

Kirk Woll 2010-08-04 21:39:11

+2 A:

What I want is a programming language that doesn't get in the way. It should let me think about the problem at hand, not how to write it in the language.

musicfreak 2010-08-04 21:40:16

So you love higher level languages. :D Sadly they, by design, tend to be slow and less powerful.

Razor Storm 2010-08-04 22:48:55

@Razor Storm: I don't think it's "by design". I think not enough time and energy is being put into making them faster and more powerful, that's all. Of course no JavaScript code will ever match the speed of hand-written and fully optimized assembly, but eventually we'll get to the point where it won't matter, because there will be virtual machines for JavaScript/Python/<insert language here> that will be fast enough for 99% of tasks.

musicfreak 2010-08-05 04:06:56

@Razor Storm: To add, there are also many high-level languages (mostly functional ones) that are actually pretty fast by design. Haskell, for example, can even compete with C++ in some instances, especially where parallelism is involved.

musicfreak 2010-08-05 04:10:45

@musicfreak: Nice addition, musicfreak. To clarify, what I meant was that in declarative programming, handling more control of the implementation to the compiler/assembler/interpreter gives the programmer less ablility to fine tune the exact operation of the script to context, environment, or scaling that it is to be run as, and as such the compiler/assembler/interpreter must make some assumptions regarding optimization decisions, which might not always be perfect. Also, higher order languages have many useful features that take a lot of resources, such as garbage collectors and the like.

Razor Storm 2010-08-05 04:51:46

@Razor Storm: True, but I think the scope of tools (including languages) should be as narrow as possible. The more the language fits the specific problem I'm trying to solve, the better it is. Besides being easier on the developer, the language/tool can be optimized for that one purpose, instead of being a very general implementation that makes many assumptions about your code. And as for that last part, that is very true, although to be fair, things like garbage collection are done so quickly nowdays that you likely won't notice a difference by fine-tuning it. VMs are pretty smart these days.

musicfreak 2010-08-05 06:10:12

@musicfreak. That's true, and besides CPU resource is so cheap nowadays it'd be almost pedantic to meticulously fine tune your code to use as little cycles as possible, of course memory and disk access is still a significant bottleneck, but most higher level languages are pretty smart about its memory management.

Razor Storm 2010-08-05 16:20:05

@Razor Storm: Yep. Not only is hardware getting faster, but VMs are getting much smarter. Just give it time; eventually we'll all be programming in Python and Ruby and JavaScript. :)

musicfreak 2010-08-05 20:16:23

+1 A:

I'm not at all a "language geek," so when I go looking for a new language it is usually because any language I already know is in some way sub-optimal for the problem I need to solve -- thus, the primary things I look for in a new language are features that will directly address whatever my current problem is.

Beyond that, however, good tool support is pretty much a universal requirement.

Josh Petrie 2010-08-04 21:41:16

Languages should not have debuggers - that's what IDEs are for. And I must admit that if all the debuggers for C++ (my main language) disappeared tomorrow I wouldn't much care. The secret of being a good programmer is not to spend time in the debugger, and you do that by not writing bugs in the first place.

anon 2010-08-04 21:41:49

You might have to share the secret of writing bug-free code the first time through.

Peter Leppert 2010-08-04 21:45:27

@Peter It's worth spending the time you would have spent in the debugger in taking care when writing the code. and as for the inevitable bugs, I tend to fix them by thinking - the really difficult bugs (such as those in MT code) can't be fixed using a debugger.

anon 2010-08-04 21:49:32

I partially agree... I rarely use the debugger. There are a class of bugs well-suited to debugging with a debugger, and another class of bugs better suited to debugging with detailed logging. Better programmers appear to make mostly the latter sort of bugs.

rmeador 2010-08-04 21:53:41

I'm pretty sure the asker meant language design not compiler implementation. Whether there is a debugger is not something the inventor of the language has to decide upon. It is the writer of the interpreter/compiler/assembler that has the liberty to add these random bells and whistles. Of course, if you don't like debuggers, you can just not use them. I agree that debuggers are useless when it comes to bugs that are dependent on the design choices made in your program, but they can be quite useful in finding stupid errors.

Razor Storm 2010-08-04 22:54:17

Of course you can say "just don't make stupid errors then!", well humans are not infallible. Besides, even if you find a way of quadruple checking your work to completely get rid of little mistakes, I still believe it is quite a lot more efficient to run a simple debugger a couple of times to catch a small bug rather than rereading through thousands of lines of code. Of course, ultimately it's all just a matter of opinion, but you see that's the point. If you don't like debuggers dont use them.

Razor Storm 2010-08-04 22:54:38

@Razor The OP actually said that he thought a debugger was essential, which is what I was responding to. and if you have to read through thousands of lines of code to find a bug, you don't understand your code base.

anon 2010-08-04 23:06:53

@Neil, oops. :P However, on your second point, the thing is, you don't always use your own code, and thirdparty APIs' behaviors aren't always as well documented as you hope.

Razor Storm 2010-08-04 23:49:21

+3 A:

Higher order functions
Type inference (preferred) or dynamic typing
Pattern matching is nice, but not an absolute requirement
Same for good meta-programming facilities

sepp2k 2010-08-04 21:42:20

a little bird told me that someone loves OCaml or F#.. :)

Jack 2010-08-04 23:27:59

+1 A:

What are you looking for from a programming language before you will consider using it out of choice?

The language should be useful for dealing with tasks/problems I encounter. Nothing else matters.

Think about it - what's the point in readability, completeness, availability of libraries, IDEs, type systems and language features if you won't be able to use language to solve your problems for some reason?

SigTerm 2010-08-04 21:48:38

The point is that those things mean you will likely be able to use the language to solve your problems -- and the lack of those features makes it likely you won't be able to solve your problems, or at least it will be much more difficult.

Chris Dodd 2010-08-05 00:02:54

@Chris Dodd: I don't think so. I haven't finished learning at least two languages (both with great features) because they were not useful for tasks I encounter. Also, no matter how great your favorite language is, if it isn't widely used, you'll be in trouble - there will be a lack of libraries, and getting the programming job associated with that language will be difficult. There are great language people rarely use. And there are not so great, but widely adopted language. Therefore, "nothing else matters".

SigTerm 2010-08-05 01:05:23

It depends on what the language is going to be used for. Also, "features" could be better defined in the question.

Features can range from "object oriented", to "dynamic", to "JIT-compiled", to "strong typed", etc.

Crusader 2010-08-04 22:02:38

Let the language have a decent Foreign Function Interface so that it can use libraries defined outside its world. (I say “language” because I would like there to be one way to do it, not several, one per implementation.) With that, the language can be easily hooked up to existing code (operating systems, GUIs, advanced math libraries, etc.) and be put to work doing useful things. Without, the language can only ever be a toy; I do not use BrainF**k to do anything relevant, not because it is not Turing-complete, but because it can't do anything real with that Turing-completeness.

Named subprograms (functions, procedures, whatever) are kind-of essential too.

Donal Fellows 2010-08-04 22:19:47

First and foremost, a language should give me constructs which I can wrap my head around in reasonable time (where the exact value of "reasonable" depends on how powerful and generic it is) which allow me to solve problems efficiently (in terms of brain cycles and typing effort, not CPU cycles) once I can handle them. In other words, gimme higher and higher abstractions until they'd make my head explode, then stop.

Of course I prefer good implementations of concepts I'm already familiar with. For example, Python has great support for iterators and extends the concept by adding generators and generator expressions (list/dict/set comprehension is just syntactic sugar for generators). A language without such powerful iterators (or none at all!) better gives me an equally or more powerful way to consume data structures (e.g. recursion + pattern matching is fine to consume a linked list and very handy when walking trees), or shows me a way/area of programming which has different requirements (for which the language has in turn good solutions).

To name some specific requirements, higher-level (named subroutines etc are assumed) stuff I need to program effectively includes first-class functions and some kind of polymorphism (preferrably parametric polymorphism, but I can get along with OOP + nominal subtype polymorphism if I have to), ideally including generic types (again, I'm a huge fan of parametric polymorphism).

delnan 2010-08-04 23:26:19

ansaurus

tags:

views:

answers:

What features must a language have?

related questions