The single common denominator I've seen so far is that all Windows users switching to Linux, expect Linux to _BE_ Windows. They want to right-click on the desktop and get "Properties", and they want a "Start->Run" paradigm. They try to "de-configure" the Linux machine to live and breathe like their previous Windows environment, instead of learning why Linux _EXCELS_ past Windows, and exceeds where Windows fails, they just want Windows.. on Linux.
Isn't this what the prior poster meant when he said "... don't understand or are against change."?
Maybe we can live the unsavory aspects of life vicariously through robots. For example, we could let robots have wars and kill each other--not just on Battlebots, but in Afghanistan and anywhere else the U.S. stages its wars.
I'm afraid that this is too optimistic. Competition and strife are part of all life. To exemplify this, what would occur if your robot warriors lost and you didn't want to abide by the terms of the winners? Violence is always going to be part of war, alongside politics and propaganda.
Better yet, employ robots in menial manufacturing jobs so that humans can reach some semblance of equality. Just a thought, but flame away.
Indeed, this sounds like a very good idea, but without menial jobs, where will people who don't have skills work? There will always be people who, for one reason or another, do not have any skills which transcend the "menial" labors your refer to. Barring that, what about lazy people who don't want to develop skills - do they get a free ride at the cost of resources? Unskilled work is necessary to provide a semblance of equality, otherwise the contrast will become even more pronounced between skilled laborers and the unqualified.
The best solution is to augment (rather than replace) aspects of life which can be augmented with technology and make progress.
I don't have a lot of money to spend on CDs, and even if I did, purchasing music which you haven't heard is a total shot in the dark. In the past, I would hear music my friends listened to and buy CDs from the artists I liked, if I had the money to do so. With the advent of the big P2P networks, I was able to check out a much wider variety of music, though I still only bought what I could afford. When I was exposed to so much music which I liked, I found myself making greater allowances in my budget for music - though you would be correct in the assertion that I downloaded much more than I paid for. I purchased what I found to be most interesting, rewarding the musicians which I felt deserved it most - many of whom I would never have heard if I had continued learning about new music through my peers. I now spend more money on music than I ever have in the past, though I listen to more music than I could afford to purchase - and at the same time, I have diversified my cultural input by stepping outside of the clicques my friend have ordered themselves into.
Who is this hurting? Musicians whose music I don't like who were relying on name recognition for shot-in-the-dark sales.
How is this good? It helps create a more evolving music market which can function via natural selection (ie, survival of the fittest) rather than survival of the best-funded (advertised).
I spend more money on music now than I did before, nobody is losing sales to me - I can't buy any more music than I do.
Comcast reassured customers Wednesday that the information had been stored only temporarily, was purged automatically every few days and "has never been connected to individual subscribers." But it said it will stop recording the information, anyway.
Funny how it doesn't say anything about not being transferred or duplicated. Of course, "individual subscribers" is not the same thing as "subscriber clusters" or "market groups"... what's the granularity they did use?
He said that while the company was recording details about customer Web browsing, it did not use the information to build profiles of online consumer behavior.
Of course not, there are other companys who do that for you!
"Comcast absolutely does not share personal information about our customers, and we have the utmost respect for our customers' privacy," Watson said.
He doesn't say that they don't sell it, or for that matter, what they do use it for.
Either way, the info they collected before they stopped was very likely sold, and it was worth a lot of money. This would be a handy trick to swap some PR for some quick cash if the need arose.
Hmmm... I don't recall having replied to a post that said Java or VB were dead and obsolete languages, just Lisp.
I suppose that next time someone tells me that they think William Shatner's acting stinks I should retort with "My car acts funny sometimes" or something similarly tangential to the discussion.
Here's a categorized list of companies successfully using Allegro Common
Lisp, along with a couple examples from each; follow the links for
more companies and more information:
I am a Lisp developer, and I'm proud to point out that Common Lisp does these tricks, specifically my favourite implementation - Allegro Common Lisp employs all of these features and more.
Please take a look at information available on www.franz.com, and email with any questions you might have.
Oh, and by the way - here are some success stories from a variety of people who have used AllegroCL for their projects (NASA, Microsoft, Square USA, etc.)
If that's your goal, and you don't mind hacking the kernel a bit to accomplish the trick - why not use the ATX soft power? It wouldn't require a specialized debugging isa card, just an ATX board and power supply.
Perhaps I'm in the minority, but I read the comments to get info from the comments themselves, and I don't often want to bother with digging into all the links that say "more info here".
Of course, you're welcome to post a link to www.franz.com as you like.
I'm a Lisp programmer (Allegro CL mostly), so naturally I would like to see more books covering Lisp. I'd specifically like to see the following topics covered:
Network programming with Lisp for a wider variety of protocols
Advanced tuning with foreign functions/mixed language programming
Graphics and OpenGL programming with Lisp
Sound programming with Lisp
Game programming with Lisp
Databases in Lisp
I'd really like to find more practical Lisp examples on bookstore shelves.
Oh, and before I hear "Lisp can't do that", here's a short list of Lisp success stories:
Honestly? I still don't know, I haven't really heard it from the horse's mouth, so to speak. All I know is that he's got a problem with us, but to say I know why he feels that way would be a bit presumptuous.
So. Where's the racist act? In saying the word, or in differentiating between the speaker?
Simple. The racist act is ignoring the intent with which it was spoken in favor of observing that ethnicity is a factor involved in the conversation. Ignore race to end racism, don't attempt to compensate for it by analyzing it.
Since I'm a Lisp fiend: while we're on the subject of programming for bioinformatics, I'd like to point out that Allegro Common Lisp has been used by a few folks in the field. Here are two links:
If an ISP has unlimited access which it is calculating on the basis of an average SINGLE user with a SINGLE machine, and it states it clearly in its contract that you are paying for a single-user/single-machine, then anyone putting more than that on their link is in breach of their contract. They have calculated their prices based on their assumption. Of course you may think -and might even be right- that their prices are too high, but does that morally allow you to be in breach of contract? In the same way, we all feel that MS-whatever licenses are way too high, but are we morally allowed therefore to install each program on 10 machines (certainly not legally).
Their assumption is going to be incorrect.
Would it take into account:
Average b/w for web browsing?
Average b/w for email?
Average b/w for instant messaging?
So far, so good? What about:
Average b/w for video conferencing?
Average b/w for transferring files from work to home, when you do CAD?
Average b/w for downloading linux iso's to do research into which distro is the best?
Low-bandwidth customers are always going to come out on the bottom if they aren't getting a package tailored for their low-consumption. So, how are 3 PC's behind a NAT that are used for _anything_ less ethical than one PC without NAT that's constantly sucking its fully allowed bandwidth? Should the latter have their service cancelled even though their agreement says they can use XXX Kb/sec. down and XXX Kb/sec. up - unlimited? If not, then why punish a NAT user?
Glad to answer, I hope this help clarify my former level of programming skill to you.
Prior to joining franz and learning Lisp, I was much more "high-level" in the sense that I would often make use of several programs that other people wrote to accomplish a task which I would now (much more efficiently) program my own solution to. I tinkered in C, C++, PHP, and Perl, and a few others, but the most I did with those was web-related simplistic CGI software and a few minor administrative tools and shell scripts. Nothing fancy, not even any socket programming. No, I wasn't totally new to programming, but I was far less skilled than most programmers I'd met.
There are quite a few companies using Lisp for quite a few different things in the "Success Stories" section of the Franz website (makers of Allegro Common Lisp). Examples include the Final Fantasy movie, Crash Bandicoot, Orbitz (as above), and tons of other places that tend to surprise people who are unfamiliar with Lisp.
correction - make that a non-site-license deal or a VAR... but I don't do sales work, so I don't really know what I'm talking about. I know you've got way too high a number for anything I have seen, though.
I think you've got your numbers wrong there, perhaps you're talking about a site-license deal or a VAR. I could be wrong, but I haven't heard of any single deals of that magnitude around here.
Since the day I joined Franz Inc. as the new Webmaster, I have been
writing more code than at any previous point in my career. I have
become immersed in Lisp programming, specifically AllegroCL, which I found to be a
stimulating challenge to learn. I discovered that writing Lisp is
sheer joy to anyone who has ever been frustrated out of programming by
the tedium of obligatory declaration of data types, allocation and
de-allocation of memory and the like, or simply by the time they take
to learn. To finalize my education in AllegroCL, I was tasked with
replacing the Franz webserver with AllegroServe. Though I am not a
slow student, I made many mistakes and found that the simplified
testing of code via the AllegroCL debugger and the ability to modify a
program while it is running were indispensable tools both in my
education and software troubleshooting. Making use of these features,
I have found that adding new code to a program is remarkably easy to
do, even when that new code requires making significant structural
changes. In the end, I'm always left with a program which runs as
quickly as any others I use and exhibits enhanced stability and
security features while maintaining a reasonable memory footprint.
Among my first tasks at Franz was familiarizing myself with
Allegro Common Lisp. My interest in Lisp's long, rich and diverse
history was one of the chief reasons I applied for the job, so I was
happy to oblige. I've always found the history of computing to be of
great interest, and Lisp has been there throughout most of the last 50
years (of currently-used languages, only Fortran predates its
nativity), so I find its endurance of especial interest. Lisp has
undergone a process of evolution during its lifetime spawning several
dialects, one of which is Common Lisp; AllegroCL is an implementation
of Common Lisp.
The aspects which I find most satisfying in AllegroCL include
automatic memory management and dynamic typing of data. Both of these
features eliminate a tremendous amount of tedium from coding and allow
me to get more work done in less time. I was never a serious
programmer before I was introduced to Lisp, but now I've found a
passion which outweighs my penchant for computer gaming. In the past,
I would frequently spend much of my free time mastering the newest
reason to own a 3d-accelerated video card, but recently I've found
that I have more to show afterwards if I write code for fun, as
evidenced by the chatroom software I wrote as an educational exercise
which can be seen in production on my server at home, here
(running on AllegroServe). It took a little longer to write the chat
software than it usually takes me to master a new game, but at a total
of 16 hours, it was less than half the time that most games take to
complete. I began working more and producing a tremendously increased
level of output, all without the slightest increase in my stress
level.
After spending a couple of months with Franz, familiarizing
myself with my responsibilities as Webmaster while learning Allegro
Common Lisp, I was tasked with converting the Franz website from Apache webserver to an AllegroServe-based
solution, which entailed writing a webserver which used AllegroServe
at its core and provided all of the features which I found in Apache,
while adding a few site-specific features. AllegroServe's chief
developer, John Foderaro, and I were able to complete this task in
time for the recent release of AllegroCL 6.1. The speed of
development under AllegroCL was due in no small part to the ACL
debugger of which I made prodigious use early-on. The ability to
inspect running code and make modifications at the point of failure
not only made it a simple matter to identify and fix bugs, but it was
also an invaluable educational tool. Initially, I wrote bad code -
lots of bad code - but every mistake I made was immediately obviated
and resolved through liberal application of this handy tool. The
ability to directly interact with data in a running program provided
education that extended beyond the scope of any single programming
language, my ability to visualize software structure and the flow of
data was greatly enhanced.
After a few weeks of use, I began to realize that I wasn't
having more than one bug in my code every few days - needless to say,
I was elated. Until this point, I was working on relatively simple
aspects of the webserver, such as the Franz menu generation, customer
survey, and trial download sections. This accelerated rate of
learning gave me enough positive feedback that I felt comfortable
taking on more ambitious segments of the project. After I progressed
through the header, menu, and footer-wrapping code which provides the
interface to my earlier menu generator's output on Franz' "lhtml"
pages, I came to the logging facility. By far, writing the code to
manage the log handling was the most challenging aspect of the
webserver's design so far. It was at this point that John and I came
to realize that we would need to significantly enhance the
virtual-host capabilities of AllegroServe to provide such services as
separate access and error log streams for each individual virtual
host. Despite the challenge, John managed to implement these changes
in less time than it took me to write the code to handle formatting
the logfiles in a manner compatible with Apache's output, which Franz
especially required to enable the continued use of certain website log
analysis tools. The two of us had completely changed the manner in
which AllegroServe handled logging in a mere two days. John also
eventually added excellent support for running standard CGI programs
which would have their own log streams, and I made use of the added
functionality to support a "cgiroot" which allows the Apache-like
feature of being able to specify a path in which cgi programs will
reside while sending any cgi log output to the vhost error log. I
would encourage any current Apache users who wish to try-out
AllegroServe to make use of this feature when configuring a server, it
makes CGI installation and use a snap. After I'd written the bulk of
my contribution to our system, I hit upon another necessary feature,
the ability to include in-tree access control files akin to
".htaccess" files under Apache. This was a significantly more complex
challenge than the logging and virtual host modifications John and I
had previously added, due to the depth of the AllegroServe feature-set
we would have to make available for modification within these files,
and the associated security concerns. This obstacle took a fair
amount of time to surmount, John made significant changes throughout
AllegroServe, and we went through a great deal of testing to ensure
that no security risks had been created. In the end, we were
satisfied that we had made a very worthwhile addition to the
webserver.
I continued writing interface and configuration code and
enlisted John's expert help whenever I would find a feature
AllegroServe lacked, and we concluded the conversion with a version of
the Franz webserver that has only required minor modifications since.
When I had ironed-out any remaining bugs, of which there were
fortunately very few, John assisted me in profiling our code to assess
its speed bottlenecks. After heavily load-testing the server, we
discovered that the slowest part of the code was that used to check
the timestamps on files for the purposes of updating our cache. This
was greatly satisfying because the speed of this code was so fast that
we could not consider this to be a problem. We also discovered that
there was an excessive memory waste within a few seemingly clean
segments of code, we were using a dynamically-sized string creation
function which relies upon the multiple different data types for the
sake of convenience. We converted this to make use of a large
fixed-size array which would contain the string, even if it grew as
long as it possibly could, and halved the server's memory usage.
Bandwidth load testing showed that we had an extremely fast server -
we were able to utilize around 850-900KB/sec. across a 10 megabit
network when running the system on an Intel Celeron 533.
Additionally, thanks to our prior memory-usage enhancement which
came-up during profiling, we were only using a total of 30MB of RAM
for the webserver, cache and all.
I am very satisfied to have had a hand in such a successful
project, especially successful considering that I was a rank novice
programmer when I began work on it. The speed with which I learned to
program in AllegroCL was an entirely new phenomenon to me, one which
has enriched my computer usage and allowed me to express my ideas for
software in code, something I never had the capability of doing in the
past due to my unwillingness to suffer through the tedium programming
had historically presented me with. When I found myself attaining a
satisfactory level of programming ability, I was struck by the ease of
writing clean and modular code on the first attempt. Augmenting that
ability, the ease of adding and restructuring AllegroCL code to a
running or non-running program, especially with the aid of the ACL
debugger, greatly decreased both my development time and my
frustration while further enhancing my level of programming skill. I
have learned a great deal about Lisp, AllegroCL, and programming in
general over the course of this project, and without it I would not
have had the chance to make such a satisfying acquaintance with
Allegro Common Lisp, which has become my programming language of
choice.
And obviously personal moral choice has nothing to do with it? I'm solely at the mercy of my raw animal desires and cultural dogma alone... I'm not responsible enough to think and evaluate my situation and potential outcomes of my actions.
Slashdot Mirror
The single common denominator I've seen so far is that all Windows users switching to Linux, expect Linux to _BE_ Windows. They want to right-click on the desktop and get "Properties", and they want a "Start->Run" paradigm. They try to "de-configure" the Linux machine to live and breathe like their previous Windows environment, instead of learning why Linux _EXCELS_ past Windows, and exceeds where Windows fails, they just want Windows.. on Linux.
Isn't this what the prior poster meant when he said "... don't understand or are against change." ?
Maybe we can live the unsavory aspects of life vicariously through robots. For example, we could let robots have wars and kill each other--not just on Battlebots, but in Afghanistan and anywhere else the U.S. stages its wars.
I'm afraid that this is too optimistic. Competition and strife are part of all life. To exemplify this, what would occur if your robot warriors lost and you didn't want to abide by the terms of the winners? Violence is always going to be part of war, alongside politics and propaganda.
Better yet, employ robots in menial manufacturing jobs so that humans can reach some semblance of equality. Just a thought, but flame away.
Indeed, this sounds like a very good idea, but without menial jobs, where will people who don't have skills work? There will always be people who, for one reason or another, do not have any skills which transcend the "menial" labors your refer to. Barring that, what about lazy people who don't want to develop skills - do they get a free ride at the cost of resources? Unskilled work is necessary to provide a semblance of equality, otherwise the contrast will become even more pronounced between skilled laborers and the unqualified.
The best solution is to augment (rather than replace) aspects of life which can be augmented with technology and make progress.
I can speak for myself, but I think that you should provide some figures if you are going to speak for most of the prior Napster (etc) users
I disagree, but let me explain why:
I don't have a lot of money to spend on CDs, and even if I did, purchasing music which you haven't heard is a total shot in the dark. In the past, I would hear music my friends listened to and buy CDs from the artists I liked, if I had the money to do so. With the advent of the big P2P networks, I was able to check out a much wider variety of music, though I still only bought what I could afford. When I was exposed to so much music which I liked, I found myself making greater allowances in my budget for music - though you would be correct in the assertion that I downloaded much more than I paid for. I purchased what I found to be most interesting, rewarding the musicians which I felt deserved it most - many of whom I would never have heard if I had continued learning about new music through my peers. I now spend more money on music than I ever have in the past, though I listen to more music than I could afford to purchase - and at the same time, I have diversified my cultural input by stepping outside of the clicques my friend have ordered themselves into.
Who is this hurting? Musicians whose music I don't like who were relying on name recognition for shot-in-the-dark sales.
How is this good? It helps create a more evolving music market which can function via natural selection (ie, survival of the fittest) rather than survival of the best-funded (advertised).
I spend more money on music now than I did before, nobody is losing sales to me - I can't buy any more music than I do.
Comcast reassured customers Wednesday that the information had been stored only temporarily, was purged automatically every few days and "has never been connected to individual subscribers." But it said it will stop recording the information, anyway.
Funny how it doesn't say anything about not being transferred or duplicated. Of course, "individual subscribers" is not the same thing as "subscriber clusters" or "market groups"... what's the granularity they did use?
He said that while the company was recording details about customer Web browsing, it did not use the information to build profiles of online consumer behavior.
Of course not, there are other companys who do that for you!
"Comcast absolutely does not share personal information about our customers, and we have the utmost respect for our customers' privacy," Watson said.
He doesn't say that they don't sell it, or for that matter, what they do use it for.
Either way, the info they collected before they stopped was very likely sold, and it was worth a lot of money. This would be a handy trick to swap some PR for some quick cash if the need arose.
Hmmm... I don't recall having replied to a post that said Java or VB were dead and obsolete languages, just Lisp.
I suppose that next time someone tells me that they think William Shatner's acting stinks I should retort with "My car acts funny sometimes" or something similarly tangential to the discussion.
Here's a categorized list of companies successfully using Allegro Common Lisp, along with a couple examples from each; follow the links for more companies and more information:
I am a Lisp developer, and I'm proud to point out that Common Lisp does these tricks, specifically my favourite implementation - Allegro Common Lisp employs all of these features and more.
Please take a look at information available on www.franz.com , and email with any questions you might have.
Oh, and by the way - here are some success stories from a variety of people who have used AllegroCL for their projects (NASA, Microsoft, Square USA, etc.)
If that's your goal, and you don't mind hacking the kernel a bit to accomplish the trick - why not use the ATX soft power? It wouldn't require a specialized debugging isa card, just an ATX board and power supply.
Damn, didn't work... well, do a search on "developing a speech impediment" on amazon.com's books if you want to see my silly little joke.
Or for that matter, perhaps developing a speech impediment would suit your particular needs.
Perhaps I'm in the minority, but I read the comments to get info from the comments themselves, and I don't often want to bother with digging into all the links that say "more info here".
Of course, you're welcome to post a link to www.franz.com as you like.
I'm a Lisp programmer (Allegro CL mostly), so naturally I would like to see more books covering Lisp. I'd specifically like to see the following topics covered:
I'd really like to find more practical Lisp examples on bookstore shelves.
Oh, and before I hear "Lisp can't do that", here's a short list of Lisp success stories:
Why do you think bil Laden hates Americans[?]
Honestly? I still don't know, I haven't really heard it from the horse's mouth, so to speak. All I know is that he's got a problem with us, but to say I know why he feels that way would be a bit presumptuous.
So. Where's the racist act? In saying the word, or in differentiating between the speaker?
Simple. The racist act is ignoring the intent with which it was spoken in favor of observing that ethnicity is a factor involved in the conversation. Ignore race to end racism, don't attempt to compensate for it by analyzing it.
Why hasn't anyone mentioned applying this technology to fuel cells?
Since I'm a Lisp fiend: while we're on the subject of programming for bioinformatics, I'd like to point out that Allegro Common Lisp has been used by a few folks in the field. Here are two links:
Pangea Systems Inc. (now DoubleTwist) for EcoCyc.
MDL Information Systems to design new drugs.
An exceptionally good question in light of the argument.
If an ISP has unlimited access which it is calculating on the basis of an average SINGLE user with a SINGLE machine, and it states it clearly in its contract that you are paying for a single-user/single-machine, then anyone putting more than that on their link is in breach of their contract. They have calculated their prices based on their assumption. Of course you may think -and might even be right- that their prices are too high, but does that morally allow you to be in breach of contract? In the same way, we all feel that MS-whatever licenses are way too high, but are we morally allowed therefore to install each program on 10 machines (certainly not legally).
Their assumption is going to be incorrect.
Would it take into account:
- Average b/w for web browsing?
- Average b/w for email?
- Average b/w for instant messaging?
So far, so good? What about:- Average b/w for video conferencing?
- Average b/w for transferring files from work to home, when you do CAD?
- Average b/w for downloading linux iso's to do research into which distro is the best?
Low-bandwidth customers are always going to come out on the bottom if they aren't getting a package tailored for their low-consumption. So, how are 3 PC's behind a NAT that are used for _anything_ less ethical than one PC without NAT that's constantly sucking its fully allowed bandwidth? Should the latter have their service cancelled even though their agreement says they can use XXX Kb/sec. down and XXX Kb/sec. up - unlimited? If not, then why punish a NAT user?I don't buy into your logic.
Glad to answer, I hope this help clarify my former level of programming skill to you.
Prior to joining franz and learning Lisp, I was much more "high-level" in the sense that I would often make use of several programs that other people wrote to accomplish a task which I would now (much more efficiently) program my own solution to. I tinkered in C, C++, PHP, and Perl, and a few others, but the most I did with those was web-related simplistic CGI software and a few minor administrative tools and shell scripts. Nothing fancy, not even any socket programming. No, I wasn't totally new to programming, but I was far less skilled than most programmers I'd met.
There are quite a few companies using Lisp for quite a few different things in the "Success Stories" section of the Franz website (makers of Allegro Common Lisp). Examples include the Final Fantasy movie, Crash Bandicoot, Orbitz (as above), and tons of other places that tend to surprise people who are unfamiliar with Lisp.
Here are the categories the Franz site lists:
correction - make that a non-site-license deal or a VAR... but I don't do sales work, so I don't really know what I'm talking about. I know you've got way too high a number for anything I have seen, though.
I think you've got your numbers wrong there, perhaps you're talking about a site-license deal or a VAR. I could be wrong, but I haven't heard of any single deals of that magnitude around here.
Since the day I joined Franz Inc. as the new Webmaster, I have been writing more code than at any previous point in my career. I have become immersed in Lisp programming, specifically AllegroCL, which I found to be a stimulating challenge to learn. I discovered that writing Lisp is sheer joy to anyone who has ever been frustrated out of programming by the tedium of obligatory declaration of data types, allocation and de-allocation of memory and the like, or simply by the time they take to learn. To finalize my education in AllegroCL, I was tasked with replacing the Franz webserver with AllegroServe. Though I am not a slow student, I made many mistakes and found that the simplified testing of code via the AllegroCL debugger and the ability to modify a program while it is running were indispensable tools both in my education and software troubleshooting. Making use of these features, I have found that adding new code to a program is remarkably easy to do, even when that new code requires making significant structural changes. In the end, I'm always left with a program which runs as quickly as any others I use and exhibits enhanced stability and security features while maintaining a reasonable memory footprint.
Among my first tasks at Franz was familiarizing myself with Allegro Common Lisp. My interest in Lisp's long, rich and diverse history was one of the chief reasons I applied for the job, so I was happy to oblige. I've always found the history of computing to be of great interest, and Lisp has been there throughout most of the last 50 years (of currently-used languages, only Fortran predates its nativity), so I find its endurance of especial interest. Lisp has undergone a process of evolution during its lifetime spawning several dialects, one of which is Common Lisp; AllegroCL is an implementation of Common Lisp.
The aspects which I find most satisfying in AllegroCL include automatic memory management and dynamic typing of data. Both of these features eliminate a tremendous amount of tedium from coding and allow me to get more work done in less time. I was never a serious programmer before I was introduced to Lisp, but now I've found a passion which outweighs my penchant for computer gaming. In the past, I would frequently spend much of my free time mastering the newest reason to own a 3d-accelerated video card, but recently I've found that I have more to show afterwards if I write code for fun, as evidenced by the chatroom software I wrote as an educational exercise which can be seen in production on my server at home, here (running on AllegroServe). It took a little longer to write the chat software than it usually takes me to master a new game, but at a total of 16 hours, it was less than half the time that most games take to complete. I began working more and producing a tremendously increased level of output, all without the slightest increase in my stress level.
After spending a couple of months with Franz, familiarizing myself with my responsibilities as Webmaster while learning Allegro Common Lisp, I was tasked with converting the Franz website from Apache webserver to an AllegroServe-based solution, which entailed writing a webserver which used AllegroServe at its core and provided all of the features which I found in Apache, while adding a few site-specific features. AllegroServe's chief developer, John Foderaro, and I were able to complete this task in time for the recent release of AllegroCL 6.1. The speed of development under AllegroCL was due in no small part to the ACL debugger of which I made prodigious use early-on. The ability to inspect running code and make modifications at the point of failure not only made it a simple matter to identify and fix bugs, but it was also an invaluable educational tool. Initially, I wrote bad code - lots of bad code - but every mistake I made was immediately obviated and resolved through liberal application of this handy tool. The ability to directly interact with data in a running program provided education that extended beyond the scope of any single programming language, my ability to visualize software structure and the flow of data was greatly enhanced.
After a few weeks of use, I began to realize that I wasn't having more than one bug in my code every few days - needless to say, I was elated. Until this point, I was working on relatively simple aspects of the webserver, such as the Franz menu generation, customer survey, and trial download sections. This accelerated rate of learning gave me enough positive feedback that I felt comfortable taking on more ambitious segments of the project. After I progressed through the header, menu, and footer-wrapping code which provides the interface to my earlier menu generator's output on Franz' "lhtml" pages, I came to the logging facility. By far, writing the code to manage the log handling was the most challenging aspect of the webserver's design so far. It was at this point that John and I came to realize that we would need to significantly enhance the virtual-host capabilities of AllegroServe to provide such services as separate access and error log streams for each individual virtual host. Despite the challenge, John managed to implement these changes in less time than it took me to write the code to handle formatting the logfiles in a manner compatible with Apache's output, which Franz especially required to enable the continued use of certain website log analysis tools. The two of us had completely changed the manner in which AllegroServe handled logging in a mere two days. John also eventually added excellent support for running standard CGI programs which would have their own log streams, and I made use of the added functionality to support a "cgiroot" which allows the Apache-like feature of being able to specify a path in which cgi programs will reside while sending any cgi log output to the vhost error log. I would encourage any current Apache users who wish to try-out AllegroServe to make use of this feature when configuring a server, it makes CGI installation and use a snap. After I'd written the bulk of my contribution to our system, I hit upon another necessary feature, the ability to include in-tree access control files akin to ".htaccess" files under Apache. This was a significantly more complex challenge than the logging and virtual host modifications John and I had previously added, due to the depth of the AllegroServe feature-set we would have to make available for modification within these files, and the associated security concerns. This obstacle took a fair amount of time to surmount, John made significant changes throughout AllegroServe, and we went through a great deal of testing to ensure that no security risks had been created. In the end, we were satisfied that we had made a very worthwhile addition to the webserver.
I continued writing interface and configuration code and enlisted John's expert help whenever I would find a feature AllegroServe lacked, and we concluded the conversion with a version of the Franz webserver that has only required minor modifications since. When I had ironed-out any remaining bugs, of which there were fortunately very few, John assisted me in profiling our code to assess its speed bottlenecks. After heavily load-testing the server, we discovered that the slowest part of the code was that used to check the timestamps on files for the purposes of updating our cache. This was greatly satisfying because the speed of this code was so fast that we could not consider this to be a problem. We also discovered that there was an excessive memory waste within a few seemingly clean segments of code, we were using a dynamically-sized string creation function which relies upon the multiple different data types for the sake of convenience. We converted this to make use of a large fixed-size array which would contain the string, even if it grew as long as it possibly could, and halved the server's memory usage. Bandwidth load testing showed that we had an extremely fast server - we were able to utilize around 850-900KB/sec. across a 10 megabit network when running the system on an Intel Celeron 533. Additionally, thanks to our prior memory-usage enhancement which came-up during profiling, we were only using a total of 30MB of RAM for the webserver, cache and all.
I am very satisfied to have had a hand in such a successful project, especially successful considering that I was a rank novice programmer when I began work on it. The speed with which I learned to program in AllegroCL was an entirely new phenomenon to me, one which has enriched my computer usage and allowed me to express my ideas for software in code, something I never had the capability of doing in the past due to my unwillingness to suffer through the tedium programming had historically presented me with. When I found myself attaining a satisfactory level of programming ability, I was struck by the ease of writing clean and modular code on the first attempt. Augmenting that ability, the ease of adding and restructuring AllegroCL code to a running or non-running program, especially with the aid of the ACL debugger, greatly decreased both my development time and my frustration while further enhancing my level of programming skill. I have learned a great deal about Lisp, AllegroCL, and programming in general over the course of this project, and without it I would not have had the chance to make such a satisfying acquaintance with Allegro Common Lisp, which has become my programming language of choice.
And obviously personal moral choice has nothing to do with it? I'm solely at the mercy of my raw animal desires and cultural dogma alone... I'm not responsible enough to think and evaluate my situation and potential outcomes of my actions.
Please hold my hand and show me the way.