addSlot complicating module handling

[Lee Salzman]

Samuel Bronson, you read my mind. :)

While Mark here meant speed of execution, Samuel touched on something
that I liked to emphasize now when I talk about what Slate is and where 
it is
going and that is... <<drumroll>> total cost of operation.

How many man hours does it take to write an office suite in C? How many 
in Slate?
I'd like to think it'd take on the orders of magnitude less in Slate 
than in C. Now, one
could reasonably assume a Slate version might, with reasonable levels of 
optimization
that are standard for Java, be about twice as slow as the best C 
version, and consume
twice as much memory.

So, Mark, I offer you a Faustian bargain: I can take man years of your 
development time,
and your program will run on older computers, or I can save you a 
staggering amount of
development time, while only letting your program run reasonably on 
modern computers.

On the face of it, it may seem absurd, but every developer unfortunately 
stares at this bargain
and fails - fails miserably. Just so they can have the satisfaction of 
their program running on a 486,
they spend much more time than they should developing and fine-tuning 
their programs at what is
really an absurdly low level. What does memory addressing and allocation 
truly have to do with an
office suite? It really doesn't. I can write systems, built in to the 
language, to deal with all this for
me, so I don't have to reinvent the wheel every time I write a program.

This reminds me in a way of when I started programming a lot of 
assembly. Half-way through writing
large programs, it dawned on me: "Sheesh, this task of optimizing 
assembly code by hand is so stinking
repetitive and boring I could write programs to do it for me!" Thus my 
interest in writing compilers was
born and many books later I do that instead of mucking with assembly. 
I'd rather repeatedly bang my
thumb with a hammer or watch grass grow in the winter than write 
assembly anymore. It is horribly
superfluous to the task at hand. But strangely enough, I enjoy writing 
programs that write assembly
for me.

Humans should not do boring repetitive crap, they should write programs 
that do boring repetitive crap
for them! I would not go back to writing large programs in C if you paid 
me. I have forgotten more about
C and C++ programming than many people will ever learn, and every bit 
that floats out of memory after
years of disuse feels like a shackle being lifted. Having seen the green 
meadows of dynamic languages, I
have no intent of ever going back. My concern now is not to make Slate 
as fast as C, it is to make Slate as
fast as possible. I will inevitably always use Slate, so it's totally 
irrelevent how it compares with C. I only
care that I've made it as optimal as I knowingly can.

Now after this long shpiel, I am not saying that Slate will necessarily 
be as slow as Java. If anything, I'd
like to think that I could do a lot better than the other guys - but 
that is just narcissism. Maybe I can,
maybe I can't, we'll find out.

Mark Thoma wrote:

>Samuel Bronson <naesten <at> gmail.com> writes:
>  
>
>>I'm sure slate will be much faster to write than either Java or C. I
>>don't know how people can stand to write entire programs in C, and
>>Java is so boring and verbose (and such a memory hog, too). It seems
>>almost like they forgot to implement syntax in Java...
>>    
>>
>
>I'd never write an office suite or video codec in a slow language. Also, why
>would I want to learn and use two languages like Slate *and* C? I don't feel
>comfortable with that thought.
>
>What will Slate's parallel features be? What about something similar to Occam or
>Eden or some other parallel language?
>
>I like the idea of subcontexts. /me wants-to-have-it
>
>Regards,
>Mark
>
>
>  
>