Language rewrite - any success stories?

On Tue, 29 Jan 2008 10:30:06 -0800 (PST), Slash <java.koder DeleteThis @gmail.com> tried to
confuse everyone with this message:

>On Jan 29, 12:48 pm, g... DeleteThis @mail.ru (Timofei Shatrov) wrote:
>> On Tue, 29 Jan 2008 09:48:17 +0100, Jakub Debski <debski.ja... DeleteThis @wp.pl> tried to
>> confuse everyone with this message:
>>
>> >awhite pretended :
>SNIP
>>
>> and recompile just this line which takes a millisecond. Or execute
>>
>> (setf number-of-monsters-per-level 100)
>>
>> The game could be already running during all of that, so you just go to
>> a newly generated level and test the balance.
>
>Or you could have an external properties file with the number-of-
>monster-per-level

Well, what about tweaking monsters' AI, or something like that? Also, you'll
need to somehow force the game to reload this properties file, though this is a
minor inconvenience. And also such file is a great enabler for cheating, and I'm
notoriously determined not to make cheaters' life easier

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
 >> Stay informed about: Language rewrite - any success stories? 

On Tue, 29 Jan 2008 10:34:21 -0800 (PST), Slash <java.koder.TakeThisOut@gmail.com> tried to
confuse everyone with this message:

>On Jan 29, 12:06 am, awhite <spud....TakeThisOut@iinet.net.au> wrote:
>> A ramble.
>>
>> In finding a new reason not to work hard at my game, I've lately become
>> enamoured of Common Lisp.
>
>Dont let love guide this sort of hard choices. Everything that starts
>has an end... in time your love for Lisp will die, and you may regret
>your choice..
>

Oh, come on, Common Lisp was around for more than 20 years, and no Lispers have
been known to switch to other languages. It's like a programmers' nirvana

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
 >> Stay informed about: Language rewrite - any success stories? 

Jakub Debski wrote:

> You don't really want to finish your game, just to play with
> programming and learn something new? Why are you asking about success
> rate then?

Not quite what I meant. I'm trying to be clear on the point that I'm
consciously trying not to be Shockfrost/Amy Wang/Krice/every other person
with high hopes and an ephemeral feature list.

> It will be the success for sure, because you will play with new code
> and learn new language.

I care about success because I want to make a game that *I* want to play.
Consciously I know that rewrites == Bad Thing (Joel convinced me of that,
among other things), but as an amateur programmer, it's hard to avoid the
temptation to drop everything to play with new (to me) technologies.

> I don't want to be rude, but this is how I see your posts.

That's ok. We're all kibologists, so "You're Allowed".

I was probably just having an out-loud thought and (then) post.

A
 >> Stay informed about: Language rewrite - any success stories? 

On Tue, 29 Jan 2008 14:33:00 +0000, Gerry Quinn wrote:
> There's a difference between 'working code' and 'releasable code'? Does
> your game so far actually work, i.e. perform as expected and not crash
> all the time?

Well, yes. Polish. But that's not the main issue.

>
> If not, your problem lies elsewhere than in compile times.

This is. I should probably try some different tools for a while, and see
if that makes a difference. VC8 seems to be highly regarded, though
setting up the process (multiple dialog boxes) seems a little convoluted.

A
 >> Stay informed about: Language rewrite - any success stories? 

At Tue, 29 Jan 2008 16:12:15 -0600,
Paul Donnelly wrote:

> I don't know why this group is so skeptical about the value of
> interactive development. It's a big time saver. While a couple of
> seconds (minutes?!) of time wasted on compilation now and then may not
> add up to a lot of hours wasted, it's awfully tedious, and means you
> can't test your new code as easily as you otherwise could.

It's all cool. Quake-like console is nice too.
But nothing beats automated unit testing -- you not
only get to test particular elements, but you also
make sure the bugs stay fixed. Of course, nothing
stops you from doing unit testing in Lisp


--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
If something happens, it must be possible.
-- Scott Cox's First Law Of Physics
 >> Stay informed about: Language rewrite - any success stories? 

Jeff Lait <torespondisfutile DeleteThis @hotmail.com> writes:

