3 ms·
You might be doing this as a learning exercise, in which case it doesn't need to be particularly innovative, and writing another Lisp or Forth implementation is
by DonaldFisk 6y ago
You might be doing this as a learning exercise, in which case it doesn't need to be particularly innovative, and writing another Lisp or Forth implementation is fine. In fact, I'd recommend beginning along those lines, followed by developing several different new languages, probably domain-specific ones. Your first attempts probably won't be worth keeping. (I haven't kept the object oriented Prolog I wrote about 25 years ago, but I do regularly use a small Prolog I recently wrote in Lisp.)
The languages at the roots of all programming languages are Fortran, Lisp, Cobol, Algol60, APL, Snobol, Forth, Prolog, OPS5, SASL, Smalltalk, Prograph. (If I've missed any out, or any of the above have important predecessors, please let me know.) A new language is unlikely to be radically different from any of those languages or their descendants - of those I listed, the most recent is from the mid 1980s. Within the descendants, which is your favourite? Can you make big improvements to it? If so, make them. Otherwise, can you improve another language so that it becomes your favourite?
One heuristic I've found useful: the right design choices at the start might be unknown, but when I need make them, they're obvious to me, and often a particular choice leads to other equally obvious choices. If the choice isn't obvious, I've probably done something wrong.
My own preference is for pure rather than hybrid languages with simple regular syntaxes (i.e. one idea expressed well), and very strong static typing.
My favourite language is Common Lisp or rather a subset of it. I have trouble thinking of ways to make it significantly better. But I also like the idea of dataflow (a few decades ago I knew some of those working on experimental dataflow hardware), and graphical programming seems to be the right approach to dataflow. Prograph was the closest existing language to what I wanted. It's isn't pure dataflow, it's dynamically typed, it's object oriented (so, unless it's Smalltalk it's hybrid), and entering programs in it involves too many mouse gestures and keystrokes. So I'm implementing a new language which corrects those deficiencies. It's been particularly difficult because I have to write an IDE as well as the language, and there aren't any textbooks I can rely on for help.
I'll have succeeded if I use the new language more often than I do Lisp, and if along the way I get a few more papers (two so far) and some academic interest, so much the better. I don't expect a wide user base. If that was important to me, it would have C syntax and I'd try to get corporate backing. Your criterion for success might differ from mine.
- lioeters 6y ago> I have to write an IDE as well as the language This part caught my attention. I've developed a few small languages over the years, with somewhat boring syntax in Lisp or Algol family. The one that has the most longevity (~7 years) and traction (estimated few thousand users) is an XML-based (!) domain-specific language. Frankly it's verbose and kind of ugly, but apparently easy to learn due to its regular, minimal syntax - a little like Lisp, if parentheses were brackets. It's also "declarative", a bit like SQL, in that the users describe the result, and magic happens internally to make it so. More recently, I've been working on a tree-structured editor for users to visually build programs/templates. Developing it has been insightful - I'm realizing that this development environment should have been there from the beginning, as a fundamental part of the language's design and user experience. All syntactic constructs, keywords, patterns, defined variables, functions, etc., can be made available to the user, with auto-complete, suggest, lists of choices. Rather than the user having to remember commands and type them in text, the environment can let them select, compose, and build. Ideally, it can ensure that a program never has a syntax error (conversely, that it makes it impossible to write/build such a program). Another aspect I've come to appreciate is instant feedback. Any kind of live preview, or automatic build/test, makes a big improvement in the flow of programming and thought process. It becomes like shaping clay. In an article about Smalltalk, I read how its integrated environment is indistinguishable from the language itself. In my daily work too, I spend most of my time in an editor with language servers for syntax highlight, autosuggest, linting, and other smart features, as well as integration with terminal, Git, remote edit with SSH.. Typing in text is still the fastest way for me to express myself, but the environment is constantly supporting it - it understands what I'm writing (often more than I'm aware), showing me what I need to know to build with minimal effort. What I like is a programmable development environment, especially one which is built on itself. Well, this has been a ramble without a point. It's an endlessly fascinating subject, and perhaps it's only natural that a programmer finds delight in creating one's own language. There's something pure and philosophical about it, like working with the very material of thought. --- A little list of links related to building interactive software visually: https://airtable.com/ https://airtable.com/ https://bubble.io https://bubble.io https://www.memberstack.io/ https://www.memberstack.io/ https://webflow.com/ https://webflow.com/ https://zapier.com/ https://zapier.com/