> BOOM: "One simple lesson of our experience is that modern hardware enables real systems to be implemented in very high-level languages. We should use that luxury to implement systems in a manner that is simpler to design, debug, secure and extend — especially for tricky and mission-critical software like distributed services."
Yes, but this is accomplished using declarative high-level languages, precisely the kind of languages that many programmers will claim are "too hard" (i.e. sufficiently unlike traditional imperative languages).
I bet almost everyone agrees that the goal of most modern software development should be "[...] to implement systems in a manner that is simpler to design, debug, secure and extend — especially for tricky and mission-critical software like distributed services."
The disageement here is on whether this can accomplished by making programming languages simplified and easier to learn as the overriding principle. Sometimes you have to use a complex tool in order to make your work better.
> ...precisely the kind of languages that many programmers will claim are "too hard"
Your argument seems to be that Prolog and Haskell are high-level and Prolog and Haskell are complicated and hard to learn. I agree up to that point. That doesn't imply that any high-level declarative language must be hard to learn. SQL and Excel are declarative high-level languages (more so than Haskell and Prolog in terms of abstraction from the execution model). Both have had much more success with non-programmers than imperative languages have.
Bloom is a much simpler language than, say, Ruby. It doesn't have data-structures. There is no control-flow. Semantics are independent of the order of evaluation. The entire history of execution can be displayed to the user in a useful form. Distributed algorithms can be expressed much more directly (eg their paxos implementation is almost a line for line port of the original pseudo-code definition). We have actually tested Bloom-like systems on non-programmers and had much better results than with imperative or functional languages.
> I bet almost everyone agrees that...
The key part of that quote was "We should use that luxury to implement systems..." ie give up low-level control over performance and memory layout in exchange for simpler reasoning. Note that in both Excel and SQL the user doesn't have to reason about what order things happen in or where things are stored. The same applies to successful dataflow environments like Labview. In contrast, programmer-centric languages like Haskell and Prolog require understanding data-structures and Prolog requires understanding the execution model to reason about cut or to avoid looping forever in dfs.
Excel, SQL and Labview are all flawed in their own ways but we can build on their success rather than writing them off as not real programming.
> We have actually tested Bloom-like systems on non-programmers and had much better results than with imperative or functional languages.
Interesting! Do you have any link to your study? I'm interested to see your methodology and how you handled researcher bias :)
By the way, SQL is a pretty complex formal system well grounded on theory. I would never write it off as "not real". Most people don't understand SQL without training, by the way.
> By the way, SQL is a pretty complex formal system well grounded on theory. ... Most people don't understand SQL without training, by the way.
I think lots of people understand, or can understand, the theory of SQL. It's the "install this, go into this directory, edit this config file, make sure it starts with the system by doing this, install these drivers for the database" stuff that stops a lot of people before they start. Same applies to pretty much everything that runs as a service, like webservers.
Really? I agree installation is a major hurdle, but in my experience -- that is, coworkers and students -- most people are helpless with SQL beyond very basic queries unless they've been trained in it and truly used it. Most people don't understand the relational algebra it's based on, either. To make it clear this is not some kind of elitist statement: I struggle with SQL, too, because so far I haven't needed to write truly complex queries in my day job.
This isn't an argument against SQL, by the way. It's an argument against the notion that the overriding principle when assessing a tool/language is whether it's simple and easy to learn.
Ok sure. My point is that there should be a clear path from "I might want to use this thing, what is it about and can I give it a spin" to "ok I get it, where can I learn more." Not to say that everyone will _instantly_ understand the concepts, but that time spent on incidental tasks is pretty much wasted.
But the basics of almost everything are approachable. The basics of Prolog, Haskell [1], Basic, etc, are all approachable. I learned programming with GW Basic, back when I was a kid; it's learnable, but I wouldn't enjoy building complex software with it.
SQL itself is a complex beast. Approachable in parts and with training, like many complex tools.
We were also taught prolog, asm and (weirdly) pascal. We didn't manage to actually produce anything interesting in any of those. The Access CRUD apps and the little VB6 games were the only working software that came out of that two year class.
> I'm interested to see your methodology and how you handled researcher bias :)
Oh we totally didn't :) Our user testing is very much at the anecdotal phase so far. Fwiw though, the researcher bias was in the other direction - @ibdknox was initially convinced that logic programming was too hard to teach. We were building a functional language until we found that our test subjects struggled with understanding scope, data-structures (nesting, mostly) and control flow. That didn't leave a whole ton of options.
Yes, but this is accomplished using declarative high-level languages, precisely the kind of languages that many programmers will claim are "too hard" (i.e. sufficiently unlike traditional imperative languages).
I bet almost everyone agrees that the goal of most modern software development should be "[...] to implement systems in a manner that is simpler to design, debug, secure and extend — especially for tricky and mission-critical software like distributed services."
The disageement here is on whether this can accomplished by making programming languages simplified and easier to learn as the overriding principle. Sometimes you have to use a complex tool in order to make your work better.