Cache lines would be the primary native type, all levels of cache would be addressable, hardware resources (down to adders and vector units) would require explicit cycle-level scheduling.

It's probably more a back-end language for a compiler, but I'd like the ability to go in and see the resulting output and tweak it. Not clear that current x86 assembly can support this, so it would be a simulator language for the next few years.

We often end up trying to fake out the compiler in order to fake out the prefetcher. The above language is a daydream that would give me much finer-grained control over what the hell is going on inside the processor than can be done with current ISAs.

New languages usually spawn from two avenues, the first is geeks playing around to try and make the better mouse trap (most fail, but it is fun to try), the second out of need, such as a language for some specific aspect (such as a scripting language for a CRM or things like Mathmatica). The later rarely goes past the range of it's design, though in some cases it does happen.

Each language must meet it's purpose and goals. Throwing out a language to do so results in a poor language as it has no meaning.

That being said there are some specific suggestions to follow in designing any language.

The first is identify your target. If it is general programming you want to adopt a structure based on C++ (Java, C#, PHP, etc.) as this is the most adopted language pattern. Mathematicians should see something similar to Mathematica, and so forth.

Secondly unless you want a fleeting language, do not structure it based on current trends, target design patterns and ideas that are historically sound, with the exception of perhaps the area you are focusing. Several languages fade or become annoying once the idea they were based on is no longer popular.

The language needs to be easily adaptable to stay relevant, such as Java implementing Lambda. If an idea is good and your language does not support it, it may be the reason it gets forgotten. However, you should not force developers into patterns that are not completely accepted, or have potential to change. This is where many languages get lost, they try to be a framework as well, or in the case of Ruby so closely tied to a framework in their popularity, that they are likely doomed in the future.

Keep in mind few frameworks last, and the ones that do, last because they are more versatile and adaptable. Languages are the same way, though some are difficult to identify the points of restriction, especially from the designer's view.

parallel programming languages are somewhat crippled by serial paradigms. I have already produced a parallel RPN language for use on gpgpu for processing images and other data for which there is time-interval framing. Set A1 is used to compute set A2 which is used to compute set A1 (etc... forever) for modeling retinal processing of dynamic images. However, I find this horribly inadequate. I wish to produce a language that enables specification of systems of autonomous units that listen to each other and talk to each other, much as neurons do. I would love to discuss the approach with like-minded developers and scientists. The language would essentially specify the rules by which a cell changes morphology/state and who it listens/reports to. This is being developed on serial computers for now, but it ought to trigger development of entirely new hardware.

It would fit a special purpose. There are already so many general purpose languages out there. There is no need for another one I think. What do I like when using a language?

I like to have a simple and powerful concurrency feature. I want to write a single command and have my code running asynchronous. I want to have first order functions to ensure a powerful abstraction. I want my algorithms to be type independent. It doesn't need to be dynamically typed, but some kind of templating mechanism would be great. I don't want to write the same algorithm x times for similar data types. I want to say, these are my data and this is the function you need to use as callback. And immutability is a must. It there is an option for mutable state, fair enough, but immutability should be default.

I think that's it for now. The point is there are languages out there covering that. Clojure or Elixir for example.

I think every programmer would like to create their own language at some point in their career...which is why there are a bazillion single-user languages all serving a very unique domain.

The Pat language would incorporate all the neat CPU features that have been introduced since C was designed, which is when most current languages stopped adopting new features from hardware functionality. It would include the ability to express conditional execution as its own type of flow control. It would support vectors primitives and vectorized functions in expressions.

It would tuned for expressing parallel execution. In this regard it would be heavily influenced by Erlang, except for the VM part...the Pat language has NO VMs ever. Unlike Erlang would allow objects or memory allocation to be shared or cloned on copy. It would also be statically typed.

Executables would also include runtime scripting hooks backed up by the language, like AREXX or LUA, but support would be fundamental and at the language level.

I have done this, because I was learning about modern languages at the time, and coming from a C/C++ background I didn’t trust them without knowing how the new clever stuff worked (notably garbage collection with cycle detection, and first-class functions with full lexical closure). Best way to learn something is implement it.

The language is called Angort. Why? No reason at all - I couldn’t tell you. It’s a random pair of syllables which popped into my head.

I already understood how parsing and code generation worked and didn’t want to play with them, and also wanted something very interactive - so I started with a very simple base: Forth. Writing a byte-code Forth-like interpreter is trivial, you can do it in a couple of hours. To that I added local variables and parameters (just for my sanity) and then collections with garbage collection (lists and dictionaries). Then anonymous functions, then lexical closure (solving the Funarg problem). That proved … tricky!

The language ended up being absurdly powerful. For example, the syntax for a list is [item,item,item…] except that’s not syntax. It’s just that the syntax is a side-effect of how the stack functions “[“ (called OP_NEWLIST internally ) and “]/,” (called OP_APPEND) work. Imagine you’ve got the code [1,2,3] - what it does is

• [ pushes a new list onto the stack
• 1 pushes 1 onto the stack
• , pops 1 off the stack and appends it to the list now on top of the stack (leaving the list there)
• 2 pushes 2 onto the stack
• , pops 2 and appends to the list
• 3 pushes 3 onto the stack
• ] does the same as “,”

We now have the list [1,2,3] on the stack. There’s a bit of syntactic sugar in the parser for dealing with the empty list syntax [] but that’s all.

This means I also get Python-style comprehensions for free. If I want to make a list of the first 30 squares, I do this:

[] 0 30 range each {i dup*,} 

Because I have first-class functions I could also do this:

0 30 range (dup *) map 

And the first class functions really do have closure:

:mkcounter |:a| 0!a (?a dup 1+ !a); 

will return a function with no arguments whose value increments every time you call it:

Angort version (c) Jim Finnis 2012-2017 4.5.0 
Use '??word' to get help on a word. 
2|0 > :mkcounter |:a| 0!a (?a dup 1+ !a); 
2|0 > mkcounter !F 
4|0 > ?F@. 
0 
4|0 > ?F@. 
1 
4|0 > ?F@. 
2 

There’s map/reduce too. Sum of the first thirty squares:

Angort version (c) Jim Finnis 2012-2017 4.5.0 
Use '??word' to get help on a word. 
2|0 > 0 0 30 range (dup *) map (+) reduce 
2|1 > . 
8555 

So I wrote it, played with it a bit and forgot about it - until I was working on my final year undergraduate dissertation and had to implement a Brooks subsumption system for a robot: Subsumption architecture - Wikipedia

This turned out to be really messy in most languages, because it involves processing data flows in a fairly complex way. So I tried it in Angort and it just flowed off my fingers. It was a beautiful experience.

So a language which started out as an exploratory exercise actually turned out to be quite powerful, and very useful. It’s got a very easy mechanism for writing C++ plugins, and I have a lot of native C++ libraries now. I’ve used it a lot in my PhD work for data analysis and visualisation. It’s probably my favourite language.

It probably shouldn’t be. It’s still got a few bugs, it’s deeply unsafe, and is very old-fashioned. But I love it. It’s mine and fits how my broken, slightly elderly brain works.

I read the CONLANG-L mailing list (for fans of constructed languages) for several years — and picked up a fair bit of what I know about linguistics from there.

So I’ve occasionally toyed with the idea of creating a language of my own.

There have been a couple of attempts of taking an existing language and pushing it through some sounds changes to look different, but nothing serious — I lack the creativity to make a “nice” language.

But two things that have always been on my wishlist for if I ever did sit down to make a language of my own are that it would have a vocative case and a dual number. I’ve always had a soft spot for those two language features.

In other words, nouns (especially names) would have a special form used when you are speaking directly to a person (like how in Slovak, “God” is Boh but when you’re speaking directly to him, “God!” is Bože!).

And nouns would have distinct forms not only for singular (exactly one thing) and plural (many things) but also for dual (exactly two things) — like how in Maltese, you have sena “(one) year”, sentejn “(two) years”, snin “(more than two) years”.

First, the alphabet would be an alphabet like the Latin one we use in English and not a syllabary or characters.

The spelling of the word and the sound of the word should be consistent and intuitive like Japanese and not at all like English.

All plurals would just be an extra sound added to the end of the base.

The sentence order would be SVO because that is just more intuitive in my mind.

Then, verbs would all have consistent rules with no exceptions. There would be no conjugations based on who the subject is, only based on past, present, and future. For example, I eat, you eat, he/she eat, we eat, you all eat, they eat for present. And past might only add Ed at the end and that would be the case for all verbs. I eated, you eated, etc. And future could be the same as English with the 'will' modifier in front of a present tense verb, I will eat, you will eat. Then, continuous tense would use the verbs to be to indicate tense and would only modify the continuous verbs just like in English except to be would follow the rules above. For example, I is eating, you is eating, etc. for present continuous, I ised eating and you ised eating, and I will is eating, you will is eating, etc. for future. Same case with present perfect. I would have commands just all use the present tense verb with an added o on the end like in Hindi. Eato, runo, etc

These are just a few things I would have. My list could go on and on, but here's a short example of what this might look like.

I'm using Japanese words since their spelling and sounds make sense. Boku = I, Kimi = you, Kare = he, boku tachi = We, Kimi tachi = you all, and Kare tachi = they. Taberu = present form of to eat. Ringo = apple. Su at the end of a word makes it plural ( not actual Japanese, just my perfect language). With before a present verb makes it future. De at the end of a present verb makes it past. Gu at the end of a verb makes it continuous. Iru= to be.

Boku taberu Ringo - I eat the apple

Kimi taberu Ringo - You eat the apple

Kare taberu Ringo - He eats the apple etc

Boku taberude ringosu - I ate the apples

Boku wiru taberu Ringo - I will eat the apple

Boku irude taberugu Ringo - I was eating the apple

Boku wiru iru taberugu Ringo - I will be eating the apple

Taberuo ringo - Eat the apple

This was just a short example of what my ideal, most intuitive form of language would look like. This may seem confusing since it really is different from any real language out there, but in my mind, these things would make a language much easier to learn with more consistency, efficiency, and intuitiveness.

Okay, so I’m taking the question as creating both a language and a writing system. I’ll start with the language…

I reckon that (plurals aside - they’re relatively logical but a pain in the ass), Swedish is the most simple language I know in terms of structure. The definite article as a suffix is something I would start with, however the common Romance nouns would be easier to learn. German pronunciations and compound nouns would be another practical addition - with limits, of course! No genders, of course - nothing is more annoying in a language. No accents or umlauts or anything, just simpler that way. Possessives can be added as an extra suffix, in this case ‘a’, unless the word ends in a vowel, in which case it will be a ‘s’. Tenses would simply be a different sound - all present tense words have ‘ah’ sounds (‘hat’ = has) and past has ‘eh’ sounds (‘het’ = had). Future will utilise an ‘ooh’ sound as the equivalent of ‘will’ - (‘u hot’ = will have - despite the unfortunate connotations in English) and the perfect tense. Perfect tense can vary depending on noun, probably based upon the Romance or Germanic perfect tense. To negate something, ‘not’ would be used much like Swedish ‘inte’ or French ‘pas’. Mostly English pronunciations will be used, except for ‘u’ as ‘ooh’ and ‘j’ as ‘yuh’. There will be no passive voice, thus cutting down on pesky verb conjugations. Plurals will be, and I repeat, standard! No bloody irregularities! Again, a suffix: ‘en’ or ‘men’ if the word ends in a vowel.

Basic words:

And = et (prounounced as ‘ehtt’)

To have = hot, Has = hat, Had - het

To do = ton (pronounced as ‘tawn’), Doing = tan, Did = ten.

I = Je (pronounced as ‘Yeh’ - a schwa.)

You = Du (pronounced as ‘doo’)

We = Ve (pronounced as ‘veh’)

They = De (pronounced as ‘deh’)

My = Me (pronounced ‘meh’)

Good = Br

(1 = En), (2 = Do), (3 = Tre), (4 = Ver), (5 = Sin), (6 = Sex), (7 = Set), (8 = At), (9 = Nef), (10 = Zen)

I’ll cover the conjugation of ‘to be’:

Infinitive: Be = vor (pronounced ‘vawr’)

Present tense: (Is = var), (Am = varo), (Are = varen).

Past tense: (Was = ver), (Were = veren).

There are no past or present participles as there is no passive voice and enough workarounds to make it okay. I’m not a linguist, so this could be a mistake!

Say we take a common term like ‘Man’ - in our Swederomantic lingo, ‘Hom’. The man = Homman. Men = Hommen. The men = Hommanen. A man = En hom.

Sentence structure would be much like German/Swedish: ‘En hom hat en per grand.’ A man has a tall father.

Compound nouns are a simple, logical way to create new words from a relatively small vocabulary. Whilst reminiscent of Newspeak, the language will develop and loanwords will increase the vocabulary. ‘Hommena per grand hat en tradrotta.’ The man’s tall father has a squirrel - ‘tree rat’. (Trad = tree), (rotta = rat).

Using verbs: “Je varo en hom.”-I am a man. “Je ver en hom.”-I was a man. “Je u vor en hom.”-I will be a man. “Je hot en tradrotta.”-I have a squirrel. “Je hot tradrottamen.”-I have squirrels. “Je ver tan dansan.”-I was doing the dance.

WRITING SYSTEM

I reckon the easiest writing system to learn would be syllabary or alphabetic, but the practicality of the Hangul syllabary impressed me enough that I can use it as a model: the characters are made up of overlaid symbols/shapes which each represent a sound - a square represents a sound made with the lips, for instance, while a bar above it indicates a plosive - indicating a ‘p’ sound. However, the aesthetic of Hangul characters doesn’t appeal to me, so I’ll create a similar system using rune-like symbols.

Taking the word ‘Homman’:

A vertical post will be the base, an horizontal line a consonant and a downwards diagonal a fricative, with variations for each, plus other shapes for vowels. The first syllable, ‘hom’, starts with a sound from the back of the mouth which is a fricative - a /h/. Because it is at the back of the mouth, the downwards diagonal begins from the left side of the post, at the very top as it is the first sound in the syllable. Below that, a circle is positioned in the centre of the post - the circle representing lip shape for an ‘aw’ sound and the central position signalling the central mouth sound. Below that, a horizontal line protrudes from the right of the post, with a small dot attached to the end. The horizontal line indicates a consonant, the right hand side position shows a sound forward in the mouth, and the small dot indicates closed lips - an /m/ sound. The next post: a triangle is on the right side at the the top. This indicates an ‘ah’ sound - forward in the mouth and slightly upward, almost nasal. Below that is a horizontal line from the right side, ending with a upward line then a circle - indicating a forward sound with tongue on the roof of the mouth and circled lips.

I may add pictures but it is otherwise as described.

The disclaimer: I am not a linguist, I just have an interest. If any linguists have any suggested ideas or edits, I’m open to expert suggestions and help! :)

