My name is Vaptistis Anogeianakis and I'm a software engineer from Greece. You can see some of my work on GitHub.
By the time I finished high-school I had already written a substantial amount of code in 3 different programming languages and this number proliferated during my university and later years. Yet the more code I wrote, the more it became apparent that the separation of languages into the camp that offers productivity at the expense of performance and the camp that does the opposite, left a huge gap exactly where I wanted to be.
I needed a language that would help me express algorithms in the same terms that I used to learn them and let me delay as many decisions as possible until I have the information to make them. Yet this language should let me optimize my implementation, when I deem it necessary, and in fact help me by collecting the performance data I need to base my decisions on.
For roughly 9 years I worked on this language I now call 'Arcadia' whenever I had the chance, and every time I learned a new programming language, I kept notes on things I could adopt, avoid or improve. Those notes can nowadays be found on BitBucket. But at some point it became obvious this wasn't a project I could finish in my free time.
So I created this campaign to gather the resources I'd need to bring Arcadia to the programming community, a language that I believe will change the way we write code and our expectations from future programming languages.
As I'll explain later, this campaign roughly corresponds to the first year of development and aims mostly at finishing the core of the design and producing the first parser.
Programming languages are the tools programmers use to create the software that runs your computer, your phone, your washing machine and car. They have a direct impact on the cost and quality of that software. The 'right' programming language can directly improve the experience of those making the software and indirectly that of those that use it.
Arcadia will:
- Be as fast as a systems programming language, but more importantly, help you make informed decisions about performance with automated benchmarks.
- Catch errors early, but more importantly, help you gain confidence about software's correctness with unit and property testing.
- Allow you to work at a higher abstraction level with mathematical notation and embedded domain-specific languages.
- Improve your productivity with powerful reflection and code generation.
- Adapt to your needs with extensible syntax and semantics.
I've paid much attention to detail, and Arcadia will feature literally hundreds of changes, small and large, to everything from the type system to the goto statement.
For a more thorough answer you can look at:
Software developers of all kinds. Although the ultimate goal is to improve the quality and reduce the cost of software for end users, those who are going to see an immediate impact in their day-to-day lives are those who build such software.
Arcadia will be a general-purpose language, which means it will be applicable to a variety of application domains.
It will be the best choice for:
-
Performance-critical applications — both high-throughput and low-latency.
-
Scientific computing — e.g. numerical analysis and computer simulation.
-
Game development — both game engines and the games themselves.
-
Desktop applications — e.g. office suites, creative applications and CAD.
-
Systems software — e.g. compilers and operating systems.
However, anything that requires high performance and a lot of mathematics will be a good fit. e.g.:
-
Artificial intelligence.
-
Image processing.
Arcadia will also be suitable, but perhaps not the best choice for:
-
Web applications.
-
Distributed systems.
It may not be suitable for:
-
Safety-critical software where formal verification is already in use.
- Use as an embeddable language. e.g. like JavaScript in web browsers.
Arcadia is a wonderful region of Greece where I've spent some quality time, but this is not why I chose the name. The name comes from the Arcadia spaceship of Captain Harlock anime. There, the artist combined features from historical pirate ship, modern battleship, jet fighter and attack helicopter into something that looked consistent and beautiful, not just a bunch of stuff stitched together, and that's exactly what I want to do with Arcadia, drawing ideas from over a dozen languages.
Arcadia will be a general-purpose, high-level, compiled, statically-typed, high-performance, safe, procedural, class-based, object-oriented, reflective, modular, extensible, concurrent, case-sensitive, free-format programming language with functional influence, compile-time and partial evaluation, limited type inference, dynamic elements, no preprocessor and support for generic, generative, contract and meta programming, unit and property testing and benchmarking.
You can find a brief introduction here.
There is a rather long list here.
No, but there is an incomplete one.
It depends on your definition of "big"! :) Ignoring the standard library, C++11 is defined in ~450 pages while C99 in ~200. Arcadia will consist almost entirely of libraries with ideally nothing built-in, but I imagine people will perceive a certain subset as "the core" language and I hope to describe that subset in a number of pages closer to the latter than the former.
When it comes to the standard library though, all bets are off! There is too much functionality I want to include and too many unknowns.
A few years ago I'd say C++. Nowadays I'm not so sure:
- C++, or better yet, the techniques used by C++ programmers that led to the development of C++11 and later have been a huge influence.
- D was also eye-opening in many ways, including showing me that others are trying to solve some of the same problems and that certain ideas were implementable.
- Most of the ideas on extensibility come from Seed7.
-
SML (and occasionally Haskell) has been my window into the functional world.
- Although not a language, Boost played a significant role as well.
Yes. But this might not be the right question to ask in some situations:
- If you call an arbitrary function at compile-time, it will fail at compile-time whether you have a static or dynamic type system.
- When you incorrectly instantiate a generic function in Java, the experience is a lot different from the one you get in C++, but both languages are statically typed.
So a better question is whether the error manifests in the caller or deep in the callee's implementation and Arcadia's answer will be the former.
It's too soon to tell, but right now I'm leaning towards compiled modules containing some sort of platform-independent code. That will allow library authors to distribute a single library binary. It will also play better with clients' ability to emit specializations of library functions.
LLVM IR's ability to either be executed directly in a JIT compiler or compiled to a standalone executable, makes it look like a good fit.
I wanted Arcadia to be free (both as in "freedom" and in "free beer"). This looked like a good way to fund the project.
But perhaps more importantly, it didn't make sense for me to create the language just for myself. This is a chance to grow a community early.
Yes. The compiler and related tools will be released under GPL 3.0 and the standard library under LGPL 3.0. Any code I send you in fulfillment of the "Translate Your Program" perk will use the MIT License.
Although I'm not purist when it comes to using proprietary software, it so happens that almost all the work done so far towards creating Arcadia, from collecting notes to writing the campaign pitch and editing the video, was done using free and open source software.
No, the notebooks I used weren't from recycled paper. :-p
The industry has decades of experience building compilers and there are good tools and libraries out there to help. Almost every feature has been implemented in some form in some existing language. Others may be new, but straightforward to implement.
There are a few things that don't seem to appear anywhere else and I don't know exactly how they will get implemented (e.g. some parts of the parser and the constraint solver for array lengths). Those are part of the reason I'll prioritize those features and ask only for funding the first year of development: I want to retire those risks before asking for more funding.
The goal I set corresponds to one person's salary plus other expenses, but if the goal is exceeded I might be able to hire some help. I'd delegate non-engineering tasks first though, as not much parallelism can be achieved in the first stages of design.
Eventually I'll have to get help both to divide and conquer and for parts where I have no expertise like locales and porting to Mac OS X. But this will be part of a future campaign. Moreover, since this will be open source, there might be independent contributors at some point!
I've never implemented a traditional, textual programming language. Not even a small one as a university assignment. But I've built a standard-compliant C++11 scanner as part of the cppgm certification (sad story really). And I've built a complete 'compiler' for a visual programming environment.
The latter translated a visual representation that resembled a mechanical drawing (but specified a GUI instead of a physical object) to a system of constraints that was solved to ultimately produce C++ & OpenGL code implementing the specified GUI. It used a technique somewhat similar to this. Although it was largely a proof-of-concept, it incorporated parsers and symbol tables for the various textual parts of the visual language.
Moreover, I've spent years not only using programming languages, but also studying their semantics, understanding their corner cases and implementation methods, reading disassemblies of the code they generate.
Last but not least, I've invested a considerable amount of time over a long period and I'm not going to give up now! I even left my day job because I wanted to see Arcadia and two more projects of mine reach the public. If that doesn't show dedication, I don't know what does!
So far I've:
- Written a prototype of the parser in D. It implements only a subset of the capabilities that are required of the final parser, but fully supports overloading fixity of dynamic operators and juxtaposition with partial support for distfix operators.
- Collected all my notes and partial designs from the last 10 years or so, organized them and made them available here. This was no small task taking almost 2 months and resulting in a document of over 150 pages. I've been updating this document ever since.
Apart from creating this campaign that is. :)
That's a difficult question that usually gets you an answer as concrete as "years".
A university assignment for creating a compiler for a Turing-complete language that contains maybe ⅓ the features of Pascal takes a semester, but a practical language takes a lot longer.
Judging from the history of Clang, D and Rust, I'd say at least 6 years for a contemporary language.
This is a huge project with many unknowns, so I believe the best way to minimize risks and provide realistic completion estimates is to fund it in stages.
In this first stage the parser will be implemented and the core of the design completed. Assuming everything goes as planned, next year I'll use the completed design to more accurately estimate the resources I'll need to start the implementation. And so on!
The following chart should give a rough idea:
![A pie chart summarizing how the efforts of the first year will be distributed.]( "Effort Distribution Chart")
Note that this is not meant to be followed to the letter and that tasks will intermix temporally rather than be carried out in sequence.
By the end of the year that follows successful funding and disbursement by Indiegogo, the following should be ready:
- A document (most likely PDF) that describes the grammar, syntax and semantics of a large subset of Arcadia. The grammar and syntax may be in regular expressions and EBNF respectively or Arcadia's native way of defining them, which should be complete by then.
The subset should contain at least the following:
-
Language: literals, operators, expressions, statements, types, units of measure, declarations, functions, scopes, closures, exceptions, pattern matching, structures, enumerations, interfaces, imports, exports, initialization and termination sequence, compile-time execution semantics.
-
Library: boolean, integers, floating-point, complex, character, code unit, array, vector, string, tuple, map, set, pointers, ranges, slices, DSL for PEGs, streams.
The goal is not to create a complete and final specification, but one that is sufficient for writing examples, guiding initial implementation and estimating its cost. For example comparing with other libraries to make sure nothing is missing or defining the full complement of math functions might need to be left for a later iteration.
-
A parser (most likely in C++), fully documented and tested and usable both as a library and through a rudimentary CLI. In particular it should:
- have over 90% test coverage.
- have over 95% of its functions and classes meaningfully documented.
- be accompanied by build and usage instructions.
- be accompanied by informal proofs of its termination, absence of memory leaks and computational complexity upper bound (not necessarily tight).
Ideally it will cover all the features in the table below, but it should at least cover the features in rows 1–8 and 10–11.
Perk fulfillment will follow the dates mentioned for each perk.
Many languages come with an immutable syntax that belongs to a subset of LR(1), allowing easy construction of their parser by a tool like Bison. Others have a predefined core that can be extended with new operators under some constraints. Arcadia will join a small family of truly extensible languages.
Even without additional operators, Arcadia's syntax will most likely not be LR(1). Its parser will have to use contextual and type information intelligently to allow even unambiguous programs of ambiguous grammars. And that while keeping computational complexity linear with respect to the length of the input.
Like Arcadia as a whole, its parser will combine features rarely, if ever, seen together. The situation is best conveyed using a table:
| |
C |
Java |
C++ |
D |
ML |
Prolog |
Fortress |
Seed7 |
Arcadia |
| overloading operator semantics |
❌ |
❌ |
✔ |
✔ |
❌ |
❌ |
✔ |
✔ |
✔ |
| overloading membership (.) semantics |
⁃ |
⁃ |
❌ |
✔1
|
⁃ |
⁃ |
❌ |
✔ |
✔ |
| defining new operators as pre/in/postfix |
❌ |
❌ |
❌ |
❌ |
✔2
|
✔ |
✔5
|
✔ |
✔ |
| overloading operator fixity |
⁃ |
⁃ |
⁃ |
⁃ |
❌ |
✔4
|
✔6
|
✔8
|
✔ |
| defining new distfix operators |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
✔7
|
✔ |
✔ |
| new operator definitions in local scope |
⁃ |
⁃ |
⁃ |
⁃ |
✔ |
❌ |
❌ |
❌ |
✔ |
| juxtaposition |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
✔ |
❌ |
✔ |
| chaining |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
✔ |
❌ |
✔ |
| user-defined literals |
❌ |
❌ |
✔ |
❌ |
❌ |
❌ |
❌ |
❌ |
✔ |
| new operators not separated by white space |
⁃ |
⁃ |
⁃ |
⁃ |
❌ |
❌ |
✔ |
❌ |
✔ |
| removing existing operators |
❌ |
❌ |
❌ |
❌ |
✔3
|
✔3
|
❌ |
❌ |
✔ |
| operator status is part of the type |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
✔ |
| operators introduce scopes and definitions |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
❌ |
✔ |
| 1 |
Only forwards member names not found in class or struct to a special template function. |
| 2 |
Postfix is not supported. Prefix can be simulated by omitting the parenthesis in function call. |
| 3 |
Pre/in/postfix operators can loose their status. Other constructs like lists can't be changed. |
| 4 |
An operator name can't be infix and postfix at the same time. SWI Prolog doesn't support it at all, while YAP Prolog only supports simple cases. This claims it's prohibited by the ISO standard. |
| 5 |
Fortress doesn't as much allow 'defining' new operators as 'assigning meaning' to operators from a large but fixed set. Properties like precedence and associativity are predefined. |
| 6 |
There are some restrictions. Most notably there can't be whitespace between postfix operators and their operands. |
| 7 |
Bracketing operators are supported, but other constructs like if-then-else are not. |
| 8 |
An operator name can't be infix and postfix at the same time. This is based on the reference implementation. I have found no documentation of the limitation. |
This was perhaps the most difficult decision I had to make while preparing this campaign. What's the minimum amount that would make this possible? There are no manufacturing costs. I can also do most things myself so there is little to be paid on wages. A laptop or a printer would help, but the real resource going into this is my time: a year of it.
As I mentioned earlier, this isn't something I can do in my free time: it has to be a full-time job. Moreover I'll have no other source of income during this period, yet I'll need to sustain myself, pay the bills,... even live a little! :)
There are a lot of ways I could go about pricing a year of my time, but the annual salary at my last job — adjusted for updates in tax law, currency rates and related factors — seemed the least arbitrary.
This proved harder than it sounds. Partly because Greek tax law changes so frequently lately that even tax consultants have trouble keeping up. Partly because there were many options: like creating a company or not. It's also not uncommon for a year's income to be taxed retroactively using next year's updates in tax law, so the following is really a best guess:
![A pie chart summarizing how the $60,000 funds will be spent.]( "Money Distribution Chart")
This is a "fixed funding" campaign so, in the event that the raised amount falls short of the target, Indiegogo will refund all contributions to the backers that made them instead of transferring them to me.
The project, of course, will be canceled and the language won't be finished. No perks will be sent.
I have some stretch goals in mind for that case.
Apart from that, more money will mean more people working on the project and/or the same people working for longer. If only the requested amount is raised, the plan is to run a second campaign the next year. If the goal is exceeded by a meaningful amount, I'll delay the second campaign and start working on other parts of the compiler and/or design document immediately after the deliverables for the first year are completed and all perks fulfilled.
Yes and no: with the exception of "Discuss One-on-One" and "All of the Above" perks, I won't be collecting any personal information directly, but Indiegogo will make some of the information they collect available to me. In particular, I will get access to backers' full names and e-mail addresses. I won't get access to payment information (e.g. credit card numbers), nor shipping addresses (since I won't be shipping anything physical).
The aforementioned names and e-mail addresses will be used exclusively for the purpose of completing this campaign (e.g. sending perks or notifying you of a delay) and I won't share them with 3rd parties, unless absolutely necessary. e.g. I won't sell this information, nor will I send you any advertisements, but there is no practical way I can send you an e-mail without my e-mail provider seeing your e-mail address.
If you have claimed the "Discuss One-on-One" or "All of the Above" perk, you will be prompted, at some point, to choose a video conferencing application and provide the associated contact information. (e.g. Skype Name for Skype or telephone number for Viber) This information will only be used for the purpose of making the video conference call and won't be collected in a database, nor shared with 3rd parties.
I will make best efforts to keep the above information secure.
You will be given the option to select a different name or not appear in credits at all.
In fact, Indiegogo gives you a similar range of options, during checkout, for the name that will be displayed publicly next to your contribution on the campaign page. Consequently I plan to use this choice, if practical, so that you don't have to input the same information twice.
Yes, but I haven't decided on the exact terms yet. It will probably be something more permissive than "All rights reserved", but less permissive than a Creative Commons license.
The intention is to allow you to print them on a T-shirt that you'll wear in a public place, but not to make them available for download. I don't intend to allow commercial use either.
I can't guarantee that your idea will be made part of the language, or that it will have its original form if it does. I can't even guarantee that the idea will be processed by any specific date, since I don't know what you'll send. But I can guarantee your name and idea is immortalized in the project's page and this should be done by the perk's estimated delivery date. Apart from that, I'll do my best to process ideas and document why they were accepted or rejected.
Yes, but I prefer you wait, in case I need you to send it using a particular format or medium. (e.g. input in a web form instead of an e-mail)
If you decide to back the project, I assume it's because I've convinced you that humanity will benefit from the creation of this language. The perks you choose will be an added bonus.
This perk comes from past experience discussing Arcadia with other people. The way people engage with the project is by suggesting I look at or include, or by asking if I'll include XY feature from ZW language. And although this interaction is invaluable, it also takes a lot of time to research each one of those features and even more to understand how they interact with what I have already planned.
Although completely original ideas are possible and very welcome, this is what I had in mind when adding the perk.
So by buying this perk you support the project twofold, both by mentioning something I might not have thought of otherwise and by funding the time it will take me to process it.
Please avoid naming a patented feature. If you do name one, please clearly state the fact that it's patented. Your name and proposition will be noted, but the feature won't be included in the language.
Your choice among Skype, Viber, WhatsApp, Discord and Facebook Messenger. If you really want to use something else, name it and I'll see what I can do.
Near the perk fulfillment date, you'll receive an e-mail prompting you to choose a video conferencing application and provide the corresponding contact information.
I expect to start the process near the Estimated Delivery Date. First you'll get an e-mail initiating negotiations for a mutually convenient date and time. Differing time zones might be a source of difficulty, but hopefully all calls will be scheduled and carried out within the specified month.
Any one of C, C++, C++/CLI, Java, Javascript, D, Pascal, AWK, GLSL and Standard ML should be fine as long as you stick to the standard language and library. MATLAB, Visual Basic and Prolog should also be fine as long as you don't use advanced features or unusual parts of the library. I might be able to get back to you for some OpenCL C, C#, Python, Perl and Bash programs too. In any case, send your snippet and if I can't make sense of it, we can negotiate a different language or snippet.
Something self-contained and with a clear purpose that exposes a certain set of features. It can be an algorithm or data structure, a function or type definition, a meta-program or test case. It can be complete or a mock-up. Ideally it will be something I hadn't thought of!
That depends on when I'll receive the source snippet and how complicated the snippet will be. I expect to be ready to start translating near the Estimated Delivery Date and you'll be notified through Indiegogo and/or e-mail when I am. Assuming you will send your snippet timely, you'll have your translation soon after.
Yes, but I won't get back to you before the Estimated Delivery Date.
Your choice, as for the Discuss One-on-One perk.
The process will be the same as for the Discuss One-on-One perk.
