N# is working amazingly well for my Arcade program! It's doing exactly my intention: Object-Oriented programming with better syntax and more features than SmileBasic.

11/10 extremely unreadable syntax

Well, for one, it's uncommented. Secondly, it works on a different paradigm than SB, meaning code should be thought out and structured differently. Thirdly, it's much better than, say, C or Haskell.

Nobody says anything bad about C! Low level languages are much better than higher level languages, with the exception on Java, because of how well it manages the background processing, making it sometimes faster than C But why would you take an already broad, polymorphic function like VAR and limit it down to only ints? Integers were made to work with binary, and we are not allowed to use binary

This SmileBasic app was interpreted, and your app is interpreted even more Not only is it an extreme performance drop, but its at the point where higher level code will not improve efficiency. Its because of how much work the background parser has to do in order to condense and simplify the code, which I am sure you are not doing [thats the only reason that high level languages are successful]

That is where you are incorrect. The N# compiler compiles its code into SB, which means that code can theoretically run equally fast. Plus, with 'VAR,' it was replaced by 3 keywords: string, int, and float. These types work the same as the SB equivalents. Plus, I don't know where you learned Java was a good language. C#.NET is so much better (I've used both).

Also, the newest N# version uses full AOT compilation to SB. So runtime parsing is nonexistant.

I'm curious, does it run the code directly, realtime? Or does it create a new file of the default smilebasic syntax?

Simeon, you think its an interpreter,but he calls it an compiler.. its converted ONCE INTO SMILEBASIC CODE, then the program gets run via the normal smilebasic interpreter

Etwas is correct. The N# code is parsed once, and the compiler generates a separate PRG file that can be run and published completely independently of any N# supporter files.

Ok so its a "compiler" Thats not the point though, your attempting to convert object oriented into procedural code And unless if you put most of your effort into simplification and code compression, then its sure to be slower than smilebasic code directly I'll be taking a compiler class for my computer science major soon I would like to see the code for this, it is pretty interesting

N#'s strength is not in speed, but rather in its ability to implement the OOP paradigm into SmileBasic. Also, N# is available for download.

The key, description, instructions, etc. are all located over at smilebasicsource.com

N# does a huge deal of simplication during the compilation process. For example, private functions are added by the compiler not recognizing the function name outside that particular class. Becaude of this, private functions add no speed decreases in the output. Also, you seem to put speed of a language above everything else. I'd like to remind you that other factors (like design) matter also.

But you also know, like in mcds, that speed is important for mass processing

Yes, I do know that speed is important since I made MCDS and had to deal with all of the angry 'lol ur gam iz not fest enuf' comments. I'm just saying that it's not all you should look for in a language.

gotcha