What would be your ideal programming language look like if you could design one from scratch? What would be different/better about it compared to existing languages (C/C++, Python etc.)?

It would have a syntax like C# and memory handling like Rust.

The language’s objects would have support for built-in, thread-safe, message passing (queing) so that objects could pass messages to each another without knowing too much about each other (i.e. no explicit shared/base class or interface required).

Both dynamic and fixed (block/atomic) string types would be included as standard types. Both ANSI and Unicode would be natively supported.

Type information would be built-in, so that you would get C#’s is and as operators. On the fence about rich reflection-type capabilities, although I think a simple (runtime) metadata system would be a good idea (read: a was to add metadata to classes and libraries/packages and examine this metadata at runtime).

Library/package support built into the language and platform (think cargo).

Documentation features built into the language and could be built into libraries/packages.

Single-file support - no separate code and header files.

A rich standard library that is on par with .NET or at the very least C++ 23, allowing for code to more easily go multi-platform and have consistent and predictable behavior on those platforms.

Container types would have built-in support for degrading into or evolving from standard C-style binary/wire formats.

Misc other built-in features: extension methods, simplified (automatic and manual) parallelism and acceleration (GPU/CUDA), native XML and JSON types with serialization support, simple remoting of messages and interfaces (RPC),

Lastly, code would be compiled, not interpreted, and would NOT use whitespace for scoping (Goddess forbid! 😁).

