What would make you try (or not try) a new programming language?

Question

I've been designing a pragmatic programming language for 5 or so years, and it probably won't be released for several more years (probably until after my current and next startups succeed or fail).

In the mean time, I have two questions that may prove interesting:

1) What attributes of a new programming language could entice you try it on your next project?

2) What attributes of a new programming language could prevent you from trying it on a project? (i.e. no libraries, ...)

To make sure this question isn't a philosophical debate (thus getting closed by admins), please describe your own tool selection predicates, rather than theorize about the broader population's preferences :)

Thanks!

Answer 1

New Language - people who work on C++ always look for a language which has better support for memory management without compromising on speed [Java has better management, but slow compared to c/c++].

Qt is really nice in such a way that it takes ownership of children and destroys whenever parent goes out of scope but when you have pointer to pointer kind of stuff, it also fails.

--Cheers

Answer 2

For a new general purpose language to gain adoption, I think one feature trumps all others: integration with an existing established platform. You don't have time to write all the libraries a language needs, and why should you have to? New languages like Clojure and Scala are cool in and of themselves, but what has really made them "go viral" is the fact that they target the JVM and and interoperate with Java. Besides the free libraries your language gains, this means people who use it don't have to abandon their old code base overnight; they can instead migrate incrementally over time.

The next big thing is tooling; you need a rock solid, preferably fast compiler. You need an IDE with a debugger. A package manager can't hurt. Most programmers will not tolerate second-rate tools; they'd rather keep writing Java boilerplate, because at least there they have a nice IDE to help them refactor it.

Finally there is the actual technology of the language itself; its new ideas, or novel combinations of old ideas, the cuteness or brevity of its syntax. These are probably the things you, as the language designer, care about most in the language--and it is important. Even with platform integration and great tools, nobody's going to switch to a language that brings nothing new to the table.

Answer 3

The "crossing the chasm" approach is to pick a niche and dominate it - be leaps and bounds ahead of the competition. That will at least give you a shot at further visibility. You have to pick a niche, because, with limited time and resources, you're simply not going to be better at everything - you have to pick something you can excel at.

Even then, I don't think the odds are good, so doing it for your own education and for fun is the best thing. Also: release early and release often!

Answer 4

I give you my 2 cents.

1 - Absolute need:

• Garbage collector,
• very high level feeling (bonus if it also can feel low level at wish),
• Readable
• feel new ; here are some possible examples:
  • have a metapost like linear equation resolver (bonus if convex equation resolver)
  • visual debugger
  • even better metaprogramming feature than Ruby
  • ...

Bonus:

• impressive graphic library (visible program)

2 - Absolute NO:

• too Verbose,
• not fun
• not portable

Answer 5

First class functions and closures with an easy syntax. Ever since learning ruby and javascript I can't look at any language that doesn't have first class functions and runtime code manipulation facilities.

Answer 6

1) What attributes of a new programming language could entice you try it on your next project?

Two basic things stand out for me when selecting a language:

• A different cognitive model needed to use it. Something different than Lisp, Prolog, Haskell, C++, or Perl.
• Excellent libraries.

2) What attributes of a new programming language could prevent you from trying it on a project? (i.e. no libraries, ...)

• Lack of libraries
• Duplication of a solution existing programming languages already have solved.
• Buggy compiler
• Compiler that only works on 1 OS.

--

Generally, it has to either perform my goals better or stretch my mind better. Not only a little bit better, but a lot better - enough to justify learning it in a deep sense and committing months of work to it. At the moment, I'm working on understanding Lisp on my own time - learning other languages is only going to happen at the behest of my workspace.

Answer 7

For me it must be easy and understandable to use. It must also solve a business need. And it absolutely must have a first class debugger.

Beyond that, it will have to solve the problems I currently face in C#; which, quite frankly, are very few.

My history runs from pascal to Delphi to VB (oh how I hated those 2 months) to ColdFusion, PHP, Classic ASP, Java on to my current favorite: c#. There was a viable personal and business reason for each change.

