SRL Archive - Discussions & Debates

Just wondering why SRL/Simba chose free pascal as its language.

What are its strengths compared to something like Java or C++?

So it was compatible with scar (I think)

From: Hawker
So it was compatible with scar (I think)

One could then ask the question: why did SCAR use pascal? I don't know, maybe someone else does

From: KeepBotting
One could then ask the question: why did SCAR use pascal? I don't know, maybe someone else does

Guess we'd need to ask kaitnieks or someone around when scar was first made

Simple language, Kaitnieks himself was probably used to Delphi, so Pascal was a logical step since there was an interpreter for it (PascalScript). Benefits? Well, it's not as bad as C++ and Java, and it's nice as a scripting language here. These days I would probably prefer Python, but hey. :)

From: Wizzup?
Simple language, Kaitnieks himself was probably used to Delphi, so Pascal was a logical step since there was an interpreter for it (PascalScript). Benefits? Well, it's not as bad as C++ and Java, and it's nice as a scripting language here. These days I would probably prefer Python, but hey. :)

How hard would it be to put a python interpreter inside of simba

that's the "easy part" or am I wrong?

SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

Fact is, I don't care what anyone says, Java, C++, .NET languages…just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.

From: the bank
SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

Fact is, I don't care what anyone says, Java, C++, .NET languages…just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.

Yup ^ There's a reason why pascal is no longer used for much of anything nowadays..

Thanks for all of the responses. Really interesting!
Definitely agree with the bank, is a very ugly language.

From: the bank
Fact is, I don't care what anyone says, Java, C++, .NET languages…just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.

I find object pascal very nice looking.

Also, considerably faster than Delphi? You clearly don't know much about Delphi then. Delphi is fast (it compiles to quite optimized native machine code), none of the mentioned languages are notably faster. They might in some cases be a few times faster than FPC (but that's usually not noted), but FPC is not Delphi.

I can assume you mean to say those languages (errm compilers) are much faster then Lape (not Delphi), then you wouldn't be wrong. But for what we do speed isn't really that much of a concern, when a speedup is needed you simply extend it with a "plugin" (dll), this plugin can be written in any language capable of compiling a lib.

From: slacky
I find object pascal very nice looking.

Also, faster than Delphi? You clearly don't know much about Delphi then. Delphi is fast (it compiles to quite optimized native machine code), none of the mentioned languages are notably faster. They might in some cases be a few times faster than FPC, but FPC is not Delphi (and that's usually not noted).

I can assume you mean to say those languages (errm compilers) are much faster then Lape (not Delphi), then you wouldn't be wrong. But for what we do speed isn't really that much of a concern, when a speedup is needed you simply extend it with a "plugin" (dll), this plugin can be written in any language capable of compiling a lib.

I mean no disrespect, however Pascal/Delphi are ridiculously wordy languages. Not only does this, ironically, decrease readability due to the clusterfuck that is an application, but also limits efficiency of the developer by making code longer and take more time to write.

As far as Delphi compiling into machine code that is optimized anywhere near the degree of say C or C++ is ridiculous fallacy. Take these benchmarks for example. Of course these sorts of things are specific to compilers themselves, but I would put VisualStudio 2014 or even GCC faster than any Delphi compiler I've ever used.

I've used Delphi extensively, including creating the OpenSCAR project a year or so before Simba was even released. And yes, I'm well aware of Simba's plugin capability.

Delphi is fairly quick, you're correct, but it is not the fastest, and leaves a lot to be desired in terms of efficiency, specifically for the developer. Its just so damn "wordy".

I also think Pascal is the most easiest language to understand with no prior coding knowledge.

Obviously most languages out class it, but pascal does a decent job for RS scripts.

Also don't forget we're using a interpreter (Lape) which is far from FPC.

From: Olly
I also think Pascal is the most easiest language to understand with no prior coding knowledge.

Obviously most languages out class it, but pascal does a decent job for RS scripts.

Also don't forget we're using a interpreter (Lape) which is far from FPC.

I 100% agree with you but for all the wrong reasons. I feel that yes, for the simple things, pascal is a very simple language to learn. However, the more advance features of it I find are harder to use and learn than the higher level features of more popular languages. This is due to objects being more stuffed into it rather than the language being built around them.

I also believe pascal can teach some very poor practices, such as lack of care to case-sensitivity.

Ultimately, I agree, it works fine for our goal.

