Open Turing (How to make turing)

[wtd]

Keep in mind that if you wish to create an open source Turing, you'll have to perfectly replicate its semantics, as well as its syntax. Yes, even the things you don't like.

Anything else would be just another programming language, and a fairly lame one at that.

[Tony]

thx for splitting this Dan I've PMed you with my thoughts on copyrights. For the benifit of the others - syntax would be difficult to copyright, languages often borrow parts from one another (and certain things just make sense. You can't copyright for or if then). Supposedly Turing borrows heavily from Pascal (although I haven't tried it out myself, so can't comment).

What remains is "Turing" as in "programming language". That would actually be a viable trademark. We'd just have to use another dead Mathematician's name in place. (You know, the whole IceWeasel deal)

wtd - Turing would have to be replicated to the best of our abilities, yes - that's the feature we are aiming for. Though arguably processes could be left out As long as the original Turing syntax remains as a subset of the language, I don't see why it can't be extended with new modules. Granted that it might cause some confusion (since that would not be backwards compatable with the original Turing). Perhaps force an explicit include? I'm jumping ahead of myself again...

[md]

Processes ahould be easy to implement, monitors would be a little harder, but not by much.

The hardest part is parsing the language and generating (preferably human readable) C/C++ code. Potentially even Pascal code...

[wtd]

Well, Tony, the only real reason Turing is in demand at all is that it is mandated for use by students in some schools. If the Turing you could provide cannot work seamlessly with the Turing Holtsoft provides, then it's useless for those students.

Similarly, if you extend the language, students will still not be able to use it. Any work they turned in which depended on things made possible by that extended Turing would be rejected by their teachers for not working with the official Holtsoft Turing environment.

[md]

Unless such extentions are implemented as Turing code (probably slow) and as a hook to a native version; so like if you write 3d functions then you'd have to implement them in Turing, and potentially also provide a OpenGL version in C/C++ or whatever that is used instead where possible.

[Tony]

Good point. You are right, we should concentrate on the full compatibility before else.

I do want to hear your opinion on one thing though. Given an alternative graphics engine (say OpenGL), the code ends up running phenominally faster, and renders better (clearer colours, anti-aliasing, etc). The same code works with the original Turing, but looks more pixalated, and appears to lag.

Would you consider that a problem?

[Andy]

The only problem i'd see with that is students convincing teachers to stop using Holtsoft's Turing and use ours. Which would in turn, cause Holtsoft to lose profits, resulting us getting sued.

[Tony]

why would schools do that? we don't offer any Turing support (does anyone know how Holt's distribution license works?)

Is there any case law on the topic of people not upgrading to new Microsoft Office, and using OpenOffice (or heck, even Google's apps) to continue working on the same files?

[md]

Andy wrote:

The only problem i'd see with that is students convincing teachers to stop using Holtsoft's Turing and use ours. Which would in turn, cause Holtsoft to lose profits, resulting us getting sued.

There is no grounds for a lawsuit, nothing to worry about. Unless we copy routines written by holtsoft. Cleanroom implementation is key here; some people look at the existing turing code and write docs, some people who have never seen the code look at the docs and write new code.

But like tony says, schools will not use free software unless there is a support contract there. So there really isn't any competition there.

[Dan]

Tony wrote:

I do want to hear your opinion on one thing though. Given an alternative graphics engine (say OpenGL), the code ends up running phenominally faster, and renders better (clearer colours, anti-aliasing, etc). The same code works with the original Turing, but looks more pixalated, and appears to lag.

Would you consider that a problem?

It could be in poorly wirten code. Since noramly turing whould be slower the student may not put any kind of dealy of fps control in there game and in open turing it whould happen so fast it whould be unplayable. In the other way around a student could make some bad code in open truing that runs ok but in real turing it takes a day or so to run a frame.

This is just a simple example, there could be many other timing issues if the sutedent is not using the best coding partucies.

[md]

I think if this is just a command line tool (and I'm definitely not up for writing an IDE) then very few beginners will use it. Only people who are really interested would use it (or people who just want to run some of these supposedly nifty programs...). While that may limit hte user-base at first it's probably also a good thing. No need to worry about stupid users if there aren't any.

[wtd]

Command-line for free, and that is easily obtainable would likely be more appealing than you think. Plus, it's the easier of the two (CLI, GUI) options to implement, and as such is the logical first choice.

[Tony]

well the GUI based IDE is essentially just a graphical wrapper for the compiler (and packs a bunch of extra features like a text editor, and perhaps debugger options). So command-line compiler is the first step, IDE could be a project on its own.

(btw, my detailed commentary on the legal aspects of Turing's syntax can now be found on the blog)

[Clayton]

Tony wrote:

Good point. You are right, we should concentrate on the full compatibility before else.

I do want to hear your opinion on one thing though. Given an alternative graphics engine (say OpenGL), the code ends up running phenominally faster, and renders better (clearer colours, anti-aliasing, etc). The same code works with the original Turing, but looks more pixalated, and appears to lag.

Would you consider that a problem?

Well considering OpenGL (as you so rightly said), runs so much faster than the "official" turing, you could get problems when a student makes a game that is fairly graphically dependent and a bit of a CPU hog even on OpenGL, then they go over to the official version, and it then runs so slow you can count the iterations of a loop. I think that, should this get started, we should try and keep it as close to the official versions speed as possible. (That is, if this IDE thing gets off the ground)

wtd wrote:

Command-line for free, and that is easily obtainable would likely be more appealing than you think. Plus, it's the easier of the two (CLI, GUI) options to implement, and as such is the logical first choice.

Right you are. I personally would take the command-line option if it was for free. It also has the upside for students to learn how to use the command line, and other things, such as traversing directories etc.

[Tony]

Freakman wrote:

we should try and keep it as close to the official versions speed as possible. (That is, if this IDE thing gets off the ground)

But that means intentionally crippling the language (with what? artificially implanted clock-cycle caps?)

and the IDE we are free to play with. It's just the source code compatibility that we are conserned with.