I’ve spent the evening trading e-mail with the creator of Sierra. Please forgive the lack of context, but I’m posting my last reply, since I think it sums up my thoughts on the language well.
Ok, I’ll shift my focus from Sierra as implemented to your stated higher level goals for the purposes of trying to illuminate my points.
As background I skimmed EWD340, not having read it in 20 years, and a couple of Milner’s papers contemporary to the IFIP paper since I don’t have a copy of that handy at the moment. You weren’t specific on Dr. Hoare’s work, but I’m relatively familiar with a large portion of it.
I think it’s somewhat disingenuous to talk of a real-time bug checker, since the vast majority of bugs that are hard to find belong to the second class of programming faults described by EWD, those that there is no proof of mechanical recognition. Indeed, even though his specific example ( loop completion, now a subset of fixed point determination) is a much better understood problem, it is not deterministically possible to predict the outcome (the halting problem). Nor are you correct in your assertion that one has to wait until compile-time for existing languages to find bugs. Static analysis can and has been integrated into IDEs (Kleidermacher; 10.1109/THS.2008.4534479).
I can’t address the specific 1986 paper from Milner, but as a general situation, it appears that he was interested in formal abstractions of what code does as opposed to natural language programming per se. Since the problem of natural language programming is itself a composition of natural language processing (an open problem) and automatic proof building (also an open problem), I going to assume that you intend to approach the problem of correct code from the perspective of formal abstraction. In that case, it’s pointless to talk about the Algol derivative languages since much more modern pure languages are at our disposal. Haskell (which implements Hindley-Milner type inference) would be a much better launching point, but I think many of the problems you seek to solve are non-issues in Haskell. The difficulty of programming in Haskell stems from the need to express human thought as a formalism.
This leads to your interest in cutting C in half. Haskell accomplishes this by removing much of the overhead of Algol derived languages, but the result isn’t human readable.
Fibbonacci in Haskell:
fib n = fibs (0,1) !! n
where fibs (a,b) = a : fibs (b,a+b)
This is neither easy to read, nor immediately intuitive (though admittedly it would be hard to have a significant logic bug in this code).
Sierra as it exists today isn’t a level above existing code since it doesn’t significantly vary from C. That example I sent earlier is neither terser or more readable than the equivalent C code. Nor does much in your existing specification show progress towards more intelligible code. While I understand that this represents a first step, it is essentially a step *backwards*. “var” was implemented and discarded by Wirth in Pascal. Operator overloading (+ as addition and concatenate) was tried and discarded in C++. “y@myPixel” is neither better nor worse than myPixel.y, but having both is confusing and neither implies that y is a property of MyPixel.
Many languages have obviated the need for C pointers and direct memory management (see Java, Haskell, etc). In fact, it is possible to have a reasonable garbage collector for C (Boehm, Spertus, WG21/N2310=07-0170). Nor is verboseness particularly a problem (EWD said as much in ’72), human communication is terribly verbose with low S/N and lots of redundancy to make up for it. Nor do I think there is a compelling case that interactivity can improve the situation.
You speak of “higher up” than “traditional languages”, but the truth is that you still seem to be generating a 3GL language without even addressing the existence of domain-specific and constraint based languages (4GL and 5GL respectively). Indeed most new language development seems to be integrating 3-5GL into comprehensive systems. Frameworks like Hadoop have us programming across large-scale distributed systems, They’ve abstracted away the idea of a single execution thread or even a single computer, and they hide the network/memory/latency issues in ways that I don’t think you’ve even considered.
I just saw a blurb about “Julia” (http://julialang.org/), which appears to be an attempt to be most things to most programmers. I don’t know anything beyond the press release, but frankly they at least are hitting all the right notes.
And I think this is the fundamental problem with your pitch for Sierra (here and during the last 3 years). Your approach and materials seem to have ignored the last 25 years of programming language research and development. Whether the end product is compelling or not is impossible to judge because what I can see of it today doesn’t seem well informed. I took the time to read some of the trials and tribulations you seem to have suffered in trying to bring Sierra to market, and while I feel for your struggle, I wonder if you ever had competent technical advice. Your existing demo tackles the problem from the wrong level. You’re taking a bottom-up approach to developing Sierra (which is appropriate), but there doesn’t seem to be a top-down roadmap for the language. I have asserted that you seem to have moved backward from C, and without seeing where you’re going I have no way of assessing otherwise. General assertions that there are higher-level, fuzzy logic components in the future have the ring of SHRDLU (Winograd, MIT AI Technical Report 235, February 1971). It’s 40 years later, and I don’t think we’ve made much progress with that project either.
So maybe that’s my advice to you. Get a roadmap together. Let’s see a architecture overview for Sierra. Let investors (Kickstarter and VC) know that you’re aware of what has been tried, and have concrete ways to do better. At this point, it’s not about the code, it’s about the path.
