Transvestite or Variables [Poll]

Yes, I have strong opinions on an unimportant naming decision for your personal project that you have not described in your post.

Fortunately you have removed all doubt with your cryptic reference to mixing your project with ajax.

If I understand this correctly, you are asking if your scripting language should be named "Transvestite" or "Variables". I would be so bold as to suggest that niether is a good name. One has rather awkward connotations associated with it, and the other is just downright confusing.

You should name it transvestite, and it should be based on German, with three genders for the variables, and a whole bunch of conjugation rules for calling functions. Except that the conjugation rules should be reversed so that if you want to call a function on a feminine variable you have to use the masculine conjugation.

Wait, this wasn't supposed to be a serious discussion was it?

John B

Quote:

Original post by Vorpy Yes, I have strong opinions on an unimportant naming decision for your personal project that you have not described in your post.

I've described it in the past on these forums. OR rather I've failled at describing in the past on these forums, seeing as how nobody got WTF I was talking about.

Quote:

Original post by Vorpy Fortunately you have removed all doubt with your cryptic reference to mixing your project with ajax.

Sarcasm is hardly needed here.

Quote:

Original post by Vorpy If I understand this correctly, you are asking if your scripting language should be named "Transvestite" or "Variables". I would be so bold as to suggest that niether is a good name. One has rather awkward connotations associated with it, and the other is just downright confusing.

Search for the thread "html vs. variables", I decided on the option of naming it Variables as a joke.

Quote:

Original post by JohnBSmall You should name it transvestite, and it should be based on German, with three genders for the variables, and a whole bunch of conjugation rules for calling functions. Except that the conjugation rules should be reversed so that if you want to call a function on a feminine variable you have to use the masculine conjugation. Wait, this wasn't supposed to be a serious discussion was it?

/me rolls eyes.

Quote:

Original post by DakeDesu /me rolls eyes.

What?

Do you genuinely believe that you can ask "Should I call my language 'transvestite' or 'variables'?" and be taken seriously by anyone?

Grow a brain.

John B

Quote:

Original post by JohnBSmall Quote: Original post by DakeDesu /me rolls eyes. What? Do you genuinely believe that you can ask "Should I call my language 'transvestite' or 'variables'?" and be taken seriously by anyone?

I suppose you are right... but you know, you could do something silly like, I don't know, suggest something better.

Quote:

Original post by JohnBSmall Grow a brain.

I could live without inflamatory comments.

Quote:

Original post by DakeDesu Quote: Original post by JohnBSmall Quote: Original post by DakeDesu /me rolls eyes. What? Do you genuinely believe that you can ask "Should I call my language 'transvestite' or 'variables'?" and be taken seriously by anyone? I suppose you are right... but you know, you could do something silly like, I don't know, suggest something better.

You already had something better. In another post on the topic you mentioned that 'transvestite' was just a working name and the language would actually be called something like ForwardScript. What's wrong with just using that, unless the whole thing is supposed to be a joke (in which case don't get pissed off when people don't take it seriously).

John B

Quote:

Original post by JohnBSmall Quote: Original post by DakeDesu Quote: Original post by JohnBSmall Quote: Original post by DakeDesu /me rolls eyes. What? Do you genuinely believe that you can ask "Should I call my language 'transvestite' or 'variables'?" and be taken seriously by anyone? I suppose you are right... but you know, you could do something silly like, I don't know, suggest something better. You already had something better. In another post on the topic you mentioned that 'transvestite' was just a working name and the language would actually be called something like ForwardScript. What's wrong with just using that, unless the whole thing is supposed to be a joke (in which case don't get pissed off when people don't take it seriously).

