At 08:32 PM 4/6/2012, Rugxulo wrote: > > For more than half of those languages, there doesn't exist a (at > > least serious) DOS implementation. > > You rather have to use what is available, and that is fairly limited... > >There is easily an implementation for more than half of those, but >often it's hard to find. So you have to dig fairly hard, and sometimes >it's fairly old and doesn't work well anymore (on modern hardware, >OSes, etc.).
That's why I clearly mentioned "serious"... > > It doesn't matter for example if PHP is in the top of this popularity > > list when there is no use for that in DOS. Or JavaScript, or Haskell, > > Ruby, Python, Objective-C, C# or Java, just to name a few... > >Ruby, Python, and Objective C work in DOS (among others) thanks to >DJGPP. But apparently those aren't "true DOS enough" for you. Correct, as soon as DJGPP gets in the mix, you are just trying to emulate *ix on DOS. With an enormous overhead... > While I >sympathize, I don't know what else to tell you. You have to take what >you can get (or roll your own, which ain't easy). Correct again, and that's why I don't consider these "serious" implementations. Just because something exists, doesn't mean that it is also practically usable... > > And if there is a more or less complete DOS port, for things like > > Python, D, you still have to fight with the inherited Unix/Linux or > > Windows centric concept of a lot of those. > >Yes, it's true, most code these days is POSIX or Windows only, which >definitely complicates things. They don't care for being minimal or >compatible to things outside of that (sadly). What code are you talking about here? If you write your own, this isn't an issue. And if you are looking for existing DOS code, it isn't an issue either. Only if you try what I consider futile and start to "back port" Windows or Linux applications to DOS. I am sure that in the vast majority of cases (there might be exceptions) the result will be rather "half-a***d"... > > And how does it matter "how popular" a language is, it matters what > > you want to achieve. And then try to use the best tool for the job, > > as with everything else in life... > >Well, if you're going to port something, you need helpers, testers, >and examples, etc. If I choose Python, hypothetically, I'm probably >going to have more people helping me than if I chose Occam. But like I >said, we're low on volunteers, so it doesn't matter. FreeDOS isn't >shiny and new enough for "most" people to bother with it, sadly. First of all, why "port something" instead of developing new. In a lot of cases, proper documentation to begin with, this might not be more difficult. Or take significantly longer. And the result might be even more "rewarding" than trying to adjust source code for a different OS to the inherited limitations. And your example of choosing "Python over Occam" for anything FreeDOS based/related doesn't make sense. You will get certainly more/enough people familiar with C or Pascal, two long time used, tried and test languages... Yes, (Free)DOS isn't "shiny and new", that is by definition and that isn't necessarily a bad thing. As I mentioned in my other reply, people just need to understand strengths and weaknesses and act accordingly. And people need to start collaborating again, on a common goal. That's why for example all those wanna-be GUIs that popped up a few years ago ended up going nowhere... Ralf ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
