2.00 Okay, so, here's how things are...

[namida]

Basically - I haven't written any code for this in quite a while. I've worked a bit on the enhanced versions of graphic sets, but that's it.

Since I didn't get too far in the first place, and I do see a lot of criticism of Delphi (not to mention using it is a major factor preventing cross-platform; although Lazarus exists it doesn't seem to work so well for cross-platform use in graphical apps in practice)... I'm wondering how logical it might be to try and learn something new, and start again using that, also somewhat using this as a project to learn the new language.

If I was going to learn something new, key factors would be:
- Needs to be capable of cross-platform use, otherwise that kills the whole point of moving away from Delphi.
- It'd have to be something that's useful and widespread in general. No obscure languages that might be cross-platform suitable, but don't have much real-world usage.
- Nothing too complicated. I am not going to try and make NL2 in Brainfuck.
- Needs to be compilable. So, sorry Java and Python.

Any recommendations from the programmer-types among the userbase? For the record, I currently have decent amounts of experience with BASIC and Delphi, some very basic knowledge of PHP, and am currently learning Python through university (needed one paper that could be literally anything the uni offers to complete my degree, so I thought "why not, this seems like something I could handle quite well"). I figure the obvious candidates would be C or C++ (dabbled with them in the past but never really got the hang of them, but I was a lot less capable at that time), but I'm open to other ideas.

If there really isn't anything suitable, I may consider just slowly modifying NL1 towards the intended feature set for NL2, rather than going for a full-blown rewrite.

EDIT: I also should mention - the less files there are in the final program that aren't actual data files (DLLs, etc), the better. For reference, current NeoLemmix only uses a single DLL (Bass.DLL), and even that gets built into the EXE (and extracted and run from memory at runtime).

[NaOH]

I would always recommend C++ and SDL2. C++ has gotten a lot friendlier in recent years with the advance of C++11.

Downsides: installing libraries can be scary at first. And it's much easier to develop for C++ on Linux (I think you prefer windows?).

Upsides: well-supported language. Very fast. You get the most control over the computer. (If you've ever felt frustrated at not being able to do something that ought to be possible in theory, this almost never happens to me in C++)

I'm sure Simon will come along in a bit and recommend D...

[namida]

Downsides: installing libraries can be scary at first. And it's much easier to develop for C++ on Linux (I think you prefer windows?).

My main PC is windows, but I do also have two Linux PCs (one x86-64 based (a somewhat-old netbook), one ARM-based (Odroid-XU4)). Supporting Windows is non-negotiable, supporting Linux too would be highly preferable.

[NaOH]

As with most things about C++, cross-compiling is a pain to set up. But once it's up and working it isn't much hassle.

I find it's not very common for code to break down between different operating systems so long as you keep portability in the back of your mind when writing the code. Normally the problems related to file i/o stuff or making use of os-specific utilities. This is all easily avoidable if you use Boost libraries.

[namida]

Cross-compiling isn't a huge matter, especially with Linux users generally preferring to compile from source than have a pre-built binary anyway. Likewise, if cross-compiling is difficult, I'd probably just compile on Linux to test on Linux (which I'd probably need to do anyway to compile for ARM and test there - an attempt (although probably one that might go better if someone more familiar with the process than I currently am was doing it) to compile and run Lix on an ARM-based Linux device mostly worked but had problems with sound and the Cuber skill).

[Simon]

The full rewrite. >_>

• It will take several years, even though you can look at existing code.
• You have to support the old ecosystem, because it has users, while developing the new.
• You will reintroduce a lot of bugs that have already been solved and forgotten about.
• Joel on Software about rewriting, classic article from 2000 warning against it, or Why You Should (Almost) Never Rewrite Your Software

Sorted recommendation of language: (don't rewrite), C++, D, Rust, Go, Python, C, Java, others.

I'll make another post later with problems of C++ and D. This article comparing D, Rust, Go from 2 months ago was acknowledged as an overview.

-- Simon

[namida]

Yes, I think that all things considered, the best idea is to ditch the full rewrite idea, and instead slowly improve the existing version. Indeed, many of the things in V1.37n are first steps towards that.

Given this, I'm now going to be closing this subforum. However, I won't delete it, as the posts may be useful to reference.