Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Язык программирования (и ОС) ФОРТ (FORTH) Slashdot: Economics of programming language design


Информационный Канал Subscribe.Ru

http://developers.slashdot.org/comments.pl?sid=138807&cid=11621789

Economics of programming language design(Score:1) 
by 2901 (676028) on Wednesday February 09, @04:12PM (#11621789) 
(http://www.cawtech.freeserve.co.uk/) 
It started with great excitement. FORTRAN, LISP, BASIC, ALGOL, PASCAL,
PL/1, FORTH, COBOL. The economic underpinnings were clear enough, and
had three aspects:

1)The early versions of these languages left plenty of room for
improvement. That is to say, a new improved language offered cost
savings to the ultimate users of IT services.

2)The early versions of these languages were relatively simple. It
hadn't cost too much money to develop the language that far. Those
who wanted to start from scratch on a new language had to justify a
relatively modest expense to duplicate what had already been
achieved, and could point to the prospect of large savings to come
under point 1.

3)Compared to today the languages were not widely
deployed. Businessmen did not have to think in terms of duplicate
staffing, with one team skilled in the old language to maintain the
legacy code base, while another team skilled in the new language
work on duplicating the code base, and one day moving on to writing
new code that will eventually save money.

As the years rolled by languages got better. The benefits of new
computer languages were hit by diminishing returns. The threshold
cost, the money you must spend to get the new language competitive
with the old language, rose and rose. The installed base grew, and
with it the costs of change.

A theoretical solution to these problems was the programmable
programming language. Rather than start from scratch, reprogram the
old language. Under the name "extensible programming languages" this
idea had failed serveral times. Sticking points included:

1)Extension mechanism not powerful enough (C #define)

2)Extension mechanism too complicated(ALGOL68C,PROLOG)

3)Base language too simple(FORTH)

There is a three-way pull. The simpler the base language, the easier
it becomes to make a powerful extension mechanism without it becoming
too complicated.

By 1990 it was becoming clear that the CL macro system made CL into
the first fully practical programmable programming language. This
revolutionised the economics of programming language design. Compare
making a new language feature available by starting from scratch with
programming it into a programmable programming language. The advantage
of starting from scratch is that you can get the syntax "just so". If
you want the cost saving of using a programmable programming language,
you have to accept the syntax of the base language, and some mild
constraints on the syntax of your added feature. But there are
savagely diminishing returns in fiddling with syntax. That last 10% of
getting the syntax just so saves what? 1% of programming cost,
perhaps, if you are lucky and the new syntax really is an improvement.

With a programmable programming language the "new feature" is simply a
file a macro-definitions. All your legacy code still runs in the "new
language". Your programmers simply have to learn the extra bit. No
starting over.

A fully practical programmable programming language destroys the
economic rational for programming language design. The point of a
computer programming language is to save money. The point of a new
language is to save more money. There is no point in trying to save
money the expensive way, rather than the cheap way.

Very few persons have understood this. Programmers in other languages
haven't. I don't think many CL programmers have realised either. CL is
politics, not art. I think the reaction of most Lispers, to realising
that not only has Lisp won, but specifically CL has won, is to say "Oh
shit, if we had realised that we were going to be stuck with it for
all eternity, we would have done a better job of designing it."
Tough. The era of computer language design ended 13 years ago. Sorry
you missed it.

Now you are probably aware that computer language design continues
apace, with perl, ruby, python, java and C#. So you are about to
re-read the preceeding paragraphs hoping to spot the mistake. I'll
save you the trouble. The false axiom is that spending lots of money
starting from scratch and retraining all your staff is stated to be a
cost. This is not an /objective/ fact. One man's cost is another man's
revenue stream. The IT vendors that you pay your costs to are the
grateful recepients of their revenue stream.

The problem for the IT industry is not to save their customers money,
but to enhance their own revenue stream.

Consider automating your payroll. You save $10million on clerical
costs, and pay $1million for information technlogy. Net saving
$9million. Revenue for the IT industry $1million. Understand that it
is not their job to sack your clerks for you. If you keep on the
redundant clerks, your costs go up by the $1million that went to
enhance IT revenues.

It is the job of the IT industry to add to their customers'
costs. That is where their revenue comes from. It is up to the
customer to realise savings elsewhere so as to show a net saving. The
sales proposition from IT is: add to your costs here, by spending on
IT, and subtract from your costs there, by spending less, a lots less,
on something else. It is the customers responsibility to make sure
that the cost saving actually materialises.

The fundamental problem for IT is that once a program is written, it
stays written. The challenge for the IT industry is to develop vendor
oriented money iteration technology that makes the customer pay again
and again for the same of stuff.

Having said all that I can now clear up a major confusion. Question:
Why has CL not been widely adopted by the IT industry? Answer: It is
not their responsibility to do so.

It is not that they have examined the technology and found that it
will not save IT costs. Nor is there a conspiracy to rip off the
customers. The simple truth is that it is not their job to find ways
to reduce their revenue stream.

A simple example will clarify this. Some transportation companies save
money by using fancy computerised systems to optimise their use of
trucks. The money comes from truck manufacturers and drivers and goes
to IT. This technology was a supplier-push technology. The IT
industry saw that they could divert revenue from other industries that
their customers bought from, so they made it happen.

CL is customer-pull technology. The IT companies will churn happily
away introducing new languages, at great expense to their customers
for as long their customers continue to pay. If the money keeps
flowing, not only will C++ and PERL be replaced by JAVA and PYTHON,
but they in their turn will be replaced by DARJEELING and MONGOOSE.

It is the customer's responibility to shut off the money.
"Asymmetrical information" is the key concept here. CL will be widely
adopted when the Chief Information Officers of large corporations
start telling their boards: hang on a minute, my empire doesn't need
to be this big, there are big internal savings to be made. 

Subscribe.Ru
Поддержка подписчиков
Другие рассылки этой тематики
Другие рассылки этого автора
Подписан адрес:
Код этой рассылки: comp.soft.prog.forth
Архив рассылки
Отписаться
Вспомнить пароль

В избранное