C++ religious war (was: llua Higher-level C API for Lua)

classic Classic list List threaded Threaded
101 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

C++ religious war (was: llua Higher-level C API for Lua)

Dirk Laurie-2
2014-03-16 6:00 GMT+02:00 David Crayford <[hidden email]>:

> The compiler I use (IBM xlc) is extremely aggressive wrt inlining when
> optimizing. If you don't hose it down with -qinline=limit=num you end up
> with big ass binaries!

I have with my usual considerateness edited the subject line to
better reflect the direction that the thread has been taking.

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Coda Highland
On Sat, Mar 15, 2014 at 11:04 PM, Dirk Laurie <[hidden email]> wrote:
> 2014-03-16 6:00 GMT+02:00 David Crayford <[hidden email]>:
>
>> The compiler I use (IBM xlc) is extremely aggressive wrt inlining when
>> optimizing. If you don't hose it down with -qinline=limit=num you end up
>> with big ass binaries!
>
> I have with my usual considerateness edited the subject line to
> better reflect the direction that the thread has been taking.

I dunno, it hasn't really seemed so much like a religious war -- or
really, even, a war at all. I haven't seen any anti-C++ zealots trying
to bring up why C++ sucks, or any C++ apologists defiantly claiming
that C++ is the ideal language. It's been a really rather tame
discussion about issues to be aware of and techniques with which to
handle them.

I mean, if we wanted to start a religious war, try suggesting that Lua
should be written in C++ instead of C89 and see where THAT goes. ;)

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

steve donovan
On Sun, Mar 16, 2014 at 8:14 AM, Coda Highland <[hidden email]> wrote:
> I mean, if we wanted to start a religious war, try suggesting that Lua
> should be written in C++ instead of C89 and see where THAT goes. ;)

Absolutely!  We have enough of a frothy when suggesting C99 ;)  But
(and this is important) Lua does _build_ with C++ and can use proper
exception handling rather than that weird hack called longjmp.

At least, we're not discussing editors.  That gets out of control
really quickly!

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Benjamin Heath

Actually, the new subject line had me hoping for a spirited flame war when I saw it. Can we start a real one anyway, just for kicks?

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Thijs Schreijer
Yeah! Fire fire burn !!!!

:)


-------- Oorspronkelijk bericht --------
Van: Benjamin Heath
Datum:16-03-2014 08:11 (GMT+01:00)
Aan: Lua mailing list
Onderwerp: Re: C++ religious war (was: llua Higher-level C API for Lua)

Actually, the new subject line had me hoping for a spirited flame war when I saw it. Can we start a real one anyway, just for kicks?

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

steve donovan
In reply to this post by Benjamin Heath
On Sun, Mar 16, 2014 at 9:11 AM, Benjamin Heath
<[hidden email]> wrote:
> Actually, the new subject line had me hoping for a spirited flame war when I
> saw it. Can we start a real one anyway, just for kicks?

Well, Enrico has done my mind a service with his remark that he is a
C++ user, not enthusiast. Magnificently pragmatic (we are engineers,
after all: whatever works for the job). Since I've become known as a
ex-C++ enthusiast, here's some balance.

The basic criticism of C implicit in C++ is that C is too
weakly-typed, and gives fewer guarantees that a compiled program will
behave correctly.  Having recently sweated over C in a stressful
deadline situation, I know this very well - humans are error-prone,
especially when under pressure.  It allows more elegant and safe
abstractions, for instance you are less likely to shoot your foot
using Selene than using llua when working with the Lua API at a higher
level. The 'abstraction penalty' you pay can be very little, at least
measured in execution speed, since C++ will inline ruthlessly.  The
built-in support for OOP makes large-scale program organization easier
and less verbose.

However, everything has costs - that 'ruthless inlining' can really
give you fat executables, since this is the default behaviour for
templates - and in modern C++, just about everything is a template,
whether sensible (standard containers) or not (strings and iostreams).
 Again, because of templates, compile times become intense and error
messages become the stuff of legend.

