Temple of The Roguelike Forums
Development => Programming => Topic started by: Xecutor on June 17, 2011, 01:22:14 PM
-
What features in the scripting language can make development easier?
Beside all the basic stuff that most of scripting languages have.
Something that can't be done on a library level.
Probably some kind of high level rules matching for advanced AI?
Some advanced algo that would be much easier to use when it is built in into engine
rather than when it is exists as external lib?
All ideas are welcome :)
-
All ideas are welcome :)
In that case I think it should be worth thinking if scripting is needed at all. I have found it confusing so I'm not using it. I guess compile speed has been an explanation for using scripting, but these days compiling is really fast, takes no time at all when you change only couple of source files and then run.
-
All ideas are welcome :)
In that case I think it should be worth thinking if scripting is needed at all. I have found it confusing so I'm not using it. I guess compile speed has been an explanation for using scripting, but these days compiling is really fast, takes no time at all when you change only couple of source files and then run.
Scripting is not about compilation or execution speed. It's about development speed.
Scripting languages have RAD features not available in c/c++ and, to a lesser extent, C# and Java.
Scripting languages (usually) have rich abilities for data presentation as well as data parsing.
Not to mention almost free data de/serialization.
-
Scripting languages have RAD features not available in c/c++ and, to a lesser extent, C# and Java.
Scripting languages (usually) have rich abilities for data presentation as well as data parsing.
Not to mention almost free data de/serialization.
RAD features?
-
Hi,
All of those features you mention are also available to the c++ programmer through the use of libraries. For example, serialisation is very easy and very unobtrusive to implement with a decent serialising library ( boost , for example ). If by RAD you mean Rapid Application Development, then that has been available for a lot of languages, both compiled and interpreted, for many years.
That is not to say scripting doesn't have its place, for example if you want things easily modded and programmed by people not familiar with the core language of your engine, then it can allow others to modify aspects of the host application.
That being said, for a roguelike being written by a C/C++ developer, its just not worth the mental gear change in my opinion :).
Cheers
Dave.
-
Yes, RAD is rapid application development.
C++ has closures, coroutines, continuations, delegates?
Effort required to make boot::serialization to work is still effort and can't be compared to zero effort.
I wrote several 7drls and one full fledged roguelike in C++.
I have a feeling that significant amount of routine work could be avoided.
-
Hi,
No, c++ as a language doesn't have those , but you didn't mention them in your post either. Although quite how coroutines , for example, will help roguelike development I'm not sure, but since I've only written one roguelike ( not released as its simply not polished enough ) perhaps you could elaborate on how those particular features help :).
For my own endeavors I've quite often considered integrating a Scheme ( its another language I occasionally dabble with ) for scripting purposes, but it always comes back to what I mentioned in my previous post in that it doesn't seem to buy me anything in terms of roguelike dev. I think its the mental gear change when switching from c++ I find too much, especially given how expressive c++ is anyway :).
Cheers
Dave
-
I have looked at Boost's serialization, and it still looked cumbersome. But I have not really tried. A real life comparison of a roguelike using Boost serialization, or just doing saving by itself, would be helpful.
Coroutines are useful for game development, but I am also not sure whether they are so helpful for roguelikes.
After writing a big roguelike (one that I have not released, not Hydra Slayer) in a heavily scripted way I see lots of situations where using C++ would be cumbersome. Creating a new type or monster, or a new interaction, seems much more straightforward. But it depends on the developer and what kind of interactions frequently appear in a given design.
As for the original question, see my posts in the "Handling deaths/corpses" thread. They describe properties of the script language I am using.
-
Hi,
No, c++ as a language doesn't have those , but you didn't mention them in your post either.
I said 'beside all the features ...' :)
Although quite how coroutines , for example, will help roguelike development I'm not sure, but since I've only written one roguelike ( not released as its simply not polished enough ) perhaps you could elaborate on how those particular features help :).
Coroutines can make implementation of complex AI features and multiturn abilities easy and transparent.
Coroutines allow straight logic where in C++ you have to break it into several (many?) pieces.
It's hard to estimate before you try :)
I've made some prototyping in falcon and I love results very much.
Actually I already have rich perl experience, and I know how convenient and fast script development could be.
But perl is too heavy and hard to embed.
I tried many different scipting languages, I liked some features of ones and other features of others.
Falcon is the best so far featurewise, but it's too far from release version,
but I took part in development in case I fail with my project :)
For my own endeavors I've quite often considered integrating a Scheme ( its another language I occasionally dabble with ) for scripting purposes, but it always comes back to what I mentioned in my previous post in that it doesn't seem to buy me anything in terms of roguelike dev. I think its the mental gear change when switching from c++ I find too much, especially given how expressive c++ is anyway :).
Well. I have around 16 years of C++ development behind. I know what C++ can and what it can't.
C++0x will make things much better, but it's not yet here. I'm tired of waiting (it was supposed to be C++2008).
But I'm somewhat afraid of many features of boost. boost::spirit example compiles more than 3 minutes in release configuration, that's not even fun.
-
Hi,
I'd mention I don't mean to put the case to actually use boost serialize for an actual roguelike, I mentioned it more to point out serialising can be pretty much considered a "solved problem" for c++ ( not just boost, of course, there are others , but boost is the one I am most familiar with ). For my current project I am actually using plain old .ini files, which seem to work just grand, although my thoughts do wander from time to time to using sqlite ( but I guess that is a whole other discussion! :) ).
Xecutor : mea culpa with the c++ features, seems I had a problem between my eyes and my brain :D.
Currently I'm using VC2010, and enjoying the c++00x features it provides, but it would be nice for it to be more fully fledged. Given time I'm sure things will improve.
Cheers
Dave.
ps: yes, template compilation times can suck somewhat, but I have a reasonably fast box, so most projects I don't really notice, and for big projects it is a good excuse to go have a cup of tea :).
-
Well, I myself am a big fan of the Lua scripting language, and for some time now have integrated it into every project of mine, and even wrote a couple little games exclusively in Lua, although speed issues kept this from becoming really workable.
In my opinion, embedding a language like Lua presents several clear benefits for roguelikes. Firstly, it allows for more intuitive, flexible data files to contain various types of game data. Many RLs use data files for storing things like monsters, items, etc, and the benefit of this is *almost* universally agreed upon, so I won't waste time arguing *why* you would want to do this, but how scripting can make it better.
First of all, with traditional data files, you have to write a parser to read and load all the game data. This presents its own set of problems, including many potential bugs, caused by either the parser, or a typo in the data file. By using a script instead, you can more intuitively load this data, and any error will be easy to trace, down to the exact line. Also, by scripting data files, you can take advantage of conditional statements and other programming constructs that are impractical to implement with a traditional data file.
One example of how conditional statements in a data file might be useful could be in the case of revising content in a future update of your game. Let's say that in v1.0, a kobold has an attack rating of 5. You soon realize this makes them underpowered, so for v1.1, you decide to increase it to 8. Now, normally, you can just overwrite the old value and forget about it. But what if the player updates your game to v1.1, but is still playing a savefile from v1.0? Now, suddenly, all the kobolds magically become stronger, which may break game balance for that version. Using a scripted data file, you can conditionally load different versions of the same data by checking for the version of the player's savefile. Problem solved. Obviously, there are many other useful things that can be done with scripted savefiles.
And, on the note of savefiles, using a script for savefiles also makes things easier. You can simply write the savefile as a script that automatically loads the game data. This makes the savefile human readable by default, which can be *immensely* helpful for debugging and balancing your game. And, if using a language like Lua, you can compile the script to bytecode if you want to, to prevent the player from reading or altering the data.
I've also found scripting to be useful for higher level AI implementation. Since developing any reasonably decent AI involves a lot of trial and error, and constant minor tweaking, using a script for this makes the process much quicker. If you do this, though, I highly recommend putting all of your lower level AI routines in your engine, for speed reasons.
Dungeon generation, also being a trial and error process, can also benefit from this boost to development speed.
One of the most obvious benefits is that it allows others to modify your game, without being competent C/C++/Java/whatever programmers. Editing monster values in a script is pretty easy for a beginner.
All in all, I'm very much so in favor of scripting, and I see ToME as being a stellar example of the potential power of a C (or C++, not sure) engine, with Lua scripting capabilities.
If you're serious about adding scripting to your game, I highly suggest you check out Lua. It's definitely one of the fastest available, is comparatively painless to embed (at least compared to certain other languages), and has, in my opinion, awesome capabilities. It's a very simple, easy to learn language, but extremely powerful, through the use of its rather phenomenal tables data types.
Anyways, just my two cents.
-
First of all, with traditional data files, you have to write a parser to read and load all the game data. This presents its own set of problems, including many potential bugs
This assumes that you need a data file in the first place OR that you need text based data and then convert it to numbers. But you can just place the data in C++ source code. It's easy and fun!
-
But you can just place the data in C++ source code. It's easy and fun!
It's a little bit better in c++0x with data in source, but current version of c++ is not so good at this.
You can't create dictionary data directly. You can create map from array at init time.
But you need to do this manually for every different data type.
Not to speak about data updates. If your data is in script, you can update script. Even in runtime.
If you data is in c++ source, you must recompile binary.
Serialization in C++ is easily solvable problem, but it is routine task and a little error prone, in some cases.
Every time you introduce new object, you need to write several lines of code to support serialization.
While it's easy, it takes time. If you develop you rl here and there 10 minutes each time,
extra time spents that are not directly related to game are somewhat of a waste.
-
You can't create dictionary data directly. You can create map from array at init time.
But you need to do this manually for every different data type.
What are you talking about? Take a look at how I did it in Teemu:
http://koti.mbnet.fi/paulkp/teemu/teemu.htm
No maps, no bullshit.
Every time you introduce new object, you need to write several lines of code to support serialization.
I don't know what's the problem with serialization (or save/load game as we people call it). Again, look at Teemu's Tar_Ball class to see how it's done easily. You just save the dynamic, changing data of a class and then restore them from data stream. That's it. It's the easiest part of roguelike programming.
-
You can't create dictionary data directly. You can create map from array at init time.
But you need to do this manually for every different data type.
What are you talking about? Take a look at how I did it in Teemu:
http://koti.mbnet.fi/paulkp/teemu/teemu.htm
No maps, no bullshit.
Yeah, how true. If you don't need them than whole world don't need them too.
Every time you introduce new object, you need to write several lines of code to support serialization.
I don't know what's the problem with serialization (or save/load game as we people call it). Again, look at Teemu's Tar_Ball class to see how it's done easily. You just save the dynamic, changing data of a class and then restore them from data stream. That's it. It's the easiest part of roguelike programming.
Your thinking is bounded by complexity of your game.
In wizard's quest there are over 100 effects.
Each effect have owner and most of effects have dynamically generated value(s) and some have dynamic effect description.
There are over 50 monsters and a lot of them have unique abilties that have dynamic values.
All this stuff must be saved.
If you are so sure that scripting is not needed, just ignore this topic.
@linux_junkie :
Lua have scanning garbage collector. When a lot of data is manupulated, gc lockdowns can be visually noticable.
To my taste syntax of lua lacks syntactic sugar. Dual nature of table is somewhat confusing and sometimes can lead to bugs.
I can't get used to ':' as method call operator. In presense of '.' operator I'm constantly confusing them.
As for speed - my prelinamenary tests are comparable to lua. Don't know how it will slowdown when
I'll add all the features, I hope not too much. I designed it with optimizer in mind.
If what I planned will work as I planned, my engine might even compete with lua :)
@Dave:
I can try C++0x features with g++ and clang too. They are great.
But I can't use them in production code. Yet.
@Z:
I've read you post in that thread. IMO something like this can be solved with delegate+coroutine combo.
For most cases delegates are enough. Coroutines looks nice when you need to inject code into
multiphase event, like 'object taking damage'.
If I misunderstood what you are talking about, can you make more complete example.
-
Yes, the methods themselves can be done as delegates. But you also need an engine which performs the work of adding methods to objects, calling them, and removing them. This should be a part of the script engine, otherwise it could get too slow.
I don't see where co-routines fit.
-
What do you mean by scripting language? A very high level, dynamically typed language that has an intrepeter?
I've always found the term confusing - what's "scripting" and what's "programming"?
-
What do you mean by scripting language? A very high level, dynamically typed language that has an intrepeter?
I've always found the term confusing - what's "scripting" and what's "programming"?
Yes, I'm talking about high level dynamically typed programming language.
It has virtual machine that executes pcode.
Yes, the methods themselves can be done as delegates. But you also need an engine which performs the work of adding methods to objects, calling them, and removing them. This should be a part of the script engine, otherwise it could get too slow.
I don't see where co-routines fit.
Event handler of multiphase event can be executed as coroutine that can skip to required phase, when needed.
For example:
func onTakeDamage(source,target,damage)
org=damage.clone()
skip(afterBlock)
source.takeDamage(target,org)
end
event handler stores original damage taken by unit and, if damage wasn't blocked, source also takes this damage.
Between event start and damage blocking code original damage value can be affected by many factors.
-
Between event start and damage blocking code original damage value can be affected by many factors.
In my solution each method added gets a priority, and they are executed from highest to lowest priorities, i.e., only the highest one is executed, but it can call down the next one. I can choose if a method calls down before, after, or in the middle of doing its own thing. For example, in a WriteName method that outputs things like "large rusty iron shield of flaming (equipped)", highest priorities are assigned to the most external prefixes and suffixes (large, equipped), lower ones to the internal ones (iron, of flaming), and the lowest priorities to the noun ("shield"). If I want to add an effect which consists of several parts which have different priorities (interleaved by methods gained from other sources), I just add two methods (in the example above this happens for the "large shield" which is a specific item type). I don't see how coroutines help here...
-
For my own endeavors I've quite often considered integrating a Scheme ( its another language I occasionally dabble with ) for scripting purposes, but it always comes back to what I mentioned in my previous post in that it doesn't seem to buy me anything in terms of roguelike dev. I think its the mental gear change when switching from c++ I find too much, especially given how expressive c++ is anyway :)
I have too - scheme can buy you loads IMO, once you know how to get some power from it.
It may interest you to know that Guile, which was designed to embedded, has finally reached version 2.0, and is appareantly much improved.
-
It's hard to estimate before you try :)
I've made some prototyping in falcon and I love results very much.
Actually I already have rich perl experience, and I know how convenient and fast script development could be.
But perl is too heavy and hard to embed.
I tried many different scipting languages, I liked some features of ones and other features of others.
Falcon is the best so far featurewise, but it's too far from release version,
but I took part in development in case I fail with my project :)
I don't understad what you mean by Perl being "heavy" (with resources?), but... you don't have to embed.
You can easily just write your game in the higher level language, and write modules for it in C to do the heavy lifting. I'm sure perl has a way to do this. My scriptling language of choice, Ruby does this quite easily. I didn't feel the need to embed it at all, I just made a C library of stuff that needs to be fast and wrapped that as a C module.
I don't like falcon because it's way too weakly typed. "cat" + 3 should nut return "cat3". that's just wrong and strange.
-
In wizard's quest there are over 100 effects.
Each effect have owner and most of effects have dynamically generated value(s) and some have dynamic effect description.
There are over 50 monsters and a lot of them have unique abilties that have dynamic values.
All this stuff must be saved.
So what? If you create over-complex data structures then they are going to be difficult to save and load. In my experience you can also do stuff the simple way. For example number of X don't really matter, because they are saved in same way.
If you are so sure that scripting is not needed, just ignore this topic.
There is no scripting in Kaduria either and it's supposed to become a major roguelike.. so yeah, I know I don't need scripting.
-
There is no scripting in Kaduria either and it's supposed to become a major roguelike.. so yeah, I know I don't need scripting.
Maybe if you'd used a higher level language it'd be done by now.
-
Maybe if you'd used a higher level language it'd be done by now.
Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.
-
Maybe if you'd used a higher level language it'd be done by now.
Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.
ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua. Plus, it should be obvious to anyone, and in the professional and academic world is undisputed common knowledge, that the choice of language, as well as what tools you use, undeniably plays a large role in *any* programming project. Choice of language and tools, coupled with the developer's proficiency in them, is critical to any project that wants to ship this century. To suggest otherwise reveals an extreme lack of understanding of the software development life cycle.
Higher level languages, which features more machine instructions per line of code, by their very nature result in a more rapid release, whereas lower level languages take more time, as well as requiring a greater debug time. This is why many software companies make extensive use of higher level languages for applications that are not speed critical, since speed is where most higher level languages lose their edge.
This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope. I'd say he pretty much makes the value of scripting languages undeniable. By coding a robust engine in C++, which uses OpenGL for rather impressive graphical effects, as well as being highly modular, he's able to add an absurd amount of content with every release, solely because of the increased productivity of working in a higher level language like Lua.
All in all, whether or not you choose to make use of a scripting language is up to you, and depends on your design goals. But to suggest that because *you* don't use it, that it doesn't provide a huge productivity boost for others who may use it, is silly and absolutely wrong.
-
ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua.
So what? After all, you can do stuff with scripting as well.
This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope.
I think he is just damn good programmer. Nothing to do with scripting really. But I wasn't really impressed by ToME 4. It maybe has tons of stuff, but you know.. it's kind of boring.
-
I think the programmer plays a more vital role than the language. Lots of people are writing RLs in Python, but DarkGod is the only one making a big success. Partly I think it's his experience of writing older languages that has taught him to make the most of Lua.
Scripting vs non-scripting is down to personal preference. Both are valid tools in anyone's hands. Certainly scripting makes many things convenient (especially submissions from community members), but if the dev is more comfortable with something else then he should stick to what he likes.
-
Maybe if you'd used a higher level language it'd be done by now.
Yeah, that's what people say. But I haven't seen their major roguelikes... I really think that in game development the programming language plays very little role.
ToME 4 is a recently released major roguelike (whether you like it or not), *and* it features scripting with Lua. Plus, it should be obvious to anyone, and in the professional and academic world is undisputed common knowledge, that the choice of language, as well as what tools you use, undeniably plays a large role in *any* programming project. Choice of language and tools, coupled with the developer's proficiency in them, is critical to any project that wants to ship this century. To suggest otherwise reveals an extreme lack of understanding of the software development life cycle.
Higher level languages, which features more machine instructions per line of code, by their very nature result in a more rapid release, whereas lower level languages take more time, as well as requiring a greater debug time. This is why many software companies make extensive use of higher level languages for applications that are not speed critical, since speed is where most higher level languages lose their edge.
This is also why Dark God has been able to release a very ambitious ToME 4, coupled with constant updates, which are all impressively large in scope. I'd say he pretty much makes the value of scripting languages undeniable. By coding a robust engine in C++, which uses OpenGL for rather impressive graphical effects, as well as being highly modular, he's able to add an absurd amount of content with every release, solely because of the increased productivity of working in a higher level language like Lua.
All in all, whether or not you choose to make use of a scripting language is up to you, and depends on your design goals. But to suggest that because *you* don't use it, that it doesn't provide a huge productivity boost for others who may use it, is silly and absolutely wrong.
I am pretty sure the vast majority of tome4 is in Lua. also the other stuff is in C, not C++.
Just to be pedantic :)
-
I think the programmer plays a more vital role than the language. Lots of people are writing RLs in Python, but DarkGod is the only one making a big success. Partly I think it's his experience of writing older languages that has taught him to make the most of Lua.
Scripting vs non-scripting is down to personal preference. Both are valid tools in anyone's hands. Certainly scripting makes many things convenient (especially submissions from community members), but if the dev is more comfortable with something else then he should stick to what he likes.
I disagree. The simple fact is the languages we are talking about are higher-level and more concise than C++. You can get more done, faster.
Pure C++ will perform better yes, but it's not that big a deal if you just code up the hot-spots in C, which most of these languages allow.
-
I don't understad what you mean by Perl being "heavy" (with resources?), but... you don't have to embed.
perl depends A LOT on it's modules. When you type 'use strict;', strict.pm is actually module, that resides in lib.
It's hard to make small 'portable perl' package. And naked perl have no sense.
XS is worst extension interface from usability point of view.
And using swig adds significant overhead.
I don't like falcon because it's way too weakly typed. "cat" + 3 should nut return "cat3". that's just wrong and strange.
If left side of add op is string, than right side is converted to string. IMO that's ok.
In 99% of cases when you will add something to string, you will mean "append textual presentation to string".
Having to explicitly cast things to string for this 1% of error cases is odd.
3+"cat" will raise error.
-
i'm wondering, does speed really matter in roguelikes? maybe for the AI?
i haven't finished a rogue yet, but we're happy with scripting a complex Java machinery with JavaScript at work. Certainly made our team more productive :)
-
Consider something like ADOM's animated forest, which contains something like 1500 monsters. Each of them move each turn. If you calculate FOV for each of them, and it covers the whole level, that is 2000 cells. Let's say you do 20 simple operations on average for each cell. Then you get 60 millions operations per turn. Current computers do about 400 million simple operations per second, so if you would get a slight lag. If you use an ineffective script language, or notify each monster whenever a monster in its sight moves, or your monsters have equipment and bodyparts which affect the strategy of other monsters, or something like that, then it will be too slow.
So it seems that you cannot have a roguelike which features heavy expressive-but-inefficient scripting, huge armies of monsters, large FOVs, and complicated AIs.
But huge armies and large FOVs are things that (in most cases) you can remove easily once it turns out that the game is too slow.
-
Consider something like ADOM's animated forest, which contains something like 1500 monsters. Each of them move each turn. If you calculate FOV for each of them, and it covers the whole level, that is 2000 cells. Let's say you do 20 simple operations on average for each cell. Then you get 60 millions operations per turn. Current computers do about 400 million simple operations per second, so if you would get a slight lag. If you use an ineffective script language, or notify each monster whenever a monster in its sight moves, or your monsters have equipment and bodyparts which affect the strategy of other monsters, or something like that, then it will be too slow.
So it seems that you cannot have a roguelike which features heavy expressive-but-inefficient scripting, huge armies of monsters, large FOVs, and complicated AIs.
But huge armies and large FOVs are things that (in most cases) you can remove easily once it turns out that the game is too slow.
The sane policy would be to write that bit in C, instead of the whole thing :D
The overhead for C modules (for Ruby at least) is quite small, for a big C function that does alot of grunt work you can't even pick it up.
-
i'm wondering, does speed really matter in roguelikes? maybe for the AI?
i haven't finished a rogue yet, but we're happy with scripting a complex Java machinery with JavaScript at work. Certainly made our team more productive :)
I can speak from experience with this one, having produced two nDRLs, both primarily written in Lua, using C++ calls to libtcod. While Lua is a very fast scripting language (most benchmarks place it as a serious contender among the fastest), some frequently called operations caused significant speed issues.
This was a particular problem for Zombie Swarm, which featured large numbers of zombies, as well as up to three allied AIs. The allied AIs weren't very complex, and the zombie ones were downright simple. But repeated calls to these routines (I should note the game was in realtime) resulted in significant slowdown, even on fast machines. So even with most of the heavier lifting being done by libtcod, like with pathfinding, I just found a scripting language inadequate. But after moving the AI primitives (move-to-player, attack-player, etc) over to C++, the speed quit being such an issue. It still wasn't fast enough overall, but I also had lighting effects and other such things further slowing things down.
All in all, I'm still definitely in favor of utilizing scripting languages, but believe that they should be used for what they're good for, and core engine behavior isn't it. After my experiences embedding Lua in C++, I can't imagine ever writing a roguelike in anything else. It made my coding sessions far more productive, as well as allowing me to painlessly make minor balancing tweaks, that would have been a chore in C++. Not having to recompile every time you change a couple values is a huge blessing.
-
Not having to recompile every time you change a couple values is a huge blessing.
That's what modern IDEs are for, they only compile files you change and compile times are pretty close to zero. Linux users however may be unaware of such modern tools... and they have to use scripting.
-
Hi,
I've been a bit busy over the last week or so and have only now just caught up with the thread. Very interesting discussion with much to ponder :).
In fact there is so much material I'll need quite a bit longer working out a proper coherent response!, however one thing I would like to add is that ultimately I don't think it matters too much whether you script or don't script as long as the job gets done.
Cheers
Dave
-
Not having to recompile every time you change a couple values is a huge blessing.
That's what modern IDEs are for, they only compile files you change and compile times are pretty close to zero. Linux users however may be unaware of such modern tools... and they have to use scripting.
You don't even need a modern IDE for that, since makefiles have been doing it for decades now. Regardless, I use a modern IDE, and recompiling still takes longer than simply saving a script file. That's not even to mention the fact that scripts can be edited and saved while the program's already executing, which also saves you the time of having to restart your application. Good luck doing that with C/C++, regardless of how modern your IDE is.
And as for your silly, pointless, uneducated comment regarding Linux users, well, that actually was about what I expected from you anyway. Most good IDEs are cross platform, and from my experience, the IDEs that are not cross platform tend to suck anyway. I can't imagine having to do any serious work on a Microsoft system.
-
That's not even to mention the fact that scripts can be edited and saved while the program's already executing, which also saves you the time of having to restart your application. Good luck doing that with C/C++, regardless of how modern your IDE is.
I'm not taking any sides here, but I do want to point out that Microsoft's Visual Studio has had an edit-and-continue feature for quite some time...
-
Regardless, I use a modern IDE, and recompiling still takes longer than simply saving a script file.
Yeah, but it can't be other than matter of couple of microseconds. Unless the IDE or compiler is awfully slow.
And as for your silly, pointless, uneducated comment regarding Linux users
They are silly, those stone age linux users.
I can't imagine having to do any serious work on a Microsoft system.
Well, actually, all serious work is done in Windows systems. You can't work with linux, because it needs constant updating and it's unreliable. Linux is mainly for hackers who want to do everything the hard way.
-
Considering linux runs on the 10 fastest super computers in the world, I'd say that the most serious work gets done on linux :) Windows is probalby only good for writing gui's and facebook apps.
-
Considering linux runs on the 10 fastest super computers in the world
It's not work, just some crazy scientists playing with simulations.
-
That's not even to mention the fact that scripts can be edited and saved while the program's already executing, which also saves you the time of having to restart your application. Good luck doing that with C/C++, regardless of how modern your IDE is.
I'm not taking any sides here, but I do want to point out that Microsoft's Visual Studio has had an edit-and-continue feature for quite some time...
Which doesn't work under 64Bit-Systems if you don't specifically target 32bit. And compile times are horrible in c#/.net compared e.g. to java =) Its very annoying if you practice tdd.
-
Well, actually, all serious work is done in Windows systems. You can't work with linux, because it needs constant updating and it's unreliable. Linux is mainly for hackers who want to do everything the hard way.
serious work is serious!! :D
-
I have too - scheme can buy you loads IMO, once you know how to get some power from it.
It may interest you to know that Guile, which was designed to embedded, has finally reached version 2.0, and is appareantly much improved.
Hi,
I keep a modified copy of S7 scheme to hand ( https://ccrma.stanford.edu/software/snd/snd/s7.html (https://ccrma.stanford.edu/software/snd/snd/s7.html) ). It's a bit basic , well extremely basic actually :), and lacks the features of a full blown scheme like Guile or DrRatchet, but I've found it very handy for providing a good bit of intelligence to a couple of C++ apps I maintain for work.
Cheers
Dave