

Factor VM ported to C++ - visitor4rmindia
http://factor-language.blogspot.com/2009/05/factor-vm-ported-to-c.html

======
gcv
About 18 months ago, I ported a project I was working on from C to C++. I,
too, wanted a few C++ features to simplify life, mainly to use the STL, but
also for inheritance in a handful of places. I got what I wanted, but I have
since concluded that switch to C++ was, on the whole, a mistake.

First, don't discount the longer compilation times. After learning Lisp, I
became rather addicted to the rapid turn-around time of compiling code at the
level of individual functions. I can tolerate C because, with a relatively
clean build setup, it compiles quickly. g++ on my project is between 10 and 20
times slower than gcc. This means that, as I make minor changes, I'm more
likely to have to wait a while for a build to finish. This means I'm more
likely to slack off in between builds. This kills (my) productivity horribly.

Second, auxiliary tool support on Unix leaves a lot to be desired. I sprinkle
my code with templates in places where they promote readability, and I use STL
containers. gdb, at least the version I'm using, does not support displaying
data in STL containers. This means that when I have to track down a problem
with data in a map, gdb can't help me. I have run into nasty problems for
which I had to write custom print-this-templated-structure-to-log code. In
addition, g++ error messages which involve templates absolutely suck. Luckily,
I can quickly figure out what I need to change just by looking at the affected
line.

After thinking through these issues, I concluded that C++ wasted more of my
time than it saved. YMMV, of course.

~~~
vicaya
If minor changes trigger long compilation, there is something wrong with your
code organization. I found that if you count linking time the total build time
difference between c and c++ for significant project is not that big at least
not at 10-20x.

There are plenty of gdb macros that support stl containers even 18 months ago.

LLVM is also written in C++ for good reasons.

~~~
wheels
_If minor changes trigger long compilation, there is something wrong with your
code organization_

A lot of larger C++ projects use "pimpl" for this reason
(<http://en.wikipedia.org/wiki/Opaque_pointer>). Also in professional projects
with large code bases that I've worked on in the past we've always had a
distributed compilation environment (distcc, icecream, etc.)

~~~
vicaya
In a lot of cases, just use forward declarations to avoid unnecessary includes
in the header files goes a long way.

------
SwellJoe
So Factor is not at all what I thought it was. I thought it was roughly a
modern Forth for the JVM...and I thought the point of it was at least
partially the JVM. Not dependence, but the ability to _use_ Java libraries.
The realization that this is not at all the case makes Factor seem more
interesting but less useful, to me.

~~~
vizard
Factor has not been related to JVM in any way for many years now. The core of
the VM has been in C since 2004 and now it has been ported to C++.

~~~
SwellJoe
Yes, which is why I said it is not at all what I thought it was. I was wrong
before, and now I know. How wrong my existing knowledge of Factor was
surprised me enough that I commented on it.