Particularly for _infrastructure_ projects, using C++ makes it harder
for a project to communicate with the rest of the universe - e.g. FFI
bindings to C can be very straightforward, whereas the C++ ABI is much
more complex (quite apart from name mangling).  This is very relevant
to the business of doing Lua bindings.

Stroustrup says that there's a lean and elegant language trying to
escape from C++, and this is why I'm interested in the next generation
of statically compiled languages. Nimrod is particularly promising - a
fresh, no-compromises approach to compile-time metaprogramming with a
very straightforward syntax.  But it has no corporate sugar daddy, so
it's likely to remain niche.

In the meantime, I've been trying to make C more expressive (llib
project) but this is all getting rather off-topic for people
interested in a powerful, lean dynamic language called Lua ;)

(Static and strong typing are orthogonal concerns, of course, although
this point is commonly misunderstood.  Lua is the C of dynamic
languages in many ways, compact, few dependencies, and tending to
weaker typing - we pass around tables where Pythonistas would tend to
create a named class, etc.)

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Jeremy Ong
I think you've written a well-thought out summary that brings to light
to issues well.

To me, the following list embodies all the "tensions" that each
programming language tries to resolve in its own way.

1. Type safety vs type flexibility
2. Lean runtime vs batteries included
3. Small syntax vs expressive syntax
4. Opinionated virtual runtime vs native runtime (aka what does the
scheduler do)
5. Speed vs safety

In addition, languages make decisions early about

1. Build system/ecosystem
2. Code organization (module/objects/headers)
3. Static typing (templates) vs runtime typing (reflection)
4. Embedded vs native execution

Having used in order of exposure BASIC, C, PHP, Javascript, C++, Java,
Lisp, Python, Ruby, Haskell, Erlang, Lua, R, C#, Elixir, Rust, and
probably a few more I'm forgetting, I've concluded that there is no
war. Only a series of tradeoffs that should be considered for each
project.

However, it *is* true that languages have varying degrees of technical
debt due to poor decisions made early in the design of the language.
For example, Javascript was meant to be embedded into small webpages
as simple scripts to manipulate the DOM and transfer small chunks of
data back and forth from the server via JSON. As a result, JSON is an
inefficient protocol and build tools and modules aren't natively a
part of the language. PHP was also written in a time when web
applications were smaller and so the OO part of PHP wasn't introduced
until much later, which had tons of its own warts (inconsistent API,
oddities with static members, etc.).

I think the real war that should be waged is the one between people
who think that there is "one true language" and those that are more
polyglot oriented.

On Sun, Mar 16, 2014 at 1:06 AM, steve donovan
<[hidden email]> wrote:

> On Sun, Mar 16, 2014 at 9:11 AM, Benjamin Heath
> <[hidden email]> wrote:
>> Actually, the new subject line had me hoping for a spirited flame war when I
>> saw it. Can we start a real one anyway, just for kicks?
>
> Well, Enrico has done my mind a service with his remark that he is a
> C++ user, not enthusiast. Magnificently pragmatic (we are engineers,
> after all: whatever works for the job). Since I've become known as a
> ex-C++ enthusiast, here's some balance.
>
> The basic criticism of C implicit in C++ is that C is too
> weakly-typed, and gives fewer guarantees that a compiled program will
> behave correctly.  Having recently sweated over C in a stressful
> deadline situation, I know this very well - humans are error-prone,
> especially when under pressure.  It allows more elegant and safe
> abstractions, for instance you are less likely to shoot your foot
> using Selene than using llua when working with the Lua API at a higher
> level. The 'abstraction penalty' you pay can be very little, at least
> measured in execution speed, since C++ will inline ruthlessly.  The
> built-in support for OOP makes large-scale program organization easier
> and less verbose.
>
> However, everything has costs - that 'ruthless inlining' can really
> give you fat executables, since this is the default behaviour for
> templates - and in modern C++, just about everything is a template,
> whether sensible (standard containers) or not (strings and iostreams).
>  Again, because of templates, compile times become intense and error
> messages become the stuff of legend.
>
> Particularly for _infrastructure_ projects, using C++ makes it harder
> for a project to communicate with the rest of the universe - e.g. FFI
> bindings to C can be very straightforward, whereas the C++ ABI is much
> more complex (quite apart from name mangling).  This is very relevant
> to the business of doing Lua bindings.
>
> Stroustrup says that there's a lean and elegant language trying to
> escape from C++, and this is why I'm interested in the next generation
> of statically compiled languages. Nimrod is particularly promising - a
> fresh, no-compromises approach to compile-time metaprogramming with a
> very straightforward syntax.  But it has no corporate sugar daddy, so
> it's likely to remain niche.
>
> In the meantime, I've been trying to make C more expressive (llib
> project) but this is all getting rather off-topic for people
> interested in a powerful, lean dynamic language called Lua ;)
>
> (Static and strong typing are orthogonal concerns, of course, although
> this point is commonly misunderstood.  Lua is the C of dynamic
> languages in many ways, compact, few dependencies, and tending to
> weaker typing - we pass around tables where Pythonistas would tend to
> create a named class, etc.)
>

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

