3 ms·

One of the first things you will find out, if you attempt to write a new programming language and then use it for actual production work, is how much users of t

by akeefer 16y ago

One of the first things you will find out, if you attempt to write a new programming language and then use it for actual production work, is how much users of that language will miss simple, taken-for-granted things like debuggers. Creating a programming language by itself isn't all that hard. The real work is actually making it usable with good error messages and stack traces, tools like debuggers and profilers, editor support (if you're into that sort of thing), and documentation and specs. All of that (especially good editor support) is easily an order of magnitude more work than a parser and a compiler, and that doesn't even consider libraries you might need to write if you can't interoperate with an established language. (Spoken from personal experience, for what it's worth).

nickik 16y ago
but the real hard thing is to make a language people want to use. If you did that the rest will be done by the comunity but even then it a lot of work. One of there reasons new langauges are often targeting the JVM or the CLR. You can reuse most of the tools and libs with less work.
- akeefer 16y ago
  Exactly. Funny story there . . . we started our JVM language as interpreted, more or less, and ended up having to write our own not-so-great debugger for it. We decided to compile it down to native java bytecode precisely so we could take advantage of all the native Java tools that work with standard Java-like classes, such as debuggers, profilers, and even just stack traces. That approach doesn't work so well for languages that don't match Java relatively closely (i.e. stack traces in Closure are, I understand, pretty horrific), but for our language it's turned out pretty well.
naner 16y ago
Or as Steve Yegge claims, the programming language doesn't matter nearly as much as the tools: http://vimeo.com/16069687 http://vimeo.com/16069687
- akeefer 16y ago
  Indeed, it's the overall "experience" (for lack of a better word) of programming in a particular language that matters. That's influenced by not just the syntax and structure of a language but also by all of the development tools, libraries, frameworks, documentation, and tutorials available, as well as the methods of working that those enable (i.e. REPL versus fast deployment, compilation steps required, ability to reload code on the fly, etc.).

by akeefer 16y ago

nickik 16y ago

but the real hard thing is to make a language people want to use. If you did that the rest will be done by the comunity but even then it a lot of work. One of there reasons new langauges are often targeting the JVM or the CLR. You can reuse most of the tools and libs with less work.

akeefer 16y ago
Exactly. Funny story there . . . we started our JVM language as interpreted, more or less, and ended up having to write our own not-so-great debugger for it. We decided to compile it down to native java bytecode precisely so we could take advantage of all the native Java tools that work with standard Java-like classes, such as debuggers, profilers, and even just stack traces. That approach doesn't work so well for languages that don't match Java relatively closely (i.e. stack traces in Closure are, I understand, pretty horrific), but for our language it's turned out pretty well.

naner 16y ago

Or as Steve Yegge claims, the programming language doesn't matter nearly as much as the tools: http://vimeo.com/16069687 http://vimeo.com/16069687

akeefer 16y ago
Indeed, it's the overall "experience" (for lack of a better word) of programming in a particular language that matters. That's influenced by not just the syntax and structure of a language but also by all of the development tools, libraries, frameworks, documentation, and tutorials available, as well as the methods of working that those enable (i.e. REPL versus fast deployment, compilation steps required, ability to reload code on the fly, etc.).