Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Python ➜ mushclient + python + multithreading = boom
mushclient + python + multithreading = boom

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #15 on Wed 14 Jul 2010 05:32 PM (UTC)
Message
David Haley said:
Twisol said:
Python and the like are really good standalone languages, and they're very good when that's what you're writing. But I'm not sure it's the right tool when you want an embedded language.

Eh, Python isn't nearly as bad to embed as some of the other languages. And many applications (e.g., EvE Online) have very, very successfully embedded Python.

Yeah, I'm sure it's just fine to embed. I only think it's not the right tool for the job. I might look up some Eve scripting to see how theirs looks though.

David Haley said:
In principle somebody could do a proper embedding of Python as Nick did for Lua, if you felt like spending the time on it. I think the words about subpar experiences are slightly exaggerated when it comes to this, but you do need an advocate of some sort willing to stand behind it and do the work.


Yeah, it's definitely possible. It would be a bit of a nightmare to maintain multiple languages within the same project, and it's needless bloat when most users will only use one language. Hence the DLL approach, which has its own set of complexities. I tend to think that, overall, it would be a subpar experience with at least one language.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #16 on Wed 14 Jul 2010 06:12 PM (UTC)
Message
Twisol said:
I'm sure it's just fine to embed. I only think it's not the right tool for the job.

It's fine to embed, but not the right tool for embedding? ;)

Twisol said:
It would be a bit of a nightmare to maintain multiple languages within the same project, and it's needless bloat when most users will only use one language.

Surely this is a slight exaggeration?

Besides, just because most users use a single language doesn't mean that a single language is used by most users...
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #17 on Wed 14 Jul 2010 08:58 PM (UTC)
Message
CJI said:


Now, where have I seen thread used... Where could it be... Oh, yes, I remember:

void CMUSHclientDoc::ThreadFunc(LPVOID pParam)



Yes indeed. I was going to admit that MUSHclient actually uses threads a bit. That code I did myself. In my defense, that was long before I read about "threads are evil".

Also MFC (the underlying library) also uses threads, in particular modal dialog boxes are not really modal dialogs, but MFC kicks off a new thread, and then locks the underlying window so you can't click on it. The reason is to keep the document "alive" while you stare at the dialog. You can see this in action, because if you edit the world's configuration, you can see text from the MUD scroll by underneath.

In fact this itself caused a major headache, because the configuration editor could not assume that the data structures had not changed while you were looking at them. For example, a trigger that deleted another trigger, might delete a trigger while you were editing it.

However you can live without threads. The stop-start nature of data to and from a MUD would seem to cry out for threads, but instead the client uses asynchronous IO routines (as do many servers) which still give you the ability to handle half-completed actions.

As noted, threads solve one problem, but create another. At least coroutines, which pause at deterministic places, cause far less problems with issue like whether variables change in value from one line of code to the next.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #18 on Wed 14 Jul 2010 09:04 PM (UTC)
Message
David Haley said:

Eh, Python isn't nearly as bad to embed as some of the other languages.


No doubt Python can be embedded. However as someone who embedded Lua directly, I can report it took quite a lot of work. Basically you have something like 400 script functions which need some sort of "glue" routine to interface them with the underlying functionality they are supposed to do.

And then you need to handle differently things like arrays (which in the WSH end are done with Variant arrays) and convert them into the script equivalent (in the case of Lua it was tables). And booleans are done differently in Lua at least (the number zero being considered true, for example).

Then it all has to be tested. And documented.

And then I look at other games (eg. World of Warcraft client) which *only* supports Lua, and I ask myself "why go to all the effort?".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #19 on Wed 14 Jul 2010 09:21 PM (UTC)
Message
Well, I was mostly trying to probe what makes a given tool the right one for this job. I think the WSH approach here is good enough for Python, generally speaking, so I wouldn't ask that you actually do this work unless somebody really really wanted Python -- in which case they should provide the binding themselves. ;)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #20 on Wed 14 Jul 2010 10:13 PM (UTC)
Message
David Haley said:
Twisol said:
I'm sure it's just fine to embed. I only think it's not the right tool for the job.

