I'd stick with the silver bullet idea. I don't see machine learning going anywhere, and what passes as machine learning today is just a buzzword.
And others remained impossible still, e.g. cold fusion.
Cold fusion not withstanding, most aren't prohibited by physics - in fact humans already are an existence proof that bio-machines can already create software autonomously with no change in physics, so seems like a question of when, not if.
Definitely not. Machine learning is up there with 2012's nosql movement as one of the most overhyped silver bullets.
The improvements to programming over the last 30 years have been incremental more than anything in spite of the hype cycles of various silver bullets (OOP, functional programming, side effect free code, TDD, nosql, static types, etc.)
Machine learning can't even predict a simple binary proportion ratio. No, it's not a silver bullet.
Machine learning is very effective in categorizing things - for example, given an image estimate whether it pictures a cancer cell or not.
On the other hand, machine learning sucks where you need to predict things instead of categorizing - for example, given a set of factors, figure out your risk of getting cancer within 5 years.
Any such machine learning predictive system will be useless due to under- or overfitting.
(Again, I'm not an expert, just a guy who has many years of experience trying to build such predictive systems.)
Did I miss this? The thesis says it's about what will happen "within a decade" of 1986 -- "as we look to the horizon of a decade hence". He makes no projections beyond that, that I see, and the timeline seems specifically chosen to suggest that further large improvements are still possible but will take time.
Improving the essential complexity has not moved much at all, which is why my computer science education from 24 years ago is still pretty much the same one people get now and hasn't lost its relevance. The removal of the accidental complexity sometimes means it's only the essential complexity left shining through.
In that sense, while he may have had the humility to time-bound his predictions to a mere decade, they've still stayed fresh much longer than that.
(Reading the entire Mythical Man Month in 201x is a bizarre experience; all the specific tech references are so dated that they are more myth than fact now, yet, the underlying points those references are in support of are still quite fresh. Arguably a bit incomplete now, we have teams of a scale well beyond what they had then, sitting on piles of software yet larger, but still correct at the core.)
1. Build vs. Buy - I would say that open source has generally become the "COTS" solution that Brooks was looking for.
2. Requirements refinement and prototyping - agile development.
3. Incremental development - also agile, as well as different evolutionary architecture approaches
4. Great designers - the establishment of technical career ladders at many companies.
Again, none of these things are silver bullets, but they have contributed to significant progress in our industry.
I love this. So rare nowadays to scientists make bold predictions.
Disclosure: I work on Tree Notation (https://treenotation.org/).
Two years ago, in 2017 I predicted Tree Notation will be a silver bullet: by 2027 we will have a 10x improvement in reliability, productivity, and simplicity, thanks to the Tree Notation ecosystem.
2 years later, and thousands of experiments and conversations later, I'm almost positive that will happen.
Every lambda calculus, including yours, corresponds to a Cartesian closed category. Your system is not at all as new as you think; what you are actually inventing are new ways to write down parsers, akin to the many other ways that folks are trying to write down programs in JSON or XML or YAML.
The only advantage that you've got at this point is a 2D addressing scheme, you might think, but E had that in the late 90s: http://www.erights.org/elang/kernel/LiteralExpr.html
Second time I heard this suggestion (https://news.ycombinator.com/item?id=20504193), thanks! Done. http://longbets.org/793/ - “In 2027, at least 7 out of the top 10 TIOBE languages will be Tree Languages AND/OR 0 out of the top 10 languages on 2017's list will be in the Top 10 in 2027. ”
> Your system is not at all as new as you think
I agree. It's mildly new. Tiny tiny little details that make a big difference in practice. To get here I had to stand on the shoulders of giants: built the largest DB of computer languages in the world (over 10k languages with over 1k columns).
> but E had that in the late 90s
Great reference, thanks. E and Kernel-E are great, but the devil is in the details. There are a tremendous amount of tiny little details in Tree Notation and Tree Language that compound to make this something new. You can't take anything out of Tree Notation without losing something important. Everything else you can add via a Tree Language. That makes this closer to binary, imo. There are at least a dozen things that could be taken out of Kernel-E, which itself is a subset of E.
Interesting question though. Can you elaborate?
How is this different than an Abstract Syntax Tree (AST)?
Each word has a location in 2D space. There is a physical manifestation of your program’s source code.
The parsed version (with the words of your source replaced with their parsed types), has the same shape (physical manifestation) as your source code.
So source == AST.
Currently traditional languages this is not true. They are stripped to 1D and the further you move from lisp the more different they become.
<a><b></b></a>
===
<a>
<b>
</b>
</a>
How do you deal with large complex code? Lots of folding?
Large complex code hasn’t turned out to be too difficult yet. The key is well designed tree languages for the task at hand. Also, sublime text helps :). Have some code bases in the 6 digits loc. It’s all about tooling though. I don’t really use folding yet but perhaps that would be another feature that can make things easier, good suggestion. Things like type checking, syntax highlighting, auto complete, are essential.
In XML you would need to insert tags defining the whitespace so that it would be seen by programs operating on the AST.
Are your “two different structures” any different from the same representation in XML?
I think it’s a fair analogy to say tree Notation is just a much simpler XML.
At least 2x as simple:
<proof></proof>
proof
By 2020, we expect Flow to be a competitive rival to Python or R for 80% of data science tasks.
That's incredibly ambitious. Checking in -- are you within 4 months of reaching that goal?
Brooks dared to predict that thirty years later, software would still be created by programmers sitting in front of editors, painstakingly typing up code branches for all of the scenarios a given program is supposed to handle. And their output would still mostly suck, because of the infinity of possible states, mostly due to variables and synchronicity. Complexity that cannot be abstracted away.
Given how starry-eyed we usually are about even the near future, that is bold.
The web, language advances, tooling - these are quality-of-life improvements. They don't 'solve' the inherent complexity of software development, the way it was promised by CASE tools (Brooks' likely target with his essay) and countless other 'business oriented' approaches. In fact those approaches have failed so many times that they have been largely abandoned, so in recent times, Brooks' essay might seem superfluous.
The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Not yet, given that it is still an esoteric tool for a specialized class of problems, as part of traditional software systems. But with increasing computing power, I can imagine a future where machine learning can be set to work on broader tasks and start to look like magic self-directed software development.