“Fashion is a form of ugliness so intolerable that we have to alter it every six months.” - Oscar Wilde

If I were to design a programming language, it would be to scratch an itch, to solve the kinds of problems that I need to solve and that I would want to use.

I tend to work in the high-performance computing space, being largely tasked with solving problems where conventional wisdom says that current hardware isn’t up to the job. I try to make it work. This means I have to think about all levels of the complexity stack, from individual bits to large-scale structures.

It would also have to be the kind of programming language that I could design, and that’s a very important consideration. I doubt that I could design a good dynamically-typed language, for example, because that’s not something that I generally value. If I think I need dynamic typing, such as for a high-level scripting layer, good dynamically-typed languages already exist (e.g. Erlang, Scheme, Smalltalk) that are better than anything I could come up with.

Basic principles

The core principles of this hypothetical language are:

• The programmer and compiler need to work as partners. The programmer’s main job is to express intent, and their secondary job is to tell the compiler what it can’t work out for itself with as little verbosity as possible. The compiler’s main job, beyond generating good code, is to give good feedback about what it understands in a way that helps resolve misunderstandings.
• The language should be designed for programming in the real world, not a fantasy world. For example, the platform that our programs run on is actual hardware, not software. And it is especially true that programs don’t run on a specific language implementation. If a program needs to be coupled to a language’s implementation details, something has gone deeply wrong.
• You also must be able to work at the abstraction level appropriate for the problem that you’re trying to solve at this moment.
• The language must give you guarantees: safety guarantees, performance guarantees, and so on. Ideally, the programmer should be able to define their own guarantees and the compiler will check them. But common guarantees must be available without boilerplate; I want rapid development sometimes and anal-retentive software engineering safety sometimes.
• Easy things should be easy, common hard things should be straightforward, uncommon hard things should be possible.
• A programming language cannot afford to be fundamentalist about anything. One-size-fits-some is no way to build complex systems. It’s fine to force a programmer to think in new ways to use a new programming language, but you must never force them to think in only one way.

