If Foo Is So Great How Come You Are Not Rich
If Foo Is So Great How Come You Are Not RichThe idea was discussed somewhere here on wiki, but it did not come to a conclusion. Some claim that certain technologies or techniques (let's call it "Foo") can make software "significantly simpler" to create and/or maintain. If this was the case, then why don't gurus in Foo produce commercial software that goes up against the big titles such as MS-Excel, Auto-Cadd, SAP, etc and blow them out of the water? If Foo makes it twice as easy to write software, then your profit margins would be gigantic compared to the roughly 5% usually expected and you'd grow to dominate everybody. It is hard to believe out of the (at least) 1,000 fans of Foo, not one of them is taking advantage of this golden opportunity. This makes it seem as if Foo fans are full of you know what. Can all 1,000 Foo fans really be Altruistic?
It doesn't matter how quickly you can create an MS-Excel, AutoCAD or SAP clone, if you don't have the marketing clout, reputation and long-term industry momentum of Microsoft, Autodesk or SAP AG, you're not even going to be noticed. Specialist technologies are a powerful tool when you build bespoke applications and compete with other bespoke application developers. With the right tool, you can genuinely blow your competitors out of the water. Such tools can make a big difference in custom and vertical markets. They make no difference in horizontal, COTS markets.
Those are claims, not evidence nor detailed analysis. I can't do much with that paragraph as given other than consider it a general anecdote.
{Similar could be said of the first paragraph.}
It's mostly a question, and 2 wrongs don't make a right.
{GarbageInGarbageOut. There is such a thing as bad questions, which don't allow for good answers. But that doesn't mean the answer was wrong. Can you prove it was wrong?}
As typical with anecdotal observations, I cannot confirm nor deny it. Statements like "With the right tool, you can genuinely blow your competitors out of the water" should have more detail behind it (even if that detail is more anecdotes), otherwise it's not worth stating, in my opinion. It's far too general.
{I'm not the author of the 'blow out of the water' comment, and I'd agree it contains some content that is dubious or irrelevant. OTOH, it is almost never worth elaborating any point other than the main point. Which, in this case, was in the first sentence - referring to 'marketing clout' and 'reputation', which are specific examples of NetworkEffects. Of course, even NetworkEffects are an incomplete answer; another factor is simply that software development costs are usually a very small fraction of a company's budget. Writing equal software twice as fast doesn't mean anywhere near twice the profit from the CEO's perspective; in many cases (e.g. for internal business software), it might only amount to a 1% difference.}
Software development and maintenance (SDM) cost is a big part of the budget of a software company. For a software company, assume about 1/3 of their budget is SDM, which I believe to be realistic. If a GoldenHammer improves SDM costs by 50%, then their revenues would be roughly 17% higher (50% x 0.33). That's a huuuuuge advantage: you'd be eating the markup up. I believe the answer is because there is no GoldenHammer.
I'm not the author of the 'blow out of the water' comment -- at least I don't recall writing it -- but I agree with it. I also agree that it's irrelevant to the main point, but as there's some curiosity about it I'll provide an anecdote to back it up: In the late 1980s, I founded a small software company with some partners. We originally intended to develop videogames, but the videogame market at the time was unstable and risky so we refocused on developing bespoke (custom) business software. Initially, we used ExBase -- as did most similar consultancies at the time. However, as ComputerScience graduates (which was relatively uncommon for consultancies at the time -- most were staffed with accountants and/or downsized middle managers) we recognised the flaws and limitations of ExBase and developed an alternative consisting of C (later, C++) libraries and associated tools designed to facilitate building custom business applications. That was highly successful. Our in-house libraries and tools allowed us to develop more user-friendly applications that exhibited better performance than ExBase, and develop them faster, and re-use code more easily than ExBase. That allowed us to bid lower than our ExBase-using competitors and deliver better quality. Within a few years, we were the only bespoke business software developer in our market area -- our competitors simply couldn't compete with us. For us, our C/C++ tools were a GoldenHammer -- at least compared to ExBase.
I've seen C/C++ custom biz apps fail to last because lower-level pointer and RAM management issues created lots of odd bugs. I saw no evidence it was a competitive threat to ExBase in general, or I would have jumped into it. True, it gave you far more control over the hardware and graphics, but the flip side is that mistakes in the lower-level stuff created odd bugs like random crashes and data corruption. Perhaps some know how to use C/C++ well in such a domain and others don't. C/C++ itself is not a GoldenHammer, but the combination of the right staff members using the right tool in the right domain. Those who mastered ExBase and knew where to use it and where not to also did well and created successful products. Master your tool and respect both its strengths and weaknesses and you can do well with a wide variety of tools.
I think that what you are missing is something the economists call "the network effect". It means that a network is more valuable when a node is added. Think about having an marvellous cellphone that can't call anybody, because the cellphone network isn't part of the usual telephone network. It's conceivable that Foo, on the conditions of the stablished product (Bar) would be better. But Bar has the "network effect" and that's why is the chosen one. I think that the PrisionerDilema? has some connections with it. Programming languages and their popularity are very tied to the "network effect". (cf. http://en.wikipedia.org/wiki/Network_effect)
Why does popularity matter?
Popularity matters because of the network effect, and various other forms of inertia in technology. See also: http://en.wikipedia.org/wiki/Virtuous_circle_and_vicious_circle
I mean specific to this topic. Do you mean like staffing? Having sufficient replacement staff available in the market-place before investing/relying-on a given technology? But such is a real factor to consider, as described in GreatLispWar. -t
Human resources - e.g. education or staffing - is certainly one aspect of the network effect. But there are dozens of such aspects: libraries, frameworks, documentation, tools and IDEs, man-hours spent on compilers and optimizers, marketing or visibility, etc. all increase with popularity, with the size of the 'network'. These are all part of the network effect for programming languages. The reality is that Foo can't win by being 20% better than its incumbent competitor for its purpose, because it is never given a fair chance. So even if there is a technology that would save a company 30 man-days each year, you'll never get to use it unless some big company is willing to back it. Foo needs to be about 10x better for its purpose to compete on technical merit alone. Conversely, if a big company is willing to back a technology (e.g. Google with its 'Go' language, or Sun with Java) it can succeed despite dubious technical merit. One can have enough money and influence to bootstrap the network effect. Or one can get lucky, or seize some opportunity (like Netscape and Brendan Eich did, rushing JavaScript to beat Microsoft to the goal). The network effect is incredibly unfair, but so is life.
Why would the network affect matter that much? I agree it matters some, but not to the level you describe, especially in new industries where big libraries of tools and add-ons don't exist yet anyhow in the legacy or current tools/languages.
It is true that in "new industries" without the established incumbency, new tools can more readily establish a niche or foothold. For example, that's how JavaScript won in the first place. There is also a notion of KillerApplication - e.g. RubyOnRails was the primary cause of success for Ruby, the first language to provide and heavily promote that sort of framework. Of course, new industries are relatively rare (because they quickly mature into established industries) and must often integrate with old industries. And almost any KillerApplication can be cloned to other languages within a year or two, eventually negating that advantage. Network effects aren't evenly distributed. But they are significant enough to have crushed many projects and companies... and more than sufficient to answer the topic question.
If they can be cloned and be nearly equally competitive, then the original language/tool wasn't significantly better after all. But there is also the age old quick-to-write versus quick-to-read trade-off in that a language/tool tuned for "get it up quick" (in the right hands) may not be optimized for team maintenance. Being useful for rapid prototyping and/or experimenting is a good feature to have in some circumstances, but may force tradeoffs in other areas that may become more important in a maturing market. RubyOnRails has a bit of a reputation for being a "write-only framework" in that it can drive second-generation maintainers crackers when "clever abstractions" are a bit too clever, and thus perhaps is favored by sleazy marketers promising "we can build you a full interactive site for cheap cheap cheap, or your mattress is freeeeee!"
I would agree if you reworded that to: "if they can be cloned with nearly equal quality." If a clone is only competitive because of network effects (e.g. because the clone was developed in a popular language), but otherwise had poor quality (e.g. poor performance, security, extensibility, maintainability, and other NonFunctionalRequirements) then it doesn't seem reasonable to conclude that the original wasn't significantly better. Conversely, of course, it's quite feasible that a clone has even higher quality (and this isn't always a reflection of the tools; sometimes it's just lessons learned). In any case, I didn't mention KillerApplications as 'evidence of quality' (they aren't!); rather, I mentioned them only a common vector by which a non-mainstream tool or PL can gain some penetration and footholds in an established industry despite heavy resistance from network effects.
Alice: Bob, why are you unwilling to try this new great technology?
Bob: Because it's new. It hasn't proven itself yet.
(years later) Alice: Bob, why are you unwilling to try this old great technology? It has been used in several projects to great success.
Bob: Those are just a few minor projects. The technology hasn't established itself in the industry. Nobody else is using it, and I can't hire people that know it. I have a lot on my plate, and don't have time to learn some newfangled idea. The company that initially developed it went under because nobody would buy. Clearly, if it was better, then people like me would have picked it up years ago, and they'd be rich.
Alice: sigh...
It would be really nice if the parties involved in this continuous back-and-forth sniping could do so without creating new pages every day that contain minor variations on pointed rhetorical questions that weren't interesting to begin with. Serious case of WikiPollution?. Take it to email, please.
It is a fairly common question in my observation, in more than one language/paradigm even.
Yes, but it's not really a question about programming. Starting a successful business entails a zillion factors other than technical merits of a technology, not the least of which is chance. Do you really want to have a discussion such a broad, general topic? Pointless. And for any number of specific programming technologies, there are other places where this has been discussed ad nauseum -- collect the information together on a more specific page if it's of interest as a separate topic.
Also, the snide tone of this page's title, and several others which have been created recently, grates. It seems ... juvenile. Nyeah nyeah nyeah.
You are welcome to smooth out the snideness.
There is no point. It's simply a FlameWar, and in a war, there is no incentive for either side to say, "You win!" Another page, say IfBarCanBeSoCompellingWhyAmEyeNotUsingIt?, will be created if people successfully answer the question on this page. Here, one obvious value of Foo can be answered with PaulGraham. But then you have people releasing the mainline of attacks on Paul's character, or his achievements, etc. Or they'll ask, "Why aren't all Foobaristas rich?" And right now on a WhyWeHateFoo? page, someone's manipulating reality to say that improving Foo is impossible. Of course, I could say one acronym to shut that position down. But then another snide head will pop up, to be bashed with the padded stick. It's pointless. The best you can do is stem the worst of the wiki, and accept that some lies will get through, polluting the stream. It's all a DoS attack so you don't get any work done. I'm certain there is at least one troll at work, just having fun, and I salute him. There is enough good content in the world, for those who take the time to browse and think, and for those who don't... perfect, let them stay with a community that wants as many people as it can get its hands on. Win-win.
While the tone and tenor of this page is a bit snide, I'll agree... the page seems to be a clear reference to PaulGrahams (in)famous comment that he considers a particular value of foo--CommonLisp to be precise--to be a "competitive advantage". To me, that sounds like a claim that "shops which use Lisp can do things demonstrably faster and/or cheaper than shops that don't." While I don't doubt that many tasks can be done better in Lisp--especially in the hands of skilled Lisp programmers, the SecretWeaponArgument has numerous holes in it that it's hard not to take seriously.
I find your arguments completely reasonable. But let's just take this page on face value. If I actually spread an enormously convincing argument that Foo=Rich, enough that all the FlameWarriors stop posting on the wiki and start making money, guess what -- Foo would no longer be so profitable. I mean, we are getting into logical binds here, whose very rules force one to discriminate against Foo. It's just sad now. For all his flaws, PaulGraham is a zillion times better than some of these snide WikiPolluter?s. Many of his critics (I'm not talking about you) don't come near the standard they hold for him.
I'm sick of this wiki; I only come here to rebut the worst lies, and it's just... I think it's fun for once a week, but any more and it's an unrewarding job.
You seem unwilling to face the reality that MostHolyWarsTiedToPsychology.
Re: "For all his flaws, PaulGraham is a zillion times better than some of these snide..."
Paul is just one person who got rich perhaps because of Lisp. However, there does not appear to be tons of others doing the same. Many successful dot-com's used ASP, PHP, Java, etc. also. In fact, Yahoo is rewriting much of Paul's Lisp code into C++ or PHP (IIRC), although the reasons they give are odd.
Getting rich has little to do with what language you pick, there are far too many other factors involved in business. Quality of product has little to do with success, microsoft already proved that marketing has far more impact on success than quality, language, skill, or anything else you can think of.
Yes, but even if the software part is only 20% of total costs, a big advantage there may make your profit margin go from say 1% to 10%. (Anybody have cost breakdown figures for a typical fledgling software company?) As often described in natural selection discussions, a small percent difference can add up over time. If a company competing with Microsoft grew one percent faster than MS when it first went public, the one percent would compound to make such a company about 30 percent larger than MS about now.
{Being a start-up in a new industry may not be representative of software projects in general. Writing maintenance-friendly code for a "typical" developer may require a different technique than growing faster than your competitor in the dot-com gold-rush. Paul doesn't have a lot of experience in a more typical organization, so his perspective is a bit tilted to a specific situation.}
MicroSoft is rich, and most of its products suck. I think that says enough about the assumptions underlying this page's title.
Many consider their products "good enough". Plus, MS's prices were often better than compitors at the time before they used "product lock-in" as their primary weapon. For example, Lotus-123 was slow to get a GUI and damn expensive compared to MS-Excel. MS-Word was easier to use than Word-Perfect (for newbies, at least). Besides, I am thinking of more niche-based products as a comparison rather than mass-market software. There's a lot of niche software out there.
Microsoft products were relatively feature-rich for a reasonable price. Thus, between features, quality, and cost, MS scored high on two of those and that's largely why they succeeded. Nobody's ever shown they can master all 3 in multiple products. It may be because WorseIsBetter.
"Study Finds You Don't Have To Be Smart To Get Rich": http://www.informationweek.com/news/showArticle.jhtml?articleID=199201363
Merge this topic with SecretWeaponArgument?
Then again, some of the discussion in SecretWeaponArgument is actually about trade secrets, which was not the intention of this page.
First of all, several comments have brought PaulGraham into the mix. In his case, he's been saying "Foo *is* great! It's how I got rich!" Thus, he isn't exactly the best person to look at, as an example of IfFooIsSoGreatHowComeYouAreNotRich. Indeed, he's a counter-example.
Second, the observation that network effects, and even business decisions, affect the success of a business, independently of the value of a given technology, is spot-on. I know of one company that made rugged little computers that could be put into all sorts of uses. By the time they figured out their best market, they ran out of funds, and were unable to continue.
I even remember someone telling me of a great literal network product, considerably faster than Ethernet, and had a few other advantages to boot. But because the device wasn't called "Ethernet", they had a very difficult time convincing businesses to go with it! So they literally went out of business, because they couldn't get a big enough network off the ground that could take advantage of their business model.
Third, using technology can be easy--nothing is stopping any of us from picking up a Lisp, and writing a program that repeats, ad nausium, "Hello World" all the time. But to extend that to a 3D game, with lots of math and stuff, is hard! (And this is from someone who, as a mathematician who loves such things, has actually tried to do this, albeit in Python and not yet in Lisp or Haskell.) It takes time to put together something complex. In the meantime, I have a family to feed, so I need to convince others to pay me money, and I generally do this by using libraries and languages and platforms and even the computer hardware that was chosen for me, to one extent or another. I am now working for a Telecommunications Company, and their basis is a product called Asterisk, because it was the platform available at the time; there's a new platform called FreeSWITCH, that does things better...but the company hasn't switched (even though we're interested in the new platform) because of all the resources and scripts that rely on Asterisk.
All this new technology is wonderful, but old technology isn't completely useless just because it's inferior. There's a cost to switching, or even to something new, and unless those costs can be overcome, sometimes you're just stuck at being poor. Heck, sometimes you're stuck at being well-off. While Paul Graham is fortunate enough to have become rich, there's the possibility--however unlikely--that a startup will reach a "local maximum" where there's just enough customers to please, but not enough to continue to grow, that you become a profitable business that won't necessarily become rich. But that doesn't mean the business--or the technology it's founded upon--isn't worthwhile! --Alpheus
I find it statistically unlikely that say a Lisp-centric software company would not eventually form to kick the standard language companies' asses if it was really a true productivity improver. Lisp was popular in the 80's due to the AI bubble and many were eager to hop into the fad and run with it. I realize there is more to a company than programming cost, but in a software publisher org it's roughly half the total costs. If Lisp gave them a 20% productivity advantage over Algol/C-style languages, then they'd have a 10% productivity advantage over competitors. That would give them a pretty hefty profit margin and they'd grow fairly quickly compared to the "Algies". If you can make the argument that Lisp has not been commercially tried often enough, please do. -t
I suspect your 'statistically unlikely' has no statistical basis whatsoever. In any case, software companies rarely compete in terms of "productivity". They compete in terms of: domain expertise, good ideas, location, software performance and quality, networking, marketing, reputation, persistence, and a bunch of other things. I sincerely doubt productivity is even among the top ten factors for success.
You are saying that if all the developers only worked 4 hours a day, nobody would know the difference? And "productivity" is not necessarily explicitly-measured productivity. If your biz depends heavily on software, then a roughly 10% increase in programming productivity should eventually manifest itself in terms of profit and market-share, especially among multiple companies using the "better" approach. (Some text since added after reply below.)
[Point nicely misunderstood.]
Anyhow, we'd probably have to look at actual expenditures to see how much is related to software development and maintenance cost. I expect that for niche markets with a fairly close-nit or slowly-changing customer base, development labor would be a significant part. It's "executive"-oriented "marketing-ware" that has a high BullshitBudget?.
For the sake of argument, lets say hiring a room full of Lisp whizes would work for most companies if they simply just did it. However, the decision makers have no visible reason to try unless enough companies try it and demonstrate it works first. It's not realistic to expect them to take your word for it; they want to see it working "live" first in sufficient quantity. Around four is the magic number I'd estimate to get the industry's attention: if 4 software-heavy companies were clearly successful and had relatively recently hired a room full of Lisp whizes, other companies would begin to take notice and try it themselves such that it would start self-perpetuating.
Lisp has and always had the "industry's attention". Whilst it's not as popular as mainstream languages like C#, Python and Java -- and its quirky nature means it probably never will be -- many large, diverse code shops employ it somewhere. In some industries, like financial services and automated trading, it -- along with other functional programming languages -- is popular.
I am mostly considering "mainstream" IT. I agree it has some niches where it may do well, but these are largely domains that benefit from a so-called HackerLanguage.
By some definitions of "mainstream" IT, there isn't any need for languages outside of VisualBasic and MicrosoftExcel, and there's a lot more need for the latter than the former.
I don't see that to be the case. I've worked in shops where "write-only" programming would have been a good fit, but managers resisted techniques favoring such, largely out of unfamiliarity. And the opposite can happen: a coder may be proficient using a very "compact" form of expression, and nobody complains because work is getting done: UNTIL this coder leaves and the follow-on programmer is confused by the prior technique. A lot of it depends on the personally of the organization or specific managers at the time, not necessarily an overall plan. But being burned by the second sticks in their mind far more than the first. Lost "extra" productivity margins are not very visible to owners/managers (unless it's their main cash cow), while outright stoppage due to the second is quite visible and memorable. An analogy would be home water heaters: If your heater is inefficient, you may grumble a bit while paying bills, but when it's outright broken, you cuss your ass off under the cold shower.
There's a related "war saying" that the best way to defeat your enemy is to subliminally nibble away at them, not bash them in the face.
You don't see what to be the case? You don't see a lot of VisualBasic and MicrosoftExcel?
Some of what may be a case of SovietShoeFactoryPrinciple?
The drawbacks of Lisp may be more visible to decision makers than the benefits.
Probably. Lisp is quirky. It's in use, even popular, where specialist requirements drive the need for a language of its capability. Mainstream IT doesn't demand much of programming languages.
Depends on how you define "demand much". Most orgs want "serviceable" software at a "good" price with little or no interruption due to shifting staff. Those are "demands". If you can build a better mouse-trap that delivers those without significant new drawbacks, you'll be Kazillionare.
In general higher abstraction is harder to manage, verify (by owners), and hire for. That's just the way it is. Some niches can handle the tradeoffs for higher abstraction due to the nature of the domain or happenstance of personnel. But just like winning the Superbowl, that requires skill, luck, timing, and perhaps gambling that the right combination of people click with each other and stay around.
Plus, what works under one management style may not work under another. The "traditional" approach will never be "A" grade, but it will usually be at least "C" under most management styles. An abstraction-leveraged management technique may be "A" under it's current (optimal fitting) management style, but perhaps would be "D" or "F" under most others. Thus, a change in owners or a retirement could send things spiraling down.
As far as the PopularityOfLisp, I disagree, but will leave that topic to that wiki topic.
By "mainstream IT doesn't demand much of programming languages", I mean "mainstream IT" generally doesn't demand higher-level constructs, metaprogramming and generative programming, high-performance arbitrary-precision numerical processing, extreme fault-tolerance, and so on. What it does generally demand are facilities to produce simple data recording, processing and reports, in a repeatable and maintainable fashion at reasonable cost, without requiring a high degree of technical competence.
Not this fuzzy argument again. How do we know if something "demands higher-level constructs", and what are "higher-level constructs" exactly? Without some kind of definition or sample sets to compare and study, your statements are not useable to readers. Are we back to HOF-square-one yet again? I encounter apps all the time that could make use of meta-programming techniques, but I usually avoid them because it makes non-me maintenance more difficult, NOT because it's not a useful technique. It's the balancing point between the power of more abstract techniques and team-skills & staffing issues as discussed in EconomicsOfAdvancedProgramming (which is largely about productivity versus risk).
What argument? I'm still not clear what you're arguing for or against. Are you arguing that higher-level constructs -- like higher-order functions, for example -- shouldn't exist at all?
I am saying that the need-level for "high-level" constructs is not really what's shaping "mainstream" expectations or shop practices. The industry found that a reliable supply of PlugCompatibleInterchangeableEngineers is more important than the benefits of higher abstraction. And I suspect the areas where Lisp shines is in WriteOnlyLanguage-type of apps or sub-systems, such as one-time throw-away queries, reports, or studies. However, it then wouldn't really show up on the language radar (like TiobeIndex) because the org wouldn't care whether one used Lisp, APL, or BrainFsck for fungible sub-apps as long as the programmer "gets it done" quick and reliably.
Of course the need-level for "high-level" constructs is not mainly what's shaping "mainstream" expectations or shop practices, though it clearly has some influence. High-level constructs do, over time, make their way into mainstream languages. However, Lisp is a specialist language for meeting specialist requirements. It is used by organisations that have such specialist requirements, which by definition are fewer than those with mainstream requirements. Therefore, Lisp is not as popular as languages used to meet mainstream requirements. There is nothing to debate here -- that is how it is.
That's not the position of a "typical" SmugLispWeenie. To them, Lisp should be almost everywhere and is not a niche language. You killed the original SmugLispWeenie and took over their body, didntcha!
I can't speak for SmugLispWeenies, as I am not one. I consider languages on their merits alone, and try to avoid Fanboyism. [FanBoy]
It doesn't, particularly. Should it?
It helps to be on-topic :-)
I responded directly to your comments.
Maybe that was a mistake :-)
If there was an algorithmic solution to achieving domination and blowing your competitors out of the water, everyone would be employing it and everyone would be blowing everyone else out of the water. There wouldn't be much left in the water.
The whole process of competition in a free market is predicated on high failure rates. If those failures can't be on technical grounds then they must be on other grounds - however specious those grounds may be. But there have to be failures.
Because being rich is almost completely about luck. Many people that work hard every day of their lives die poor and plenty of fantastic ideas, books, inventions never get realised because of a lack of money or being in the right place at the right time. If Steve Jobs had not met Steve Wozniak, we would never have heard of either of them, for example. So, naturally, Foo being great is no guarantee of being rich.
I disagree it's purely about luck. SteveJobs is more likely than the average bear to do well because of his passion and (selective) charisma regardless of where the ebb and flow of life would take him. I would point out that he helped kick-start the CGI animated movie industry per Pixar and Toy Story in his time away from Apple. He has a nose for the future, for what can be squeezed out of existing technology, and for consumer reaction to as-of-yet unseen ideas. True, he has failed big at times both inside and outside of Apple (expensive Lisa, Next, "cube" Mac), but the size of his successes seem to greatly over-shadow his failures.
See also HowCanSomethingBeSuperGreatWithoutProducingExternalEvidence, IfSmalltalkIsSoGoodWhyDoesNobodyUseIt, GreatLispWar, PopularityOfLisp, EconomicsOfAdvancedProgramming, ExBaseRant, WebStoresDiscussion
EditText of this page
(last edited November 17, 2014)
or FindPage with title or text search