Well, this is more or less to change the working name of the project. Mostly because I've already had atleast one thread on "Transvestite" reported to the mods based on the working name alone. I'd prefer not to have ever post I make on this project reported to the mods (If you'd notice I already have a warning level of 10%, and my rating is in karma hell).

I could do ForwardScript as the working name--but I am a little unsure if I want to attach the name "ForwardScript" to this project, as it does not entire match up (other than this being a language for interactivity with its functions being based on Postscript).

Quote:

Original post by JohnBSmall Do you genuinely believe that you can ask "Should I call my language 'transvestite' or 'variables'?" and be taken seriously by anyone?

...

"The idea is to create a language that is stored in a SQL style database (preferably PostgreSQL, but most likely MySQL). The idea is I can store a program in an SQL database, move the database, but run it with an interpretor written in say Python, where as the previous interpretor might be written in PHP or Perl."

Were you serious when you wrote that in a previous post? Because I'll tell you right now that that idea doesn't float. You could already do that with Java, Python, or any other language that uses an interpreted bytecode. You'd just need to write an application to read the bytecode out of the database and feed it to the interpreter. Or if you mean storing each line, or even each expression, as a separate entry in the database, I don't think having to repeatedly execute queries would be good for performance.

Usually programs are just stored in files, and files are a lot easier to move than databases. Java and Python already have different interpreters, so I don't see how the language the interpreter is written in is important.

It apparent you missed base on what I was doing completely. I hope I am wrong here. The idea is to optimise a scripting langauge based on what is in a database.

Quote:

Original post by Vorpy "The idea is to create a language that is stored in a SQL style database (preferably PostgreSQL, but most likely MySQL). The idea is I can store a program in an SQL database, move the database, but run it with an interpretor written in say Python, where as the previous interpretor might be written in PHP or Perl." Were you serious when you wrote that in a previous post?

Yes, yes I was.

Quote:

Original post by Vorpy Because I'll tell you right now that that idea doesn't float. You could already do that with Java, Python, or any other language that uses an interpreted bytecode.

Supply links--because I've yet to see it.

Quote:

Original post by Vorpy You'd just need to write an application to read the bytecode out of the database and feed it to the interpreter.

Uh, maybe I misled you--it is not bytecode in the database--instead it is the script.

Quote:

Original post by Vorpy Or if you mean storing each line, or even each expression, as a separate entry in the database, I don't think having to repeatedly execute queries would be good for performance.

Each line? Not quite--take a look at the table's definition again. Each operator/function yes, but not each line. The idea is to get a language that is optimised to SQL rather than flat files.

Quote:

Original post by Vorpy Usually programs are just stored in files, and files are a lot easier to move than databases.

Databases are just as easy to move as files. The only difference is you have to dump the database or table first, where as with files, you need to archive it when distribute the script.

Quote:

Original post by Vorpy Java and Python already have different interpreters, so I don't see how the language the interpreter is written in is important.

I am not sure I follow you here.

OK, so the script is based on a RISC type of assembly language, so each operation can have certain parameters. Right? And the database has a table whose entries are the line numbers and their associated operation?

I'm just not seeing the point. How is this better than organizing code by lines in text files? What do we gain, besides wedging the language into a database? Couldn't we just as well dump the database to text files and say that's the language? Or if the language has constructs that are difficult to represent in easy to read text files such that we'd need something other than a text editor to easily understand them, how does putting the script into a database help?

Quote:

Original post by Vorpy OK, so the script is based on a RISC type of assembly language, so each operation can have certain parameters. Right? And the database has a table whose entries are the line numbers and their associated operation?

Well, I asked about behaviour, and had to come to my own decisions. And it is not really line numbers--it is operation number.

Quote:

Original post by Vorpy I'm just not seeing the point. How is this better than organizing code by lines in text files? What do we gain, besides wedging the language into a database? Couldn't we just as well dump the database to text files and say that's the language?

So, you are asking, why is storing stuff better in databases comparied to why is storing stuff better in text files? I think that is kind of a loaded question.

Quote:

Original post by Vorpy Or if the language has constructs that are difficult to represent in easy to read text files such that we'd need something other than a text editor to easily understand them, how does putting the script into a database help?

Well, the idea is to create a different paradigm of programming. Compare high level to low level langauges--they tend to feature different pros and cons when compared. My idea is to both enlighten the machine as well as the user of the machine. (I do not mean any religious connotations when I say enlightened). Think of the paradigm this language provides in comparison to flat files as the paradigm C++ provides with OOP compared to what C provides with functional programming.

It is similar as C++ does not quite make it to OOP, but is closer to OOP than C. With this language, it does not quite make it to a SQL optimised langauge, but opens the doors to SQL optimised langauges in the future.

(Yes, I am fully aware that C++ was not the first OOP language. No, I am not trying to start a language war between OOP vs. Proceedural vs. Functional vs. Process based programming or C vs C++)

Quote:

So, you are asking, why is storing stuff better in databases comparied to why is storing stuff better in text files? I think that is kind of a loaded question.

You can't be serious. A database is added overhead compared to a flat file. Databases are used to speed up relational searches between large datasets. Your dataset is a sequential set of instructions. No relations, other than the operation number.

A flat text file is, essentially, a database. You can easily reference any 'row' in the database by fetching the appropriate ... line. Because line numbers are the operation order.

Explain to me why you'd even consider using a database for this, except that the term sounds cool.

Quote:

Well, the idea is to create a different paradigm of programming.

Assembly in a database is still assembly.

What benefits does storing the source/bytecode of the script in a database give?

hey dake, i have absolutely nothing against anyone sexual preferences
but seems like you raising the "im gay!" flag in every post you make lately
this a gamedev board, im pretty sure theres a crapload of other places on the internet to go "alternate life style banzai!!!" all you want

There's just no new programming paradigm here. Going from a text file to a database is just changing the file format (well, databases kind of abstract away from the file format, allowing the user to specify the tables and relations and indices desired and letting the dbms take care of the details, but it's the same idea). And I have a hard time imagining what SQL would contribute contribute to the language, besides a syntax for writing queries to locate where various operations were used. IDEs already provide features like this without databases by building their own internal representations of the program.