From: Olly
I also think Pascal is the most easiest language to understand with no prior coding knowledge.

Obviously most languages out class it, but pascal does a decent job for RS scripts.

Also don't forget we're using a interpreter (Lape) which is far from FPC.

Dunno about this, i'd say that Python is easier to read/write.

From: slacky
I find object pascal very nice looking.

Also, faster than Delphi? You clearly don't know much about Delphi then.
I can assume you mean to say those languages (errm compilers) are much faster then Lape (not Delphi), then you wouldn't be wrong.

Lol..

The ONLY time Delphi is "faster" than C, C++, C#, and Java, is in code-writing speed. You can write code faster in Delphi than the mentioned languages because you have less to worry about (memory management, "gotcha's"), etc..


Even then, I would bet you can write code faster in C# and Java than Delphi by a long shot. Delphi's optimiser will NEVER be as aggressive as Clang's LLVM or the JIT compiler used by .Net 4.5+. Not sure about the JVM.


The reason we use Pascal and Delphi for Simba and Scar is simply ease of use. With these languages, we can write scripts and code within a day of learning it. The tutorials are easy to follow. There's no "gotcha's" or stupid stuff to worry about (well there is, but not too many [other than the bugs in Lape]). It's straight forward.

I like the other languages but I can never see them being used for scripts. Those are for full fledge programs.


@OP; The only legit reasons I can think of is:

extremely easy to learn
easily used as a scripting language (although, this is arguable since we can use LUA or Python or w/e)

That's it. If we could do it all over, I would vote PYTHON as the main language for Simba. Not Lape or Pascal script or Delphi (although Scar Titan is using Delphi and looks fairly nice).

From: the bank
I mean no disrespect, however Pascal/Delphi are ridiculously wordy languages. Not only does this, ironically, decrease readability due to the clusterfuck that is an application, but also limits efficiency of the developer by making code longer and take more time to write.

As far as Delphi compiling into machine code that is optimized anywhere near the degree of say C or C++ is ridiculous fallacy. Take these benchmarks for example. Of course these sorts of things are specific to compilers themselves, but I would put VisualStudio 2014 or even GCC faster than any Delphi compiler I've ever used.

I've used Delphi extensively, including creating the OpenSCAR project a year or so before Simba was even released. And yes, I'm well aware of Simba's plugin capability.

Delphi is fairly quick, you're correct, but it is not the fastest, and leaves a lot to be desired in terms of efficiency, specifically for the developer. Its just so damn "wordy".

This goes to you as well @Brandon:
I never claimed delphi was the fastest or faster then the mentioned languages (compilers). I only saeid that the other languages (bank mentioned) aren't notably faster. Also that test you show there seems to be around 14 years old or so.. And it only tests 1 single thing.. Computing PI, where I don't see Delphi being any notably slower then any of the C compilers (at least not the the degree where it's worth mentioning).

I didn't claim Delphi to spit out machine code optimized to the same level as GCC. I only said "quite optimized".

Pascal languages are indeed very wordy, and for some this is an issue. I however haven't noted my self being very limited by it's wordy syntax. It does force you to type a lot more compared to the more compact languages out there, but on the other hand I find it extremely clear, so I can often take a quick look at some random piece of code and understand it/what it does quite quickly, and this on the other hand saves me a lot of time, this is not the case for me in most C-based languages, any language filled with all sorts of punctuation-marks isn't nearly as clear.


And all in all.. Who really needs the fastest of the fastest compiler?
Any compiler that spits out machine-code is usually good enough. There are very very few cases where one actually would need to care about the microscopic speed difference between GCC and Delphi. Can you mention any? And if speed is that important in what ever you do can't you just have the most critical parts written in assembly?
Assembly in FPC and Delphi is extremely simple to use.

From: slacky

And all in all.. Who really needs the fastest of the fasts languages?
Any compiler that spits out machine-code is usually good enough. There are very very few cases where one actually would need to care about the microscopic speed difference between GCC and Delphi. Can you mention any? And if speed is that important in what ever you do can't you just have the most critical parts written in assembly?
Assembly in FPC and Delphi is extremely simple to use.

Yes you are right. The mentioned languages are not "much" faster naturally but the optimisation of the other languages are done a ton better.

And yes we DO need the fastest at times. We use image processing in our scripts (OpenCV doesn't use Pascal or Delphi for a reason). We read directly from the GPU in OpenGL and Direct-X. Doing this more than 30,000 per second in Pascal & Delphi is a LOT slower.

In high performance critical code, it matters. It's not just a few nano-seconds or micro-optimisation. It's seconds that are passing as the time piles up.


But we are arguing about scripting languages so yes, I would say you are 100% right and that it doesn't matter.. but we could have been using Python or Lua instead of Lape or PascalScript.

So there's no "particular" reason why we use Pascal or Lape over Python or other scripting languages. I can count many reason why we use it over C, C++, C# or Java but definitely not Python or Lua.

It all just comes down to one choice which Wizzup made and that was to use Pascal. But I highly doubt there was any specific reason behind it other than ease of use and easy transition from Scar to Simba without having to learn new languages.

From: Brandon
Yes you are right. The mentioned languages are not "much" faster naturally but the optimisation of the other languages are done a ton better.

And yes we DO need the fastest at times. We use image processing in our scripts (OpenCV doesn't use Pascal or Delphi for a reason). We read directly from the GPU in OpenGL and Direct-X. Doing this more than 30,000 per second in Pascal & Delphi is a LOT slower.

In high performance critical code, it matters. It's not just a few nano-seconds or micro-optimisation. It's seconds that are passing.


But we are arguing about scripting languages so yes, I would say you are 100% right and that it doesn't matter.. but we could have been using Python or LUA instead of Lape or PascalScript.

Regarding OpenCV, have look at it's code. The most critical parts are usually written as SSE2 instructions.. And, alternatively can be compiled to use your GPU (Using OpenGL).
You also mention OpenGL, I am not sure why. OpenGL can be used from any language that can do external function calls (and AFAIK they all do it pretty much the the same way) so there is no slowdown there, if you where to use OpenGL from delphi.

From: the bank
SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

Fact is, I don't care what anyone says, Java, C++, .NET languages…just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.

Agreed
It'd be nice to have like maybe the client itself in C++ or .net since they're speedy and reliably cross platform "today" (.net is now open source so we'll see it in mono with better compatibility soon)
and with many interpreters so people can code in what they like imo

From: slacky
Regarding OpenCV, have look at it's code. The most critical parts are usually written as SSE2 instructions.. And, alternatively can be compiled to use your GPU (Using OpenGL).
You also mention OpenGL, I am not sure why. OpenGL can be used from any language that can do external function calls (and AFAIK they all do it pretty much the the same way) so there is no slowdown there, if you where to use OpenGL from delphi.

Ahh you're being stubborn. Now the thread is derailed completely.. ={

OpenGL can be used in any language such as Pascal, Delphi, and Java yes.. But what language is it written in? It's definitely NOT Pascal or Delphi. It isn't Java. It's C.

There's ONE reason for that: SPEED. There IS a slowdown in other languages (even Delphi and Pascal) which is what you're not understanding.

The simple indirect access to a C API isn't optimised out. When you load these API's in other languages, a whole new layer is added on top of it. JNI is the perfect example and there's NO WAY to get rid of it. Delphi is managed.

I'd like to start with the very basic core of Delphi: http://stackoverflow.com/a/180449/1462718 HEAP ALLOCATIONS.

The cost of a heap allocation vs. stack allocation. Everyone knows allocating on the stack is WAY faster than heap allocations. It's as simple as pushing the stack down and popping it. There's no memory book-keeping or tracking going on. There's no need to "free" allocations (which also costs).

This alone already puts Delphi behind. If you wanted to allocate on the stack in Delphi, you're forced to use Assembly. Not all allocations in OpenGL require a heap allocation (which is usually done for LARGE objects). See "Small String Optimisation" vs. Heap allocated strings.

Next is the usage of the "try-finally" idiom for freeing memory allocations. There's no such thing as "Free Exceptions" in Windows. Windows has three kinds of exception handling.. VEH (Vectored Exception Handling) and is used in Windows XP, SJLJ (SetJump LongJump) and SEH (Structured Exception Handling) and Linux has Dwarf, Dwarf2 and Dwarf3.

In Windows, SJLJ will COST you 15% speed NO MATTER WHAT. You will never be able to optimise it out. You automatically incur this cost by just using a 32-bit version of GCC alone (even if you don't use ANY exceptions at all!).

Next is SEH (http://www.microsoft.com/msj/0197/Exception/Exception.aspx and http://www.codeproject.com/Articles/82701/Win-Exceptions-OS-Level-Point-of-View). This is the one Delphi and all languages that use Windows MUST use (SJLJ is optional and only used as a hack in GCC). The cost of a SINGLE exception is to push the stack down and allocate a structure such as the below, run your code, unwind the stack when the exception occurs (pop the below structure off the stack and cleanup all stack allocated variables, then run the exception handler):

typedef struct _EXCEPTION_RECORD
{
  DWORD     ExceptionCode;    // which exception occurred
  DWORD     ExceptionFlags;   // additional exception info
  struct _EXCEPTION_RECORD *ExceptionRecord;
  PVOID     ExceptionAddress; // where the exception occurred
  DWORD     NumberParameters;
  ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;

This is done in ALL LANGUAGES that works on Windows. This cost alone is why C programmers stay away from raising exceptions in WinAPI and instead use "goto" and "return codes".

So just using an idiom such as the one in the above Delphi sample, you incur the cost of an exception without even realising it. And this is required because an allocation may fail and throw an exception and if you don't catch it, you will incur the cost of a memory leak.

This cost is not paid in C++ because you don't have to use exceptions due to RAII and automatic destruction of objects. The only way to avoid this cost in Delphi is to use records/structures (POD) and completely avoid creating classes/objects.


Anyway, unless you plan on allocating and handling all the memory yourself and writing a lot of assembly, you're out of luck. Every time you use SetLength on an array, it has the overhead of reference counting, copying on write, etc.. Are you saying you're going to get rid of the core features of the language for speed?

There's a whole layer of memory difference. In Pascal & Delphi, allocations are done completely different. The same memory you allocate in Pascal and Delphi cannot just be passed to C and expect it to be used the same way.

For example, in Tesseract, I have to COPY the string to a Pascal allocated buffer.


For example in @the bank;'s random-int plugin, he does (the difference between malloc and AllocMem):

Function PSAlloc(size: Integer): Pointer;
begin
  Result := AllocMem(size);
end;

var
  TIA: TIntegerArray;
begin
  SetAllocator(@PSAlloc);

  TIA := randomIntArray(0, 500, 1000); //generate 1000 random ints
end.

then in C he does:

void (*allocator)(int) = NULL;

void SetAllocator(void (*alloc)(int))
{
    allocator = alloc;
}

void* randomInt(int min, int max, int count)
{
    int* TIA = (int*)allocate(count, allocator); //allocate memory using Pascal instead of C.
    generate_random(TIA, min, max, count);
    return TIA;
}

He had to use an allocator because malloc & new aren't compatible with AllocMem. AllocMem has a lot more book-keeping than a simple malloc. AllocMem is equivalent to: book-keeping + malloc combined. However, malloc already does its own book-keeping so now you have the overhead of double keeping and an extra layer of incompatibility.

The TIntegerArray will simply crash right there and then. Allocating the TIA in Simba and then COPYING the data to it can be done but again, you incur the cost of a COPY.


If I allocated pointers to some structures in C, I have to COPY it to the Pascal/Delphi side. You can't just pass the memory and expect it to work (unless you guarantee the exact same memory alignment and layout). Then you have to worry about alignment as well.

JNI is even worse, Jagex had to write a custom OpenGL wrapper (jaggl.dll) in C just to interface with their application. They copy every single texture and model into a java.nio.ByteBuffer. This buffer is then passed to OpenGL which makes its own copy to the GPU (allowing the user to delete their own copy). So now you have a Java copy, you have a Java ByteBuffer copy and you have an OpenGL copy. That's 3 copies for each texture and 3 copies for each model. To narrow it down to TWO copies, Jagex decided to "Map" the buffer directly to their ByteBuffer. But now you have the overhead of just TWO copies.. but that's NOT all! You have the overhead of forcing the GPU to "sync" with the CPU (to access the mapped buffer) all to avoid a single copy (which is a fairly good trade off).

So all in all, Jagex had to write a custom plugin, create a duplicate of every model and texture and map the buffer (sync GPU with CPU). Without this, they'd have 3 duplicates. This right here is UN-AVOIDABLE, which is why they do what they do. Simply because they use Java. They can also use the "Unsafe" class to access buffer pointers directly, but it's another JNI overhead.

Next, the OpenGL plugins have to COPY the buffer to SMART to use (and then SMART copies to Simba which is irrelevant but adds up).


The same goes for OpenGL in Pascal and Delphi. It's not a native Delphi or Pascal API. Not only do you have to use indirect function pointer access, but you have to worry about memory alignment, packing, etc.. There's no static linking in Delphi to OpenGL or Direct-X. You have to use LoadLibrary and create a function pointer for all THREE HUNDRED AND SEVENTY-THREE functions and then call GetProcAddress to get the address of each OpenGL function to assign to your function pointers (which you have to write the signatures for). All of this, Delphi does under the hood for you. We can consider this overhead "NEGLIGIBLE".

Although Delphi can use pointers directly, you have to guarantee layout (contiguous memory) and alignment (dword, byte boundaries) for ALL structures and allocations and mapped buffers.

You're going to have to start using raw memory in Delphi just to get comparable speed. Things like "string", "arrays", et al will have to be dumbed down completely to raw dirty memory allocations with manual freeing.

Things like bit-fields cannot be used in Delphi or Pascal so you're out of luck. So all this incompatibility + overheads is just absolutely ridiculous. So just by using Delphi, you've already given yourself a huge disadvantage (although not even close to being as bad as Jagex using Java for OpenGL).

So it's not so much the "overhead" of loading the functions or calling them (which does add up eventually not is negligible).. It's the overhead of using the language itself. The core functions and classes of the language (which has to now be avoided to pass to C.. PChar for String, Raw memory allocations for everything, alignment/layout/packing, et al).

In that case, you might as well use C. But again, Python should be Simba's scripting language. Not Delphi or C.

From: Brandon
Ahh you're being stubborn. OpenGL can be used in any language such as Pascal, Delphi, and Java yes.. But what language is it written in? It's definitely NOT Pascal or Delphi. It isn't Java. It's C.

There's ONE reason for that: SPEED. There IS a slowdown in other languages (even Delphi and Pascal) which is what you're not understanding.

The simple indirect access to a C API isn't optimised out. When you load these API's in other languages, a whole new layer is added on top of it. JNI is the perfect example and there's NO WAY to get rid of it. Delphi is managed.

Didn't mean to come of as stubborn. I pointed out 1 thing, and asked a question (badly formulated), where I asked why OpenGL would be better from C ("You also mention OpenGL, I am not sure why") which you answered (in a somewhat spiteful manner I must add).

And yes, I do know why he passed an allocator to the plugin… Meh. So harsh for just because I asked a small simple question.

- I think i'm done here.

From: slacky
Didn't mean to come of as stubborn. I pointed out 1 thing, and asked a question (badly formulated), where I asked why OpenGL would be better from C ("You also mention OpenGL, I am not sure why") which you answered (in a somewhat spiteful manner I must add).

And yes, I do know why he passed an allocator to the plugin… Meh. So harsh for just because I asked a small simple question.

- I think i'm done here.

I'm not being spiteful. It's just the way I write. I write how I think (as if I'm explaining to myself, but in a more natural way [unprofessional because who speaks to themselves professionally].. My capitalisations are for emphasis, not shouting. I rather that, than painting it in red to make it clearer). I was just explaining, not for just you (even though I figuratively ask questions like "do you know why".. but "you" doesn't refer to just YOU but to the other readers as well), but for others who are reading as well. They might not know why the allocator was passed or what a memory layout is. Relax a bit. It's just a discussion. Not an argument or a put down. I don't put down capable programmers (which you obviously are [SimbaEXT, Memory Reading, etc). I don't put down incapable programmers either because they can learn.

My post is simply an explanation to the question and a discussion of WHY it is slower by a lot more than just a few nano-seconds which was implied previously.

As I have already mentioned, I would use Delphi, but definitely not as Simba's scripting language and it isn't a plausible language for GPU programming (as I described). Python would be my vote for scripting. I'd use Delphi over C if it really came to that. If you don't know, I love Scar Titan (Delphi) more than I do Simba (Pascal) and I love auto-it more than I do both of the aforementioned. Simply because of the "power" of it and it's a ton "faster" than Lape.. So again, this is where the "need for speed" comes in I guess. Although Lape may not hamper our abilities to code or to get things done fast, it's just not my cup of tea for a scripting language. Neither is Delphi. Neither is C (absolutely horrible choice). However, there's a reason we're here and not over at Scar or Autoit. Personal choice & Open Source (ability to contribute to make Simba better.. which is hard to do at Scar). The same personal choice that made Pascal our scripting language and not Python or Lua.

To answer OP's question of what are it's strengths compared to others: "NONE". It doesn't compare to others. It's just easier to learn. That's it. I personally hate comparing languages. Just choose what's best for the Job and Delphi, C, Java, C++, certainly isn't that IMO.

My choice is PYTHON or .NET if I even had a choice.

From: slacky
Didn't mean to come of as stubborn. I pointed out 1 thing, and asked a question (badly formulated), where I asked why OpenGL would be better from C ("You also mention OpenGL, I am not sure why") which you answered (in a somewhat spiteful manner I must add).

And yes, I do know why he passed an allocator to the plugin… Meh. So harsh for just because I asked a small simple question.

- I think i'm done here.

Don't be so easily offended, he didn't say anything to attack you just laid out some facts.

No one is denying you clearly have knowledge about the matter, but certain things you claimed from the beginning are simply false. That's all Brandon or I were trying to say.

Don't let an intellectual conversation bring you down, no body meant anything bad, and discussions like this is what help us both individually and as a community grow and become stronger and more informed developers.

Bringing back reference to the OP, I actually personally feel Java is the best approach to runescape macros. Tried and true.

The game is written in Java, to think that Java doesn't have a bit of a dominance in that regard is silly. Reflection API alone is clearly incredible.

I have been just looking around and reading your posts @Brandon trying to learn something although a lot of it is a bit over my head :D You seem like you reeeeally know the technical side of just about everything.

From: SirPrize
I have been just looking around and reading your posts @Brandon trying to learn something although a lot of it is a bit over my head :D You seem like you reeeeally know the technical side of just about everything.

I personally understand only half of his posts
@Brandon;

Well. The speed of the code always depends on who wrote the code. In any language the shitty-code can be written. State of modern compilers is that now the speed FPC and C++ approximately equal to. In this indiscriminate use of C ++ in Linux rather disadvantage, because we have a lot unmanained code. Solely because of it an eyes can break. But it works. But straight-Pascal compiler is much faster in compilation speed any C-like compiler. C and C ++ is good for microcontrollers, but for practical things - either have to reinvent the wheel, or look for someone already written code, or use the monsters like Boost or QT.

It'd definitely be nice to have python instead of pascal that way knowledge gained writing scripts here could be applied to pretty much any application you want. Python is and can be used for almost everything you would want to write (I especially like ipython notebook, been using it to do stuff for the last 2 years) and for the rest you probably should get someone else to write it in C or (this is painful) learn C yourself. I hope at some point simba makes this transition.

From: Brandon
I would vote PYTHON as the main language for Simba.

A little off topic but, how long do you think it would take to convert all of the current code into Python if everyone that knew how, here, worked on it? Let's just pretend they all devoted their free time to it whenever available and estimate.

Also, reading your posts is like trying to interpret another language(haha…). It would probably help if I actually knew anything about coding :p

Lol, It won't happen even if it did 90% of people would still use pascal.

If you want a python simba like this bug @slacky to make a newer release of rafiki.

From: Olly
Lol, It won't happen even if it did 90% of people would still use pascal.

If you want a python simba like this bug @slacky to make a newer release of rafiki.

But we can made a python extension mechanism for Simba on FPC:)

From: the bank
SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

Fact is, I don't care what anyone says, Java, C++, .NET languages…just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.

Java and C# are not prettier on the eyes than (modern) Free Pascal. Prettier on the eyes is just a matter of taste, anyway. Also, C# and Java are not faster than FPC by any significant margin.

From: grats
How hard would it be to put a python interpreter inside of simba

that's the "easy part" or am I wrong?

Yes, that is the easy part. The hard part is integrating everything well. I put some effort into libmml/pymml, and Ian has recently picked that up quite a bit. So in theory with a bit more work you can do quite some basic and advanced stuff from python using Simba's library. But not the GUI parts.

From: Wizzup?
Java and C# are not prettier on the eyes than (modern) Free Pascal.

I'm going to go ahead and call bullshit on that. Especially from an OOP standpoint.

But like you said, I suppose a lot of it falls onto personal preference.

From: Wizzup?
Yes, that is the easy part. The hard part is integrating everything well. I put some effort into libmml/pymml, and Ian has recently picked that up quite a bit. So in theory with a bit more work you can do quite some basic and advanced stuff from python using Simba's library. But not the GUI parts.

Stop double posting, use edit button, noob.