> On Jan 29, 8:17 pm, Paul Donnelly <paul-donne... DeleteThis @sbcglobal.net> wrote:
>> Jeff Lait <torespondisfut... DeleteThis @hotmail.com> writes:
>> > Interactive development isn't something unique to interpreted
>> > languages.
>>
>> That's good to hear, although you seem a little hazy on what constitutes
>> an interpreted language.
>
> I am very hazy for a very good reason. "interpreted" is really a
> function of the implementation of the language, not the language
> itself. BASIC can be compiled and C++ could be interpreted. I think,
> however, there is an understanding of their being a sort of divide
> between "compile and test" and "change source code on the fly", with
> the latter generally made possible through an interpreter.

Typically I would use the terms "batch-compiled" vs. "interactive". But,
as you say, a language that is usually thought of as purely
batch-compiled can be implemented interactively as well (to some degree,
at least). The crux being that it's a matter of implementation, as you
say. But still, "interpreted" is not the word I would choose to make
this distinction, because it implies that the language ultimately under
discussion is in fact usually interpreted (with all the baggage that
entails (SLOW SLOW SLOW)). That's certainly not the case in this
particular thread, nor do I get the sense that it is true in the general
case these days. I worry sometimes that good technologies (interactive
languages, garbage collection, humbucking pickups) are harmed in the
public eye by associations (slow, slow and for wimps, muddy) that are at
best anachronistic.

>> And I merely observed more than the expected level of naysaying about
>> interactive development.
>
> Naysaying because the implication was a shift in language, not because
> the thing itself was not good. I would be curious what you think
> about my claim that interactive development is bad because, like GOTO,
> it begets bad habits.

Indeed, perhaps they were just trying to help him avoid learning
anything new^W^Wrewriting lots of code.

I think that avoiding interactive development in favor of writing
perfect code with no help at all the first time is a lot like avoiding
crutches with a broken ankle. It's not going to teach you a lesson so
much as punish you for something you can't change. Maybe you could think
all the way through the problem, come up with an answer, type it in,
check it for errors a few times, and be completely correct. Maybe you
could also hop everywhere on your good foot. Attempting the superhuman
won't necessarily make you become Superman.

I think that the computer can be a helpful scratchpad for the thinking
step, especially since half of writing the algorithm is figuring out how
best to represent it in the language. Often I write my functions in a
kind of exploded fashion with lots of temporary variables, then turn
them inside out (substituting calculations for variables verbatim) step
by step when I know I've written the correct code. I can test easily
between each iteration to make sure I'm doing what I meant to.

