I think you might be right that he was an early player of a patent filing game that has grown to become rather controversial in some spheres, namely software. The only way to know, besides being alive at that time, is to do the historical research.
Can you recommend any primary sources to learn more about this history (besides the patents themelves)? It sounds like you have read some?
On the bright side, not everyone took the Edison approach. Are you familiar with the history of Hans Bessemer and his approach to patents?
It's because some people really do like complexity.
They like writing 200 pages of documentation. And some like reading it. They want complexity. Keep adding stuff.
I remember reading one of the Windows programmers' hero's writing about some massive document of several hundred pages he wrote while on the Excel team at Microsoft and being overjoyed when he learned Bill Gates had actually looked at it.
I remember reading a post by some programmer on Sitepoint boasting about his program that was so complex it would make your eyes burn, or something like that. He was bragging about this.
I recall all the people in mailing lists and forums who get annoyed when anyone talks about conserving memory or disk space. The reason? Because these resources are so plentiful we can afford to waste them. That is a truly great reason. Brilliant.
I once had a colleague who said software is like a gas. It expands to fill space.
There are a great majority of prorammers who are not only OK with this state of affairs but they seek to preserve it. They get defensive when confronted with spending effort to simplify something.
There's a lot of discussion of simplicity that is just lip service. The truth is, simplicity is not easy. It is not a matter of adding more stuff. And we know programmers are lazy. Simplicity, real simplicity - removing stuff, would make many programmers uncomfortable. It would remove them from their comfort zone.
Simplicity is not burying things under five layers of abstraction so that it fits someone's preferred way to model a solution.
Simplicity is taking away things that are not essential until nothing further can be taken out.
It is cutting things down to size.
Achieveing simplicity means reducing someone's 200 pages documentation or their dizzyingly complex program whose source "will make your eyes burn". It may include using compact symbols instead of someridiculouslylongfunctionname. It means some stuff that someone spent time producing must get cut out.
The creators of complexity are not going to be happy with this. Because they like complexity. They like verbosity. It's comforting. They detest what appears to be cryptic.
That is the price of simplicity. To achieve it in today's programming environment involves offending some people. As such, we avoid it. We discuss it, but we really just dance around it much of the time. Let the complexity continue. We can pretend more abstraction equals more simplicity. Be happy, be productive and have fun.
Meanwhile the connoiseurs of simplicity are marginalised, often leaving them to write occasional blog posts like this one and to work on their simple projects in relative isolation. Embedded programmers know the feeling. Those who appreciate simplicity, and really do trim things down to size, are not the majority.
Keep posting those articles on Forth, hoping someday people might catch on.
What you are arguing for is efficiency, not simplicity. Cryptic and highly compact routines, symbols instead of telling names and memory / disk space conservation beyond the point of diminishing returns, all increase complexity, rather than reduce it.
> I remember reading one of the Windows programmers' hero's writing about some massive document of several hundred pages he wrote while on the Excel team at Microsoft and being overjoyed when he learned Bill Gates had actually looked at it.
When you have a spreadsheet programme you start with something relatively simple. You then add functionality. You add pivot tables and charting and macros and etc. At what point do you stop and say "We need to re-write the entire code from scratch to make sure this stuff is all tightly integrated and bug-free?" or "We need to split some of this functionality off into separate by integratable softs to protect the core product and provide split pricing for power users"?
It's ironic that you're linking to one of Joel's articles in your response, given that he's actually the "Windows programmers' hero" that the comment was referring to: http://www.joelonsoftware.com/items/2006/06/16.html.
Your blog says you have an EeePC and run Plan 9. So does Plan 9 run on the Eee? If yes, which Eee model do you have?
As for the article, it's been a while since I looked at Inferno. Thanks for redirecting attention to it again. It seems like it would make a great mobile OS.
I am going to try running Inferno on an EeePC. Will it only run on Linux? How about BSD?
Inferno seems to do fine on BSD, OSX, Windows. It had a little trouble coping with CLang but a makefile tweak to make it use gcc fixes it.
If you want to try runnong Plan 9 on an EeePC, 9atom is tuned for that. I have one of the older ones (701 is the model, I think) and it does boot Plan 9.
I just ran across No Execute on your blog. I can't believe I never found that before (I've chased up all the Plan 9 stuff before).
I've also been an Atlast user for a few years. Can't believe I never heard about your fork of it. John Walker's writeup on Atlast should be required reading for all programmers.
I'm going to try 9atom. I have a newer Eee with no CD drive. With BSD I can convert iso to img, add boot code and be up and running quick. But I guess it won't be so simple with 9atom? If this works, I'll be very happy.
I couldn't agree more about the Atlast writeup. I'm glad for the vast proliferation of Lua, if for no other reason than it has made scriptability a library. I can certainly believe you've never heard of my fork. I actually feel bad because it's still "in beta", being a work in progress. I've been meaning to send a patch to Mr. Walker for the 64-bit issues, but there's always another bug or feature in the way, and I've held off on a "real" (tarballs on a server, documentation) release until I ping him and fix some bugs.
Regarding 9atom, I don't recall any difficulties booting from USB, but it was a while back, and I didn't quite get it installed. I've been running 9front for the most part when I run Plan 9.
The part about the colleagues only putting in a few productive hours each day is spot on. They are riding on the company's coattails. It is a sort of corporate-sponsored welfare that no one notices until the company stops performing. Then the dead weight is cut loose. Look at Yahoo.
Maybe some people don't find sitting in meetings all day to be all that satisifying. But they are stuck in it due to family expenses. Maybe they would prefer something more stimulating, if they could have the chance.
The default state of the startup should be: _fun_.
More fun than you would have by being required to show up and remain for eight or more hours each day at a corporate campus where you can clearly see people are not getting much done, but are relying on their position as a source of corporate-sponsored welfare.
To work on a startup should be a privilege for anyone who has worked in a corporate setting for any length of time.
Riding on the success of a large corporation is easy. In many cases all you need to do is show up. But that doesn't always mean you were "a success" or a part of the reason for the company's success. You may have come along after they had already succeeded, looking for an easy payout. Some people make a career out of this. They never join early stage companies. Again, there are family expenses and these motivate people's decisions.
Working on a startup is a way to be able to take full credit for whatever happens. It might be credit for failure. It might be for success. But at least you know you were responsible, and not riding on someone else's coattails.
I'd love to see some of the search engines who are catering to more sophisticated searchers just tell us the BOSS, or whatever cache they are licensing, API functions and then indicate which ones they are supporting.
For all we know several of these search engines are all accessing the same cache and they are simply choosing to focus on different options that the cache license offers and making different arbitrary CGI decisions like slash bang whatever.
It makes sense to hide details behind "magic" if the users are unsophisticated. But it seems like there's really little reason to do this for sophisticated searchers.
Maybe there is and I am just not seeing the competitive advantage or value addition.
At the same time, I feel like we may have different search engines all using the same licensed cache source and trying to differentiate themselves on multiple implementations of idiosyncratic ways to access the same cache API, instead of focusing on more basic factors, like speed and privacy.
Maybe searchers just want to access that licensed cache which is too expensive for them to subscribe to. Maybe it's not so important all the fancy things one can do with CGI. Maybe the fancy things are important. Maybe they just crave "features". I don't know.
But my guess is the BOSS cache is probably not that hard to work with and that most searchers could get their searches done easily enough, in simple fashion, if they had their own BOSS subscriptions, without the need for lots of customisations (which equate to the exotic features of these search engines).
