Hisashi Morita ([info]hisashim) wrote,
@ 2005-11-17 22:21:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
[Business][Language][Lisp][Ruby] Secrets of Successful Programming Language Business
Secrets of Successful Programming Language Business
---------------------------------------------------

As I had a chance to talk with Mr. Fritz Kunze (President of Franz Inc.) in the party after Franz's Lisp seminar today, I asked him a question, that is:
What is the secret of successful language business?

I asked him because I remembered matz (a language designer, the author of Ruby) wanted to know how to succeed in language business.

Fritz generously answered to my question, though the first thing he said was that it's very hard to succeed in language business. His answer was as follows if I recall correctly.

(Note that these are based on my distorted memory and not exactly what they said. If there are anything that are not true, it's my fault.)

  • Be a cult leader.
    Programming language is a cult. It's a religion. Many programmers stick to one language and do not change it for 50 years, their entire career. So you have to be like a cult leader to gain a good user base.

  • Get a partner who is really good at marketing and sales.
    You need a person who knows marketing and sales very well, even if he/she has opinions contradictory to yours. Do not get a partner who is a geek type like yourself, or you will miss the market.
    Hire a nice and talented woman to maintain good public relations, since your users / customers are geeks, and geeks do listen to women but not much to men.

  • Use a standardized language.
    ANSI Common Lisp is a dirty language. But it is standardized. In business, it's very important to be standardized. In a world of standardized language, there are many vendors and implementations, and they are compliant to the specification and interoperative.
    Mr. Hisao Kuroda, the Head of Knowledge Engineering Devision at MSI, took over and explained us why he would not use those new scripting languages for his business. It's because they are not languages but only implementations that lack written specifications. He wants his application software to survive no matter what happens to the implementations. It's not a matter of preference but a matter of survival.
    So, write a specification.

  • Be very lucky.
    Language business is very hard. You need a very good luck to survive.


Other interesting topics:

  • It takes 15 years for a programming language to mature. It was guaranteed that those venture companies in 90's which used Java failed.

  • Databases sells better than languages as product.


(I will add more when I remember more.)

It was a very interesting talk.

(I will cancel this post if anyone concerned thinks I should.)

(Post a new comment)


[info]mutiny
2005-12-01 07:22 pm UTC (link)
Mr. Hisao has a great point about not betting the farm on a specific implementation. That's why I'm so hot on Python. It's language is quite standardardized, the syntax changes in a very regimented and pragmatic way, and there are a variety of implementations I can choose from so I don't have to bank on just one and have the flexibility to pick whichever one I want.

(Reply to this)(Thread)
language standardization, separation of specification and implementation
[info]hisashim
2005-12-02 02:21 am UTC (link)
Yes, I agree that, in respect that it has multiple practical implementations, Python leads other scripting languages. (And by the way, I like its attitude toward human readability, though I like a language more when it "encourages" me to write right than when it "restricts" me to write right. But everything has trade-offs and a designer has to make a decision...)

I didn't know Python went ANSI/ISO/ECMA/whatever standard and could not find relevant information, though I knew it's well documented. Any URLs?

(Reply to this)(Parent)(Thread)
Re: language standardization, separation of specification and implementation
[info]mutiny
2005-12-02 07:25 pm UTC (link)
Python's readability is definitely one of the biggest things that drew me to it, also. Although I don't think Python is "blessed" by any kind of standards body I think the Python's PEP process for changes trumps any kind of standards body, designed and enhanced by the users rather than a closed committee.

(Reply to this)(Parent)
Python standardized ?!
(Anonymous)
2005-12-02 03:22 pm UTC (link)
What is the matter with fanboys ? Don't you know the first thing about programming ? Do you think "standardized" means "Guido said that'll stay" ?

A standardized language goes through a process via an organization like ISO, ANSI or ECMA. They are responsible for standards in other engineering and technical areas. Languages like C, C#, Common Lisp, Eiffel, Fortran, Forth and SmallTalk all have standards. Notice how some of these languages are "old", but still very much in use by serious enterprises and research centers. Software that's made to last. Very different than hype posted on Slashdot. Or very different from "scripting" language hypes.

Languages like Python change according to the whims of their developers. They change as you go. For instance, lambda will be extricated form next Pythons. If you've written code with lambdas, it won't work.

The problem with many of those languages mentioned above is that they are very large. This means it's easier to pick up Ruby than SmallTalk. But this is not a rule. Eiffel, as a language, is small. So is C. But their libraries are large. So you need to work at them, You can't approach programming languages with the "10 days" approach.

Sadly, so many people spend time and energy with badly implemented languages, forgetting that many good engineers have worked to design sophisticated languages. Languages designed for the professional, not designed for a hobby or for the purpose of learning how to design a language.

The open source community would do better to focus on the standardized languages. They have lasting power, and all of them (with the exception of C) are better designed than any scripting language du jour.

(Reply to this)(Parent)(Thread)
Re: Python standardized ?!
[info]etrepum
2005-12-02 03:55 pm UTC (link)
Languages like Python change according to the whims of their developers. They change as you go. For instance, lambda will be extricated form next Pythons. If you've written code with lambdas, it won't work.


Uh, no. That example is incorrect. lambda isn't going anywhere. Just because Guido muses about something on his blog doesn't make it a pronouncement. Deprecation in Python happens in phases and involves a PEP.

(Reply to this)(Parent)
Re: Python standardized ?!
(Anonymous)
2005-12-02 06:48 pm UTC (link)
A standardized language goes through a process via an organization like ISO, ANSI or ECMA. They are responsible for standards in other engineering and technical areas.
An open-source-driven language like Python goes through a process as well. But instead of corporate representatives, committee-based design, and a stamp of approval, they have an internally agreed upon standardization process. Things like the level of importance given to backward compatibility are decided upon by the community. The decision process in Python is relatively formal -- with the enhancement documents (PEPs) and standards for deprecation. Backward compatibility is taken quite seriously. Ultimate authority belongs to a single person (in this case Guido, but a similar person exists for most open source languages); I don't see how this is any worse than decision making by committee. Indeed, it is far simpler and more efficient, while also more transparent and accountable.

Some of the better standardized languages were designed in a similar way (though usually not transparently), then standardized after the fact. Smalltalk and C# are examples of this. Time will see how C# fairs, but Smalltalk (as a language) hasn't changed significantly since that initial phase of design stopped. If you think it is Perfect And Never Should Be Changed, then that's fine. But it isn't community driven, and never was.

Some of the bad examples of standardization involve standardizing unimplemented features. (My impression is that later Fortran standards succumbed to this.) This never happens in open source languages; the implementation is the standard, thus nothing that doesn't exist can be standardized, and the standardization is authoritative -- the standard is the functionality as implemented. This is actually better for backward compatibility, because there's never an issue about whether the implementation has a bug, or the standard has a bug. What Is, Is, and if you want to be backward compatible you are backward compatible with what was actually implemented, which is the only thing people actually relied on. Developers don't code to a spec when it doesn't match an implementation, they always code to the implementation.

When there are competing implementations, standardization through standards bodies might matter more. Open source licensing removes this motivation, and removes the standards body without removing the essential process; language users benefit immensly.

(Reply to this)(Parent)(Thread)
Re: Python standardized ?!
(Anonymous)
2005-12-02 08:13 pm UTC (link)
All of these points are valid and and important for open-source language designers, but none of them are really relevant to language standardization as discussed in the original post, Anonymous.

Mr. Kuroda was talking about standardized languages FOR HIS BUSINESS. One gets the impression, at least from reading their English website, that most of MSI's customers are large companies that do VLSI design/fabrication or auto manufacturing. In other words, companies with a high ratio of pointy-haired bosses to engineers, low per-capita productivity, and (theoretically) vast economies of scale.

Those companies have such a huge organizational overhead that it makes sense for them to demand standardization-- they want to buy a product, use it for 15 years, and then (maybe) write a memo to form committee to consider the possibility of making a recommendation to forward a request for the updated software to the purchasing department's managerial oversight team. They can do it with car parts and Hydrofluoric Acid-etchers, and they want to be able to do it with software too, and they're OK with using software that is only marginally not-a-waste-of-money. That's just the way they are, and since they have truckloads of money to spend, software suppliers like MSI have evolved to think a little bit like that too.

Be honest here: how much benefit would a huge institutional user like Toyota derive from using a fluid/standard language like Python, given the environment of intermittent, serious, or perhaps total neglect where some of that languages projects will have to function?


... not that it matters. You can yell as loudly as you want that Python is so a really good language. But CL and Scheme are still both better languages, and they will be Python gets macros.

(Reply to this)(Parent)

[info]xach
2005-12-02 04:00 pm UTC (link)
Section 3.3.8 of the Python Language Reference is a prime example of how not to standardize and specify a language.

(Reply to this)(Parent)(Thread)
Because?
(Anonymous)
2005-12-02 06:07 pm UTC (link)
?

(Reply to this)(Parent)(Thread)
Re: Because?
[info]xach
2005-12-02 06:09 pm UTC (link)
It says, in essence, "getting this right is too hard, here are some heuristics." That's not good enough.

(Reply to this)(Parent)(Thread)
Re: Because?
(Anonymous)
2005-12-02 10:50 pm UTC (link)
In standards they simply specify the core subset formally and define the remaining behaviour "implementation-dependant". Even standards does not define every very detail of the language!

(Reply to this)(Parent)(Thread)
Re: Because?
[info]graydon
2005-12-02 11:53 pm UTC (link)
Yes, but read 3.3.8: it's really bad, and it's an important part of the language.

(Reply to this)(Parent)

(Anonymous)
2005-12-03 09:30 pm UTC (link)
what are you talking about? http://www.network-theory.co.uk/docs/pylang/ doesn't contain a chapter 3.3.8

(Reply to this)(Parent)(Thread)

[info]xach
2005-12-04 01:09 am UTC (link)
In that link, the section is 4.3.8.

(Reply to this)(Parent)(Thread)
Does getting rid of it make it ok?
(Anonymous)
2005-12-05 01:14 pm UTC (link)
Quoting from the link:
In Python 3.0, coercion will not be supported.

Is this good enough? Cause of course then the heuristics all go away.

(Reply to this)(Parent)(Thread)
Re: Does getting rid of it make it ok?
(Anonymous)
2005-12-05 02:25 pm UTC (link)
Does the "language reference" thoroughly document Python 3.0? Unless it does, it's not good enough.

(Reply to this)(Parent)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…