Re: Macros and little languages

[Paul Graham <address@hidden>]

--Howard Stearns wrote:
> Is it more important for a language to promote code that is readable by 
> anyone versed in the particular programming language, regardless of  the 
> application domain, or is is it better to for a language to make it easy 
> to churn out new code that works for particular applications?
> 
> Some say code is read (maintained) more than it is written, and by more 
> people, so that in the long run, a uniform programming-language-domain 
> style is most important.  
> 
> Others say they are paid to write code, but that writing or fixing, it's 
> easier when working in the problem domain.
> 
> Some worry that sufficiently powerful program-domain code, or 
> conversely, that sufficiently powerful application-domain code, is too 
> hard for mere mortals to work with for writing or for reading.
> 
> Some claim that development tools can reduce the exposure to code to 
> such a small amount that the issue becomes moot.
> 
> How do the answers depend on whether we're talking about a closed group 
> of programmers employed for a single task, vs. an open-source project, 
> vs. distributed group-accreted semantics built on the Web in the next 
> generation?  Is there any way to defiine the issue specifically enough 
> to actually say something more useful than personal preference?
> 
> 
> 
I think these are all good points.  I would just add that, even if
code "spends" more time being looked at later by other people than
it spent being written by the original author, those later minutes
may not be worth as much as the earlier ones, because if you don't
have a language that's fast to program in, your app may never
survive to be read by anyone.  For example, a lot of Viaweb's
competitors used languages like C++, presumably partly because
they were "mainstream" languages and anyone who came along later
to maintain them would have an easy time of it.  But this same
technology made it slow to *develop* programs.  Result: they
are out of business, and no one is reading all their nice
new-hire friendly mainstream code.  

Over and over we hear that the time required to develop
software is proportionate to the source code size.  So if
a startup uses a language that's diffuse, for the sake of
whatever vague high-minded principle, they'd better hope 
that their competitors don't call their bluff.

--pg