That last point is extremely important, and can be illustrated with a few examples:

• “Everything is an X” (where X could mean object, function, whatever). Sorry, no. I can guarantee you that in the real world many (if not most) interesting things aren’t X. And if everything is an X, then nothing is.
• Automatic garbage collection. When it’s a good fit, or even an okay fit, it’s wonderful. When it’s a bad fit, it’s beyond horrible. In the real world, there is no single “right way” to manage memory.
• Bytecode VMs, JIT, dynamic heroic optimisation. It might save you a little development time, at the cost of an opaque performance model, or even worse, an inherently unpredictable performance model. Saving a little bit of the programmer’s time to waste a little bit of the customer’s time isn’t necessarily a good tradeoff.

So as you can see from these examples, a lot of current trends in programming language, while they have advantages, do cause problems in real programs. And the way these things typically work out is that often (even most of the time) the disadvantages don’t matter, but when the disadvantages do matter, they are not a mild inconvenience, they are a severe showstopper bug.

One of the worst mistakes you can make in any kind of technology design is to say “this is a good thing, so let’s turn it up to 11 and make people do it all the time”.

There are almost no programming language features which are bad to have, but conversely, there are almost none that are good to require.

Ergonomics

I would try to avoid Wadler's Law. Syntax matters, but syntax should ideally be designed last. The good parts of the syntax should not get used by features that turn out to be less important. (This is, incidentally, both the main strength and main weakness of C++. C++ wouldn’t work without C compatibility, but it does mean that all the good syntax is taken by C.)