steve donovan
On Sun, Mar 16, 2014 at 10:48 AM, Jeremy Ong <[hidden email]> wrote:
> I think the real war that should be waged is the one between people
> who think that there is "one true language" and those that are more
> polyglot oriented.

That's a very good point.   If you only know one tool, you force it to
fit all tasks.  ("If all you have is a hammer, everything looks like a
nail").  This also gives perspective to the long wait for the "one
true language" since it cannot be both 'one' and 'true' ;)

For polygots to get on, there has to be interoperability.  That counts
against the "opinionated runtimes" (e.g. JVM, CLR) since you can
either join them or leave them.  I like C for many of the reasons I
like Lua:  flexible, pragmatic, small and fast to compile.

(There are cognitive factors in language adoption. I appear to be one
of those who find it difficult to wait for a compiler ;))

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Rena
In reply to this post by steve donovan
On Sun, Mar 16, 2014 at 2:54 AM, steve donovan <[hidden email]> wrote:
On Sun, Mar 16, 2014 at 8:14 AM, Coda Highland <[hidden email]> wrote:
> I mean, if we wanted to start a religious war, try suggesting that Lua
> should be written in C++ instead of C89 and see where THAT goes. ;)

Absolutely!  We have enough of a frothy when suggesting C99 ;)  But
(and this is important) Lua does _build_ with C++ and can use proper
exception handling rather than that weird hack called longjmp.

At least, we're not discussing editors.  That gets out of control
really quickly!


I hate to ask, but now I'm curious... why *doesn't* Lua use C99? Is it because of Microsoft compilers not supporting it well, or are there other reasons?

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Jeremy Ong
In reply to this post by steve donovan
Many runtimes support interoperability though. It's easier if it's
thought of from the inception of the runtime. Examples include BEAM
(erl ports) and Haskell's FFI. C# has interoperability within the .Net
ecosystem. That said, some people don't have any need for interop at
all. This is true if you're running a sandboxed web/game server for
example.

As for compiler speed, I understand :). I fall in the camp of people
who are willing to wait because I believe the compiler is doing useful
work for me (type checking, static assertions, compile time
expressions, generics). This does mean I have to be proactive about
segmenting my code in smaller compilable units (library separation).
I'm more inclined to wait the more robust the type system is up to a
point. As compilers get better/faster, more parallelized, and more
heavily optimized, my hope is that the impatient programmers among us
won't feel like they're sacrificing too much time with a more heavily
compiled language.

Of course, there is the case when I can't tolerate compile times, and
that's when I'm scripting websites, UI, game behavior, or anything I
want immediate visual/audio feedback on. That's where things like Lua
come in.

On Sun, Mar 16, 2014 at 2:04 AM, steve donovan
<[hidden email]> wrote:

> On Sun, Mar 16, 2014 at 10:48 AM, Jeremy Ong <[hidden email]> wrote:
>> I think the real war that should be waged is the one between people
>> who think that there is "one true language" and those that are more
>> polyglot oriented.
>
> That's a very good point.   If you only know one tool, you force it to
> fit all tasks.  ("If all you have is a hammer, everything looks like a
> nail").  This also gives perspective to the long wait for the "one
> true language" since it cannot be both 'one' and 'true' ;)
>
> For polygots to get on, there has to be interoperability.  That counts
> against the "opinionated runtimes" (e.g. JVM, CLR) since you can
> either join them or leave them.  I like C for many of the reasons I
> like Lua:  flexible, pragmatic, small and fast to compile.
>
> (There are cognitive factors in language adoption. I appear to be one
> of those who find it difficult to wait for a compiler ;))
>

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Jeremy Ong
In reply to this post by Rena
It's clearly so people can make youtube videos of Lua compiling in a
1990 version of Turbo C :D

On Sun, Mar 16, 2014 at 2:15 AM, Rena <[hidden email]> wrote:

> On Sun, Mar 16, 2014 at 2:54 AM, steve donovan <[hidden email]>
> wrote:
>>
>> On Sun, Mar 16, 2014 at 8:14 AM, Coda Highland <[hidden email]>
>> wrote:
>> > I mean, if we wanted to start a religious war, try suggesting that Lua
>> > should be written in C++ instead of C89 and see where THAT goes. ;)
>>
>> Absolutely!  We have enough of a frothy when suggesting C99 ;)  But
>> (and this is important) Lua does _build_ with C++ and can use proper
>> exception handling rather than that weird hack called longjmp.
>>
>> At least, we're not discussing editors.  That gets out of control
>> really quickly!
>>
>
> I hate to ask, but now I'm curious... why *doesn't* Lua use C99? Is it
> because of Microsoft compilers not supporting it well, or are there other
> reasons?
>
> --
> Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Enrico Colombini
In reply to this post by Jeremy Ong
On 16/03/2014 10.22, Jeremy Ong wrote:
> As for compiler speed, I understand :). I fall in the camp of people
> who are willing to wait because I believe the compiler is doing useful
> work for me (type checking, static assertions, compile time
> expressions, generics).

I tend to be in the opposite camp: for my way of working (relatively
short bursts of very high concentration, lots of microtesting and
measurements) feedback speed has a very high priority.
That's one of the many reasons I love Lua :-)

(just to demonstrate how coherent people can be: I am currently using
Atmel Studio 6, which is about as fast as a turtle before morning coffee)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

David Crayford
In reply to this post by steve donovan

On 16/03/2014 4:06 PM, steve donovan wrote:
> However, everything has costs - that 'ruthless inlining' can really
> give you fat executables, since this is the default behaviour for
> templates - and in modern C++, just about everything is a template,
> whether sensible (standard containers) or not (strings and iostreams).
>   Again, because of templates, compile times become intense and error
> messages become the stuff of legend.

Even C can give you fat executables. What with loop unrolling and the
strange instruction scheduling that
the optimizer generates for modern processors. The compiler I use goes
out of it's way to avoid branches. Sometimes
a small loop can be unrolled into a hundred instructions using
load-on-condition/store-on-condition instructions. A memcpy()
when the length is constant can generate 20-30 move instructions. It's a
space for time trade-off.

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

steve donovan
In reply to this post by Jeremy Ong
On Sun, Mar 16, 2014 at 11:22 AM, Jeremy Ong <[hidden email]> wrote:
> As for compiler speed, I understand :). I fall in the camp of people
> who are willing to wait because I believe the compiler is doing useful
> work for me (type checking, static assertions, compile time
> expressions, generics).

The enemy of C++ is its heritage as a C-compatible language, which
includes a build system that was new when men wore bellbottoms and
women had flowers in their hair.  That is, most of that wait is not
essential for the extra checking and due to the preprocessor pumping
in massive includes. In this sense, C is bad for C++.  (Compare this
to the wonderful smart linker that Delphi had and weep.)

It doesn't have to be like this. When I was working on UnderC I
realized two things (a) it is not essential to build an executable for
testing and (b) if you can maintain live compiler context then headers
only need to be parsed once. This happens naturally if you have an
interpreter, plus an incremental compiler like Lisp systems.  (They
are still smug about that and for good reason).  However, I moved on
to other problems.