Before finally leaping between them I dug in and made the code work. However, for each move there finally came a moment when it was obvious the new language exceeded the previous one. This isn't to say that Java (for example) isn't better today than it once was; just that at the time I moved it wasn't good enough.

Now, if you were able to make a language with a c style syntax that provided better scale out potential (think in the hundreds of servers with 10's of thousands of users arena) then I might seriously consider it. Maybe something with a strong tie in to both a traditional RDBMS and a NoSQL database and an awesome multi-threaded debugger.

Answer 8

Here are a couple of my own answers:

1. (good)

   • encodes lessons learned & best practices: I'd rather not have to re-discover over time what more experienced developers already know.
   • compiles to javascript: I just learned Java + GWT for this reason. I personally believe this is currently the best way to develop sophisticated in-browser programs.

2. (bad)

   • no static typing: Despite the verbosity of Java, I am in love with the tool support (Eclipse) made possible by static typing. (I'm contrasting this with my Python background).
   • no libraries: I can't build a competitive product if I have to start from scratch.

Answer 9

My biggest absolute no is any language that doesn't treat its users as consenting adults and tries too hard to enforce its vision of "correct" programming. To me a language should make it easy to write good code, not hard to write bad code.

Examples:

1. Purely functional languages.
2. Requiring that everything be declared inside a class to force OO-style programming.
3. A general avoidance of highly expressive features (lambdas, operator overloading, dynamic typing, type inference, default function parameters, etc.) just because they can lead to obfuscated code when used incorrectly.
4. Extremely rigid type safety, even when I explicitly ask to get around the type system.
5. Pedantic "features" like checked exceptions and requiring that every file contain only one top-level, public class.
6. Abstractions that you can't get underneath when there is no good technical reason for these limitations.

Answer 10

What would be cool:

1. A language that just understands concepts as "Numbers" and "Text" and doesn't make ME choose between int16, long, double or latin1, utf8, utf16.

2. Programming modal/concepts/ide that makes threads/multi-core a breeze.

What would be uncool:

1. Compiler/Interpreter crashes. The Language should expect idiot programmers ;-)

2. Unexpected/unreliable results or behaviour.

Answer 11

1. Garbage collection. It's like air. There are very few cases where I don't want it. If I don't want it chances are I'm willing to do some sort of dance to make a vacuum chamber.

2. Decent String support. Pretty much everything these days involves string manipulation.

3. Exceptions. Unless you have something actually better. Go's tacked on exceptions remind me of the cat puking on the floor.

4. Libraries. Despite what Lisp programmers say. I don't want to spend any of my time coding for database inter-connectivity.

5. Objects. Somethings really want to be objects. Database connections for instance.

6. Lambdas. Somethings want to be functions not objects.

7. CPAN. Not specifically CPAN but something filling it's shoes. There may be value in a license compatibility check.

8. Optional lazy evaluation. This is pure wish list. Sometimes you want to get data lazily and have it look like everything else. There probably needs to be some sort of mechanism to ensure non memory resources get released in a timely fashion.

Answer 12

If it has the letters 'J', 'A', and 'V'.

EDIT: BTW, I answered this for the "not try".

Answer 13

Documentation Whenever I think of adopting pretty much anything new -- be it an API, a framework, or a language -- I want to make sure that there is solid documentation so I can get it working and/or resolve problems quickly. I realize this is not a language feature per se, but one thing I really like about python is that it's very easy to add documentation to functions and classes, and very easy to get access to that documentation directly from the console.

Are you planning on making this open source? If so, go ahead and release it now. Everyone will understand that it's in alpha stage, but waiting until it is "ready" sometimes means it is never ready. Having a lot of early adopters and users means that you'll have the second important feature for a programming language:

Answer 14

Bear with me, as I'm writing this from my mobile phone.

The reason I'll personally go for a new language & try it out are the following:

1. The purpose it was created: Pascal was first an educational language that gain worldwide popularity. Java gained popularity as you could write mobile applications. For C++, the fact that it was designed to write kernels, you get the point.

2. Readability: Java & Pascal are easier to read source codes (close to the english language) than its C++ counterparts with many pointers. If language can be easily programmed and source code can be easily read, that will constitute to easy documentations and source tutorials.

3. Can run on multiple platforms: The reason I haven't played with Objective C & X-code is simple, I don't own a Mac. I can develop on .NET platform in linux with Mono. Adobe released Flex whose compiler is written in java & runs on any platform. You can't leave one demographics of developers.

4. IDE integration: not ideal but IDE's have advantages.

In essence, what I'm trying to say is that a new language exists based on:

• Problem existing languages have & the creator of the new language thinks that he/she has a better solution that can work in his/her new language.
• Do what Apple does, You must have a Mac and X-Code (or Mono Touch) to program iPhones, etc.

Focus on Point #1 (which I think is priority) and work from there. That's how Microsoft came up with C#.

Hope my 1 cent worth helps! :-)