The language’s type system has to be based on mathematics as far as possible: theorems-as-types, data-structures-as-algebras, proper-classes-are-not-types, and so on. Why mathematics? Because it’s understood, and you already know that you can reason formally about it. In particular, we need to be able to capture relationships between types in the form of many-sorted algebras. I don’t know precisely what this would look like, but I know it’s important because I often miss having it.

There must be strong compile-time safety guarantees by default, such as type safety. But more importantly, it should be easy and quick for programmers to define their own compile-time guarantees (e.g. never mixing a “row coordinate” with a “column coordinate”). It should be especially easy to make “small” abstractions (e.g. wrapping an integer into something type safe) which are essentially free at run-time.

I would pay close attention to namespaces and flexibly porting names across different namespaces, which is something I’ve talked about elsewhere.

It would be nice to have seamless support for working with scripting layers: reflection, marshalling/demarshalling, that sort of thing.

Scale

The language has to work at all scales.

I should be able to write straight-line low-level code where I can more or less see the assembly language that would be generated. I must be able to “feel” the bits underneath. Ideally, there would be intrinsics for instructions which most common platforms have but can still be emulated on platforms which don’t (e.g. bit-hacking instructions, SIMD arithmetic).

I should also be able to think in terms of data structures and algorithms, and the properties that they satisfy.

I should also be able to think in terms of the problem domain. Unless you’re talking about simulation, most things are not “objects” in the Simula/Grady Booch sense, and any programming language that thinks everything is an object is deluding itself. So this is not something that the language would encourage. Nonetheless, I would like to think in terms of domain-level concepts where appropriate. The ability to embed a DSL without additional tools would be nice.

I should also be able to think in terms of components and subsystems. So the language will have abstract interfaces with inheritance, native support for dynamic shared objects, and so on.

The actor model is increasingly important these days, because computers are looking more and more like networked CPUs, even within in one device. So I’d be looking hard at Erlang, Smalltalk, and people who are using this programming model in other languages.

Performance

A language which doesn’t have support for raw performance is a scripting language. There’s nothing wrong with that, but that’s not the space that I work in.

A compiler or interpreter should not have to be installed or shipped to run a program. It’s fine if this is an option, but it should not be a requirement.

The language must provide some performance and optimisation guarantees. Something that consistently bugs me about C and C++ is that there is a lot of “undefined behaviour” in the standard, put there so that you don’t prevent certain optimisations from happening. Where’s the guarantee that the optimisation will happen? It’s the worst of both worlds. (And before you ask, consider the guarantee in Scheme that tail calls are always optimised…)

On the other hand, as noted above, a program should never be coupled with the implementation’s internals (be it the compiler internals, a virtual machine internals, or what have you), and especially not for performance reasons. If you can’t express a guarantee mathematically, don’t give it as a guarantee at all.

Conclusion

The language I want only vaguely resembles languages that currently exist. It seems a bit modern. And yet, I kind of want to step backwards to a time when people didn’t think they knew how to design programming languages. As an industry, we could all do with a bit more humility.

I actually designed a little language for fun at one point, and it was influenced by JavaScript and Lua and Scheme and Haskell and, well, that was a mistake. It's all too complicated! I ended up having weird corner cases and shortcomings, even though my intentions were good.