As for performance, Mike Pall has given us an existence proof that
dynamic languages don't have to suffer in performance compared to
compiled languages.  The trouble with dynamic languages is when doing
'programming in the large'.  With C, I can jump around a large
codebase like a mountain goat;  Eclipse makes Java almost pleasant.
Without explicit type annotations it's hard to do that with dynamic
languages.  (You just need enough to resolve the ambiguities so type
inference can fill the gaps - see the Typed Lua project).

The people who manage big codebases in Lua have to do a lot of
thinking up front and use extra tooling, like static type checkers.
It would be cool if they could share some of their stories, but what
they share in common is that they are not casual scripters!

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Coda Highland
On Sun, Mar 16, 2014 at 8:55 AM, steve donovan
<[hidden email]> wrote:

> On Sun, Mar 16, 2014 at 11:22 AM, Jeremy Ong <[hidden email]> wrote:
>> As for compiler speed, I understand :). I fall in the camp of people
>> who are willing to wait because I believe the compiler is doing useful
>> work for me (type checking, static assertions, compile time
>> expressions, generics).
>
> The enemy of C++ is its heritage as a C-compatible language, which
> includes a build system that was new when men wore bellbottoms and
> women had flowers in their hair.  That is, most of that wait is not
> essential for the extra checking and due to the preprocessor pumping
> in massive includes. In this sense, C is bad for C++.  (Compare this
> to the wonderful smart linker that Delphi had and weep.)

C++14 has modules that solve a lot of this, including making module
headers insulated from preprocessor shenanigans.

I'm a C++ enthusiast, myself, in addition to a C++ user, to the point
where I'm currently working on the C++ grandmaster certification
course, in which the final project is to build a C++ compiler capable
of building its own sources. I picked the language up in 1997, before
it was even standardized, and seeing C++11 come out and C++14 in the
pipelines... C++ is really evolving into a very nice modern language
now.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

steve donovan
On Sun, Mar 16, 2014 at 6:12 PM, Coda Highland <[hidden email]> wrote:
> C++14 has modules that solve a lot of this, including making module
> headers insulated from preprocessor shenanigans.

It appears that it won't make C++14 (which is a minor update/bugfix
release). The clang people are working on an experimental
implementation, but we may have to wait a few years for this all to be
reality.

> course, in which the final project is to build a C++ compiler capable
> of building its own sources.

A much more interesting target is doing an interactive interpreter.
It is deeply cool evaluating "cout << "hello" << endl" from a REPL.  I
would point to my UnderC project but it's a dead end architecture - I
did not have the necessary theoretical background to do it properly.
Mind you, if I had, I would never have dared to try.

BTW,  I shall get out the old ucc and see how it handles the Lua
includes.  Then people can practice their Lua stack calls
interactively.

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Coda Highland
On Sun, Mar 16, 2014 at 9:20 AM, steve donovan
<[hidden email]> wrote:
> On Sun, Mar 16, 2014 at 6:12 PM, Coda Highland <[hidden email]> wrote:
>> C++14 has modules that solve a lot of this, including making module
>> headers insulated from preprocessor shenanigans.
>
> It appears that it won't make C++14 (which is a minor update/bugfix
> release). The clang people are working on an experimental
> implementation, but we may have to wait a few years for this all to be
> reality.

Aw, pooh. That's too bad. I suppose it did seem a bit ambitious for
such a short timeframe.

>> course, in which the final project is to build a C++ compiler capable
>> of building its own sources.
>
> A much more interesting target is doing an interactive interpreter.
> It is deeply cool evaluating "cout << "hello" << endl" from a REPL.  I
> would point to my UnderC project but it's a dead end architecture - I
> did not have the necessary theoretical background to do it properly.
> Mind you, if I had, I would never have dared to try.

I was planning on doing something like that anyway! I don't see any
specific reason why it shouldn't be straightforward to do that. Sadly
I won't be able to actually deploy my code to anyone due to the
class's honor code, which is a shame -- I'm quite proud of some of the
pieces.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Dirk Laurie-2
In reply to this post by steve donovan
2014-03-16 17:55 GMT+02:00 steve donovan <[hidden email]>:

> the wonderful smart linker that Delphi had

Had?

<http://www.lazarus.freepascal.org>

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Sean Conner
In reply to this post by Jeremy Ong
It was thus said that the Great Jeremy Ong once stated:
>
> I think the real war that should be waged is the one between people
> who think that there is "one true language" and those that are more
> polyglot oriented.

  Another axis to view this on is "tools vs. langauge" [1].  I don't use an
IDE [2] and thus, I'm free to pick any langauge I want, and not have the
language forced on me because of the environment [5].

  That said, I am a language snob, and given my preference, will NOT use C++
(because it's damn near impossible to know the entire langauge), PHP
(because they know not what the hell they're doing [6]), Perl (because there
is more than one way to everything, so you better know them all or you can't
read Perl) or Python (significant white space---possibly forgivable in
Fortran 66, a sin in anything designed past 1970).

  Is C perfect?  No [7].  But it's simple enough to understand.  So is Lua.  

  -spc (So is assembly, but that's so simple, it borders on tedium)

[1] http://blog.osteele.com/posts/2004/11/ides

[2] I can't stand them.  I never have.  Initially because the built in
        editors sucked [3] but now, it's because they tend to lock you into
        a single language.  Sure, they *may* say they can do cross-language
        development, but last I checked [4], Eclipse consistently crashed
        when I tried loading up two simple C files (a .c and its
        corresponding .h file).  

[3] To give an indication about how long ago this was, I'm talking about
        Turbo Pascal 3, and shortly thereafter, Turbo Pascal 4, which
        changed the editor environtment completely.

[4] Last year.

[5] I downloaded Eclipse.  It could deal with Java only.  If I wanted to
        edit C/C++ files, I had to download an entirely different copy.
        Perhaps there was a way to edit Java, C and C++ with the same
        engine?  I don't know.  I decided to stop wasting my time with
        Eclipse and keep using the same editor I've been using for twenty
        years.

[6] "I was really, really bad at writing parsers. I still am really bad
        at writing parsers. We have things like protected properties. We
        have abstract methods. We have all this stuff that your computer
        science teacher told you you should be using. I don't care about
        this crap at all."
                -- Rasmus Lerdorf, creator of PHP

        "I'm not a real programmer. I throw together things until it works
        then I move on. The real programmers will say "yeah it works but
        you're leaking memory everywhere. Perhaps we should fix that." I'll
        just restart apache every 10 requests."
                -- also Rasmus Lerdorf

[7] One obvious flaw is the pointer syntax.  But another, lesser known
        (or quite possibly it's just me) flaw are function prototypes for
        static functions.  Why do I need them?  This isn't 1970 anymore.  We
        don't have to strive for a one-or-two-pass compiler anymore.  Just
        scan ahead looking for static functions, then do a second pass for
        the compilation step.  How hard is this?  Sheesh.

Reply | Threaded
Open this post in threaded view
|

Re: C++ religious war (was: llua Higher-level C API for Lua)

Sean Conner
In reply to this post by Enrico Colombini
It was thus said that the Great Enrico Colombini once stated:

> On 16/03/2014 10.22, Jeremy Ong wrote:
> >As for compiler speed, I understand :). I fall in the camp of people
> >who are willing to wait because I believe the compiler is doing useful
> >work for me (type checking, static assertions, compile time
> >expressions, generics).
>
> I tend to be in the opposite camp: for my way of working (relatively
> short bursts of very high concentration, lots of microtesting and
> measurements) feedback speed has a very high priority.
> That's one of the many reasons I love Lua :-)

  In my experience, you can have either a fast compiler, or a fast
executable (output from a compiler).  

  There are fast C compilers.  One of the fastest is TCC.  At one point
(back in 2006 I believe), someone used TCC to boot Linux (that is, compile
the Linux kernel at boot time) in under 10 seconds.  It didn't produce a
fast kernel though.

  -spc


1234 ... 6