Answer 15

The only thing that would absolutely entice me to try a new language would be a language that's at least as high-level as what I have now, and at least as flexible (e.g., w.r.t. metaprogramming). The good news is that I'm willing to try anything once, especially if it has crazy new ideas, so this isn't a rule set in stone. :-)

Things that would tend to turn me away from trying a new language, again not absolutes:

• if it didn't have a repl, I'd probably be much less inclined to try it

• if its syntax is complex, I'd probably avoid it entirely, because life is too short to become a language lawyer in yet another arcane syntax

  For example, Ruby syntax, if you took out some of the crufty old corner cases, is about the right level -- adding complexity beyond that, like Perl or C++, just means that I'm going to spend more time thinking about the syntax than the program, and that my text editor is never going to work quite right with it -- you don't need complex syntax for good language features.

  (If you grok Perl and C++, cool, more power to you. I mean no disrespect to you or your language. I personally can't figure them out, so any language with that level of syntactic complexity is not for me.)

• complete lack of tools

  You don't need everything right away, but if all you've got is an interpreter, especially one written in C, it's certainly going to seem like a language not built for metaprogramming, and so I'll not have much interest in it. (Extra bonus points for being self-hosted!)

• being called "pragmatic"!

  Ouch ... sorry. But that sounds to me like a language aimed at solving one kind of problem, and I want general-purpose tools. (I don't think their creators ever called C or Lisp or Smalltalk "pragmatic", and I want to learn the next C or Lisp, not the next PHP or Java.)

• if it depends on some very different platform for key functionality (like C or the JVM, if the language isn't otherwise much like C or Java), I'm less interested

  This one is admittedly in stark contrast to what other people have already written. For example, I'm less inclined to try Clojure because it's on the JVM. They seem to have less incentive to build good new native libraries, and if I just wanted to glue existing Java-language libraries together, Java itself is pretty good at that. The kinds of metaprogramming I do today would be impossible in Clojure-using-Java-libraries, because they're black boxes.

  Also, over the years I've used native libraries, and "just wrap a C library" libraries for HLLs, and the "wrap a C library" solution is always much more complex, which means it's harder to set up, and when (not if) I run into trouble, much harder to debug. So if you say you've got a new system that can use all my existing libraries, I just hear "cross-language function call debugging nightmare".

  A powerful and flexible language needs far fewer libraries than weaker languages. If I had to write a C program that needed a linked list, I'd probably look for a library (maybe Glib). If I had to do it in Python, I could probably write one in less time than it took to find a library. And that's not even the easiest language for writing a linked list!

  If I'm moving up in the abstraction spectrum, it means I'll need fewer libraries than I'm using now, which is already "not very many". So make a great language, and we'll figure out libraries if we need them, using the new metaphors for this language. Any time spent wrapping <string.h> or java.lang is a waste of time, to me.

I guess a few of my remarks are the opposite of what other people have said. The possible interpretations are either:

1. they're right, I'm wrong
2. I'm right, they're wrong
3. none of us know what the heck we're talking about, and you should just make something cool for yourself, like Dennis and Ken did :-)

Good luck, and I look forward to seeing what you make. I think 5 years of design time is a lot more than a lot of successful programming languages get!