The real issue? The design was arbitrary, and parts ended up not fitting together well. It felt like I started building up a circle in two directions and then the ends didn't quite meet up. There were bugs not in interpreter but in the actual language semantics. And what do I do now?

I also sometimes have this problem when cutting bagels.

After that exercise, I see the same issues in other languages. Even popular ones! The whole Python scoping malarkey? It must have seemed like a reasonable idea at first—after all, why do we need to declare variables explicitly?—but it just didn't quite get there. And the same with automatic coercions in JavaScript or PHP: it starts out seeming reasonable, but in the end there is no way to make it consistent.

This last one is a particularly appropriate illustration. We can come up with a good scheme for just going between strings and numbers but, as far as I could see when playing with the same design space, there's no natural or consistent way to extend it to other types. The web of conversions gets too large and becomes either unintuitive or inconsistent. We might want to convert 0 to False and False to "False", but probably not 0 to "False". All of a sudden, whenever we use this "implicit" feature, we have to really carefully keep track of what the underlying type really is at any given moment—which completely defeats the point of making these conversions automatic! I ended up completely giving up on the whole idea. It's just not workable.

All these languages—mine included—are designed in a haphazard, arbitrary fashion. They end up as collections of features that their creators liked. Maybe some, or even all, of these ideas are neat, but then they don't quite work together, or have weird corner cases, or are less expressive than they could be. The language as a whole suffers.

If I were to design another language, I wouldn't want to start from a foundation like that.

Instead, I would want a base that's small, simple and consistent from the getgo. I would start either from a rare handful of minimal, carefully designed languages (Scheme and SML spring to mind) or, more likely, build directly on top of an existing formalism like some variant of the λ-calculus.

The λ-calculus was not designed as a practical programming language, so it can sacrifice accessibility and readability in favor of simplicity and consistency. It would let me build up the core of my language in a direct, natural way with well-defined semantics. Then I could layer on a friendly syntax and higher-level features in a superficial way, without affecting the underlying semantics.

One particularly nice thing about the λ-calculus is that it allows me to look at language features in isolation. If I have an idea, I can first test it out on a very bare-bones λ-calculus, without needing to worry about the rest of my language. Isolating features like this makes it easier to consider all their possible permutations and to find ways to simplify them. It's also a great way of prototyping designs and getting the initial kinks out. After that, I would just fold them back into the language as a whole, looking at how they interact with everything else. This part, naturally, is quite tricky, but having it in a separate stage of the design process means that at least the initial draft of the feature is easier to do. Trying to work on features as part of the whole language the whole time makes them this difficult all of the time.

So I wouldn't start with an existing language but rather something as simple as possible. But this doesn't mean I won't take ideas and inspiration from other languages! Features from other languages would be approached the same way, by starting with a simplified model based on the λ-calculus. Moreover, a bunch of other useful features might end up as just syntax sugar or completely orthogonal to the rest of the language, which makes adding them in much easier. The nice thing about syntax sugar specifically is that as long as I'm content that the base features it desugars to are sane and consistent, I know the sugar is as well. No need to think about it separately—it's essentially a feature for free, at least from a language design point of view.

I'd still draw on the ideas of other languages I've used—or even just read about. I just wouldn't start from any of them.

Finally, I should note that some variation of the λ-calculus is not the only option for a simple underlying model. Rather, I would be happy with anything sufficiently simple and elegant. The reason λ-calculus is attractive is because even more complex typed variants contain very few actual constructs and come with a very straightforward evaluation rule; it also has close ties to mathematical logic and other mathematical structures that pop up all over the place, lending it a Platonic air of legitimacy. But it's not the only mathematical system with these properties, and seeing a language evolve from something else like a different strand of logic or something more algebraic in nature would be interesting.

I cannot honestly say I’ve got far in creating languages, but I’ve started a few and made plans for many more.

Most of my conlang ideas are for experimental languages, intended to stretch what is possible in language beyond what is familiar from the world’s natlangs, or even most of its conlangs. Either I’d like to demonstrate that something is possible when most people would think it’s not, or I’d just like to see how something turns out if it follows a certain principle or design. Many such ideas involve taking some language feature to an extreme or attempting a design that’s challenging or difficult.

Such ideas include:

• The ‘opposite’ grammar to English
• A whole suite of languages with a common phonology and vocabulary for purposes of experimenting with different grammars, e.g.:
• All verbs are transitive
• All conjunction content is affixed to verbs
• All dependents and particles are incorporated within heads and content morphemes
• Verbs become nouns and nouns become verbs
• Combining all lexical information in one syllable/morpheme, and all grammatical in a second syllable/morpheme, in each word
• Combining the simplest popular conlang, Toki Pona, with the most complex, Ithkuil
• European auxlang style combined with polysynthetic grammar, inspired by Poliespo but made really functional and attractive
• The most awkward a language can be in irregularity, inconsistency, redundancy, perversity, complication, impracticality and confusion
• Reducing all meaning distinctions down to a series of binary choices represented by only two possible syllables/morphemes
• Combining subject, verb and object in one morpheme with no separation of the elements
• A language purely for static situations, with no verbs but with lots of adpositions
• Trivocalic roots, like Semitic triconsonantal ones but with vowels rather than consonants, and consonants forming the inflections
• Expressing inner experience rather than supposed objective reality
• A philosophical language that doesn’t use a priori vocabulary
• Attempting to enable all known forms of grammar in the world’s natlangs
• A pasigraphy that similarly expresses all different grammatical patterns and represents any language’s meaning
• A pasigraphy that uses pretend phonographic symbols which are actually unpronounced and combined to create words

Besides these I have had some ideas for other kinds of conlang besides experimental ones. There are at least a few alternate/geofictional artlang ideas, such as:

• An Austronesian language set on a fictional island in the South China Sea
• A language isolate in central Europe, similar to Hungarian, having arrived by migration from Asia and in an unknown family (hence lexified a priori yet with realistic influence from other European languages)
• A language descended from an imaginary sister of a little known ancient non-Indo-European language such as Etruscan, Iberian, Minoan or Proto-Basque

If you were to tasked to create your ideal programming language from scratch with all the features, syntax, and design philosophies of your liking; which current programming language(s) would it resemble the most?

*One* ideal language?

Isn’t going to happen. That’s because languages are trade-offs. And the trade-offs often conflict.

I use C for a lot of things specifically because it’s a low-level strongly-typed compiled language, which leads to its strong points - easily optimized and fast code.

I use Perl for a lot of things because of features only possible because it’s a dynamically-typed interpreted language.

You try to mash them together, and having to support dynamic typing so it will be able to do Perl-like things will trash the reasons for having C-type stuff, and having the C-type stuff puts a big crimp its ability to do Perl-like stuff.

If you look at previous attempts to design “one language for everything”, you notice that neither PL/I or Ada is in widespread use - and neither one tried to implement functional programming, or Lisp-style paradigms, or things from the Smalltalk or Forth world. Try to cram all of *that* in as well as what PL/I and Ada *did* try to cram in, and you get this:

All the languages I design are for my own amusement. Their features vary so I don't get bored. One was made of a bunch of trivia about Germanic languages glued together with some rules of my own. Another had mood and grammatical relationships conveyed by clause-initial particles. Another had seventeen cases, most of which I invented independently, the choice of which is determined by which one of the twenty classes that verbs fall into. Another was inspired by my friend's remarks about Russian verb prefixes and features from other languages. Another, which I'm working on now, was designed to be stranger than the rest.

In the latter language, verbs aren't marked for tense but for subject status (i.e. extant at the time of the utterance, inextant at the time of the utterance, perennial, imaginary, and unknown at the time of the utterance).

Noun phrases (or adjective phrases in copula complements or verbs in clauses without noun phrases) are marked for clause-type. For reasons that I don't have time to explain, this makes it easy to delete constituents without losing information.

Nouns and pronouns are marked for three grammatical numbers: unal (YOO-nul, i.e. singular/singulative), plural, and confundive (kun-FOON-div, i.e. non-count, collective, plural for aggregates of identical objects, plural for things/beings that typically occur in groups, and neutral).

Lone and subordinate clauses in a sentences have the same grammatical forms.
Relationships among the clauses are marked by specially inflected intermediate verbs.

Many adpositions have converse meanings depending on whether they are used as prepositions or postpositions. So "in the box" would be literally be "in the box," but "that the box is in" would literally be "the box in."

Generally speaking, I spend most of my time playing with clause structure and morphology.

Thanks for the A2A.

I don’t think I’d create a language from scratch, because everything I know about language comes from real languages. Frankly I’d just use English as a base and make some modifications. So, how would I change English?

• Clusivity
  [1]
  : English only has one word for “We”. Languages with clusivity have two words for “we”, one that include the person being spoken to, and one that excludes that person. So if I were to say to you “We(I) are going to the store”, then you know that you, John, and I are going to the store. But if I say “We(E) are going to the store”, then you know that only John and I are going.

• Agglutination
  [2]
  : Some languages like Russian and German allow you to form words by simply combining roots, where English uses multiple words or hyphens. English already sort of allows for this, but it’s not exactly proper. However, I think it’s useful when describing things with a sort of permanency, while more temporary ideas or things can retain the hyphen structure. For example, submachinegun ought to be one word, rather than sub-machine gun. In German you find words such as beerhaus or “beer house”. While we call it a bar, it makes sense to me that beerhouse ought to be one word.