It's fine to embed, but not the right tool for embedding? ;)

Well, if you look at what I responded to, you'll see that by "fine" I meant that the difficulty isn't great. The rest of my point was that I don't think it's the right language to embed, at least in this case.

David Haley said:
Twisol said:
It would be a bit of a nightmare to maintain multiple languages within the same project, and it's needless bloat when most users will only use one language.

Surely this is a slight exaggeration?

Not really. Have you seen all of the glue code one has to maintain for the Lua interface? You'd have to do this again for every additional language.

David Haley said:
Besides, just because most users use a single language doesn't mean that a single language is used by most users...

But having all languages in one program just to satisfy everyone is impractical, especially with static linkage which would, as I mentioned, introduce a lot of bloat, most of which any given user won't ever use (because they use just one of those languages generally). Dynamic linkage is a better solution, but we have that in WSH, and I've voiced my perspective on WSH already. (And, of course, WSH is not cross-platform.)

I think MUSHclient is the only program I've ever seen to support multiple languages this way. WoW uses only Lua, even EvE only uses Python, and I don't see anyone there complaining about a lack of options.


Nick Gammon said:
However you can live without threads. The stop-start nature of data to and from a MUD would seem to cry out for threads, but instead the client uses asynchronous IO routines (as do many servers) which still give you the ability to handle half-completed actions.


I'd like to note here that Aspect uses an excellent event-based library called EventMachine, and I try to avoid threads in general. It's not like I have anything remotely near completion, but so far it's really quite easy to deal with, and I like this model a lot.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #21 on Wed 14 Jul 2010 10:21 PM (UTC)
Message
David Haley said:
Well, I was mostly trying to probe what makes a given tool the right one for this job. I think the WSH approach here is good enough for Python, generally speaking, so I wouldn't ask that you actually do this work unless somebody really really wanted Python -- in which case they should provide the binding themselves. ;)


I think there's a lot about Lua that really lends itself to embedding. The big one for me is that it's extremely easy to sandbox. I want control over what scripters can and can't do within my application. If I don't have that control, it's risky both for me and anyone using those scripts. Lua also comes with a minimalist standard library, which you control the presence or absence of. That's probably a "bad thing" for people who want to use Lua for standalone programs, but it makes it a wonderful candidate for embedding.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by CJI   Poland  (7 posts)  Bio
Date Reply #22 on Thu 15 Jul 2010 12:33 AM (UTC)

Amended on Thu 15 Jul 2010 03:41 AM (UTC) by CJI

Message
I'll reply in reversed order.

Twisol said:

The big one for me is that it's extremely easy to sandbox.


Well, sandboxing, if done well, is secure... But I really don't like the idea. You reduce danger of executing harmful code, but at the same time you greatly reduce functionality available in scripts. I just checked, out of curiosity, and this code worked:


import win32api
world.Note( win32api.GetComputerName() )


It means that almost all WinAPI calls are directly accessible from my python scripts. I could create new window (threading works to some extent - just accessing "world" object crashes MUSHClient, so I could really create another system-level window and do anything with it!), paint on the desktop, register (with pyHook) callback to intercept mouse and keyboard messages - system-wide (which is good, sometimes - and bad, if I want to write keylogger and convince someone to use my script...). And many, many more cool things, if I felt like refreshing my WinAPI skills.

If Python was properly sandboxed, this would (or at least should) be impossible. I'm not sure I really want to trade this functionality for security, especially considering that NOW it works that way and no one complains ;P

Twisol said:

I think MUSHclient is the only program I've ever seen to support multiple languages


I think so too. And that's one of many reasons why I use MUSHClient, and why I think it's simply the best client out there. Please don't talk about dropping support for other languages. Pretty please :)


David Haley said:

I think the WSH approach here is good enough for Python [...] unless somebody really really wanted Python -- in which case they should provide the binding themselves. ;)


I agree. Absolutely. I might - some time in future - give it a try, but - generally speaking - the way it works now is sufficient for me. So maybe some day as an exercise, but not anytime soon.

Nick Gammon said:

And then you need to handle differently things like arrays (which in the WSH end are done with Variant arrays) and convert them into the script equivalent (in the case of Lua it was tables). And booleans are done differently in Lua at least (the number zero being considered true, for example).


There are tools that automate part of the process. I know that they exist, but unfortunately I have no experience in using them... So as I said - maybe some day :)

Nick Gammon said:

Also MFC (the underlying library) also uses threads, in particular modal dialog boxes are not really modal dialogs, but MFC kicks off a new thread, and then locks the underlying window so you can't click on it.


I don't get it - why these dialogs are modal in the first place? My character once DIED! because of this! (It was over before I closed two dialogs that I had open...)

And Microsoft Foundation Classes are evil ;) I programmed some time with pure WinAPI in C, and then, fortunately, switched directly to QT and C++, so I was spared pleasure of working with MFC - but what I remember from quick overview is pure horror I felt. ;)

Nick Gammon said:

In my defense, that was long before I read about "threads are evil".


I really think that there is nothing to defend. Threads are just one of many tools you can use. They are not evil, neither they are some kind of super solution of "panacea". They have their weak points and advantages. Especially now, when mutlicore processors are so common, using threads is worth considering. Synchronization is an issue, but done right - poses no real threat to stability (but debugging is still hard). Threads are not evil. Their misuse - is.

David Haley said:

It's fine to embed, but not the right tool for embedding? ;)


Twisol explained later, but I think that embedding does not necessarily have to heavily restrict, or sandbox, embedded language. Twisol seems to have another opinion.

Twisol said:

You can use UdpListen() in MUSHclient to set up a UDP port to listen on, and run a standalone Python program that uses your thread to watch the file. Then when it sees a change, it can notify your MUSHclient script via the UDP port.


I thought about it for a brief moment, but that would be adding complexity instead of reducing it. If I had to script some kind of socket communication I'd do this with non-blockng socket using TCP from pure Python.

Twisol said:

Most of these languages come with extensive standard libraries already.


And, as I said earlier, I consider this an advantage. I understand your concerns, but really, sandboxing Python or Ruby or (I guess) PERL cuts their usability by half at least. Their main strength are huge standard libraries (yes, yes, elegant and pragmatic design, metaprogramming capabilities, beautiful syntax, etc. too, but if I could choose language based on syntax and design I'd pick haskell or ocaml ;) ).

If security is that big of the concern, you always can sandbox whole app or even system, like with BOCHS or the likes. It will be secure, no matter how inefficient.

On the other hand - I wrote my persistent data storage using SQLAlchemy and MySQL, effectively bypassing MUSHClient variables and never using them. I'd be very unhappy if I had to rewrite it and use variables (or built in sqlite) again... Miniwindows are sweet, but using them with WinAPI-like calls is painfully inefficient (in terms of code complexity) - I prefer generating image with PIL and then rendering it. I couldn't do it in heavily restricted environment...

Phiew. I wrote it all, thanks for reading :)

And one last thing - is it possible to register callback which will be called just before script engine restarts?

PS. Please correct any grammar or spelling mistakes I make. I read a lot in English and I have spell checker on, but I have very few opportunities to write, unfortunately.
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #23 on Thu 15 Jul 2010 01:14 AM (UTC)
Message
CJI said:

I don't get it - why these dialogs are modal in the first place? My character once DIED! because of this! (It was over before I closed two dialogs that I had open...)


Modeless dialog boxes are a special sort of pain themselves. :)

For example, if not closed yet, where do they go? I particularly dislike the Find dialog boxes that hang around even after you have found what you want.

