I'll go first. 13 years ago I created a specialized language for processing XML data. XmlPl marries the syntax of C, XML and XPath. It is very fast and efficient. It never caught on. See http://xmlpl.org.
Despite being a modest, fun experiment in stripping JavaScript down to a minimal skin, and without any corporate backing, it wound up catching on a little bit.
Thanks to the hard work of Geoffrey Booth and Simon Lydell, among others, there's a new "V2" version that includes many ES6 and 7 features that's almost ready to go: http://coffeescript.org/v2/
CoffeeScript was designed extremely conservatively. The goal was to stick close to JavaScript semantics, to avoid having a runtime, and to avoid features that would require gymnastics and overcomplications in the output, or would run noticeably slower than the raw JS equivalent.
These days, I'm most interested in trying something from the other end of the "political" spectrum: What would happen if you tried to make a web language that wanted to strip HTML, CSS and JavaScript down to their essence — but were extremely liberal in the techniques you used to get there?
I'd like to get a chance to give that a try some day.
It was a huge net positive for web development. 2009-2011 were really heady times - a whole programming community emerged from a deep, dark cave with new tools and a new optimism for the web.
Give me an optionally typed, ES6-flavored Coffeescript and I'll be a happy developer.
And, as you say, array comprehensions largely remove the need for each/map/filter etc, which also has potential for a nice performance boost.
So, extremely liberal, you said... :-) Thinking about this I started to wonder about other systems producing a similar output to the trio html/css/js. I realized PostScript is such a system, but for fixed size documents. People actually explored using PostScript for GUI applications in the past, as described in [1]. At some point I'd like to explore [2] and [3] to see if some of the ideas could be modernized and adapted for the web.
1: https://en.wikipedia.org/wiki/PostScript#Use_as_a_display_sy... 2: https://en.wikipedia.org/wiki/Display_PostScript 3: https://en.wikipedia.org/wiki/NeWS
> I'm not about to start using it for real projects,
> it's really just a thought experiment about how nice
> JavaScript could be with an alternative syntax.
I've used it a bit for fun, but never for work.
And I think that the future of JavaScript is probably always going to be JavaScript — until a web language comes along that's so compelling it's just obvious that it will be the right direction, and then the question won't even have to be asked.
CoffeeScript, as a concept, was mostly finished back in the 2010-2011 days, as a layer on top of ES3.
CoffeeScript 2, while a great step forward in terms of practicality for folks who want to use it with ES6 features like classes and modules — is also a step backwards for the notion of CoffeeScript: For example, we don't have to formalize classes anymore because JavaScript has them now, and unfortunately JavaScript has done them in a very static way that's not at all the direction CS would have taken. Ditto modules.
As an open source project, it will continue to work just as well as it always did. But I definitely don't foresee a return to general relevance, ever.
2. I wrote the Sage preparser, which adds a bunch of math-friendly syntax/language extensions to Python, in order to make it more suitable for interactive use for math. I realized this was needed while giving an early demo of Sage at PyCon in 2005. Otherwise, users of the competitor products to Sage would be much less likely to consider switching. This seems to have worked pretty well, and fortunately I think we haven't added anything to the preparser in years.
We were going for a matlab like language but R and Octave weren't deemed ready. For those of you who are already objecting in your head, I'll grant you that I'm not sure we made a good choice here but this was the early 2000s:(
What we were after was a vectorized language that would let you write your quant formulas without having to write loops.
For instance, if you wanted to run say Black Scholes over multiple expiry dates and multiple underlying prices you could pass in a vector of dates and vector of strikes to your model and it would return a grid of results for the permutations of values.
Since this is pretty processor intensive we also had language features for splitting your calculations over multiple machines in your datacenter.
All of this has since been comoditized, but when we started most of this wasn't present.
The company ended up being the calculation engine for calculating risk metrics like VaR for several large banks being acquired by a large financial company, so in that sense it was a success.
The downside of writing our own language was that quants weren't thrilled about having to learn a new language that wasn't a really transferable skill as quants tend to move around from company to company alot.
So the fact that we wrote a language ended up being a barrier to adoption. it also meant that we did a lot of consulting with the banks to get the initial modesl setup, which was good for providing income, but bad in the sense that our good quants soon became our clients good quants.
To give some background: I'm working on a program to allow anyone to create video games. But to add custom functionality, my users need to use some kind of programming/scripting language. Since these are non-technical people, it must be as easy and simple as possible.
Therefore I'm now making a language (called Screenplay) where you don't really have to learn anything. You click 'add action' and a wizard guides you through making your action. You select the subject, then the verb (or action), and then some parameters. Translated to OO: you select the object, method and parameters.
I considered using a visual programming paradigm, but still text gives you the most freedom in expression. It's also easier to create new concepts in text than making a new image that makes sense.
In the long run I want my Screenplay language to resemble OO, where users can define their own objects with methods. It kind of looks like this (remember it's game related):
Hero walks to Professor
Professor says "Hi there, how are you?"
if Hero chooses "Fine"
Professor says "Nice to hear that."
else if Hero chooses "Not good"
Professor says "I thought so, let me show you something"
Professor walks 2 tiles to the left
How <actor> says "<text>"
GUI opens text dialog with "<text>" and image 'face image' of <actor>.
I'd suggest you market it as a really simple programming language. That'll work. What you've got technically looks good an sounds like it could be useful, so, cool, but you just need to change how you're selling it. Realize that people who can't logically structure and rationally think and technically design will continue to be unable to program, of course, no matter how easy the tool is to use.
Remember most people are functionally illiterate and can't read at a high cognitive level. That probably correlates very strongly with being unable to program BTW.
(edited to add, this was the wisdom of the GUI. Plenty of people are too illiterate and non-technical to ever be able to use languages, including even English prose, as a computer UI. But if you strip out most of the functionality and change it from linguistic IQ skill points to 2-D spatial manipulation, lots more people can "use" that UI... Nobody ever got noobs to use computers via every "simpler" and dumber CLIs, that madness leads to CPM and msdos, the trick was to get lower intellectual functioning people to use computers by taking away power/complexity and abandoning language and literacy entirely by going spatial with GUIs, I'm just saying as a strategy making the tool weaker never helped people who can't use tools as a historical strategy)
- It comes with a manual. You shouldn't need a manual for something simple.
- Too much prose, I like more structural things. If inform is a book, my Screenplay is technical documentation.
Inform is great for what it does, but I guess I needed something slightly different.
The major issue with all of this is that program code is built through a process of iteration: one brick on top of another. But once you hit the wall I just described, you have to face the scientifically organized structure of programming in order for the language itself to not be a mess (see PHP) or the programs written in it to be spaghetti (see BASIC and particularly GOTO).
I say this not to be a downer, just as strong encouragement to take this into account and try your best to factor this into your design. If you can make something that lets people scale really high before hitting that wall (if at all!), that would be awesome.
That's like saying "Everyone knows how to drive a car, you just keep it pointing forward and engage the engine".
Everything needs some sort of documentation, whether it be through examples (the way love2d.org/wiki is done, for example, is both informative and useful), documentation, BNF, etc. The fact that a manual exists is not a detriment, but a success -- you have enough features and complexity worthy of documenting it (although I don't mean to imply that larger is bigger :) ).
After reading the article about RUST, I have been thinking about how a compiler could take source code and write it back with fixes/suggestions right into the source so if you make a silly mistake, the compiler can just say "I think you meant..." and offer to fix it for you.
In your language, it would be beneficial to avoid "Syntax error!" and implement something like "Did you mean...", or have synonyms like "says", "exclaims", "talks", etc that compile to the same thing but add flexibility (or the compiler automatically re-writes to the preferred syntax)
It is probably fine for the purpose of simple gaming scripts.
Most users do not want to write their queries by hand, so I also built round tripping of the language to/from a GUI query builder. You can build a query graphically, edit it as text, then go back to the graphical form. Certain things cannot be displayed however, and generating good error messages was very difficult.
A weird fact is that the backend which evaluates the queries has a totally different language of its own, so there is a transpiler for that.
Thousands of people have used this language, but 99% of them did not know it.
I started working on the language to bring an elegant compositional style to low-level high-performance programming, in the form of a simple language that admits powerful tooling for program editing and visualisation. I also wanted to address usability concerns with stack-based languages (e.g., by allowing infix operators). As I’ve spent time in industry, I’ve begun to treat it as a way to address my gripes with C, C++, and Haskell; and as I’ve learned more type theory, I’ve begun to use it as a playground for type system research.
The goal is to allow pure functional programming that “feels imperative”, with a simple performance model (unboxed values by default, in-place updates, no laziness) and minimal runtime support (no GC, eventually no libc).
The latest compiler is nearly complete, but not yet usable for real programming. Still, you may like to keep an eye on its development.
After learning about concatenative languages a couple of years ago I started learning Forth and later Factor. I wanted to give Joy a try, but IIRC I couldn't make it run and, after that, I stumbled upon Cat. But Cat was written for .NET and unmaintained (I just checked and it looks like even cat-language.com is dead now...). Still, I thought the idea was very interesting, at that point I was kind of tired of Forth strictly untyped nature. And then finally I found Kitten, which I thought was very promising, however very incomplete at the time. This is how I ended with Kitten being on my list[1] of languages to keep an eye on.
I hope it goes well and you'll release as planned, I can't wait to start playing with it! :)
[1] Here: https://klibert.pl/articles/programming_langs.html#org3087a1...
I guess it’s still in a “promising but very incomplete” state. Lately I have a pretty clear sense of how I want the language to be, and people seem pretty excited about it. It’s just a matter of finding the energy to do the work…
Also, follow the repo if you want updates. The website hasn’t been updated in like 2 years, and probably won’t be until I need to prepare for a release.
It is heavily inspired by CoffeeScript (and Python), it works as a transpiler for Lua. I've since used it regularly to code dozens of projects.
It's now powering my company along with a handful of websites and supporting libraries. I've also made games and GUI apps with it. The adoption has been pretty minimal, but I'm satisfied regardless. It has definitely improved my productivity.
Since he doesn't want to mention his company, it's called itch.io. It's a game marketplace -- kind of like Steam -- but with a ton of pretty interesting ideas when it comes to advertising, pricing, etc.
The really cool thing is that the site is written entirely in MoonScript AND uses the Lapis web framework, which he also wrote entirely in MoonScript.
Anyways, if you're ever looking for a place to host and/or sell your game, itch.io is definitely the place to go.
Please don't give up on MoonScript :)
In the future I'd like to be able to run MoonScript in the browser, maybe web assembly is the answer.
Another option would be to have a JS target for the MoonScript compiler, but there are some issues with different language features that would make code sharing difficult (1 indexed arrays, metatables, etc.)
I have no plans to give up moonscript. I haven't been actively developing it recently though, which I feel guilty about.
Eventually, I found Manfred von Thun's Joy language and realized that it was better than my thing and now I've implemented that in Python in Continuation-Passing Style. https://github.com/calroc/joypy
I think Joy is pretty amazing. It's a Functional Programming language that superficially resembles Forth, in that it's stack-based, but it's much more like a mathematical notation. https://en.wikipedia.org/wiki/Joy_(programming_language)
Edit: The book you mention is on Amazon for $6 now. Ill buy a copy for historical inspiration if its contents go into detail with examples of applying her method to at least toy problems.
As for the book, I don't know if I can recommend it. I've only ever seen a copy one other time, to check if it mentions Hamilton (it does, in some end notes) and I can't say it lived up to my memories of the first exposure. I can't even say how much of it is actually original to J. Martin and how much is strictly Dr. Hamilton's.
Why? Because in GIMP it's annoying to edit animations with many layers, so I wanted to write a script that would do what I want. But rather than hardcoding a specific action, I wrote it in an extensible way, and the rest is history.
In general, I think non-Turing complete (always terminating) languages are super useful and should be used more often.
yup, always-terminating functions are also called total functions (if they're defined for every input). Which is a related concept to Total functional programming
http://docs.idris-lang.org/en/latest/tutorial/theorems.html#...
While Idris is turing complete for example, it's possible to mark functions and whole modules as total, and let the compiler prove it for you. Wish that more people knew that we have such tools available nowadays
Dhall, a total configuration language.
https://github.com/Gabriel439/Haskell-Dhall-Library
There is Morte and Anna as well, that look like the previous experiments in total languages in haskell.
The proof is easy: just set for all n, f(n) to be the nth program in your toy language in lexicographical order and then set for all n, g(n):=f(n)(n) + 1. This g is clearly Turing-computable (you can modify an interpreter to compute it) and not in your language (a la Cantor).
Consider for example TensorFlow and/or Theano. Before they added the loop and conditional Ops, they were non-Turing Complete. And you could do amazing things with it as it were.
In fact, I took a lesson from that when working on Gorgonia (https://github.com/chewxy/gorgonia) - I don't ever want it to be a Turing Complete language.
A non-Turing-complete language is any language which does not have one of those capabilities. Because the bar is so low, most languages you have used in your life are Turing-complete. For example, you can imagine a simple calculator-like language for just writing mathematical expressions. It can do all basic math operations, has conditions, but no ability to repeat things (no loops or recursion). That language is not Turing-complete. You can trivially prove that programs from such a language will finish - they can't not! there's no ability to impede progress.
A Turing Machine is literally just a tape, a movable reader/writer, and a bunch of states that dictate what the reader/writer does.
As long as you have memory, the ability to write to memory, conditionals, and some form of looping, whether it's a `while` loop, a `for` loop, or a `jmp` or `GOTO` instruction, it's Turing complete.
Note that a conditional jump (`jne`, for example) satisfies both of the latter.
Turing's Tape Machine is a UTM because the tape can be initialized with contents to turn it into any TM. Any calculation for which there is a TM can be done by the UTM (if someone can figure out what to put on the tape).
I forgot...
For instance, the do operator:
(do ((i 0 (+ i 1))) ((> i 10)) (print i))
(loop for x below 5 and y in '(a b c d e)
collecting (list x y))
(LAMBDA (A)
(PROG (B)
S (SETQ B A)
(COND ((NULL B) (RETURN C)))
(SETQ C (CONS (CAR A) C))
(GO S)))But if you can encode the Ackermann function, proof of termination is not very useful in practice - as it may consume arbitrarily large amounts of space and time to evaluate (easily more than the age/size of the universe).
Beyond that: Writing an interpreter is typically the first thing I do when I am trying to pick up a new language.
To anyone interested in learning how to design and implement a programming language, I highly recommend the 2015 offering of Brown's "Programming Languages" [1]. Implementing type inference was a revelation for me! The starter code is supplied in Pyret, but the material isn't language-dependent; the assignments can be implemented in any language.
[0] http://www.pyret.org/ [1] http://cs.brown.edu/courses/cs173/2015/assignments.html
The goal was to build a language simple enough that we could teach it to non-coder authors, to scale up the number of interactive novels we could publish.
It seems to be working. ChoiceScript is the core of our business; we're profitable with a staff of four editors, a production assistant, plus me, the main tech person. We've found that ChoiceScript makes it easier to teach writers to code than it is to teach coders how to write.
The most popular type of choice-based IF is hypertext IF, and the most popular tool for building hypertext IF is Twine. Squiffy is most directly a Twine competitor, but almost all hypertext IF is developed in Twine; nobody's using Squiffy.
That may not be Squiffy's fault. Generally speaking, IF tools rise above the noise when someone writes a Great Game in that tool, regardless of whether the tool is strictly better or worse than anybody else's tool. Then people who admire the game say, "I want to make a game like that! How did you make it?" and that gets the ball rolling.
Since Twine is more popular than Squiffy, I'd advocate that anybody starting today use Twine. (And so the rich get richer.)
We don't use Twine or Squiffy at Choice of Games, partly because Twine isn't very well suited to writing really large interactive novels, (our minimum is 100,000 words of code+text) but also because hypertext UI isn't that easy to use on mobile devices; it can be hard to accurately tap on links in the text, as opposed to tapping big buttons at the end of the text. (You can use buttons in place of links in Twine, but you start fighting the tool pretty quickly.)
The other viable choice was to have application developers write everything for the Newton in C or C++. By giving them a much higher-level framework (Scheme/Self-like language + UI views/interaction + indexed object store) we were able to get more functionality into the product/ecosystem faster and more reliably. At least I think so. Also, we didn't have much RAM to play with, and were able to do some nice memory-saving tricks underneath.
And speaking of prototype inheritance, I still think that makes a lot of sense in some domains (like UI programming) but hasn't gotten much traction.
Beyond that, having an integrated object store (as opposed to a filesystem) is an idea from the 90's that really should get more mainstream attention.
I bought a Newton in 2007 or so, just to be able to play with NewtonScript.
It compiles to JavaScript, but it has a Pythony syntax, macros and fairly advanced pattern matching. I wrote an essay about the why and the experience: http://breuleux.net/blog/my-own-language.html
I think it's a pretty nice language, but I'm biased. I use it for my personal projects (including my own markup language, Quaint: http://breuleux.github.io/quaint/), but it didn't really catch on for anything else.
With D, I could implement it and ship it in a few days or weeks.
Of course, I could (and did) add features to the C++ compiler I developed. But I soon discovered that nobody was interested in using features that were not part of the standard - even the people who proposed the features would not use them.
Over time, many of the improvements put in D found their way years later into the C++ standard.
If you've ever used Zortech C++ then you've used Walter's product.
However, while playing game after game in the evenings, I was always frustrated that I was using the inputs and outputs of my body so inefficiently. Starcraft tied up my eyes and my hands, but I still had time to think about the things I'd be coding if I weren't playing, and wished wholeheartedly that I had a few extra hands so I could play AND code at the same time.
This frustration crept into other activities like the drive to and from classes (and, even more frustratingly so, the long drive to and from home when I visited) and I eventually came up with a plan to let me code while multitasking with things that require my hands (primarily starcraft and driving).
I had taken the traditional compilers class the previous year so I had some experience with lexing and grammars, and set out to make my own voice-first programming language. I called it Bespoke (ha) and uploaded a proof of concept to GitHub[1][2] after it was featureful enough to solve a couple Project Euler problems.
I decided to use Javascript in the beginning so I could take advantage of webkit's native speech to text and get right into the logic without having to deal with processing sound or extracting words from it. After getting a proof of concept up, I expanded the flow control and data structures it supported (piggybacking on JS) and eventually wrote some fun (albeit simple) programs while gaming, but eventually gave up on the project when I realized I could code things up in a similar amount of time by just outlining code structure while gaming (also using STT) and coding up the necessary snippets in brief downtimes (between games, at stoplights, etc).
Now, I still pretty much do the same: I use a prose-like DSL that's evolved over the years to outline what to code, in what order, and how to tie it in to other pieces. I now take the train/bus instead of driving (and code at will), and outline what to code while I'm dead in Dota 2 games.
[1] https://github.com/drusepth/voice2code/blob/master/voice2cod... [2] https://gist.github.com/drusepth/3134188
I think it's still the case, C-like languages have too much grammar going on to deal with without visuals, forth is grammar-free. Also, it's naturally shell-like; instead of your 'run the code', just say the function you need to execute; you can test and redefine each function as you go.
I attempted to build this on a ZX Spectrum in 1983, based on some voice recognition code from a magazine...needless to say I didn't get too far with that hardware. I should have another go.
[1] Sample:
"Program. L axis add speed vector three point
six klicks per second. Paraphrase acknowledge."
"Increase forward speed three and six tenths
kilometers per second."
"Chief Pilot?"
"Level."
"Execute." Deety glanced at the board. "Gay Deceiver,
H-above-G will soon stop decreasing, then increase
very slowly. In about fifty minutes it will maximize.
Program. When H-above-G is maximum, alert me."
"Roger Wilco."
"If-when one hundred klicks H-above-G, alert me."
"Roger Wilco."
"If-when air drag exceeds zero, alert me."
"Roger Wilco."
"Remain in piloting mode. Ignore voices including
program code words until you are called by your
full name. Acknowledge by reporting your full name."
"`Gay Deceiver,'" answered Gay Deceiver.I couldn't listen to a podcast and code at the same time either, probably. If I'm listening to a podcast, I'm mentally trying to process it. If I'm coding, I'm mentally trying to plan/process what I've done. Any mental processing from one takes away from the other.
Podcasts, though, don't require any use of your hands. I actually feel guilty _just_ listening to podcasts (or similar) unless I'm also doing something like painting or paperwork that requires hands but not brainpower. I recognize it's kind of irrational, but it just feels like a waste of time and potential when I'm (probably) not going to live forever.
I think it's just a matter of recognizing what your potential inputs (seeing, hearing, touch, processing) and outputs (hands, voice, mental "caches" like outlines that you can context switch back into later) are and choosing activities to multitask that take advantage of the maximum amount of each without overlapping.
When I was playing Diablo II, I used to be able to complete the Secret Cow Level runs with a nova sorc almost by rote. I would often be thinking about other things, chatting with friends, calling into internet radio shows while doing this
I would love to be able to code, using a headset+phone combo, while wandering around in a park.
For details, see http://flowgrid.org.
Play store link: https://play.google.com/store/apps/details?id=org.flowgrid
P.S. If you want to create your own language, consider using my expression parser: https://github.com/stefanhaustein/expressionparser
include "stdio.h"
class Widget {
x int
y int
func init() {
@x = 0
@y = 0
}
func draw() {}
}
class Button extends Widget {
func draw() {
printf("Drawing button!\n")
}
}
func main() int {
w *Widget = new(Button)
w@draw()
delete(w)
}I'm slowly adding features to it like typing, object nesting, etc.
I created it for easier blogging. I'm not a fan of YAML because it's indent-based and I wanted to have a markdown file that hosts all the information about a post on it from the date, to snippet, to main text, title, metadata, hell even a sidebar ad, and author, etc.
I did end up creating a parser for it that I couple with a blogging engine.
The current compiler transforms the MOML file into a JS object
The same thing technically applies to any extensible language (i.e. Lisp) but a Forth programmer goes in with the expectation that the first task will be to create an application specific language. Since you have to pretty much create everything you are best off doing that in an efficient way.
Couple of examples - a language that compiles to Bitcoin script opcodes [0]. Although the Bitcoin script engine is stack based (easier to follow) I couldn't resist designing a small, simple language that could be used to write transaction output scripts. This way it's easy to understand what are the conditions of moving funds to the next owner.
Another language has first-class functions, operators as functions, optional lazy computations, but more importantly a small runtime that supports tail-calls and capturing execution as a value (callcc) [1].
I've also written parser and interpreter for Prolog [2], just to get the feeling of logic programming.
Writing a small language can make you understand the paradigm (functional, imperative etc.) better and it takes a great deal of effort to decide how should the syntax look like, how will the runtime work (usually with toy languages you provide runtime too...).
Edit: Just noticed the "except toy languages" part... :-/
[0]: https://curiosity-driven.org/bitcoin-contracts
The first was something I did in an intro to CS class. I asked the professor if I could use C++ rather than Pascal for the assignment, and was, of course, turned down. I'm not proud to admit to this, but in a fit of pique, I decided to write my own programming language in Pascal than then submit the assignment in that. The result was something called 'SeqTl', for Sequenced Testing Language. It was basically a stack oriented language somewhat analogous to Forth. There were two stacks, one for numbers and the other for strings, and the interpreter worked by continually parsing strings of tokens. (Think Tcl pre-8). (I did get an A, the professor said I should've gotten bonus points, but in retrospect he would've been within his rights to fail me outright.)
The second was about five years later, while working on industrial process control firmware. My company wanted to allow our customers to specify control algorithms that were able to be guaranteed to run within a given time bound. To achieve this, I wrote a simplified language with a C-like syntax. It lacked constructs like unbounded loops, and the compiler would run an analysis of the control flow graph and throw an error if the longest path exceeded a given projected execution time. This language also used value/status tuples rather than raw scalar values, so it could do things like propagate bad data information through a calculation. (Think NaN propagation through floating point math, but more expressive.)
The third was/is an ongoing project to write a Scheme-like language.
https://github.com/mschaef/vcsh
This codebase started out as George Carette's SIOD interpreter, although I've made a bunch of changes since. (There's now a compiler, first-class hash tables, the reader and writer are now in Scheme rather than C, there is a test suite including benchmarks, a decent REPL, etc.) Back in 2001/2, this started out as the core of a shareware calculator program I was attempting to sell online. The tl;dr on that is that the design was way too ambitous, the market didn't support it, and I didn't have remotely the bandwidth necessary for either the development or the sales. It was and is still fun to hack on, however.
Well, to be fair, in the real world its not too rare for engineers to write custom programming languages to solve their problems (see: this thread). So what you did isn't that far outside of what's really done, assuming you submitted the code for the programming language with the assignment.
That said, I think he would have been within his rights to give you a C for overengineering it :p.
Exactly.
The fun exception to the success was the time I tweaked something and broke the garbage collector, and we only found out when a job went back to the client with completely bogus results. An educational moment for me.
Years later at JPL I helped with a new Scheme dialect. It was partly in response to the politics described in "Lisp at JPL" https://news.ycombinator.com/item?id=2212211 -- we could say "this is actually a C program, see" -- but the language design was quite nice, IMHO. I can say that without backpatting because it was mostly done before I came in. Influenced by ML and Dylan; a shame it never was released.
Before this, I was on a team building a programming language for financial analysis. It had basic javascript semantics, was interpreted, and mostly returned results as data visualizations to browser based UI. Why? Because the investors believed there is a significant market for bundling data sources, along with a proprietary programming language to hedge/mutual funds. The real difficulty in achieving this is the man-years of time required to build a language capable of reproducing the same analysis used in by quants in production before ever being able to apply a technology, like GPUs, you bet can make things better. It can be especially difficult for the business leaders to make decisions that impact a programming languages development, as the highly technical quickly meets the business relevant. If you ever go this route, have system architecture/design for the programming language that will bring you to a MVP. Otherwise, you'll be paying developers to play with prog lang ideas for years!
The Binary Lambda Calculus is described in [1],[2] and further inspired this IOCCC winner [3].
[1] http://tromp.github.io/cl/Binary_lambda_calculus.html [2] http://tromp.github.io/cl/cl.html [3] http://www.ioccc.org/2012/tromp/hint.html
EDIT: there's the paper https://www.cambridge.org/core/journals/journal-of-functiona... citing an exponent of 1.963447954...
This is true for the encoded lambda calculus prefix; but not for the entire BLC program in which you can embed arbitrary binary data.
> In theory this means you could create shorter programs
Not really; BLC is universal, so program sizes are optimal up to a constant. In other words, for any language L, there's a constant c_L, such that for all x, the complexity of x according to BCL is at most a c_L larger than the complexity of x according to L.
At the time, there was no mainstream realistic option for embedding popular languages that lots of people knew into C applications. A few years later, I'd have solved the same problem with Tcl and a few extensions; then Python, then Javascript.
(1) Strix, a rule-based language with SNOBOL4-style string pattern matching.
(2) ENeMaL, a rule-based expert network management language.
(3) Gossip, an object-oriented Prolog
(4) Emblem, a Lisp dialect.
I've been using Emblem to develop
(5) Full Metal Jacket, a visual dataflow language (http://web.onetel.com/~hibou/fmj/FMJ.html)
There will always be a demand for domain-specific languages. I'd think hard about developing general-purpose languages. There are plenty out there already, and you could contribute towards them instead.
If you want to develop a new language for release, it's a good idea to develop several others first for your own use to gain some practice and learn what's involved.
Why have I developed Emblem? I wanted something simpler than Common Lisp, but didn't want to rely on third party libraries. It has support for 2d and 3d graphics, statistics, symbolic AI and a few other things.
Why have I been developing Full Metal Jacket? I wanted something significantly better than Lisp, with directed graphs as the fundamental data structure, extreme type safety, and the ability to run efficiently on multiple CPUs.
It isn't ready for release yet, and I'm taking a break from it at the moment. I'll consider it a success when I start using it in preference to Emblem.
Mostly we value declarative specification, however some domains do require in-order recipe style expressivity. The more problem-space the language can be, the easier it is to iterate, catch problems early & easily, report more meaningful errors, and optimize the compilation.
It's a craft, but I honestly think it's not a hard one to pick up. The major thing is being able to step back and think about the problem humans are tackling, not grabbing your default C style (or whatever) and trying to bolt it into some solution space. As programmers, it's easy to give zero thought to all the boilerplate and machine-fiddling required for typical programming; you must set that aside when starting from scratch with a new problem. You must also realize when existing or in-progress solutions become boilerplaty and fiddly, and have the wherewithal to step back and notice that it's not expressing the correct level of abstraction for the problem.
We've supported Bloomberg, ADP, nuclear power plants & other utilities, etc, so we need something truly viable, robust, maintainable, and worth the client's money. You have to think in their shoes, understanding the industry vocabulary of the user. You need to give them tools that closely match their natural expression of what they want the machine to do, not divert them into being programmers, yet still have all the power they need for their tasks at hand. It all starts with having a great business analyst.
We're currently working on a port to Linux and a commercial version. If you're intrigued, I'd love to chat.
I had fun with the project, learned some stuff about interpreters, and also learned that infix notation for things like arithmetic is actually pretty neat and we should probably keep using it.
I also wrote a BPF-like JIT for network packet matching once, targeting the QorIQ pattern matching engine as a backend.
One aspect of the language was that Unix regular expressions were a built-in type, and so were associate arrays. These two features worked together in a cool way:
x['hi there'] = 5
x['hello'] = 2
# regular expressions are enclosed in `backquotes`
x[`hell.`] == [2]
x[`h.*`] == [5, 2]I was unaware of compilers at that age, and came across a machine code sample which ran about two orders faster than BASIC. That motivated me to "invent" a compiler and create this proof of concept.
It was mostly useful for writing boilerplate code only once; stuff like class declarations that had to change in sync between parts of one code base. But it grew from there to the point where it let you express 'pure' algorithms in this language so that you only had to write them once, but if you wanted to you could 'override' parts of it in the target languages. It was the bastard child of a compiler and a macro processor. It saved me many, many hours writing tedious boilerplate; however I don't think it saved me more than I spend on it.
It has to be in one of my zipped up archived subversion repos somewhere...
It lets people with Python 2 code start to use new features from Python 3. (It's a backwards-compatible fork of Python 2.7 with features like async/await, function annotations, and keyword-only arguments backported from Python 3).
I was refactoring a very complex class at work that was hiding a very unsafe one liner of python doing a «safe» eval that was nowhere near safe. And after 3 days of mine + the 3 weeks from the team that appeared in the git on the work of this class, I thought, well I am told I am an idiot, but I am pretty sure one can make a safe language that only includes what customers need without taking as much time as this disgusting pile of obfuscated unsafe junk.
I did a forth based language in 16 hours on my spare time that was having the minimal requirements that satisfied real use case of all the customers.
Proposed to replace it after showing vulnerabilities.
Then I was shouted at by the CTO because it was undermining is great technical choices.
And then I realized that this Access Provider did not cared about neither their security nor the one of their customers, just about their nice boats and expensive cars and were just milking the internet users like any other ISP.
Creating your own language is dangerous ; it can make you think about too much things, do not do it.
Forgive me, but I'm leaning toward siding with that CTO on this one.
I seem to make mini-languages quite a bit now. I operate as an integrator between logical systems of complex software. I've found mini-languages, often nothing more than a macro text replacement engine, is all that is needed to enable fluid integration between vastly different technologies. The KISS principal 1000%.
[0] I think my oldest is "Compiler Construction for Digital Computers" by David Gries. My favorite isn't really a compiler book, it's Wirth's "Algorithms + Data Structures = Programs" because he implements PL/0. I used to have some PDFs by Thomas Christopher that used matrices to computer first, follow, etc sets that I thought was interesting, but have since lost those.
I also created language for describing processes (company processes).
Mostly for fun and to scratch my own itches.
* http://cirru.org * text.cirru.org (temporary solution) * https://news.ycombinator.com/item?id=13773813
I was trying to explore the expressiveness of graphical editing(at first using indentations). And it ends up with a nice tree editor that I can editor as DOM. With DOM, the layout of the code is actually the layout of AST controlling by algorithms that is responsive to screen size and AST structure.
My recent endeavour was a language with only five constructs that would mimic mathematics in the way we program:
= assign
$ print
@ loop
? condition ! else
# definition/function
$ 'Hello world'
I thought developing a browser extension to allow Uno being run from the address bar for quick calculations would be an interesting project.
say 'hello world'
let list = [1,2,3]
for item in list: say item
def add(x,y): ret x+y
is? a=1 say 'ok' no? say 'wrong'
The interpreter is written in C and is open source [1]. There is quite some old documentation here [2] (needs to be moved, this was from a google code wiki). An online demo with several example programs can be found in [3] but it does not have all the latest features of the language.
The interpreter is completely asynchronous (uses epoll etc; this is why the Javascript demo was so easy). It has many build-in modules that allow to do quite a lot of things (including sub-processes with pipe I/O, TCP client and server, receiving events from input devices, observing devices through udev events).
The language is actually built from a relatively small core which defines the syntax and basic semantics, and a larger set of modules which implement different statements. Many of what would in other languages be part of the language exists as a module in NCD, e.g. the var() statement and even If.
And here [4] is a real program written (mostly) in this language, that does something completely different from network configuration (allows controlling a Sphero robot using a joystick).
[1] https://github.com/ambrop72/badvpn/tree/master/ncd
[2] https://github.com/ambrop72/badvpn-googlecode-export/blob/wi...
[3] https://rawgit.com/ambrop72/badvpn-googlecode-export/wiki/em...
Now I'm creating Intrinsic, a programming language with a modifiable grammar while runtime. Because I found no tool chain, I published pyPEG, which is an compiler interpreter https://fdik.org/pyPEG/ Intrinsic will have a generative paradigm.
It has some features we miss in other languages (extensible&structural product and sum types), but also makes different trade-offs (all names are GUIDs behind the scenes, parameters to multi-param functions are [almost] always named).
https://medium.com/lamdu-blog/designing-programming-language...
Because awk sucks and SQL is too constraining.
My only attempt at making a "serious" language was np-lang (http://np-lang.org/tutorial - but it's defunct right now). Initially I made an interpreter in Java, later I made a parser that creates bytecode for a slightly mutated Lua VM. The reason why it's not being maintained right now is that, while basing the runtime on the Lua VM was attractive at first, it was really a dead end for me productivity-wise because I ended up spending more time with the Lua internals than was practical.
The reason why I started the np-lang experiment was that I wanted to experiment with a language that could ultimately become my scripting language of choice for web projects. I was never happy enough with it though.
I'll probably try again to make a language with that goal in mind, when I have some time and motivation to spare.
Apart from that I created several toy programming languages over the years because it's fun and I think it's also practice that can make you a better programmer by gaining a deeper understanding of the design decisions that go into a programming language and its runtime.
I also made some project-specific DSLs, mainly to facilitate configuration and user scripting. And simple, BASIC-like scripting interpreters for toy RPG projects.
I have created many in my life, non of them open source (yet; the one I am chewing on now will be I think), most of them toys, the most successful one really niche and those same successful ones embarrassingly crappy. I wrote a PHP before PHP (in Perl as well, guess it was meant to happen :) and it made me a lot of money being able to write dynamic web applications without much of the plumbing at the time. I wrote a bunch of 4GLs for finance and web CRUD applications, all sold as addons to our CMS early 2000s. After that I wrote a lot of toy languages which I meant to put on github some time but I don't think they are of interest to anyone anymore by now. I write, for my own sanity, Forths when I do embedded work, assembly work and/or work that doesn't allow me to have interactivity for development.
They 'why' is easy; the feeling that things are just not as efficient as they can be and the drive to do something about that. That will never leave me and it did give me a lot of competitive advantage over the years. Mostly in the end I end up with something that, after postmortem, would've been easier with Lisp. If I surpass that point in my life, I succeeded.
* Helped write a C++ bindings library for Ruby. I was finally getting sick and tired of doing everything in C++, and paying the cost in undefined behavior and compile times, but hadn't given C# a proper try yet. Bugs in the C API for exception handling eventually convinced me to abandon the project IIRC, but we had something functional.
* Company-internal modifications to a C++ bindings library for Squirrel, Sqrat. Bugfixes for UB, adaptations for custom smart pointers, logging, replacing exception-throwing logic in later versions... was at a company using it professionally and was encountering bugs, compatibility issues (we couldn't compile with exceptions enabled for all platforms), and poor debugging support (which I 'fixed' by adding a lot of dumping options for callstacks and the like.)
* Wrote a flash bytecode rewriter utilizing RABCDAsm. This wrapped all method calls - and statements within methods - in additional logic to track the current callstack. Our flash embedding solution didn't let us debug flash very well, but these modifications let us get real callstacks for unhandled exceptions and other errors. As a bonus, I was able to reuse much of the logic for a simple tracing profiler of sorts.
It's been perfectly usable for a while now, but it's not yet complete. Static tools for automatically identifying uses of potentially unsafe C/C++ elements in existing code, and (at least mostly) automated translation are still being worked on. And there are still elements that are missing safe substitutes (like std::string). So, if anyone's looking to kill some free time... :)
[1] https://github.com/duneroadrunner/SaferCPlusPlus
[2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
I had to query lots of data from webpages, so I made a pattern matching language where the program is a sample of the webpage. E.g. to query the the text of <span id="foo">some text</span>, you write the "program"/pattern <span id="foo">{.}</span>. Or if the webpage had multiple <span class="foo">some text</span>, you would use the pattern <span class="foo">{.}</span>+
Then I noticed, you sometimes need more expressive power than simple patterns, e.g. returning an element depending on the value of another element, so I added variables and allowed some kind of XPath expressions inside the {}. It was not really XPath, because XPath 1 has no variables, but after a while I noticed, XPath 2 has variables. There was no XPath 2 interpreter for the host language, so I implemented a standard-conformant XPath 2 interpreter for this. Not really my language, but my implementation of a language. Later I updated it to XPath 3, which became far more complex than expected, since XPath 3 does not just has variables, but is fully Turing-complete with anonymous functions. And a type system with 50+ different types. Makes JavaScript look trivial. I also noticed, XPath 3 is almost the same as XQuery 3, so I implemented that, too. http://www.videlibri.de/cgi-bin/xidelcgi
Which brings us back to your XmlPl, because XQuery was designed for the same tasks. That example node[] main() { <title>helloString;</title> } would become declare function main() as node() { <title>{$helloString}</title> } in XQuery.
Previously I made a completely different XML processor for my personal webpage. Keep all content in XML files, make an HTML file for the layout of the webpage, and then insert the data from the XML in the HTML at statements like {{$WRITE some/kind/of/xpath }}. It had control structures {{$IF}}, {{$FOREACH}}. I thought it was a good idea to keep the program separate from the markup, but it only looks confusing, so stopped using that language.
Most recently I made a language to sort my mails when they arrive on the server. More a toy than a full programming language, but the cleanest way to keep those filters http://hg.benibela.de/mailfilter/
I love that approach. Don't let non-essential constraints limit the elegance of your solutions.
http://little-lang.org is a C like scripting language that compiles down to tcl byte codes (so it can call tcl and tcl can call it). Why? Didn't like tcl, did like tk (still feel the same way). And I always wanted a scripting language with structs, I just like how structs are sort of a self documenting part of any program.
Also created an unreleased version of awk that made awk scripts first class, you could have
awk_script | awk_script
Also created a "language" for processing deltas in a version control system. This one is pretty obscure but pretty useful. Patterned after awk, so there is a begin/end and then the body is called once per delta. Here's an example that digs out the commits and displays them in JSON format:
http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt
when reading this one the rules are that stuff in double quotes is what is printed, the rest is logic.
What my DSL did was translate a lot of language into terminology that made more sense to people in that space, and wrapped frequently used combinations of functions together. I.e. if we wanted to test if an element was present in the navigation bar, we wouldn't have to find the navigation bar slideout toggle switch, validate that it was open or open it, ensure that the navbar was populated, then use an xpath query to determine whether it was present, we could just declare a simple one line test.
I had no experience with building DSLs (Domain Specific Languages) previously, no experience building an IDE, and no experience with creating or parsing syntax trees. I just knew that there was a problem and it needed to be solved.
What was conceptually very simple turned complex quickly as I ferreted out the long term goals and researched how I could build something that I could responsibly transition to people less willing to hack their way through things.
I could have built an API rather than a whole new language, but I had compelling reasons not to go that route.
Did it catch on? Yes, and no. It's been 4 or 5 years since I released it to a customer and it's still being actively used. The entire target market was less than 3000 customers, so it was never going to be a household name.
I have to say it was one of the more eye opening projects that I have taken on. The growth experience was infinitely valuable, and like all lower-level things it provided great perspective that can be useful on a variety of projects.
I made it/am making it mostly as an exercise. I like to know how things work, and there's no better way for me to learn than by doing. It's also just fun to make stuff. Last (and definitely least), it's an expression of a certain degree of frustration I have with the current offerings. My dream language—oh, maybe I should've named it "dream"—would feel like Ruby but have static types and no nil references. I wholeheartedly acknowledge the tension inherent in that statement; much of Ruby's power comes from its dynamism. But like I said, it's just an exercise. :)
Not sure if that qualifies as not-a-toy-language. Is a language's "toyness" based on its simplicity, or its intended use?
Chair:
(legs: Cylinder, seat: Slab, back: Slab)
{
attachment(legs, seat)
attachment(seat, back)
}
TestType1:
OriginType
(
a: unsequence[x: Type2, xor[y: {Type3}(), z: type4]],
b: optional[Fruit], c: >3[pet: Animal], d: 2[Animal(Blah){}]
)
{
constraint1(x, y, z)->recognize->toInt
constraint2(x, z.a.b.c)
constraint3(z, y)
}
I also realized recently that my main 'innovations' were already covered by the logic programming paradigm decades ago, so that has discouraged me some. (And I've recently started thinking that machine learning will be better for doing procedural content generation than anything produced by explicit descriptions.)
From the white paper, some of the problems Hello aims to solve are (1) Repeated re-coding of the same distributed primitives; (2) Challenging development process due to the combination of a programming language and extraneous library; and (3) Inefficient and unreliable distributed code.
Here is the white paper and reference guide if anybody is curious:
White Paper: https://docsend.com/view/zfcz7sh Reference Guide: https://docsend.com/view/65tbeht
Edit: Thank you omg.lame.dont.dotis@wtf.example.com (email edited) for the feedback. We have email capture by default because we use DocSend for sales collateral, but we've turned it off for these white papers. They're downloadable too, if you just want the PDFs.
[1] I worked for a neuroscientist [2] out of the Math Department writing software.
[2] Dr. Arnold Mandell (https://en.wikipedia.org/wiki/Arnold_J._Mandell)
[3] It would win a "Most Abuse of the C Preprocessor" award, due to writing my own template package, long before C++ had templates. Also, the language written in C, not C++. Abuse indeed.
I decided to try to work out a proposed architecture on a pad of paper during a transcontinental flight. I created a mockup simulator that seemed to work and then borrowed some hardware to see if there were any problems. There weren't any that weren't quickly fixable.
I brought in my language to my company's owners, who told me they were going to buy the language they used for $300,000. I told them they could have mine for free.
I have 2 ideas.
the first comes from the difficulty of using make. I think the make system lacks debuggability, it's not easy to log, break, step through and watch locals.
I feel that building should be handled by a domain specific language, instead of make.
I haven't researched enough though, there may be something similar, only it is not popular yet.
the second ideas comes from the difficulty of documentation.
I'm thinking of a programming language that allows you to describe the block diagram (modules) of your program easily. You need to specify what the interfaces are, how many threads ....
then a diagram can be automatically generated as a document. you then fill the internals of your module, with classes. The idea is always forcing programmers to describe design first, then implement. code and document are mixed, so the document is always up-to-date.
* cmake
* premake
* ant
* scons
* ninja
* gyp
* jam
* gn (Google)
* meson
Your second idea is basically UML and some of the tools that exist for it.
[0] http://ndmitchell.com/downloads/paper-shake_before_building-...
Its core feature is emergence/composition, to demonstrate its power, let me show you a SCARY example of a factorial function:
factorial : [ = ] ? 1 | [ - 1 factorial * [
Now, let me show you the exact same program using an EVEN SCARIER "language pack" (note, this is the exact same program, nothing is different) here:
Define the factorial function to be that if the left parameter is equal to the right parameter then return 1 else wise please take the left parameter , subtract one , recursively calling the factorial function again multiplied by the right parameter .
That terrible "english" is the EXACT SAME program as the first line, the interpreter doesn't know there was any english. I do not recommend ever coding with plain english, but it demonstrates the power of emergence/composition/currying with the language.
If anybody is curious, I'd love to explain more / chat with people / show demos. I'm ultimately going to switch the programming language's interpreter to be built with a database (the one I'm working on, http://gun.js.org/ ) so that way I can have a Turing Complete database system. Once that is working I will then be able to evaluate programs across multiple machines simultaneously and modify programs dynamically on the fly, as well as reduce O(N) operations to O(1) by spinning up N number of machines (for large enough data sets that make it worth the overhead of splitting up the load).
I wish they recorded the talk, I'll have to do it again and post it. It had a lot of other interesting ideas, like combining it with Machine Learning to sample inputs and outputs of functions to see if the computer could optimize algorithms and then issue a pull-request to its own code, becoming a contributor. :)
Each media and format had a configuration file, it was inside of this file that variables and functions were defined. If you tried to call a function that was not defined in your context that part of the tree was removed from the output (figuring it was better to make the output than to fail). This also meant that you could branch and override functions and variables dependent on the media or input format.
I regret nothing.
A lisp using json instead of sexprs. e.g. ["op", "arg", "arg"]. The team had a couple of requirements for a service we wrote: 1. Need to do batching. 2. Need to do stored-templated json responses based on data in our DB. 3. Need to not cost the project more than a week.
We had worked around #1 and #2 in awkward and debt riddled ways. (The client of the service was PHP with lack luster JSON processing, the service was java) So I whipped up Lispon and evaluator in about 3 days and had it integrated in another day.
It's lifespan was intended to be somewhat short, but like all code it's somewhat slow to get replaced and is doing its job adequately. JSON based sexprs are terrible to read.
1) I wanted to see how far you can go by making every language concept first class, because only first class things can be an abstractions.
2) But another big motivation was that languages usually grow towards building large systems in. I wanted every tradeoff to go to the human side, making it more suitable for beginners. For example, 0.1 + 0.2 = 0.3, slower by not using native floating point numbers, but much more humane. Similar motivation to remove the import statements. Or no difference between object fields or methods, e.g. string.length is the same as string.length().
Part of what I tried is that the smallest subsections of the language would be complete and useful by themselves. Without ever having to say: "this part you do not need to understand yet". That is where the "beginner friendly" part focused on.
Not by making it "simpler" if that would sacrifice first class-ness. Say JS with its global scope promotion, maybe easier, but not first-class, clashes are inevitable.
And for example, the no import thing is based on very predictable scope rules, which can be postponed while learning, but later are completely deterministic and predictable, while still first class, so that the programmer can have control over it if needed.
But in a way it was mostly an experiment to get my thoughts clear on these matters. And for instance the concurrency things in there have less to do with beginner focus.
- C/C++/Java/Javascript like syntax
- Be able to write a subset of C/C++/Javascript (meaning it can be interpreted or compiled when performance matter)
- No global variables by default, warning when locals are overridden
- Clean hash tables (no builtin methods/preperties)
- Fast enough (sadly it can't beat lua/luajit)
- Small and easy to extend (one man can master it)
- Cross platform
...
But 'creating a language' is just a tool in the programmer's tool box that allows a set of capabilities to be strung together in different ways automatically. That has been a useful tool ever since Jacquard used it to program his looms.
I did it again years later when I was writing another game engine, this time sprite-based. In this case, I could've used an external scripting language like lua, but I figured it would be fun to learn what it takes to write my own language.
I learned a ton in both cases even though they were really toy languages that were meant for a very tiny scenario.
The interpreters are available at:
I'm working on a cross between IF and LP-style MUDs with support for graphics and sounds, using Io as both implementation language and scripting language (and probably Nim for GUI once I get to it). The code lives here: https://github.com/piotrklibert/mrtr and is currently a mess, I also got side-tracked and started porting pyparsing to Io to get a nice DSL for parsing user's commands, but the idea has been on my minds for a very long time and I'm determined to finally do something about it.
I'd be happy to learn more about your project and to chat about it if you'd like.
The reason I gave at the time was: "If you have to ask, then you have never been stuck in a hotel room in Fort Worth with no internet access." (This was 2003)
1. https://esolangs.org/wiki/Toadskin
Edit: Actually there's more than one bug there. I'll get it fixed before I revive it.
It was to provide a client the flexibility they "needed" for data validation specifications.
It was a mess. We suggested many alternative routes, but the client insisted on this. We did make the saner decision to go with an already-established markup language.
We couldn't even do the full XML version, as the client didn't want to "do XML".
I created it to eliminate:
1) Situations where different people in an organization have conversations about the same thing and reach different results, not being aware of the duplication
2) Situations where lots of people in an organization are forced to copy and repeat the same information over and over again
3) Churning and duplication of effort where various people and teams are learning about how and why an organization works and how their work fits into the big picture
4) All the noise and churn it takes for a team to ramp up on a story that it hasn't seen before
- https://github.com/fold-lang/fold/wiki/Language-Overview
The language syntax is defined as a library and can be extended, which makes Fold ideal for DSL implementation. The powerful macro system can also be used to perform many static optimisations. My goal is to have a very flexible and performant language specially suitable for data processing.
I'm mostly doing it for fun, but also to make it easier to use tablesaw for exploratory analytics.
The why of it is simple: I designed it to make me happy in my work.
I've made a couple of products with it, but I don't think anyone else has ever used it for anything.
It's between versions at the moment, experiencing yet another assimilate-then-simplify phase.
> and why
I didn't intend to. It just happened. And now it's used for all kinds of things it can't really manage because it doesn't have the fundamentals right - it was just supposed to do some simple formulas and it's too late to design it like a proper language.
This is how both js and php were born I imagine...
A C like language with golang like syntax. Pure Go language implementation.
https://shanhu.io/smlvm - shows the dependency structure of the project.
https://github.com/shanhuio/smlhome - example code that we wrote in the language.
For better programming experience on touch screens.
Some time after that, the Julia language came into existence (http://julialang.org/) which is pretty much everything I wanted out of a language.
http://cowlark.com/cowbel/example.html
It's an attempt to take as many features as possible out of a language and still have an expressive Javascript-like language. It worked pretty well, but of course, actually producing the compiler is the easiest part of any new programming language.
Features include:
- all types are anonymous (although interfaces are named)
- aggressive type inference which allows the compiler to distinguish between scalars, direct objects and indirect objects (via a vtable) at compile time --- not only does it do direct function calls if it knows what type an object is, but you don't have the scalar/object schizophrenia that Java and C++ does; integers are just objects implementing the int interface, but there's no object overhead
- very limited compiler knowledge of the language semantics --- int semantics like addition, subtraction etc are defined in the standard library
- template-based generics, full closures, nested functions
- multiple return values
- objects, methods (but no classes)
- non-nullable
- compiles into C for maximum interoperability
It was going to have prototypical inheritance via composition, where an object could inherit methods from an arbitrary number of other objects, but I never got round to implementing that bit.
One of the bits I'm most proud of is that I managed to unify block scopes and object constructors. {...} constructs an object. The only difference between one used as a block and one used as a constructor is whether you assign the result to anything --- the compiler just optimises everything away is you don't! This makes nested functions and methods identical, and drastically simplifies the language semantics...
if (condition) { thisIsABlock(); }
var object = { thisIsAnObject(); }
I also came up with an idea to build a common intermediate compiler so you could use C/C++, asm, BASIC, custom language etc. on top, then a descriptor/translator file would compile to a common assembler base. This was on the Amiga (and some years before .Net).
- typesafe portable macro assembler. Used for those cases when people want "close to the metal" behaviour of C, but with less footgun potential.
- Archaeology of old language features that have been thrown out with the bathwater (e.g. COBOLs use of '.' as statement terminator, "PIC" statements)
- attempt at Perl-style language which optimises for English text readability, comprehensibility and euphony
I got so sick of writing one-off SQL queries that I wrote a very small (not much bigger than a calculator) language to express their questions. They liked it, but it had no potential for use outside of our trading desk (which was disbanded a few years later).
Professionally, no, but I've taken the approach of "I'm writing a compiler" when ingesting someone else's xml schema.
It's very useful when you need to identify and report errors very early.
Many years ago, I wrote BNF-like language to translate text into syntactic tree, it was part of my graduation project.
I also wrote a Lisp-like lexical preprocessor as an alternative to the standard C preprocessor, it can be used with other languages, for example, with Python.
I would have done it completely differently had I started again today, but it works, and "life" example code is kinda nifty.
Fairly simple language, parsed and executed in Perl. I doubt it survived long after I left, sadly.
I am not aware of any languages with 2-adic number primitives, so created one!
Sure, http-based rpc mechanisms won, but it seems like agents have a lot of promise for parallelism and code deployment.
I made a postfix stack language as a scripting system to describe bullet patterns; I didn't use it to the degree I thought I would and it was hard to debug: Lessons Learned.
I made an s-expression parser and small interpreter(not particularly Scheme-like, though) for an in-game console. It added a lot of friction to make the API accessible from this parser: Lessons Learned.
I made a data language intended to allow for the composition of documents with varying node types. Subsequently I realized I had reinvented XML and started using that instead.
I made a small VM, "Ivy", intended to provide a logical abstraction for concurrency(e.g. game actor state machines), with subthreads spawned and maintained by running a special opcode(they get pushed onto a stack, and then terminated when the opcode at the base of the stack returns false). I then target the VM as the output of various data languages. The approach didn't really provide wins in practical situations as it turned out to be more expressive to have the VM spawn more instances of itself through an API call, but it has continued to be maintained and revised and the newest generation, renamed "Hedera", is mostly designed but not operational: It's shifted to a single-thread design and a new focus on clean, hot-swappable addressing of global data resources(think URIs) which I'm using throughout the game code now.
I made an XML-syntax GUI system to supplement an IMGUI. The document acts to represent the kinds of things that are normally stored in a retained-mode layout(positioning, nesting, relative scale, etc.), and it offers finer control with explicit stack push and pop and conditionals for quick disabling of elements. I'm still using this one.
I made a story engine scripted with an XML syntax. This one uses the Ivy VM described above, first compiling the data to a behavior tree system, and then to the VM opcodes. It supports concrete functions for gameplay(setting counters, rendering text, presenting choices, substituting names and personal pronouns) as well as their structuring in terms of which ones get called when, pushing story passages onto a stack, transferring outcomes to hardcoded algorithms, and support for recalling save games if the story content changes. There is a lot of customization that precluded working with Ink, Choicescript, Twine, etc. - taken in whole, the stack is probably overengineered and could have been built faster/cleaner with different approaches, but it works.
It has no intended adamtages other than to learn how a language is created.
I'm creating a small virtual machine based around the idea of associative memory (read: tuplespaces). I'm going to use it to write a ton of declarative code for smaller devices and for some of my own projects.
the opcodes are still in a state of flux, but a partial implementation exists in Python, with the intent of porting everything to C and getting a spec up. you have operations like 'match', 'exists', 'assert', 'retract', mathematical operations...
...oh, and no callstack. ;)
(Been thinking about a language more Object Oriented than Smalltalk for a few years on and off, but not yet.)
Because time. :(
Why ? Between 2008 and 2013, Lokad provided a data forecasting API : send us your sales history and we'll respond with a good sales forecast for each product. This didn't work because:
- most customers don't have the know-how or infrastructure to clean up their sales history (for instance, by setting up adequate SQL queries when exporting data to our services), and instead either sent us garbage data, which led to garbage results and therefore lost us customers, or they cleaned up the data manually in Excel, which prevented us from being a permanent, automated step in their supply chain processes, and therefore lost us customers.
- most customers don't care about knowing the future, they care about knowing how much they have to order from their suppliers. These decisions can certainly be optimized if you have a good model of what the future looks like, but that involves even more knowledge about the customer's business and even more data (expected margins for products, current stock levels, minimum order quantities for various suppliers, etc).
Most of our sucesses in this early period were premium customers for which we could afford to write and run custom C# code that did the initial data cleanup and pre-processing, and then used the forecasts to generate a list of actual business decisions.
As you might guess, C# is not the best language for this. It costs too much to write, deploy, maintain and run. We examined the various candidates available at the time and decided to write our own language, with the following characteristics:
- 100% online, no local setup needed
- excellent static analysis to detect issues ahead of time (no type errors, null references, off-by-one or out-of-bounds errors, join arity surprises, etc)
- good high-level guarantees (no infinite loops, no accidentally quadratic operations, fully transactional behaviour)
- fast enough without manual optimization
- predictable performance (small changes in the input data should not cause major changes in execution speed)
- handle the "hard developer stuff" behind the scenes (multi-threading, memory management, error recovery, caching intermediate results to make REPL faster, etc)
- our various high-performance black boxes (such as demand forecasting) are available as functions in the language
- a small, well-designed (supply chain) standard library
Between 2008 and 2010, I created a language with Java/C# like syntax, C/C++ like semantics, strongly-typed but with type inference that was meant to be embeddable into C++ apps. I wanted to use it to create a game. However, I didn't want to created a Virtual Machine for it, so I opted to use the Parrot VM[1]. The choice to use Parrot was huge mistake because that project turned out to be a clusterfok that never worked right, even though they had been working on the VM for close to a decade, by that point. I abandoned that language and moved to another language because there were no other VMs that suited me, at that point.
Since I was burned from the Parrot VM fiasco, I decided to create another language that didn't rely on a VM, so I created a general purpose API design language. In this language, you design APIs, and then write 'generators' in JavaScript that transform the API code to the final output. The benefit of this is that you only have to create one generator for each type of code/asset that you want to create, and use the same front-end API code (call schemas). So, for example, you can create a schema for some Amazon web-service, and then have generators that would output different types of clients, or some test-servers, or automatic documentation, sample inputs, dashboards, graphs, whatever based on your one schema. The language is written in C++ and it very well tested (close to 3000 tests). My vision is that a developer will design their API schema once, and then use generators (written by the developer or by others) to generate all kinds of things from that one API: client-code, server-code, test-cases, docs, graphs, dashboards, etc. This way, we can focus on actual API design and leave the mundane tasks to the generators. The flow is like this: [schema(s)] -> [compiler] -> [intermediat representation] -> [generator(s)] -> [final output(s)] I think this language is neat.
While I was working on my API design language, I wanted to have really good error messages, and I wanted the error messages to be all in one file, so that I could glance at them easily while developing. So, I ended up designing a micro-language for handling text-templates, where you have things like: "The ($noun) is ($verb)" The thing is, you'll quickly realize that replacing variables is not enough. Eventually, you'll want conditionals, loops, .... function calls (:-0), so I added them. This micro-language is embedded in a couple of files within the API language, but I thought it was neat, so I decided to create a proper text-template language based on it, because if you do a search only for C/C++ text-template language, there are not alot of choices for this. I have the general design for the language completed in my head, and I have a basic implementation of some of the basic things like syntax parsing and variable interpolation and basic function calls, but I paused development on it for now, while C++ 17 hits the streets, because I had a real need for std::string_views to minimize string copying. Also, since I decided to make the implementation of this text-template language more robust and performant for enterprise type of use, I decided to go with an sql-like prepare->execute type of processing; this requires adding a micro-vm for the execution part, which adds to the development time.
https://drive.google.com/open?id=0B6u0pARskZtQNExpdjhfQ0dIbX...
it is a very good exercise to implement a scheme interpreter and LR parser. I have done so many times since 2007 in many different programming languages. It is a very worthwhile exercise that involves variables levels of resistance and some difficult work. The wikipedia article on LR parsers is very helpful.
Why do people train for competitions? There is such a thing as being best at the world at this stuff, but only in the imagination. There is no real "top gun" prize because you don't want these hot shots going insane with jealousy. It's just an idea. Programming languages help you compete without competing.
In the future, people won't create programming languages because the math will have caught up to handle them. As it is, codebreaking math and classified math are holding this back. I think this will change as soon as people get serious about automatic translation of mathematics textbooks such as the Springer-Verlag series (undergraduate and graduate).
I think I'm going to have to though. I used to like C++ but I really am not a fan of the direction it's moving in. It used to be a simple "better C" that let you write abstactions over simple code that you could understand how