Original question-If you were to design a language from scratch, what features would it have?

Footnotes

C is lovely, but I’d like to make it less portable.

So imagine a version of C with a set of global cache arrays corresponding to the physical caches on your processor, and the ability to assign values to individual cache lines. Most of the time you’d want to let your processor firmware manage your cache, but when necessary you could lock down some subset of cache lines and manage them explicitly.

Why would such a thing be useful? In high performance computing we often end up having to fake out the compiler in order to fake out the hardware prefetcher. Language support for cache management (and the assembly and firmware support to make that happen) would remove two black boxes that we currently have to program around.

Original question:

Should languages be conceived with the expectation of being succeeded by a language better supporting paradigms added during the language's lifetime?

This question does not make sense. Languages are not conceived. We really do not know how human languages originally came to be, but they are now a natural part of human existence. Languages are culturally transmitted from one generation to the next. It is a subconscious process. People in nature have no “expectation” of their language nor even that the paradigms (I take you means structure) exist, it is just part of what is in their reality. As civilizations advanced and writing arose, then there was an awareness of grammar, but languages continued to evolve naturally beyond the control of human consciousness. Even the attempts of many major languages to control how people use the language (like with French) fail miserably in actual practice. And you really cannot actively add grammatical structures beyond the structures that are already used, or evolving out of them. Try to talk English like an SOV language and then get your friends to do it and then get the rest of the world’s English speaker to do it. It is not going to happen. I language English speak order SVO with, because natural that is, and engineering language control consciousness beyond is! So the simple answer is “no”.

For me these would be on the short-list:

1. No “exceptions”. If baffles me as to why these exist in most languages, especially duck typed ones, when they exist in Java for such an obvious reason that is specific to it and maybe a couple of other specs.
2. It would need to have robust and easy to reason concurrency.
3. Error handling would need to very explicit and convenient to interact with.
4. Depending on the type of app I’m building it might be nice to have a garbage collected mode that can be turned off and utilize a different type of memory management. Though this may be too difficult to do in a single language spec?
5. Functions (presuming the spec has them) would be first order types
6. It would be statically typed
7. It would be easy to deploy a service and not have to deal a bunch of dependencies during deployment.
8. The language spec would be very simple and concise.
9. It would enable easy refactoring. <rant>Some may find this controversial but I believe we frequently have the optimal way of designing code and systems backwards. We paralyze ourselves trying to get the design right, figure out all the ways our code might be used. Put another way: we try to recognize patterns before we see them. It seems like if we don’t fret over that and instead have a language that lets us recognize patterns after we’ve seen them a few times, we’d be better off. A language that is easy to refactor helps with that. Although this may not apply in the future (??) I’d argue that dynamic languages fall flat on their face with this one and become magnets for technical debt.</rant>

For what it’s worth, based on my work with Rust and Go they come closest to this. I’m sure there are others I’m unfamiliar with. For example, just thinking about Haskell makes me ponder if I’m missing a whole lot of things that should have been listed.

Greg

Python:

1. Colonectomy. Get rid of the colon. I cannot figure out, once indentation is required, why is a colon also required at the end of the previous line?
2. Slice = Scalar. somearray[start:end:step]= True. This syntax is fine if somearray is a numpy list, but not if it is a regular python list.

• I submitted a formal request for this. In response it was explained why this is fundamentally not feasible.

Microsoft QuickBasic and successors:

• Ambiguity whether a statement A: B is:
• A call to already declared subroutine A and then a call to already-declared subroutine B or
• A statement label A followed by a call to already-declared subroutine B
• Prohibited duplication of a statement label in different functions or subroutines within a compiland, even though it is prohibited to GOSUB to that label from a different subroutine.
• It is prohibited to GOSUB DOONEB in subroutine B from within subroutine A. Yet it is also prohibited to have a label DOONEB in subroutine A.
• I would rather have a label DOONE in each subroutine, and within that subroutine, the code can GOSUB DOONE.

APL and successors:

• Allow syntax that provides lazy deferred evaluation. APL’s adoption was mostly stopped by Lotus 1–2–3. Its VisiCalc-like automatic recalculation (aka lazy or deferred evaluation) was a major desirable factor.
• Provide a way for an APL array element to hold a formula and its current value.
• Provide a way, e.g. ⎕RE←1 to switch to manual recalculation and back to automatic ⎕RE←0
• Provide a way to recalculate as needed. ⎕RE

Thank you for asking and letting me vent.