Most of the slowness people usually associate with Java is in the JVM startup time. Once it's been started, even on a slow machine like a P2, Java will fly along nicely.
Larger apps written in Java are still more memory-hungry than their C++ equivalents, so you shouldn't try running these sort of things on older machines with less than 128Megs or so, but I wouldn't expect larger C++ apps to run very well on machines with such limited memory either.
I hope "personal computing" means "consoles" in this context, because PC gaming is a small fry compared to consoles and would have little effect on arcades.
You've actually hit on absolutely the worst aspect of this book here. The coverage of console games is abysmal. You'd have thought that the PSX, the machine that's sold more games to more people than any other, would get more than a few column inches in a book like this, or that games companies like Sega and Nintendo would warrant pages upon pages about their history and games, but no...
Instead there are chapters upon boring chapters about almost exclusively American PC game companies. So not only are console games given short shrift, but Japanese and European companies are almost completely left out in the cold. Most of the stuff about more recent consoles consists solely of a few screenshots stuffed at the back of the book, and a meagre few paragraphs about how the PS2 is the future of gaming, or some such...
If you want a book about the history of American PC games, then I guess you'll love this book. It's a detailed, and very readable, history. But if you're a console gamer (especially someone who's only really started gaming in the '90s), then you'll find the majority of this book to be rather boring and irrelevant.
Re:Lisp is great. Where is Lisp?
on
Bitter Java
·
· Score: 1
> Today we are living in the time of XML. But most > of popular XML applications are written on Java, > Python and even Perl - but not on Lisp. Why?
Because Lisp has S-Expressions, which are every bit as powerful as XML and then some, not to mention considerably less verbose. XML is a totally braindead technology in the eyes of most Lisp programmers, and of limited usefulness to them, except perhaps to inter-operate with systems that use it.
I've yet to see an XML application that comes close to fulfilling all the hype, let alone one that comes close to achieving everything that's possible with Common Lisp.
It has nothing whatsoever to do with Lisp dialects.
Re:I'll switch to Emacs when I can fold text with
on
GNU Emacs 21
·
· Score: 1
I recently wrote a module for Emacs that does most of what you ask for, basically the hiding and showing of lines based on a particular regexp.
If you've really only been programming in Lisp for a week or so then you really haven't had time enough to appreciate what its strengths and weaknesses are. It sounds to me as though you have acquired a disease that is all too common amongst programmers - the desire to want to specialise in one language too early on.
I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.
By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.
FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.
Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.
If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp?.
And when you're done with Lisp, I'd recommend a look at Ocaml, SML, Ruby and Smalltalk (particularly the delightful Squeak)!
Efficiency, Power and Stability all sound like good attributes for commercial software to me. You're right that it's probably not the best language for systems programming though.
> the premise that because Lisp performs better it
> is a viable alternative to either language is
> flawed. Performance is not usually a factor in
> most development
This is not the only premise, as you go on to point out. I agree that it's probably the least relevant premise, but the fact that Lisp offers an improvement in programmer productivity means that getting a performance increase into the bargain is a win win situation.
> Lisp is a functional language
It is not. Functional programming is just one of the paradigms supported by Common Lisp. You can also write procedural and/or object-oriented programs if you like. In fact, Common Lisp was actually the *first* programming language to have an ANSI standard object system (CLOS).
> No doubt that Lisp is one of the great
> programming languages of all time. But still it
> wasn't designed for systems programming and
> commercial software development.
Don't be silly. This is *exactly* what Common Lisp was designed for. Have you actually *looked* at a commercial Common Lisp implementation? Perhaps you are thinking Lisp is restricted only Scheme?
> LISP and to a lesser extent Smalltalk are power
> tools. If you're good and smart, you'll write
> something which is really beautiful, elegant and
> fast. But most people aren't that good, and they
> produce crap.
What a completely absurd statement. I've seen poorly written Lisp code that would have been hard to maintain, and I've seen an awful lot of unmaintainable Java code, but to say that Smalltalk is a 'power users only' language is the exact opposite of the truth. It was designed from scratch to be easy for beginners to use and understand
> And crap in Java is still more maintainable (I
> should know, I'm untangling a 700+ class ball of
> spaghetti as we speak) than crap in LISP or
> Smalltalk.
Utter, utter nonsense. You might have untangled reams and reams of Java code for all I care, but asserting that it is easier to untangle than either Lisp or Smalltalk merely indicates to me your ignorance of both languages.
> The fact that MIT and Berkeley (I think) and
> other schools with great CS programs start with
> Scheme illustrates the point -- it's not for
> well... the dumbass in the other cube.
Neither is Java for that matter. There may be fewer traps with Java than with, say, C++, but they still exist. I'd rather fire the dumbass in the next cube than have him write crap code in *any* language... And the reason Scheme is taught at any school is because, once again, it's designed from scratch to be an easy to learn language. This allows the teacher to concentrate on the *real* issues instead of having to teach students how to overcome idiotic language limitations.
In the days of the 8-bit machines, home development was almost as common as machine ownership, because most of the machines came with BASIC on ROM. The likes of the Amiga had cheap BASIC-derived environments like AMOS. These days, the only way a young Windows user can get their paws dirty writing software for their machine is by pirating software... What fourteen year old, after having forked out $1000+ for a machine already can possibly afford another $1000 or so for development tools?
As the article suggests, the low-end segment of the developer market is an important one - any platform needs to convince people to start programming for it at some point - the only way this can be made possible for a Windows user is by pirating.
I wouldn't be surprised if MS deliberately turns a blind eye to High School/College students who pirate the likes of VB and Developer's Studio - after all, the more people who become familiar with these tools, the more people who are going to be programming for Windows.
So the contention that the price of all that Windows software prohibits people from becoming MS junkies is a false one. Perhaps honest businesses can afford it, and these are the people MS really has to convince to pay, but right at that crucial low-end, software can be just as free as it is on Linux
Slashdot Mirror
Most of the slowness people usually associate with Java is in the JVM startup time. Once it's been started, even on a slow machine like a P2, Java will fly along nicely.
Larger apps written in Java are still more memory-hungry than their C++ equivalents, so you shouldn't try running these sort of things on older machines with less than 128Megs or so, but I wouldn't expect larger C++ apps to run very well on machines with such limited memory either.
Because of course the BBC are a completely unbiased, reliable organisation who never make ludicrous claims about anything, ever.
Right.
I hope "personal computing" means "consoles" in this context, because PC gaming is a small fry compared to consoles and would have little effect on arcades.
You've actually hit on absolutely the worst aspect of this book here. The coverage of console games is abysmal. You'd have thought that the PSX, the machine that's sold more games to more people than any other, would get more than a few column inches in a book like this, or that games companies like Sega and Nintendo would warrant pages upon pages about their history and games, but no...
Instead there are chapters upon boring chapters about almost exclusively American PC game companies. So not only are console games given short shrift, but Japanese and European companies are almost completely left out in the cold. Most of the stuff about more recent consoles consists solely of a few screenshots stuffed at the back of the book, and a meagre few paragraphs about how the PS2 is the future of gaming, or some such...
If you want a book about the history of American PC games, then I guess you'll love this book. It's a detailed, and very readable, history. But if you're a console gamer (especially someone who's only really started gaming in the '90s), then you'll find the majority of this book to be rather boring and irrelevant.
> Today we are living in the time of XML. But most
> of popular XML applications are written on Java,
> Python and even Perl - but not on Lisp. Why?
Because Lisp has S-Expressions, which are every bit
as powerful as XML and then some, not to mention
considerably less verbose. XML is a totally
braindead technology in the eyes of most Lisp
programmers, and of limited usefulness to them,
except perhaps to inter-operate with systems that use it.
I've yet to see an XML application that comes close
to fulfilling all the hype, let alone one that
comes close to achieving everything that's possible
with Common Lisp.
It has nothing whatsoever to do with Lisp dialects.
I recently wrote a module for Emacs that does most of what you ask for, basically the hiding and showing of lines based on a particular regexp.
Find it at my web site.
If you've really only been programming in Lisp for a week or so then you really haven't had time enough to appreciate what its strengths and weaknesses are. It sounds to me as though you have acquired a disease that is all too common amongst programmers - the desire to want to specialise in one language too early on.
I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.
By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.
FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.
Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.
If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp?.
And when you're done with Lisp, I'd recommend a look at Ocaml, SML, Ruby and Smalltalk (particularly the delightful Squeak)!
> http://www.math.uio.no/cltl/clm/node6.html
Efficiency, Power and Stability all sound like good attributes for commercial software to me. You're right that it's probably not the best language for systems programming though.
> the premise that because Lisp performs better it
> is a viable alternative to either language is
> flawed. Performance is not usually a factor in
> most development
This is not the only premise, as you go on to point out. I agree that it's probably the least relevant premise, but the fact that Lisp offers an improvement in programmer productivity means that getting a performance increase into the bargain is a win win situation.
> Lisp is a functional language
It is not. Functional programming is just one of the paradigms supported by Common Lisp. You can also write procedural and/or object-oriented programs if you like. In fact, Common Lisp was actually the *first* programming language to have an ANSI standard object system (CLOS).
> No doubt that Lisp is one of the great
> programming languages of all time. But still it
> wasn't designed for systems programming and
> commercial software development.
Don't be silly. This is *exactly* what Common Lisp was designed for. Have you actually *looked* at a commercial Common Lisp implementation? Perhaps you are thinking Lisp is restricted only Scheme?
> LISP and to a lesser extent Smalltalk are power
> tools. If you're good and smart, you'll write
> something which is really beautiful, elegant and
> fast. But most people aren't that good, and they
> produce crap.
What a completely absurd statement. I've seen poorly written Lisp code that would have been hard to maintain, and I've seen an awful lot of unmaintainable Java code, but to say that Smalltalk is a 'power users only' language is the exact opposite of the truth. It was designed from scratch to be easy for beginners to use and understand
> And crap in Java is still more maintainable (I
> should know, I'm untangling a 700+ class ball of
> spaghetti as we speak) than crap in LISP or
> Smalltalk.
Utter, utter nonsense. You might have untangled reams and reams of Java code for all I care, but asserting that it is easier to untangle than either Lisp or Smalltalk merely indicates to me your ignorance of both languages.
> The fact that MIT and Berkeley (I think) and
> other schools with great CS programs start with
> Scheme illustrates the point -- it's not for
> well... the dumbass in the other cube.
Neither is Java for that matter. There may be fewer traps with Java than with, say, C++, but they still exist. I'd rather fire the dumbass in the next cube than have him write crap code in *any* language... And the reason Scheme is taught at any school is because, once again, it's designed from scratch to be an easy to learn language. This allows the teacher to concentrate on the *real* issues instead of having to teach students how to overcome idiotic language limitations.
In the days of the 8-bit machines, home development was almost as common as machine ownership, because most of the machines came with BASIC on ROM. The likes of the Amiga had cheap BASIC-derived environments like AMOS. These days, the only way a young Windows user can get their paws dirty writing software for their machine is by pirating software... What fourteen year old, after having forked out $1000+ for a machine already can possibly afford another $1000 or so for development tools?
As the article suggests, the low-end segment of the developer market is an important one - any platform needs to convince people to start programming for it at some point - the only way this can be made possible for a Windows user is by pirating.
I wouldn't be surprised if MS deliberately turns a blind eye to High School/College students who pirate the likes of VB and Developer's Studio - after all, the more people who become familiar with these tools, the more people who are going to be programming for Windows.
So the contention that the price of all that Windows software prohibits people from becoming MS junkies is a false one. Perhaps honest businesses can afford it, and these are the people MS really has to convince to pay, but right at that crucial low-end, software can be just as free as it is on Linux