Quote:

So, you are asking, why is storing stuff better in databases comparied to why is storing stuff better in text files? I think that is kind of a loaded question.

Quote:

Original post by Mushu You can't be serious. A database is added overhead compared to a flat file. Databases are used to speed up relational searches between large datasets. Your dataset is a sequential set of instructions. No relations, other than the operation number.

I am serious--however, you appear, from my end of this, to have missed what I am say. Databases, in general have some advantages of flat files in general

Quote:

Original post by Mushu A flat text file is, essentially, a database. You can easily reference any 'row' in the database by fetching the appropriate ... line. Because line numbers are the operation order.

So you are suggesting I use multiple text files for a simple script, using this paradigm.

Quote:

Original post by Mushu Explain to me why you'd even consider using a database for this, except that the term sounds cool.

• Self modifying code that is somewhat easier to keep track off


• Future extensions--it will not be like this forever (check out my C++ reference)


• Enlightenment of User and Computer


• To create a new paradigm of programming


• To create a langauge that can be both embedded, and scripted with the same ammount of ease


• To create an embedded language that does not require text files


• To create a language thats behavour can change based on implementation (okay, am I running wxWindows or AJAX, lets have the same commands output the appropiate stuff for those)


• The ability to save space via having functions with the same opcodes, quite literally, use the same opcodes


• An easier ability to store a core file


• With optimisations to have the Databased stored in RAM rather than HD at certain times (In a manner similar to that described in Arm/RAM Thumb/ROM), the ability to use the same syntax to put onto the stack, as to store in memory, without requiring loading a new API


• Be creative

Quote:

Well, the idea is to create a different paradigm of programming.

Quote:

Original post by Mushu Assembly in a database is still assembly.

I thought I explained this with the C++ analogy.

Quote:

Original post by The Alchemist hey dake, i have absolutely nothing against anyone sexual preferences but seems like you raising the "im gay!" flag in every post you make lately this a gamedev board, im pretty sure theres a crapload of other places on the internet to go "alternate life style banzai!!!" all you want

Citation needed.

Quote:

Original post by Kada2k6 I think you should call it Transvestite. It sure sounds more interresting than ForwardScript (or any other "general" name for a program). I have no idea what your program/script is about though.... and also, I don't think you need our help to name your program. Just call it whatever you want!

Except whenever I make a post calling it "transvestite" it gets reported to the mods for innappropiateness.

Quote:

Original post by Vorpy There's just no new programming paradigm here. Going from a text file to a database is just changing the file format (well, databases kind of abstract away from the file format, allowing the user to specify the tables and relations and indices desired and letting the dbms take care of the details, but it's the same idea).

You just aren't being creative enough. The idea is not so much a simple translation from text file to database. It is more the idea of making a language that is optimised for SQL, where as previous languages were optimised for text files (which really does not help for explaining how it is not a simple transition).

Quote:

Original post by Vorpy And I have a hard time imagining what SQL would contribute contribute to the language, besides a syntax for writing queries to locate where various operations were used. IDEs already provide features like this without databases by building their own internal representations of the program.

So you statically compile IDEs into the program, to have them do this while the program is running, with the possibility of a console running to watch what the IDE does to the program, and how the program makes use of the IDE?

Again, it is not so much to structure the program. It is more so to rearrange the program.