And say you have world configuration up with a list of triggers, and then you edit a trigger, and it is all modeless, and you maybe change a trigger option by typing in a command in the command window, then that's two dialog boxes that need refreshing to show the new information.

Look, it is probably like threads. If you use them properly they can be fine.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #24 on Thu 15 Jul 2010 01:15 AM (UTC)
Message
CJI said:

PS. Please correct any grammar or spelling mistakes I make. I read a lot in English and I have spell checker on, but I have very few opportunities to write, unfortunately.


Your English is very good. Any minor mistakes (and I haven't noticed any) could easily be made by native English speakers.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #25 on Thu 15 Jul 2010 01:28 AM (UTC)

Amended on Thu 15 Jul 2010 01:37 AM (UTC) by Twisol

Message
CJI said:
Well, sandboxing, if done well, is secure... But I really don't like the idea. You reduce danger of executing harmful code, but at the same time you greatly reduce functionality available in scripts. I just checked, out of curiosity, and this code worked:


import win32api
world.Note( win32api.GetComputerName() )


It means that almost all WinAPI calls are directly accessible from my python scripts. I could create new window (threading works to some extent - just accessing "world" object crashes MUSHClient, so I could really create another system-level window and do anything with it!), paint on the desktop, register (with pyHook) callback to intercept mouse and keyboard messages - system-wide (which is good, sometimes - and bad, if I want to write keylogger and convince someone to use my script...). And many, many more cool things, if I felt like refreshing my WinAPI skills.

If Python was properly sandboxed, this would (or at least should) be impossible. I'm not sure I really want to trade this functionality for security, especially considering that NOW it works that way and no one complains ;P

Well, yes. That's what makes it a good application language. And if the host program doesn't need to be very secure, sandboxing is completely optional (though I question how easy it would be to sandbox Python, too).

And the functionality issue is all down to what you want your users to be able to do. It's the flip side of sandboxing. The idea with sandboxing Lua is to hide all the directly abusable API calls - which is mostly just the OS and I/O libraries - and add your own APIs for doing what you want to allow. And of course you can reinstate some form of the original API, but perhaps limited to a specific directory rather than the whole computer, to minimize potential damage.

CJI said:
I think so too. And that's one of many reasons why I use MUSHClient, and why I think it's simply the best client out there. Please don't talk about dropping support for other languages. Pretty please :)

At this stage, I don't think it could happen. Too many people are used to it.

CJI said:
There are tools that automate part of the process. I know that they exist, but unfortunately I have no experience in using them... So as I said - maybe some day :)

Like SWIG? The functions being glued are kind of odd, I'm not sure how easy it would be. I've never used SWIG either, though.

CJI said:
I really think that there is nothing to defend. Threads are just one of many tools you can use. They are not evil, neither they are some kind of super solution of "panacea". They have their weak points and advantages. Especially now, when mutlicore processors are so common, using threads is worth considering. Synchronization is an issue, but done right - poses no real threat to stability (but debugging is still hard). Threads are not evil. Their misuse - is.

Well put. Still, I prefer to use threads for jobs that can be truly parallel; if at all possible I'd rather use an event-based approach like EventMachine.

CJI said:
Twisol explained later, but I think that embedding does not necessarily have to heavily restrict, or sandbox, embedded language. Twisol seems to have another opinion.

Quite right, it's not necessary. It really depends on the needs of the host application. When you're dealing with distributable third-party plugins, I'm inclined to prefer at least limited sandboxing. As you noted before, it wouldn't be nice to have a seemingly benign plugin erase all of your files.

CJI said:
I thought about it for a brief moment, but that would be adding complexity instead of reducing it. If I had to script some kind of socket communication I'd do this with non-blockng socket using TCP from pure Python.

Really? UDP is simpler than TCP, and when you're using it over the loopback interface (never leaving the physical computer), it's reliable. You just send packets at will, and receive them on the other end. That's exactly why UdpListen() was added, if I recall correctly. Before the advent of miniwindows, it could be used to communicate with an external program running additional windows.

CJI said:
And, as I said earlier, I consider this an advantage. I understand your concerns, but really, sandboxing Python or Ruby or (I guess) PERL cuts their usability by half at least. Their main strength are huge standard libraries (yes, yes, elegant and pragmatic design, metaprogramming capabilities, beautiful syntax, etc. too, but if I could choose language based on syntax and design I'd pick haskell or ocaml ;) ).

That's why I treat languages as separate tools. :) Lua is easy to sandbox. I'd never try to sandbox Python or Ruby, and I don't have much experience with any of the others you mentioned.

CJI said:
If security is that big of the concern, you always can sandbox whole app or even system, like with BOCHS or the likes. It will be secure, no matter how inefficient.

A bit overkill for the purposes I had in mind, however this is definitely something I will need to do with Aspect.

CJI said:
On the other hand - I wrote my persistent data storage using SQLAlchemy and MySQL, effectively bypassing MUSHClient variables and never using them. I'd be very unhappy if I had to rewrite it and use variables (or built in sqlite) again... Miniwindows are sweet, but using them with WinAPI-like calls is painfully inefficient (in terms of code complexity) - I prefer generating image with PIL and then rendering it. I couldn't do it in heavily restricted environment...

Eeeeergh. I completely agree with the miniwindow API, sadly. They're awesome, but they can be a real pain to use for truly complex things.

CJI said:
PS. Please correct any grammar or spelling mistakes I make. I read a lot in English and I have spell checker on, but I have very few opportunities to write, unfortunately.

I hardly had any idea you might have trouble with English. :)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #26 on Thu 15 Jul 2010 05:19 AM (UTC)
Message
Quote:
The rest of my point was that I don't think it's the right language to embed, at least in this case.

Surely, if you find yourself repeating a claim after having it questioned, it's a sign that it's time to say why you believe it. :-)

Quote:
Not really. Have you seen all of the glue code one has to maintain for the Lua interface? You'd have to do this again for every additional language.

I was mainly referring to the claim that it's "needless bloat"; it seems to me that it's needless for you, but then again you're not every potential script developer, either. But see below re: maintenance nightmare.

Quote:
But having all languages in one program just to satisfy everyone is impractical, especially with static linkage which would, as I mentioned, introduce a lot of bloat, most of which any given user won't ever use (because they use just one of those languages generally).

By your reasoning, Lua should not have been introduced because it added lots of needless bloat when people were already using other languages, and most people would not have been using Lua -- this is back when Lua was experimental in MUSHclient. Perhaps it would be used more extensively if it had a first-class binding like Lua did. Had Python been done first, Lua would be in the same boat that you've put Python in now.

Look, you don't want to use Python, but really the only argument against embedding it directly is that it would take time to do so. These arguments about "needless bloat" are entirely subjective and make sense only from the perspective of somebody who doesn't want to use Python in the first place. OK, duh. I don't see why you need to prove any point here... If somebody wants to spend the time to add the required glue, why not? It will hardly be a "maintenance nightmare" -- the maintenance is in fact rather simple, with almost all the cost entirely up-front. And besides, you won't be the one taking care of it. I guess I'm not sure why this is generating so much verbiage...
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #27 on Thu 15 Jul 2010 05:49 AM (UTC)

Amended on Thu 15 Jul 2010 05:51 AM (UTC) by Twisol

Message
David Haley said:
Quote:
The rest of my point was that I don't think it's the right language to embed, at least in this case.

Surely, if you find yourself repeating a claim after having it questioned, it's a sign that it's time to say why you believe it. :-)

I'm sorry, have you read any of my posts? If there's something I've left out, please ask specifically.

David Haley said:
Quote:
Not really. Have you seen all of the glue code one has to maintain for the Lua interface? You'd have to do this again for every additional language.

I was mainly referring to the claim that it's "needless bloat"; it seems to me that it's needless for you, but then again you're not every potential script developer, either. But see below re: maintenance nightmare.

Again, I don't think it's a good idea to support every possible language, when it's practically a given that each user will use one language and stick with it. All of the other provided languages become loose baggage.

David Haley said:
Quote:
But having all languages in one program just to satisfy everyone is impractical, especially with static linkage which would, as I mentioned, introduce a lot of bloat, most of which any given user won't ever use (because they use just one of those languages generally).

By your reasoning, Lua should not have been introduced because it added lots of needless bloat when people were already using other languages, and most people would not have been using Lua -- this is back when Lua was experimental in MUSHclient. Perhaps it would be used more extensively if it had a first-class binding like Lua did. Had Python been done first, Lua would be in the same boat that you've put Python in now.

I'm talking from our present circumstances. I wasn't here when Lua was introduced. At this moment, I think Lua is the better choice. That's a highly subjective statement, but as should be extremely obvious, it is only a thought. And I've explained why I think that already.

And again, I wouldn't change it now, because people are used to it and they want to keep it. No, I'd prefer to use Lua and only Lua from the start. I can't speak directly for Nick, but I remember him saying things previously to the same effect.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #28 on Thu 15 Jul 2010 02:26 PM (UTC)
Message
Quote:
Again, I don't think it's a good idea to support every possible language, when it's practically a given that each user will use one language and stick with it. All of the other provided languages become loose baggage.

I still don't really understand why this is an argument in favor of Lua or anything really. It means that a given person will pick a given language and stick with it. OK. How is this supposed to be relevant to which languages should be added?

And by the way no need to go into hyperbole about supporting every possible language here; that's not what we're talking about after all.

Quote:
That's a highly subjective statement, but as should be extremely obvious, it is only a thought.

Well, that clears things up for me then. Your initial posts sounded like you were trying to make an objective point; now I'm satisfied. :)

By the way, yes, I actually have been reading your posts; no need to get snippy about that. :( (If I ask the question, it means that I remain unconvinced...!)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #29 on Thu 15 Jul 2010 07:39 PM (UTC)

Amended on Thu 15 Jul 2010 07:41 PM (UTC) by Twisol

Message
David Haley said:
I still don't really understand why this is an argument in favor of Lua or anything really. It means that a given person will pick a given language and stick with it. OK. How is this supposed to be relevant to which languages should be added?

It was more of an argument in favor of picking one language and sticking with it for an application. Even though Lua has the glue code, actual close-up integration is severely lacking. We still pass function names rather than functions to serve as callbacks, as a recent poster in another topic pointed out. It's to keep things "consistent" with the other languages, but it becomes a sub-par experience.

David Haley said:
And by the way no need to go into hyperbole about supporting every possible language here; that's not what we're talking about after all.

Meh, true, but IMHO one is enough. Begin to support more, and that opens the door for people requesting their own pet languages. And if you want to keep the API "consistent" between the languages - see above - you have to settle for the least common denominator. If you don't want to keep the API consistent, it's more work to do for each language "adapter", and a script in one language doesn't translate directly to a script in the other, at least in regards to the API in question.

David Haley said:
Well, that clears things up for me then. Your initial posts sounded like you were trying to make an objective point; now I'm satisfied. :)

*shake* It's pretty much all opinion, but based on my experience (YMMV, of course). I did explain very early on that I'm not a language fanboy, and I treat my languages as tools. I'm familiar with a good number of languages (though knowing some people, I wouldn't say "a lot"), and I have my own informal criteria for picking one for a new project.

In other words, I try not to look at everything like a nail, but that means that each language has a different place. All I'm trying to say is that I'm not sure Python is the right tool for this particular job. And I could very well be wrong!

David Haley said:
By the way, yes, I actually have been reading your posts; no need to get snippy about that. :( (If I ask the question, it means that I remain unconvinced...!)

Well, you were implying that I hadn't said anything about why I believed it, which rather bothered me as most of my posts have contained at least a small note about why I prefer Lua over other languages for embedding. No worries.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

81,440 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home