Ada has a rich set of language features to express preconditions, postconditions, and invariants directly in the code, and then have those logical statements available to the compiler so that it can assume certain facts about the program's execution when optimizing:
Also, the type system lets you specify legal values with more precision than the word-based types that most languages inherited from C. For example, you can have range types that may hold integers of only a certain range, and the compiler will enforce that when assigning to variables of the type, or throw an exception if an arithmetic operation results in a value outside the range (you also have modulus types that explicitly give the wraparound behavior familiar in C). Containers allow generic constraints, and you can explicitly specify the dimensions of array types.
I find this super-interesting because I do the same thing (and made a tool out of it at http://write.itskrish.co) and it works for me just as it does for her.
For me it's just nice to have everything in my mind formally laid out, as it always becomes more trivial than it seemed in my head.
"In a race, a small language with warts will beat a well designed language because users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language fills a niche, it is hard to take its place."
Thanks for the link. I hadn't heard of it, but ended up reading through just now.
For any else who hasn't come across it before, it's a simultaneous discussion of and example of what it means to express oneself using a 'small' language. It also gets into how such small languages may be effectively designed to grow into larger languages. The document itself is an example of the process using a subset of the English language, but Steele's focus is on planning/architecting programming languages which can be effectively grown by: providing effective, general primitives which can be used to define new terms and rules for the language; and structuring the language development process in 'bazaar' fashion, allowing many people to participate in design and implementation, while someone with excellent judgement surveys contributions with an eye for good ideas/work.
I liked this quote, which is a fairly typical example of some definitions he has to make in order to stick to his own rules for the project:
Meta means that you step back from your own place. What you used to do is now what you see. What you were is now what you act on. Verbs turn to nouns. What you used to think of as a pattern is now treated as a thing to put in the slot of an other pattern. A meta foo is a foo in whose slots you can put foos.
(His use of pattern here is in the sense of pattern vs. instance.)
I thought his conclusions on what he learned by carrying out the project were also interesting and insightful. Here's part of it:
I learned in my youth, from the books of such great teachers of writing as Strunk and White, that it is better to choose short words when I can. I should not choose long, hard words just to make other persons think that I know a lot. I should try to make my thoughts clear; if they are clear and right, then other persons can judge my work as it ought to be judged.
Swift is an interesting anomaly in that the incentive to use it is so great, that tens of thousands of devs are willing to put up with the growing pains.
No competition? How about Flash, Java applets, ActiveX, Silverlight, and even VBScript -- which Microsoft pushed to compete directly with JavaScript as the embedded scripting language for the web.
JavaScript lives in a more diverse environments: Multiple browsers, webkit engine, now NodeJS, React, etc.
Varieties, cross pollination from different JS engine/teams make JS much stronger.
Flash, ActiveX, Silverlight, VBScript are all seem more mono-culture - Start to die as soon as the parent organizations/core dev team loss interest / move on to to next best thing.
Flash is a successful until CPU usage, security issues kill it. Just like strong mono-culture plant in a farm got wipe out certain deceases/virus.
It must be possible to change instruction sets when branching, in order to call or return from a function in the opposite instruction set.
There are branching instructions that can't change instruction sets for two reasons:
1. A direct branch can have more range if you can assume it's going to a 4-byte aligned address.
2. For compatibility with code written for ARM7DI and other really old pre-thumb processors. Since the original direct branch instructions ignored the bottom two bits of the target address, new direct branch instructions were added rather than change the behavior of the existing ones.
ARM and Thumb are just different encodings of the same instructions, mostly. Having switchover be done implictly via branch instructions is convenient for interworking -- you can link an ARM library with a Thumb application and it all just works, with function addresses having the low bit set for Thumb and clear for ARM. Generated code doesn't need to care beyond making sure it is using the right interworking instructions for call and return.
This is distinct from x86 32 vs 64 bit and ARM 32 vs 64 bit: in both those cases there's really a different processor mode with extra registers and so forth, and switchover is correspondingly more involved.
http://www.bbc.com/news/science-environment-39779761