Speed advantage of language written in itself?

If you have a language written in itself the advantages are?

1. You can extend it right there on the fly.

2. ?


Is speed increased? Depends perhaps but most languages are written in
C so if the alternative is writing the language in itself, will that
make it faster?

There is some Python-implementationn that claims to be faster than
Python itself, I think because it is written in Python itself. However
the cPython documentation mentions C as a speed advantage.

defn noob <circularfunc@yahoo.se> writes:

> If you have a language written in itself the advantages are?

> 1. You can extend it right there on the fly.

Yes and no. Extending it is a bit easier since it is a language that
you are already familiar, since you are presumably already using it.

Whether you can extend it "on the fly" depends on whether the language
has the appropriate dynamic linking abilities. Lisp can be modified
while running because of the dynamic linking. Other language may need
to be re-compiled before any extensions become available.

>
> 2. ?

o You get the benefits of the language it is written in to use when
implementing the language.

o You get portability advantages by having the bulk of the code in a
single, high-level language, namely the language you are
implementing.

> Is speed increased? Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?

Speed is not necessarily increased. That all depends on the quality of
the implementation, which is to a lesser or greater degree independent
of the language used to implement the language itself.

Note that languages actually don't execute in C (at least I'm not aware
of any native-C machines), but rather in some machine code. If whatever
compiler you write for your language emits good, optimized machine code,
then it will be fast. This is completely independent of what language
the compiler is actually written in. It is possible to write bad code
in any language.

So, a lisp compiler written in lisp can (and many existing
implementations do) produce very good, efficient machine code.
Certainly Allegro, Lispworks, Clozure/Macintosh, CMUCL and SBCL all
produce very good code. I'm not familiar enough with CLISP to be able
to comment on its compiler output quality.

Now, certain compiler optimizations are easier to write in a higher
level language like lisp, so there are some things that can be exploited
to make generating good machine code easier.

In any case, no matter what the language, there has to be some initial
boot-strapping procedure to get any new programming language (including
C) to run on a new processor architecture. But once a (usually simple)
base is bootstrapped, a fully native implementation can be brought up.

Now, for various reasons, it is sometimes convenient to construct hybrid
systems where more than one language is used in the implementation.
That allows you to use a greater variety of tools, applying each one in
the area where it is most appropriate.

> There is some Python-implementationn that claims to be faster than
> Python itself, I think because it is written in Python itself. However
> the cPython documentation mentions C as a speed advantage.

The implementation language is irrelevant. The important measure is the
quality of the implementation.

--
Thomas A. Russ, USC/Information Sciences Institute

defn noob <circularfunc@yahoo.se> writes:

> If you have a language written in itself the advantages
>
> 1. You can extend it right there on the fly.

You can extend languages that aren't implemented in themselves on the
fly too. Any language that allows you to load a subroutine can do
that. Lots of languages even do that quite easily. Lisp allows for a
lot of freedom to extend the language, but that has nothing to do with
wether or not the particular environment is implemented in lisp or or.

Implementing a language in the language itself (or *mostly* in the
language itself) just means you don't have to learn another language
to mess with the implementation. And you might not be held back by the
limitations of the "lower-level" language, which may or may not mean
you can optimize better. It all depends.

> 2. ?
>
>
> Is speed increased? Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?

Lots of languages aren't implemented in C. C is just a convenient
gateway to the API of many operating systems. And C is pretty fast, if
written to be fast.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

defn noob wrote:
> If you have a language written in itself the advantages are?
>
> 1. You can extend it right there on the fly.
>
> 2. ?
>
>
> Is speed increased? Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?
>
> There is some Python-implementationn that claims to be faster than
> Python itself, I think because it is written in Python itself. However
> the cPython documentation mentions C as a speed advantage.

Whether a language is implemented in itself or not is completely
independent from whether the implementation is efficient or not.

The cPython documentation mentions C as a speed advantage because the
authors of that documentation don't know what they are talking about.
cPython is implemented as a naive interpreter, and naive interpreters
are always slow. Yes, a naive interpreter in C is probably more
efficient than a naive interpreter in, say, Python.

However, you are probably referring to the PyPy project, a Python
virtual machine implemented in Python. In that approach, they use a
partial evaluator to generate a JIT compiler for Python. Yes, PyPy is
implemented in Python itself, but the efficiency comes from the JIT
compilation, not from the choice of implementation language.

