"For example, types seem to be an inexhaustible source of research papers, despite the fact that static typing seems to preclude true macros-- without which, in my opinion, no language is worth using."
This bold statement is not only wrong (cf. Peyton Jones' latest work on macros in Haskell), but also misleading. Let's start off with some opinion: In my opinion, no language without static typing is worth using. The reason is simple: Because I am human. I make mistakes. And I don't want to spend the rest of my life writing test suites to check for errors which even trivial type systems can detect.
I agree with one thing: Languages will become simpler on a mathematical level. Anyone who has used ML or Haskell will have noticed how much easier these are to understand in comparison to any imperative language out there (and, by the way, in Haskell, Strings are lists of characters). But, at the same time, I truly hope that mechanisms for proving properties about programs will become not only more powerful, but also more widespread. I would like to have static verifications of my pre- and postconditions. I would like to verify that the result of my 'sort' function returns a permutation of its input for which each element is less than or equal to its successor. These are the things I'm looking forward to seeing in the future.
Well, someone mentioned ML earlier, but to summarize: Proving your programs correct-- or at least "mostly" correct (it's hard to prove that you have applied a function of type 'int -> int' exactly the right amount of times if you can't specify what that is) has helped a lot. Anyone who has used ML or Haskell for anything serious will probably be able to attest to how hard it is to have bugs in these, when compared to weakly typed or dynamically typed languages like C, C++, Perl, Python, Java. Haskell even typechecks for side effects (and has second-order types, or "type classes", which SML/NJ is lacking), which helps even more.
The advantage of type systems is that it is, in general, easy for programmers to figure out what kinds of things they expect ("This will be a name/int tuple... the next is either a function from int to int to int or nothing..."), and reasonably easy for compilers to infer the rest (so you can annotate your code and the compiler figures out where you're wrong-- and if you don't annotate, it'll still be able to figure out that you're wrong, just not quite as precisely where). I've now arrived at the conclusion that a programming language is worth using (as opposed to investigating) if and only if it does static type checking (with parametric types); that's just my opinion, of course.
Other advances have been in garbage collection (not having to worry about freeing your memory, manually keeping refcounts etc. is a major time-saver, prevents memory leaks, and keeps your code cleaner and more readable) and formal software engineering (e.g. done in VeriFun, this allows you to formally verify that, given the semantics of your program, a certain statement holds-- while Hoare triples (as used e.g. in Eiffel) are somewhat useful, they're not quite as powerful as this.
So, if you want to write good software:
Use statically typed systems
Use garbage collection
Formally prove your programs correct
You can, of course, do the latter by hand if you don't have verification tools (or don't have them for your language of choice). The big problem with these things is that, while they tend to lead to excellent, readable and reusable code, they're harder to do than quick perl hacks which work 99% of the time and can be done by J. Random Hacker; also, you won't find many good ML or Haskell programmers-- mostly for reasons of legacy and popularism, I guess.
For reference, I rarely do the three things above. Formal correctness proofs are non-trivial, and the problem with statically typed languages is that it's (a) hard to find good libraries for them, because (b) very few other people use them (usual chicken-and-egg problem, I guess) and (c) most of my own legacy code is in those weakly typed languages, so I'd have to re-implement big chunks of code. If we're lucky, we'll one day see C and C++ and Java and Python and Perl die out, and everyone will start using statically typed languages, formally have their programs verified etc. If it happens, it'll be years away, but I believe that it's worth working towards this goal.
Think like a computer scientist?
on
Think Python
·
· Score: 1
Reverse-engineering is the 'straightforward' path. The problem with this is that it raises copyright problems; if LucasArts cared, they might try to sue them (the Win32 only NAGI interpreter has the same problem).
The FreeSCI project (and, for the most part, Sarien) have chosen the more painful path of a clean-room reimplementation for this reason: One group does the decoding and documents everything, the other group implements (and, occasionally, guesses). IANAL, but as far as I know, this is perfectly legal.
(OK, reverse engineering for interoperability purposes is legal anyway, but not in some foreign countries like the US).
The last CVS snapshots I tried actually compiled a lot of C++ stuff without internal compiler errors, and the number of
unexplainable segfaults (random jumps in the generated code) shrank a bit, too. This was two months ago; I, too, hope
they finally fixed gcc to be a valid competitor to Compaq's proprietary compilers.
Right now, it's practically impossible to compile Mozilla or KDE for Alpha, unless you spend a week working around the
quirks with cxx. I truly hope the gcc guys fixed this; I don't see any reason to upgrade if they haven't (slightly less
broken is still broken).
a) If you generate the code, you will always have to keep track of your blanks.
While this certainly is good practice for debugability, it's not pleasant as a requirement.
b) If you move control blocks horizontally (e.g. after removing a preceeding conditional), your editor (EMACS with python-mode for me) may introduce subtle errors when re-tabbing.
Sure, I'd write my code with similar indentation if it wasn't enforced anyway, but I prefer not being forced to do things unless really neccessary.
But one of Python's features is that you can use it as an embedded scripting language. However, 1.6.0 and 2.*, not being compatible with the GPL, can't be used for embedding on GPL projects, so people will have to continue using 1.5.2.
Well, that's nice and all, but we still need a way to get rid of the ia32 architecture if we truly want to have a choice. What we'd really need would be some sort of cross-assembler, so that we'd finally be able to move on to PPC, Alpha, or UltraSparc.
I beg to differ. I have yet to see/any/ nVidia drivers working on Alpha/Linux, perhaps excluding the utah-glx drivers for some of their more ancient cards.
A few hackers (among them Christopher Chimelis and Ron Farrer, well known for a lot of other work on the Alpha) have started porting it to the Alpha architecture. Have a look at the
sourceforge site.
Actually, there's a chance this might work, but it will require the proper backend to be installed first. Also, it's quite probable that this problem is directly related to the backend, i.e. it will generate an internal compiler error on ia32, too (note that the Alpha backend is quite probably written by people who know how to keep code 64 bit clean).
Still, it's a good idea. moc and ld probably won't play nicely here, but I only need it to build a few object files anyway, linking can be done later.
While it's definitely nice to see KDE progressing, I still can't get Qt to compile on the Alpha (internal compiler error). Turning off optimization helps, but this is definitely sub-optimal; I guess that's why there are no debian packages for it yet.
The right solution, of course, would be to fix gcc. Unfortunately, the next official gcc release is still a few months away (AFAIK), so it would have to be compiled against a (possibly patched) snapshot. Can't see a binary like this going into debian, especially since gcc development snapshots don't neccessarily produce efficient (or even working) code.
Does anyone see a way out of this dilemma, except for sitting in the corner and continuing to whine?
Apparently, many people would prefer good closed/proprietary drivers over mediocre free ones. What they don't appear to realize is that this leaves us stuck in square one.
The reason most of the people who're using Linux today are using it is that it does certain things better than their old OS did. Now, what happens when there's a new OS that's even better for their kind of work? Think about BSD, or the Hurd, they're even free software. Maybe you can construct a compatibility layer to run those drivers, but compatibility layers are evil.
Even worse, consider switching to a different hardware platform. No one's disputing that ia32 is the worst major hardware platform currently available, and the only reason everybody's using it is/binary compatibility/. You can't easily make the switch to PPC or the Alpha, not just because they're more expensive (guess why), but also because they don't support your funky nVidia GeForce2, and probably never will. Of course, hardware support on these platforms is pretty poor even among free software drivers (has anybody had success with utah-glx for mga on the Alpha? Keeps killing my X server), but there's at least a chance that something will happen: You can either fix it yourself, or pay someone to do it for you; you're no longer at the mercy of some high-ups in some company on a continent on the other side of the planet.
And that's what free software is about: Independence. Don't let yourself be fooled by bread and games!
Looks like they assume linux=ia32/linux... Is there any support for other platforms, like ppc or the alpha? Of course, the generated code would either be very slow or not do exactly the same as the original code on the alpha, since the popular WORD/INTEGER 16 bit values just don't work nicely on a well-designed RISC architecture. Too bad. I was hoping to port some of my older programs, but it looks like Turbo Pascal code is still not sufficiently portable.
While it's nice to see that Real is finally doing some work to support Linux, it's disappointing (though not surprising) to see that they only support ia32/Linux. Also, they stopped supporting the Xlib command line functions, i.e. you can't set the geometry from the command line anymore. This is extremely annoying, as it considerably increases the amount of manual work neccessary to view movies fullscreened.
During software development, it usually appears to be easy enough to keep your code portable across architectures, as long as you don't risk mis-aligned memory access, don't use binary files excessively, and remember to test on different architectures. I guess that things are a lot different if you have to deal with code that wasn't written with the explicit idea of being portable in the first place. How much extra effort was it to do the Alpha port of CTP? Do you think it was worth it? Will Loki continue to support Alpha and PPC architectures?
I'm aware of the fact that adventure games and RPGs have significantly decreased in importance since the computer gaming market has started to address more than just the hackers and puzzlers among us. What is your opinion on the future of these genres? It has been rumored that Loki is porting an RPG; when can we expect details to be published?
AFAIK, there are three free work-in progress players (LAGII and Sarien for AGI and FreeSCI for SCI). BTW: Does anyone have an idea of whether LAGII or Sarien performs better?
If you look at the numbers, you'll notice that the poll was reset. This means that about 2000 linux votes were lost (vs. about 400 MacOS votes). This is going to be interesting:-)
'net polls have never had any statistical value. If the Sierra executives actually believe that they can read anything out of the results of this one, then they'll get what they deserve- A whole new market and thousands of happy Linux gamers. Er. Well, maybe that's not what they'd deserve.
Slashdot Mirror
"For example, types seem to be an inexhaustible source of research papers, despite the fact that static typing seems to preclude true macros-- without which, in my opinion, no language is worth using."
This bold statement is not only wrong (cf. Peyton Jones' latest work on macros in Haskell), but also misleading. Let's start off with some opinion: In my opinion, no language without static typing is worth using. The reason is simple: Because I am human. I make mistakes. And I don't want to spend the rest of my life writing test suites to check for errors which even trivial type systems can detect.
I agree with one thing: Languages will become simpler on a mathematical level. Anyone who has used ML or Haskell will have noticed how much easier these are to understand in comparison to any imperative language out there (and, by the way, in Haskell, Strings are lists of characters). But, at the same time, I truly hope that mechanisms for proving properties about programs will become not only more powerful, but also more widespread. I would like to have static verifications of my pre- and postconditions. I would like to verify that the result of my 'sort' function returns a permutation of its input for which each element is less than or equal to its successor. These are the things I'm looking forward to seeing in the future.
The advantage of type systems is that it is, in general, easy for programmers to figure out what kinds of things they expect ("This will be a name/int tuple... the next is either a function from int to int to int or nothing..."), and reasonably easy for compilers to infer the rest (so you can annotate your code and the compiler figures out where you're wrong-- and if you don't annotate, it'll still be able to figure out that you're wrong, just not quite as precisely where). I've now arrived at the conclusion that a programming language is worth using (as opposed to investigating) if and only if it does static type checking (with parametric types); that's just my opinion, of course.
Other advances have been in garbage collection (not having to worry about freeing your memory, manually keeping refcounts etc. is a major time-saver, prevents memory leaks, and keeps your code cleaner and more readable) and formal software engineering (e.g. done in VeriFun,
this allows you to formally verify that, given the semantics of your program, a certain statement holds-- while Hoare triples (as used e.g. in Eiffel) are somewhat useful, they're not quite as powerful as this.
So, if you want to write good software:
You can, of course, do the latter by hand if you don't have verification tools (or don't have them for your language of choice). The big problem with these things is that, while they tend to lead to excellent, readable and reusable code, they're harder to do than quick perl hacks which work 99% of the time and can be done by J. Random Hacker; also, you won't find many good ML or Haskell programmers-- mostly for reasons of legacy and popularism, I guess.
For reference, I rarely do the three things above. Formal correctness proofs are non-trivial, and the problem with statically typed languages is that it's (a) hard to find good libraries for them, because (b) very few other people use them (usual chicken-and-egg problem, I guess) and (c) most of my own legacy code is in those weakly typed languages, so I'd have to re-implement big chunks of code. If we're lucky, we'll one day see C and C++ and Java and Python and Perl die out, and everyone will start using statically typed languages, formally have their programs verified etc. If it happens, it'll be years away, but I believe that it's worth working towards this goal.
Try Haskell instead. Or, perhaps, SML/O'CAML.
Reverse-engineering is the 'straightforward' path. The problem with this is that it raises copyright problems; if LucasArts cared, they might try to sue them (the Win32 only NAGI interpreter has the same problem).
The FreeSCI project (and, for the most part, Sarien) have chosen the more painful path of a clean-room reimplementation for this reason: One group does the decoding and documents everything, the other group implements (and, occasionally, guesses). IANAL, but as far as I know, this is perfectly legal.
(OK, reverse engineering for interoperability purposes is legal anyway, but not in some foreign countries like the US).
The last CVS snapshots I tried actually compiled a lot of C++ stuff without internal compiler errors, and the number of unexplainable segfaults (random jumps in the generated code) shrank a bit, too. This was two months ago; I, too, hope they finally fixed gcc to be a valid competitor to Compaq's proprietary compilers. Right now, it's practically impossible to compile Mozilla or KDE for Alpha, unless you spend a week working around the quirks with cxx. I truly hope the gcc guys fixed this; I don't see any reason to upgrade if they haven't (slightly less broken is still broken).
There are two problems related to this, though:
a) If you generate the code, you will always have to keep track of your blanks.
While this certainly is good practice for debugability, it's not pleasant as a requirement.
b) If you move control blocks horizontally (e.g. after removing a preceeding conditional), your editor (EMACS with python-mode for me) may introduce subtle errors when re-tabbing.
Sure, I'd write my code with similar indentation if it wasn't enforced anyway, but I prefer not being forced to do things unless really neccessary.
But one of Python's features is that you can use it as an embedded scripting language. However, 1.6.0 and 2.*, not being compatible with the GPL, can't be used for embedding on GPL projects, so people will have to continue using 1.5.2.
What is being done to resolve the current licensing dispute between the FSF and CRNI?
Well, that's nice and all, but we still need a way to get rid of the ia32 architecture if we truly want to have a choice. What we'd really need would be some sort of cross-assembler, so that we'd finally be able to move on to PPC, Alpha, or UltraSparc.
Uh, sorry; that one was intended as a reply to the reply which is now above it :->
I beg to differ. I have yet to see /any/ nVidia drivers working on Alpha/Linux, perhaps excluding the utah-glx drivers for some of their more ancient cards.
A few hackers (among them Christopher Chimelis and Ron Farrer, well known for a lot of other work on the Alpha) have started porting it to the Alpha architecture. Have a look at the sourceforge site.
Actually, there's a chance this might work, but it will require the proper backend to be installed first. Also, it's quite probable that this problem is directly related to the backend, i.e. it will generate an internal compiler error on ia32, too (note that the Alpha backend is quite probably written by people who know how to keep code 64 bit clean).
Still, it's a good idea. moc and ld probably won't play nicely here, but I only need it to build a few object files anyway, linking can be done later.
While it's definitely nice to see KDE progressing, I still can't get Qt to compile on the Alpha (internal compiler error). Turning off optimization helps, but this is definitely sub-optimal; I guess that's why there are no debian packages for it yet.
The right solution, of course, would be to fix gcc. Unfortunately, the next official gcc release is still a few months away (AFAIK), so it would have to be compiled against a (possibly patched) snapshot. Can't see a binary like this going into debian, especially since gcc development snapshots don't neccessarily produce efficient (or even working) code.
Does anyone see a way out of this dilemma, except for sitting in the corner and continuing to whine?
Apparently, many people would prefer good closed/proprietary drivers over mediocre free ones. What they don't appear to realize is that this leaves us stuck in square one.
/binary compatibility/. You can't easily make the switch to PPC or the Alpha, not just because they're more expensive (guess why), but also because they don't support your funky nVidia GeForce2, and probably never will.
The reason most of the people who're using Linux today are using it is that it does certain things better than their old OS did. Now, what happens when there's a new OS that's even better for their kind of work? Think about BSD, or the Hurd, they're even free software. Maybe you can construct a compatibility layer to run those drivers, but compatibility layers are evil.
Even worse, consider switching to a different hardware platform. No one's disputing that ia32 is the worst major hardware platform currently available, and the only reason everybody's using it is
Of course, hardware support on these platforms is pretty poor even among free software drivers (has anybody had success with utah-glx for mga on the Alpha? Keeps killing my X server), but there's at least a chance that something will happen: You can either fix it yourself, or pay someone to do it for you; you're no longer at the mercy of some high-ups in some company on a continent on the other side of the planet.
And that's what free software is about: Independence. Don't let yourself be fooled by bread and games!
Looks like they assume linux=ia32/linux... Is there any support for other platforms, like ppc or the alpha? Of course, the generated code would either be very slow or not do exactly the same as the original code on the alpha, since the popular WORD/INTEGER 16 bit values just don't work nicely on a well-designed RISC architecture.
Too bad. I was hoping to port some of my older programs, but it looks like Turbo Pascal code is still not sufficiently portable.
While it's nice to see that Real is finally doing some work to support Linux, it's disappointing (though not surprising) to see that they only support ia32/Linux. Also, they stopped supporting the Xlib command line functions, i.e. you can't set the geometry from the command line anymore. This is extremely annoying, as it considerably increases the amount of manual work neccessary to view movies fullscreened.
During software development, it usually appears to be easy enough to keep your code portable across architectures, as long as you don't risk mis-aligned memory access, don't use binary files excessively, and remember to test on different architectures.
I guess that things are a lot different if you have to deal with code that wasn't written with the explicit idea of being portable in the first place. How much extra effort was it to do the Alpha port of CTP? Do you think it was worth it? Will Loki continue to support Alpha and PPC architectures?
I'm aware of the fact that adventure games and RPGs have significantly decreased in importance since the computer gaming market has started to address more than just the hackers and puzzlers among us. What is your opinion on the future of these genres?
It has been rumored that Loki is porting an RPG; when can we expect details to be published?
As far as I know, KDE 2.0 is supposed to have such a tool. I've only seen screenshots of it, though; can anyone else elaborate on that tool's quality?
AFAIK, there are three free work-in progress players (LAGII and Sarien for AGI and FreeSCI for SCI).
BTW: Does anyone have an idea of whether LAGII or Sarien performs better?
If you look at the numbers, you'll notice that the poll was reset. This means that about 2000 linux votes were lost (vs. about 400 MacOS votes). :-)
This is going to be interesting
'net polls have never had any statistical value.
If the Sierra executives actually believe that they can read anything out of the results of this one, then they'll get what they deserve- A whole new market and thousands of happy Linux gamers.
Er. Well, maybe that's not what they'd deserve.