I also don't think that "shotgun" programming in which you try
everything until you find what works (or seems to) is a problem. You
don't have to try it many times before you realize that the only thing
that ever fixes your bugs is to stop and think. I find that bugs are
only ever resolved when I go over the whole thing again and understand
my mistake (either logical or a typo), or when I rewrite the whole thing
"exactly the same" and whatever it was just disappears. Of course, trial
and error may be more seductive for some people (and I don't mean to
imply that it is for *you* -- I'm recalling statements made by newbie
programmers. Probably it's something they grow out of quickly though).
 >> Stay informed about: Language rewrite - any success stories? 

On 2008-01-29, Timofei Shatrov <grue.RemoveThis@mail.ru> wrote:
> Oh, come on, Common Lisp was around for more than 20 years, and no Lispers have
> been known to switch to other languages. It's like a programmers' nirvana

The people at Reddit.com started out having their site implemented in
Lisp but got frustrated with something and switched to Python.
http://www.aaronsw.com/weblog/rewritingreddit

--
Risto Saarelma
 >> Stay informed about: Language rewrite - any success stories? 

On Jan 29, 2:23 am, awhite <spud....RemoveThis@iinet.net.au> wrote:
>
> stupid example below. I'm very much a lisp newbie, so it's probably very
> flawed.
>
> Using the REPL (Read Evaluate Print Loop) just seems faster, as
> essentially there's no real difference between writing a program, and
> using the debugger. You can write a function and debug it straight away.
> No need to stop, compile, fire up the debugger, edit, recompile, fire up
> the debugger, ad nauseum. That's the bit about c++ that's currently
> depressing me.

Not to downplay the advantages of a more "lightweight" language, but
have you considered augmenting your C++ environment? Some things that
I find make a big difference with C++ development:
- precompiled headers: in an experiment with 5,000 SLOC for a
raytracer (using gcc), this cut build times in half. If you're using
Visual Studio, add in incremental linking and it's even faster.
- proper dependency analysis. Visual Studio again handles this
directly. If you're using GNU tools, you /definitely/ need a Makefile
and either `makedepend` or `gcc -MM` to autogenerate dependencies from
#includes. It really reduces the number of 'clean builds' you'll have
to do, so any incremental compile-link phases take less than 1 second.
- what text editor / IDE do you use for programming? In both vim and
emacs, you can run make directly from within the editor, and they make
it simple to step through build errors if any occurred. If you're
using a real IDE, this is a moot point, I suppose.
- KISS. Do you really need accessors for everything? Adding the
boilerplate get() and set() functions isn't very exciting, and it's
more or less useless on small projects. I know it's OO heresy to
advocate public members, but remember that the tool (C++) is there to
serve you, not the other way around.
- Know your data structures. If you're talking about using a hash
map to store properties, why not do that in C++? You have std::map,
stdext::hash_map in Visual Studio, or __gnu__cxx::hash_map in GCC.
- Pull constants out into a separate file. Suppose you have
config.h that declares a bunch of extern variables and whatnot, and
config.cxx that defines all of them. If you want to change a compile-
time parameter, the only work required is recompilation of config.cxx
and relinkage of your final application. That's much faster than
putting constants in header files (which may require a cascade of
compilations). Or, you could go one step further and turn everything
into runtime constants with an .ini-style parser, to avoid the
compilation overhead. Or you could go crazy and embed Lua into your
application. It's certainly more up-front work to learn Lua
embedding, but it honestly shouldn't be more than a weekend to get
yourself started with Lua, and it'll save you tweak-time in the long
run without wholly committing you to a different language.

> It's *a* solution. But I'm starting to think that C++ itself requires a
> lot of boilerplate for its flexibility, and separate compilation model.

Yes. There are a few ways to reduce that:
- use templates to reduce the number of times you have to write
something.
- avoid memory management in your application layer; if you need
dynamic memory, hide it in a data structure. That way, your
application layer ends up (almost) as clean as a higher-level
language.

> The "defstruct mini" macro creates member accessors, a constructor, truth
> test, and lots more. It's concise.
>
> How much boilerplate would that take to implement in C++ ?
> The accessors, constructor, "rule of 3", plus memory management
> (via boost::smart_ptr<> is my preferred option) would swell that out
> immensely!

The "rule of 3" (which I assume means assignment/copy constructor/
destrucs easy to avoid if you use better member data structures,
allowing the compiler-generated defaults to be sufficienttor) i. Take
full advantage of the STL and boost. Heck, if you're not planning on
copying your data structures, there's no reason to even implement
assignment/copy-ctor in the first place.

> I think C# is a step in the right direction for the language - properties
> and delegates are tres cool.

Python implements properties nicely as well. IMHO, I'd skip out on
the C#. If you want the nice high-level features, go all the way to
Python or Lisp. The one thing that Java, C#, and C++ can't give is
concise functional programming.

All in all, I think it's up to what you are most interested in
exploring. If you want to play with inter-language bindings, do
that. If you want to learn a new language, do that. If you want to
learn your text editor and the arcane tricks of optimizing the GNU
toolchain, do that. If you just want to finish your roguelike... do
that, and just take a coffee break or go pee whenever it's time to
compile. At the very least, I'd look into making the improvements to
your compile time that I and others have mentioned, and see if your
perception of "compile-link time" changes.

--
Tom
 >> Stay informed about: Language rewrite - any success stories? 

On Jan 30, 8:51 pm, awhite <spud....DeleteThis@iinet.net.au> wrote:
> On Mon, 28 Jan 2008 22:22:06 -0800, Krice wrote:
> > Get Windows and Visual C++. It's incredibly fast. VC can rebuild Kaduria
> > in less than minute!
>
> Actually, Paul, I have to admit that you're right. I rebooted into
> Windows and downloaded VC++2008 last night... it compiles at minimum 3
> times as fast as g++ for my project. I make fairly heavy use of
> templates, though, maybe that's an issue for g++.

This may be partially due to the optimizer - as a benchmark, I
recompiled a major code project I work on (54524 lines total, uses
templates a lot, uses multiple threads, wxWidgets), with no
optimization and debugging options, followed by "-g -O2", and the
speed differences are absolutely staggering. The first compile
(without) took 6 minutes on the dot. The second took 10 minutes 2
seconds. I can't test -O3 due to some ridiculous template
deficiencies. I haven't used VC08, but if I recall, the default is for
VC to compile without optimizations. There are probably a number of
other options which can be cut, and disabling a number of compiler-
specific extensions which take up time (even when not used).

> Getting used to the Windows keyboard shortcuts will take some time (on
> Linux I use SlickEdit set to Emacs keybindings), but it (VC++) looks like
> a pretty solid build environment.
>
> The debugger integration looks to be good, too. I can't say I like gdb
> too much (haven't yet tried Zero, the alternative debugger).
>
> But the cmd.exe console is pretty annoying. Does anyone have a suggestion
> for an alternative? Something like gnome-console or konsole (or even rxvt
> or Eterm) would be great.

Cygwin? It comes with all sorts of Unix utilities, too.

coppro
 >> Stay informed about: Language rewrite - any success stories? 

On 31 Jan, 06:35, awhite <spud....DeleteThis@iinet.net.au> wrote:
> On Wed, 30 Jan 2008 21:19:33 -0800, coppro wrote:
>
> > Cygwin? It comes with all sorts of Unix utilities, too.
>
> No, the lack of a decent console (with scrollback, tab-key completion -
> which is a shell issue, I know - and multi-tabs) is what I'm getting at.

Install Cygwin and the X packages; it'll let you run X applications
(such as xterm) in regular Windows-style windows. In addition to that,
you can use whatever shell you prefer, and quickly access GCC to
ensure portability.

-the ru
 >> Stay informed about: Language rewrite - any success stories? 

On 31 tammi, 05:51, awhite <spud....RemoveThis@iinet.net.au> wrote:
> Actually, Paul, I have to admit that you're right.

I'm always right.

> The debugger integration looks to be good, too.

It's much better than gdb anyway, but then gdb was not
working with DevC++ at all. SDL made it go bananas and
it could not find fatal bugs (or anything). It was actually
the biggest reason why I finally had to abandon DevC++.
I just wish I would have done it sooner!
 >> Stay informed about: Language rewrite - any success stories? 

On Mon, 28 Jan 2008 22:22:06 -0800, Krice wrote:

> Get Windows and Visual C++. It's incredibly fast. VC can rebuild Kaduria
> in less than minute!

Actually, Paul, I have to admit that you're right. I rebooted into
Windows and downloaded VC++2008 last night... it compiles at minimum 3
times as fast as g++ for my project. I make fairly heavy use of
templates, though, maybe that's an issue for g++.

Getting used to the Windows keyboard shortcuts will take some time (on
Linux I use SlickEdit set to Emacs keybindings), but it (VC++) looks like
a pretty solid build environment.

The debugger integration looks to be good, too. I can't say I like gdb
too much (haven't yet tried Zero, the alternative debugger).

But the cmd.exe console is pretty annoying. Does anyone have a suggestion
for an alternative? Something like gnome-console or konsole (or even rxvt
or Eterm) would be great.

Adam
 >> Stay informed about: Language rewrite - any success stories? 

On Wed, 30 Jan 2008 21:19:33 -0800, coppro wrote:

[VC++ vs g++ compile times]

>
> This may be partially due to the optimizer - as a benchmark, I
> recompiled a major code project I work on (54524 lines total, uses
> templates a lot, uses multiple threads, wxWidgets), with no optimization
> and debugging options, followed by "-g -O2", and the speed differences
> are absolutely staggering.

Naw, I compile (for debugging purposes) without optimisation (-O0 in gcc
parlance).

> The first compile (without) took 6 minutes on
> the dot. The second took 10 minutes 2 seconds. I can't test -O3 due to
> some ridiculous template deficiencies. I haven't used VC08, but if I
> recall, the default is for VC to compile without optimizations. There
> are probably a number of other options which can be cut, and disabling a
> number of compiler- specific extensions which take up time (even when
> not used).

I can't say I've noticed much difference between -O2 and -O0 for g++.

> Cygwin? It comes with all sorts of Unix utilities, too.

No, the lack of a decent console (with scrollback, tab-key completion -
which is a shell issue, I know - and multi-tabs) is what I'm getting at.

Adam
 >> Stay informed about: Language rewrite - any success stories?