So what matters here is (a) choose the right implementation approach and
then (b) choose the right language for that implementation approach
(usually Common Lisp .

Lisp is traditionally described using a metacircular interpreter. The
classic metacircular interpreter is a naive interpreter, and is
therefore quite slow. The metacircularity is primarily interesting from
an educational and from a theoretical perspective. [1]

Pascal

[1] It is also interesting because it is a starting point for adding
reflection to a language, but that's a different story...

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

On Aug 22, 6:54*pm, Pascal Costanza <p...@p-cos.net> wrote:
> defn noob wrote:
> > If you have a language written in itself the advantages are?
>
> > 1. You can extend it right there on the fly.
>
> > 2. ?
>
> > Is speed increased? Depends perhaps but most languages are written in
> > C so if the alternative is writing the language in itself, will that
> > make it faster?
>

There are good software engineering reasons to build a language
processor in itself. The biggest is that you will discover problems
with your implementation (aka interesting bugs) that only show up in a
complex application. Other reasons are human-based. It's a big
milestone that the team can be proud of. It also fires up the team
when they see the language processor executing a complex problem. The
CLforJava project got to that point last semester, and a couple of
students will be working on a new compiler written in CLforJava over
the next couple of semesters. And yes, it is easier to write a
compiler in Lisp than in Java!

On 2008-08-22, defn noob <circularfunc@yahoo.se> wrote:
> If you have a language written in itself the advantages are?

The advantages are that you can ooze superiority out of your pores.

>
> 1. You can extend it right there on the fly.

Not necessarily. C compilers are often written in C, yet their technology is
such that you can't extend C on the fly.

Even dynamically loading functions is a chore which requires considerable
infrastructure that doesn't come with the language.

Forget about adding new syntax on the fly.

> 2. ?
>
>
> Is speed increased?

No. Doh?

> Depends perhaps but most languages are written in
> C so if the alternative is writing the language in itself, will that
> make it faster?

Speed is achieved by compiling a language into machine language (and of course
it matters how cleverly this is done). From the perspective of generating code,
it's irrelevant what the translator is written in.

It's the compiling algorithm that matters.

Do yourself and everyone else a favor and Google for ``algorithm''.

> There is some Python-implementationn that claims to be faster than
> Python itself

You can't compare a language to an implementation. We wouldn't say that ``GNU C
is a C implementation which is faster than C itself''.

Python can be said to be exactly as fast (whatever that means) as its best
implementation. Logically speaking, an implementation of Python can't be
faster than Python.

A Python compiler (whether it is written in Python or anything else) would
hopefully transform Python programs into a representation that executes faster
than Python programs that are interpreted by the popular C Python
implementation.

The difference in performance would be due to compiling versus interpreting,
not due to the compiler being written in Python and the interpreter in C.

> the cPython documentation mentions C as a speed advantage.

That would be in the context of interpreting. C is probably not a bad language
for writing a fast /interpreter/ for Python. However, if a programming language
implementation is purely interpreted, there is no point in bragging about its
performance in the user manual, because the designers haven't taken the obvious
optimization step of developing a compiler. It's analogous to touting a
wonderfully hand-tuned assembly language version of bubble sort.

In article <6h8ud1Fk105nU1@mid.individual.net>,
Pascal Costanza <pc@p-cos.net> wrote:

> defn noob wrote:
> > If you have a language written in itself the advantages are?
> >
> > 1. You can extend it right there on the fly.
> >
> > 2. ?
> >
> >
> > Is speed increased? Depends perhaps but most languages are written in
> > C so if the alternative is writing the language in itself, will that
> > make it faster?
> >
> > There is some Python-implementationn that claims to be faster than
> > Python itself, I think because it is written in Python itself. However
> > the cPython documentation mentions C as a speed advantage.
>
> Whether a language is implemented in itself or not is completely
> independent from whether the implementation is efficient or not.
>
> The cPython documentation mentions C as a speed advantage because the
> authors of that documentation don't know what they are talking about.
> cPython is implemented as a naive interpreter, and naive interpreters
> are always slow. Yes, a naive interpreter in C is probably more
> efficient than a naive interpreter in, say, Python.

Is the CPython implementation really a naive interpreter? From the little
I read it kind of compiles Python code to bytecode which
then is executed by a VM? I would not say this is naive interpretation.

> However, you are probably referring to the PyPy project, a Python
> virtual machine implemented in Python. In that approach, they use a
> partial evaluator to generate a JIT compiler for Python. Yes, PyPy is
> implemented in Python itself, but the efficiency comes from the JIT
> compilation, not from the choice of implementation language.
>
> So what matters here is (a) choose the right implementation approach and
> then (b) choose the right language for that implementation approach
> (usually Common Lisp .
>
> Lisp is traditionally described using a metacircular interpreter. The
> classic metacircular interpreter is a naive interpreter, and is
> therefore quite slow. The metacircularity is primarily interesting from
> an educational and from a theoretical perspective. [1]
>
> Pascal
>
> [1] It is also interesting because it is a starting point for adding
> reflection to a language, but that's a different story...

--
http://lispm.dyndns.org/

On Sat, 23 Aug 2008 09:37:57 +0200, Rainer Joswig wrote:

> Is the CPython implementation really a naive interpreter? From the
> little I read it kind of compiles Python code to bytecode which then is
> executed by a VM? I would not say this is naive interpretation.

After one has used, for example, SBCL, what you describe above does sound
like a naive implementation.

Tamas

Rainer Joswig wrote:
> In article <6h8ud1Fk105nU1@mid.individual.net>,
> Pascal Costanza <pc@p-cos.net> wrote:
>
>> defn noob wrote:
>>> If you have a language written in itself the advantages are?
>>>
>>> 1. You can extend it right there on the fly.
>>>
>>> 2. ?
>>>
>>>
>>> Is speed increased? Depends perhaps but most languages are written in
>>> C so if the alternative is writing the language in itself, will that
>>> make it faster?
>>>
>>> There is some Python-implementationn that claims to be faster than
>>> Python itself, I think because it is written in Python itself. However
>>> the cPython documentation mentions C as a speed advantage.
>> Whether a language is implemented in itself or not is completely
>> independent from whether the implementation is efficient or not.
>>
>> The cPython documentation mentions C as a speed advantage because the
>> authors of that documentation don't know what they are talking about.
>> cPython is implemented as a naive interpreter, and naive interpreters
>> are always slow. Yes, a naive interpreter in C is probably more
>> efficient than a naive interpreter in, say, Python.
>
> Is the CPython implementation really a naive interpreter? From the little
> I read it kind of compiles Python code to bytecode which
> then is executed by a VM? I would not say this is naive interpretation.

The bytecode interpreter is naive.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

defn noob wrote:
> If you have a language written in itself the advantages are?
>
> 1. You can extend it right there on the fly.
>
> 2. ?

You get to use the language when working on the language.

kt