And this is justification enough never to respond to posts such as yours.
Your ignorance is impressive.
(Did you read the post? ... research the links? ... the quotes?)
Nice scripting language
quote:
Original post by Kevlar-X
And this is justification enough never to respond to posts such as yours.
Your ignorance is impressive.
(Did you read the post? ... research the links? ... the quotes?)
Can you please explain me where am I ignorant?
You edited your post AFTER I replied. Just because Eve online uses Phyton that doesn''t mean Phyton is fast. Perhaps the Eve Online guys have the resources to buy a server farm, in which case even a PHP based server would work nicely. We have limited resources, so we are going for the best trade off between speed, familiar syntax (C like) and ease of embedding.
It can''t be that hard to type "Python" (you know, as in the snake, as in Monty Python), can it?
Many of the advantages you attribute to Small, even in special cases, are attributable to Python. VM? Jython, a Python implementation for the Java VM. JIT? Psyco, Python.NET, and Jython on newer JVMs. Native code? Py2exe.
In the final analysis, none of those are factors, though. You chose correctly; good luck with the MMORPG.
Many of the advantages you attribute to Small, even in special cases, are attributable to Python. VM? Jython, a Python implementation for the Java VM. JIT? Psyco, Python.NET, and Jython on newer JVMs. Native code? Py2exe.
In the final analysis, none of those are factors, though. You chose correctly; good luck with the MMORPG.
Hi guys !
You may also have a look on the ISaid - scripting engine. Its very C/C++ like and has really cool features like:
. realtime debugging environment
. very slim architecture
. software threads
. definition of new classes including members & methods
. saving & loading - states
. aso.
I think the most outstanding stuff in it is, that its having this
over-your-game-blended debugging environment with breakpoints / expression-evalution and stuff like this. It''s implemented in
around 2 days or less if you''re knowing what your doing...
greetz, Roman
ah yes, here''s the link:
www.vertex4.com/isaid.php
You may also have a look on the ISaid - scripting engine. Its very C/C++ like and has really cool features like:
. realtime debugging environment
. very slim architecture
. software threads
. definition of new classes including members & methods
. saving & loading - states
. aso.
I think the most outstanding stuff in it is, that its having this
over-your-game-blended debugging environment with breakpoints / expression-evalution and stuff like this. It''s implemented in
around 2 days or less if you''re knowing what your doing...
greetz, Roman
ah yes, here''s the link:
www.vertex4.com/isaid.php
- www.sunage-the-game.com - - www.vertex4.com - Sauk says, 'Loading is fun...'
I glanced at ISaid -- it looks less "C-like" and more like C++ used as a scripting language. But I''m sure there''s more to it than that.
Kevlar-X, your last couple of posts have been pretty degrading. I find it unnecessary.
Raduprv, I appreciate you pointing out Small. I''ve looked over it before, but your post prompted me to look into it further, and I''m liking it so far.
Incidentally, your misspelling of the term "Python" as "Phyton" is consistent, but it''s no big deal -- I''m sure Oluseyi will get over it.
Kevlar-X, your last couple of posts have been pretty degrading. I find it unnecessary.
Raduprv, I appreciate you pointing out Small. I''ve looked over it before, but your post prompted me to look into it further, and I''m liking it so far.
Incidentally, your misspelling of the term "Python" as "Phyton" is consistent, but it''s no big deal -- I''m sure Oluseyi will get over it.
![](wink.gif)
---------------------------Brian Lacy"I create. Therefore I am."
Several things I noticed:
1. People seem to think that the GPL and LGPL distinguish between DLLs and statically linked libraries. THEY DO NOT.
Linking (statically, dynamically, or via telepathic brain linkup via aliens from planet Zog) is handled in the LGPL as being an allowed use of the licence which DOES NOT require you to LGPL or GPL your code.
Linking with GPL code (again, via ANY linking means) counts as a derivative work, hence you cannot distribute commercial software linked this way.
Most of the more important open-source libraries (Gnu C library, SDL, etc) are either LGPL or some even more lenient licence. Few libraries are GPL. The licence for Python seems to be more lenient than the GPL, in that it allows linking more or less unrestricted (you may need to ship a .txt file with your game, that''s all)
2. The perceived performance of one Blender plugin is no basis for a language performance comparison:
2a. How many other languages have you seen the exact same Blender plugin written in for comparison?
2b. If the answer is "none", don''t try to read anything into it.
Seriously though, this Blender plugin might be doing something intensely difficult, in which case, you would expect it to be slow.
And finally, you should not need to worry about runtime performance of a scripting language, because your program should spend sufficiently little time running scripts, that it should not matter.
Mark
1. People seem to think that the GPL and LGPL distinguish between DLLs and statically linked libraries. THEY DO NOT.
Linking (statically, dynamically, or via telepathic brain linkup via aliens from planet Zog) is handled in the LGPL as being an allowed use of the licence which DOES NOT require you to LGPL or GPL your code.
Linking with GPL code (again, via ANY linking means) counts as a derivative work, hence you cannot distribute commercial software linked this way.
Most of the more important open-source libraries (Gnu C library, SDL, etc) are either LGPL or some even more lenient licence. Few libraries are GPL. The licence for Python seems to be more lenient than the GPL, in that it allows linking more or less unrestricted (you may need to ship a .txt file with your game, that''s all)
2. The perceived performance of one Blender plugin is no basis for a language performance comparison:
2a. How many other languages have you seen the exact same Blender plugin written in for comparison?
2b. If the answer is "none", don''t try to read anything into it.
Seriously though, this Blender plugin might be doing something intensely difficult, in which case, you would expect it to be slow.
And finally, you should not need to worry about runtime performance of a scripting language, because your program should spend sufficiently little time running scripts, that it should not matter.
Mark
quote:Only partially true.
Original post by markr
Several things I noticed:
1. People seem to think that the GPL and LGPL distinguish between DLLs and statically linked libraries. THEY DO NOT.
Linking (statically, dynamically, or via telepathic brain linkup via aliens from planet Zog) is handled in the LGPL as being an allowed use of the licence which DOES NOT require you to LGPL or GPL your code.
quote:(emphasis mine; 6(c), 6(d), and 6(e) do not apply here)
From Section 6 of the LGPL
Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. ...
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
...
The key is that the user must be able to link a modified version of the library (assuming a fixed interface, of course) to the program. The easiest way to accomplish this is with dynamic/shared libraries. Alternatively, you could ship all of the application's object files.
Your code does not need to be LPGL'd, but you must still abide by the terms of the licence.
[edited by - ze_jackal on May 20, 2004 6:51:12 PM]
Nobody mentionned Lisp as a scripting language? It seems to me that Scheme is a great contender in that area: simple, small and it has some pretty decent compilers. And I don''t think it''s so hard to use, my 12 years old brother recently asked me to teach him the basics of programming, and using DrScheme, it''s been easy and fun.
As a note, I think that a C syntax for a scripting language is a lose. The idea is to have something easy and simple to allow yourself and your users to code new stuff easily and quickly. C syntax seems overly baroque in my opinion to allow that. Not sure that people who don''t program appreciate this syntax too.
As a note, I think that a C syntax for a scripting language is a lose. The idea is to have something easy and simple to allow yourself and your users to code new stuff easily and quickly. C syntax seems overly baroque in my opinion to allow that. Not sure that people who don''t program appreciate this syntax too.
Lemme add my two bits to the thread :-)
I wrote my own scripting language, NerveBreak, to use with my games and applications after taking a look at Python and Lua - which are the most famous scripting languages among game developers. The problem with both is that i (and this is something personal) disliked their syntax.
So i wrote NerveBreak (the name is a joke because i had my nerves broke [expl: gone mad] while searching in google for a name that hasn''t already taken by another program :-). I''ve wrote several smaller scripting languages at the past, almost all dedicated to a program or game, so i knew how to start :-). I can''t say that it was easy but it wasn''t difficult either. However i enjoy writing such stuff, so i don''t know what someone who prefers to stick on gamedev would feel about it.
After i had a very simple version (coded in a night) up and running, with host-defined functions, simple garbage collection and other funny stuff, i thought to release it with full source code so anyone could take it and use it with his program/game. Since 0.1.2 i decided to put it in a "real" opensource state, so i wrote an opensource-minded license (i named it The NerveBreak License), applied for an account at sourceforge.net and made http://nervebreak.sourceforge.net/ (if you visit the front page regularly, you should know the site, since i sent a "new" about it for 0.1.3 and 0.1.4).
The NerveBreak License, in practice, is similar to LGPL. The difference (and the reason i didn''t used LGPL) is that the NBL allows you to statically link your code. Actually NBL doesn''t have any requirements about the host program and the only requirements it has is to make the source code of the library -only if you modify it- available and to put the name(s) of the contributors to the credits part of your game/program, if it has a credits part ofcourse.
I believe in opensource software, and when i can use two programs that does the same job -both freeware- and the one is opensource, then i prefer to support the opensource one. So this is why i used the same model for my library :-).
Making a scripting library all by yourself and making it available for others is an interesting task. The world is full of them, and i can''t think a feature that NerveBreak has that some other library (f.e. CSL) doesn''t. However the world is full of game development assistance tools, but gamedevs are still making their own :-). It''s about time, i suppose. If you have time to write your own tool (i had time to make NB) or you want to learn how to make a such tool (a coder a friend knew made a modeller for their game just for this reason: to learn how to write a modeller), then you prefer to do so. If you don''t have time -or you just dont like the idea- you use others''.
I wrote my own scripting language, NerveBreak, to use with my games and applications after taking a look at Python and Lua - which are the most famous scripting languages among game developers. The problem with both is that i (and this is something personal) disliked their syntax.
So i wrote NerveBreak (the name is a joke because i had my nerves broke [expl: gone mad] while searching in google for a name that hasn''t already taken by another program :-). I''ve wrote several smaller scripting languages at the past, almost all dedicated to a program or game, so i knew how to start :-). I can''t say that it was easy but it wasn''t difficult either. However i enjoy writing such stuff, so i don''t know what someone who prefers to stick on gamedev would feel about it.
After i had a very simple version (coded in a night) up and running, with host-defined functions, simple garbage collection and other funny stuff, i thought to release it with full source code so anyone could take it and use it with his program/game. Since 0.1.2 i decided to put it in a "real" opensource state, so i wrote an opensource-minded license (i named it The NerveBreak License), applied for an account at sourceforge.net and made http://nervebreak.sourceforge.net/ (if you visit the front page regularly, you should know the site, since i sent a "new" about it for 0.1.3 and 0.1.4).
The NerveBreak License, in practice, is similar to LGPL. The difference (and the reason i didn''t used LGPL) is that the NBL allows you to statically link your code. Actually NBL doesn''t have any requirements about the host program and the only requirements it has is to make the source code of the library -only if you modify it- available and to put the name(s) of the contributors to the credits part of your game/program, if it has a credits part ofcourse.
I believe in opensource software, and when i can use two programs that does the same job -both freeware- and the one is opensource, then i prefer to support the opensource one. So this is why i used the same model for my library :-).
Making a scripting library all by yourself and making it available for others is an interesting task. The world is full of them, and i can''t think a feature that NerveBreak has that some other library (f.e. CSL) doesn''t. However the world is full of game development assistance tools, but gamedevs are still making their own :-). It''s about time, i suppose. If you have time to write your own tool (i had time to make NB) or you want to learn how to make a such tool (a coder a friend knew made a modeller for their game just for this reason: to learn how to write a modeller), then you prefer to do so. If you don''t have time -or you just dont like the idea- you use others''.
--Slashstone - www.slashstone.comNerveBreak free scripting system.
In addition to all the stuff Oluseyi mentioned, I''ll point out that Python''s not big... it''s a ~120K static lib... Since you mentioned it''s serve-side, that shouldn''t even be a concern.
As for the ''indentation problem'' ... if you''re a halfway decent programmer, you already indent your code appropriately anyway. Or your IDE does.
I can''t address the issue of you finding it ugly - I don''t.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan
As for the ''indentation problem'' ... if you''re a halfway decent programmer, you already indent your code appropriately anyway. Or your IDE does.
I can''t address the issue of you finding it ugly - I don''t.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement