It rubbed me the wrong way when, after explaining for several pages that successful FAI Programmers would have to be so good that the very best programmers on the planet may not be good enough, it added—“We will probably, but not definitely, end up working in Java”
I had the same thought—how incongruous! (Not that I’m necessarily particularly qualified to critique the choice, but it just sounded...inappropriate. Like describing a project to build a time machine and then solemnly announcing that the supplies would be purchased at Target.)
I assume, needless to say, that (at least) that part is no longer representative of Eliezer’s current thinking.
That’s true. But inasfar the requirements of the FAI project are objective, independent of PL development in the industry, they should be the main point of reference. Developing your own language is a viable alternative and was even more attractive years ago—that’s what I meant to imply.
It depends on whether you want to take advantage of resources like editors, IDEs, refactoring tools, lint tools—and a pool of developers.
Unless you have a very good reason to do so, inventing your own language is a large quantity of work—and one of its main effects is to cut you off from the pool of other developers—making it harder to find other people to work on your project and restricting your choice of programming tools to ones you can roll for yourself.
Anecdotally, half the benefit of inventing your own language is cutting yourself off from the pool of other, inferior developers :-)
Remember that Eliezer’s assumption is that he’d be starting with a team of super-genius developers. They wouldn’t have a problem with rolling their own tools.
Well, it’s not that it’s impossible, it’s more that it drains off energy from your project into building tools. If your project is enormous, that kind of expense might be justified. Or if you think you can make a language for your application domain which works much better than the best of the world’s professional language designers.
However, in most cases, these kinds of proposals are a recipe for disaster. You spend a lot of your project resources pointlessly reinventing the wheel in terms of lint, refactoring, editing and code-generation technology—and you make it difficult for other developers to help you out. I think this sort of thing is only rather rarely a smart move.
I had the same thought—how incongruous! (Not that I’m necessarily particularly qualified to critique the choice, but it just sounded...inappropriate. Like describing a project to build a time machine and then solemnly announcing that the supplies would be purchased at Target.)
I assume, needless to say, that (at least) that part is no longer representative of Eliezer’s current thinking.
I can’t understand how it could ever have been part of his thinking. (Java was even worse years ago!)
Not relative to its competitors, surely. Many of them didn’t exist back then.
That’s true. But inasfar the requirements of the FAI project are objective, independent of PL development in the industry, they should be the main point of reference. Developing your own language is a viable alternative and was even more attractive years ago—that’s what I meant to imply.
It depends on whether you want to take advantage of resources like editors, IDEs, refactoring tools, lint tools—and a pool of developers.
Unless you have a very good reason to do so, inventing your own language is a large quantity of work—and one of its main effects is to cut you off from the pool of other developers—making it harder to find other people to work on your project and restricting your choice of programming tools to ones you can roll for yourself.
Anecdotally, half the benefit of inventing your own language is cutting yourself off from the pool of other, inferior developers :-)
Remember that Eliezer’s assumption is that he’d be starting with a team of super-genius developers. They wouldn’t have a problem with rolling their own tools.
Well, it’s not that it’s impossible, it’s more that it drains off energy from your project into building tools. If your project is enormous, that kind of expense might be justified. Or if you think you can make a language for your application domain which works much better than the best of the world’s professional language designers.
However, in most cases, these kinds of proposals are a recipe for disaster. You spend a lot of your project resources pointlessly reinventing the wheel in terms of lint, refactoring, editing and code-generation technology—and you make it difficult for other developers to help you out. I think this sort of thing is only rather rarely a smart move.