[OT] We need a language

[Jeff Cutsinger]

James Michael DuPont <mdupont777@yahoo.com> said:
> --- "Lynn H. Maxson" <lmaxson@pacbell.net> wrote:
 
> lisp! Anyway, I still think that the lessons learned from the gcc and
> other compilers will be useful to the tunes project.

Sure, TUNES is mostly about applying lessons already learned. But you have to
remember that a TUNES language is going to be substantially different from c,
c++, objc, java, and ada, so a lot of the issues there don't apply.
(not that you couldn't program in these languages under TUNES, although I
can't for the life of me figure out why you would want to)

> When there is a tunes language that I can output this information into,
> then I will do so. I hope that some day we will have some type of
> language specification that say, if you put your program in this
> format, then future versions of tunes will be able to support it.

TUNES will be able to support anything current systems support. Whether or not
we'll actually implement this support is another question.

> > If we did this, then we would not use a compiler, which is 
> > probably the biggest single handicap in software development.  

I'm confused. compilers are useful for improving the performance of code, and
I really don't see how they could be a handicap, unless we're talking about
braindead compilers like gcc.

> > Instead we would use an interpreter which allowed us to 
> > process the entire source composing multiple modules, 
> > including up to an entire operating system, coupled with 
> > dynamic testing.

Why can't this be done with a compiler?

> That will be possible, right now I am outputting each module and each
> function as a database that can be re-interpreted at a higher level.

Why don't you learn lisp which has these features built-in to the language?
Why reinvent the wheel? This is the real problem with c++; in order to do
useful and interesting things one has to reimplement Common Lisp (which is
most often compiled, btw), but people usually end up doing it worse than CL
(xml vs sexp, gtk/qt vs clim, templates/preprocessor macros vs CL macros,
etc). Then what you could do is implement /useful/ /functionality/ on top of
something like sbcl (a compiler), like helping to finish up McCLIM or something.

TUNES lesson for the day (for newbies):
TUNES will not restrict the freedom of the coder in any way. The website talks
a lot about formal verification, but this is always optional. The website also
talks about providing sandboxing (like current unix processes) for crappy
(read: unverified) programs. Rather, TUNES will greatly /increase/ the freedom
of the programmer by allowing her to choose formal verification. Existing
systems punish programmers regardless of the provability of the
safety/correctness of their programs by placing every program in sandboxes.
So, TUNES will not be like ML, Haskell, or Ada in that it will not enforce
static verification, /but it will allow it/. The big difference is that TUNES
will allow the user of a program to arbitrarily sandbox programs and provide
her with warnings that a program might (or even will!) crash.
Imagine downloading a program, and telling the computer to run it; if the
program is not provably safe, a warning may be issued and the user given the
option to not run the program, or to run it using dynamic types, or to run it
sandboxed, or even to just trust the program and run it anyway.
(I hope I have this correct)

-Jeff Cutsinger