"""I expect I'll be trying to hunt down my copy of WinNT that's hiding somewhere in the bottom of a box..."""
NT 4.0 won't cut it. The initial version of the game is apparently heavily dependent on DirectX 8.0, but the promise of a Mac version implies that porting to non-DirectX operating systems is feasible. Here are the Civ III system requirements ( http://civ3.com/features.cfm ):
Operating System: Windows® 95/98/Me/2000
Mac® Version coming soon.
Processor: Pentium® II 300MHz
Memory: 32 MB RAM
Hard Disk Space: 400 MB free hard drive
(+50 for swapfile)
CD-ROM Drive: 4X Speed or higher
Video: DirectX® 8.0a-compatible video card* (must be able to display
1024x768x16 bit)
Sound: DirectX® 8.0a-compatible sound card*
DirectX: DirectX® version 8.0a (included) or higher
Hey, if C were appropriate for scripting, people would use it that way. Why won't these folks just let systems languages be systems languages, and scripting languages by scripting languages?
"""Spammers take away my property and happiness. Isn't that a right too?"""
It's the *pursuit* of happiness that's a right. Spammers are pursuing their happiness just as much when they fire off a million e-mails as you are when you delete those that you receive.
Now suppose you appeal to utilitarianism:
The spammer makes $1000 bucks by sending 1,000,000 e-mails (+1000 happiness points), but in the process offends 900,000 spam-ridden citizens (-900,000 happiness points). Therefore, by a utilitarian standard, the spammer is clearly in the wrong.
I can't refute such an argument, but the US Constitution is not based on utilitarian principles; if it were, the "tyranny of the majority" would be merciless. There would be the occasional positive outcome, of course: Jon Katz would be strapped to a gurney at Terre Haute.
I believe that those who advocate initiating new programming students using a low level language such as C are mistaken. The important points to get across to fledgling programmers are:
- Programming is both an intellectual pursuit and a practical one. A programmer can ascend to lofty heights of mental exercise, write a program that's actually useful, or, **at a sufficient level of understanding, do both simultaneously**.
If the curriculum concentrates exclusively on theory, the new student is likely to lose sight of the vast utility of programming; if application is overemphasized, students may never realize the potential intellectual rewards of the activity, and risk becoming bored. Neither the blinkered utilitarian nor the soaring theorist will ever achieve a balanced view of programming if he loses interest after the first class.
- The essence of software development is design, not coding. In most situations one should plan the strategy, and only after having done so apply oneself to actually writing compiler-comprehensible code. It is crucial that novice programmers learn disciplined thought processes that are independent of a particular language. Languages are the sum of syntax and libraries; problem solving the quotient of creativity and discipline.
Genius algorithms do not comprise a solution unless they're integrated in a disciplined manner. On the other hand, well integrated but clumsy algorithms ("the naive solution") will often accomplish the task correctly but not efficiently. If resource utilization is prohibitively high or the programmer wants to produce the tightest possible code as a matter of pride, optimization can be addressed at that point, but it should have little or no effect on the overall design of the system.
Dumping the mechanical details exposed by C on new programmers (especially at any pre-tertiary level of education) before they possess a high level understanding of the process of programming is tantamount to introducing first graders to the joy of reading with Shakespeare. Yes, the Bard is a supreme sculptor of the English language, which springs from the tip of his pen to peerless heights of vigor and nuance. Youngsters will benefit not at all from this spectacular show of finesse if they're unaware of why literacy is valuable, why some of us *love* to read, and they lack the basic skills required to digest written material.
Beginners should learn to read street signs, basic instructions, and simple stories with which they can personally identify. Depending on the student, this may or may not stimulate an appetite for more complex literature, but in any case basic literacy will prove useful. Advanced students of English--especially those who aspire to become professional writers--should tackle the likes of Shakespeare.
By the same token, novice programmers should be informed of several different reasons (e.g., utility, mental exercise) why people find programming rewarding. They should be assigned simple but stimulating exercises and be guided by the teacher through the basic processes of software design. Ultimately, if they aspire to become professional programmers, they should learn the nitty-gritty of the mechanical level and the subtle intricacies of the algorithmic pantheon built thereupon.
Forcing mechanical details such as pointers and strings that must be addressed directly as arrays of characters down a newbie's throat is like springing Elizabethan English and subtle symbolism on a barely literate child who can't even comprehend the instructions on a medicine bottle.
Apparently you haven't used Python, or even read the docs; modularity is one of its strongest features.
Programming in python might produce better
code, but it is enjoyable to write? Most
write-only code (ie, scripting tasks) are
tedious if you write them the "nice" way.
First of all, I use the interactive Python console to accomplish simple scripting tasks, which is a breeze. I spend so little time accomplishing my goal that I can move on to something I really enjoy in short order, such as a more challenging program.
If the task is slightly more complex, I figure out the basics on the console and then write the complete program in a module (in Python, a module is just a file of code--a "script"). When I'm done with my simple scripting task, that module lies around waiting for me to need some slice of its functionality (a function, for instance) in the future. If I do, I just 'import' it and go to town.
For more complex tasks I use OOP, which is pleasant in Python, though not as formal and featureful as in the likes of C++. For example, I've written a fairly involved network app that uses both multithreading and sockets extensively. OOP happens to match the way I think, so I consider solid support for it indispensable (before you suggest this, I was not "raised on OO" and therefore did not begin exploring the broad world of languages with a favorable bias toward it).
As for power, Python has it aplenty. The language's philosophy, though, is that extra power should be added uniformly--through the modules and class mechanisms--rather than cluttering the core language with lots of bizarre constructs.
Concurrent programs are a breeze with the threading,
there's a parser module for manipulating Python parse trees, an shlex module for concocting simple lexers right off the bat, a Numeric module for maxtrix manipulation and other scientifically oriented numeric programming, various imaging/graphics modules for graphics programming. These are just a few of the modules that I actually use. All of this, and the core language remains the best compromise of simpilicity (Lisp) and comfort I've ever used.
For most programming tasks (even complex ones), C++/Java-type languages aren't clearly superior. Bruce Eckels, author of _Thinking_in_C++_ and _Thinking_in_Java_ (thus clearly well acquainted with both), says "Python is my language of choice for virtually all my own programming projects".
Here's a blurb:
"""
The Snack Sound Toolkit is designed to be used with a scripting language such as Tcl/Tk or Python. With Snack you can create create powerful multi-platform audio applications. Snack adds commands for basic sound handling, e.g. sound card and disk I/O. Snack also has primitives for sound visualization, e.g. waveforms and spectrograms. It was developed mainly to handle digital recordings of speech, but is just as useful for general audio. Snack has also successfully been applied to other one-dimensional signals.
The combination of Snack and a scripting language makes it possible to create sound tools and applications with a minimum of effort. This is due to the rapid development nature of scripting languages. As a bonus you get an application that is cross-platform from start. It is also easy to integrate Snack based applications with existing sound analysis software.
"""
Slashdot Mirror
"""I expect I'll be trying to hunt down my copy of WinNT that's hiding somewhere in the bottom of a box..."""
NT 4.0 won't cut it. The initial version of the game is apparently heavily dependent on DirectX 8.0, but the promise of a Mac version implies that porting to non-DirectX operating systems is feasible. Here are the Civ III system requirements ( http://civ3.com/features.cfm ):
Operating System: Windows® 95/98/Me/2000
Mac® Version coming soon.
Processor: Pentium® II 300MHz
Memory: 32 MB RAM
Hard Disk Space: 400 MB free hard drive
(+50 for swapfile)
CD-ROM Drive: 4X Speed or higher
Video: DirectX® 8.0a-compatible video card* (must be able to display
1024x768x16 bit)
Sound: DirectX® 8.0a-compatible sound card*
DirectX: DirectX® version 8.0a (included) or higher
- Pike (http://pike.roxen.com/)
- EIC (http://www.kd-dev.com/~eic/)
Hey, if C were appropriate for scripting, people would use it that way. Why won't these folks just let systems languages be systems languages, and scripting languages by scripting languages?"""Spammers take away my property and happiness. Isn't that a right too?"""
It's the *pursuit* of happiness that's a right. Spammers are pursuing their happiness just as much when they fire off a million e-mails as you are when you delete those that you receive.
Now suppose you appeal to utilitarianism:
The spammer makes $1000 bucks by sending 1,000,000 e-mails (+1000 happiness points), but in the process offends 900,000 spam-ridden citizens (-900,000 happiness points). Therefore, by a utilitarian standard, the spammer is clearly in the wrong.
I can't refute such an argument, but the US Constitution is not based on utilitarian principles; if it were, the "tyranny of the majority" would be merciless. There would be the occasional positive outcome, of course: Jon Katz would be strapped to a gurney at Terre Haute.
I believe that those who advocate initiating new programming students using a low level language such as C are mistaken. The important points to get across to fledgling programmers are:
- Programming is both an intellectual pursuit and a practical one. A programmer can ascend to lofty heights of mental exercise, write a program that's actually useful, or, **at a sufficient level of understanding, do both simultaneously**.
If the curriculum concentrates exclusively on theory, the new student is likely to lose sight of the vast utility of programming; if application is overemphasized, students may never realize the potential intellectual rewards of the activity, and risk becoming bored. Neither the blinkered utilitarian nor the soaring theorist will ever achieve a balanced view of programming if he loses interest after the first class.
- The essence of software development is design, not coding. In most situations one should plan the strategy, and only after having done so apply oneself to actually writing compiler-comprehensible code. It is crucial that novice programmers learn disciplined thought processes that are independent of a particular language. Languages are the sum of syntax and libraries; problem solving the quotient of creativity and discipline.
Genius algorithms do not comprise a solution unless they're integrated in a disciplined manner. On the other hand, well integrated but clumsy algorithms ("the naive solution") will often accomplish the task correctly but not efficiently. If resource utilization is prohibitively high or the programmer wants to produce the tightest possible code as a matter of pride, optimization can be addressed at that point, but it should have little or no effect on the overall design of the system.
Dumping the mechanical details exposed by C on new programmers (especially at any pre-tertiary level of education) before they possess a high level understanding of the process of programming is tantamount to introducing first graders to the joy of reading with Shakespeare. Yes, the Bard is a supreme sculptor of the English language, which springs from the tip of his pen to peerless heights of vigor and nuance. Youngsters will benefit not at all from this spectacular show of finesse if they're unaware of why literacy is valuable, why some of us *love* to read, and they lack the basic skills required to digest written material.
Beginners should learn to read street signs, basic instructions, and simple stories with which they can personally identify. Depending on the student, this may or may not stimulate an appetite for more complex literature, but in any case basic literacy will prove useful. Advanced students of English--especially those who aspire to become professional writers--should tackle the likes of Shakespeare.
By the same token, novice programmers should be informed of several different reasons (e.g., utility, mental exercise) why people find programming rewarding. They should be assigned simple but stimulating exercises and be guided by the teacher through the basic processes of software design. Ultimately, if they aspire to become professional programmers, they should learn the nitty-gritty of the mechanical level and the subtle intricacies of the algorithmic pantheon built thereupon.
Forcing mechanical details such as pointers and strings that must be addressed directly as arrays of characters down a newbie's throat is like springing Elizabethan English and subtle symbolism on a barely literate child who can't even comprehend the instructions on a medicine bottle.
Apparently you haven't used Python, or even read the docs; modularity is one of its strongest features.
Programming in python might produce better code, but it is enjoyable to write? Most write-only code (ie, scripting tasks) are tedious if you write them the "nice" way.
First of all, I use the interactive Python console to accomplish simple scripting tasks, which is a breeze. I spend so little time accomplishing my goal that I can move on to something I really enjoy in short order, such as a more challenging program.
If the task is slightly more complex, I figure out the basics on the console and then write the complete program in a module (in Python, a module is just a file of code--a "script"). When I'm done with my simple scripting task, that module lies around waiting for me to need some slice of its functionality (a function, for instance) in the future. If I do, I just 'import' it and go to town.
For more complex tasks I use OOP, which is pleasant in Python, though not as formal and featureful as in the likes of C++. For example, I've written a fairly involved network app that uses both multithreading and sockets extensively. OOP happens to match the way I think, so I consider solid support for it indispensable (before you suggest this, I was not "raised on OO" and therefore did not begin exploring the broad world of languages with a favorable bias toward it).
As for power, Python has it aplenty. The language's philosophy, though, is that extra power should be added uniformly--through the modules and class mechanisms--rather than cluttering the core language with lots of bizarre constructs.
Concurrent programs are a breeze with the threading, there's a parser module for manipulating Python parse trees, an shlex module for concocting simple lexers right off the bat, a Numeric module for maxtrix manipulation and other scientifically oriented numeric programming, various imaging/graphics modules for graphics programming. These are just a few of the modules that I actually use. All of this, and the core language remains the best compromise of simpilicity (Lisp) and comfort I've ever used.
For most programming tasks (even complex ones), C++/Java-type languages aren't clearly superior. Bruce Eckels, author of _Thinking_in_C++_ and _Thinking_in_Java_ (thus clearly well acquainted with both), says "Python is my language of choice for virtually all my own programming projects".
Python ( http://python.org/ )
+ Qt ( http://www.thekompany.com/projects/pykde/ )
+ Firebird ( http://firebird.sourceforge.net/ )
+ gvib ( http://www.zope.org/Members/RETierney/gvibDA )
=
A delicious cross-platform substitute for my obese friend Swing.
---
"Perl is worse than Python because people
wanted it worse." - Larry Wall, 14 Oct 1998
Snack: http://www.speech.kth.se/snack/
Here's a blurb:
"""
The Snack Sound Toolkit is designed to be used with a scripting language such as Tcl/Tk or Python. With Snack you can create create powerful multi-platform audio applications. Snack adds commands for basic sound handling, e.g. sound card and disk I/O. Snack also has primitives for sound visualization, e.g. waveforms and spectrograms. It was developed mainly to handle digital recordings of speech, but is just as useful for general audio. Snack has also successfully been applied to other one-dimensional signals.
The combination of Snack and a scripting language makes it possible to create sound tools and applications with a minimum of effort. This is due to the rapid development nature of scripting languages. As a bonus you get an application that is cross-platform from start. It is also easy to integrate Snack based applications with existing sound analysis software.
"""