> Soon we'll have advertising on every inanimate surface.
Why would we limit ourselves to inanimate surfaces? I envision a day when I go to a seafood restaurant and the oysters have a self-updating "I've been out of water DD HH.MI.SS" display attached to their shells; the lobsters have a "My claws currently weight WW ounces each, and I was harvested only HH hours ago" display on their carapaces; and the waiters have dazzling, dynamic pieces of flair attached to their uniforms that vibrantly inform me how much they love their job.
Is anyone else thinking that Verizon will side with Google, et. al., and oppose the other telcos in this effort?
Verizon's big push, the on they're basically betting the company on, is their "FIOS" fiber-to-the-home initiative. If they control the fiber going in to the home, they can stick their video infrastructure in their own CO's and (where necessary) use private broadband circuits (owned by them) to transfer data. They don't need priority on the internet to deliver their product well.
So it would seem that it's in their best interest to keep this from happening, because a 2-tier internet (with the telcos at the top) would level the playing field and negate the advantage they have with the infrastructure they're putting in now for FIOS.
Actually, that has a complicated answer that depends on how exactly the rootkit "contains source code" from an LGPL product.
Basically, the only way that you can use an LGPL-licensed library in your program without getting "tainted" is if your program is designed to work with an unmodified version of the library and is distributed as source code or an unlinked set of binaries.
If you distribute your program has an executable that's dynamically linked with the library, then you need to include notices saying that you use the library, that the library is covered by the LGPL, supply a copy of the LGPL, etc.
If your program is statically linked, then you'd need to do all the above AND supply the source code for the library and the object files for your program so that the user could relink it against a modified version of the library if they so desired.
If you "slice and dice" the library and copy parts of it in your program, then your basically required act as if the library was GPL (not LGPL).
The LGPL is complicated!
Re:Already done with mold
on
Space Lichens
·
· Score: 5, Informative
Not the same thing. The mold you're talking about in MIR would have been in the crew compartment, which, unless there's something I don't know about Russians, wouldn't have been a vacuum.
The lichens discussed in the article were in a sealed container that, once the craft was in space, was opened. So they were completely exposed to the vacuum of space.
Anyway, since when has the law cared anything about competition?
Uh, since 1890, when the US Congress passed the Sherman Antitrust Act?
I'll definately grant that printer prices (at least for the consumer models) would go up if ink went down. I think the question no-one is asking is: What's so bad about cheap printers and expensive ink? Most of the people I know who buy personal printers don't use them much--ink is a rare purchase. Over the lifetime of the printer, I wouldn't be surprised if the current pricing scheme saved them money (it's certainly saved me money).
If you're going to be printing a lot, just pick up a used business-class printer. A decent laserjet isn't that expensive off of eBay.
I think a lot of the people who use RE's a lot would be well-served by brushing up on their recursive-descent parser writing skills.
For only a little more time then it takes to write a regular expression, you can (if you know how) write a simple recursive-descent parser that:
Is more readable (and thus maintainable)
Is more efficient
Has the potential to have much better error handling (e.g., a descriptive message instead of just "RE doesn't match! Ack!")
Is much more scalable: recursive descent parsers can easily scale up to parsing an entire language (witness g++, which uses one to parse C++)
Is likely to be a great deal more correct, because it forces you to actually define a language, instead of just iteratively building up an RE
Two of the three open projects you cite also happen to be bigger than most projects, with more developers working in || at the same time than most projects. Does that help them? Read "the mythical man-month" for the answer. (Hint: no).
I agree that Mozilla and the Linux kernel are very good pieces of software--I use them each for many hours each day. I don't have a problem with them: I have a problem with using only three projects has a sample size. They're attempting to make a precise model to describe the difference in debugging time between two different development methodologies. If they want to win me over, they'll need to show that it is mostly correct for a wide variety of both open and closed source projects.
No one will argue that there are some open source projects that are world-class, and has good or better then any closed source projects. Any statement stronger then that is going to need a stronger foundation then this paper can offer.
I know this is Slashdot and the party line is "OSS Rules!," but this seems pushing it even for this audience.
This was a paper written for a class on statistics. It was not a rigorous study. Their findings are based on a lot of assumptions. They have a very small sample set--they only test their model on Linux, fetchmail, and Mozilla. Many people, including myself, consider these the cream of the crop so far as OSS goes.
Before you praise it, I urge you to actually read the paper. Don't be intimidated by it--FUD is FUD, even if it's mixed with a heavy does of greek letters and charts.
Just look for the book with a black & white line drawing of a quarter-length bus on the front.
(Apologies to anyone forced to learn QBasic for employment reasons...)
The solution is to replace e-mail, with something that requires authentication and encryption. Anyone have suggestions to what is out there already to solve this problem?
If there was, would it matter? SMTP may be an inherently insecure protocol, but the infrastructure that's been built up to support it is immense: clients and servers for more architectures then you can imagine, the training for both the users and administrators of those programs, the training for the help desk staffers of the ISP's that support the clients (most SMTP users aren't Linux junkies pining for the bleeding edge of technology--learning something new for them is tough), the time required to create, rigorously define, and refine the new protocols, etc.. The merits of the technology matter less then you'd think.
I think legislature is likely the best hope for eliminating spam--and I don't think good anti-spam legislature needs to make the FTC a domestic intelligence agency.
I have a hard time believing your management is saying "We want OpenSSH!". They're probably saying: "We want SSH!". If so, there are supported commercial SSH implementations.
Likewise, don't confuse a specific product with a class of products. If there's a market for it (especially a corporate market), there's probably a vendor selling something that will meet your needs.
Also, don't look at list prices and scream: when you're buying for a corporation, you're rarely paying list price (unless you're only purchasing a few licenses).
Lisp was a very early, successful language, because it was close to a mathematical notation and easy to implement on primitive computers. I think the uathor expects Lisp to remain a vital evolutionary branch because of its mathemtical roots.
Lisp has changed. A lot. It outgrew its "mathematical roots" very quickly--the first documented implementations had a lot of side-effecting functions that weren't based on mathematical formalisms. You might be surprised just how "unpure" the first Lisps were (and how the most common versions remain so to this day).
For example, so far as I know people never programmed in lisp on punch cards
They did. Note that chapter 6.1 of the LISP 1.5 Programmer's Manual is called "Preparing a Card Deck". You might also want to read appendix J, and look at all the *very* side-effecty and non-mathematical functions present in this very early Lisp.:)
Don't worry (yeh yeh, TM)... if this gets out of hand, patents will stop being respected. No need to worry our little panties off that this spells the end of the internet!
The problem is that this is going to screw over a whole lot of people before laws are enacted to end this legalized extortion.
What makes this especially ugly is that it's going to have a disproportionate impact on smaller web-based retailers, because they are going to have neither a legal department nor the hundreds of thousands of dollars a legal battle of this scope would cost--the only real choice will be to either pay the extortion money or not do business on the web. Everyone but the patent holder loses.
That's not how a "Bayesian script" (at least a correctly implemented one...) works.:) You don't have to scan your entire training set every time you analyze an email, what you do is analyze the training set (once) and build a datastructure from it that you can access efficiently.
For example, in a Bayesian filter you're probably interested in word frequency. So you'd go over the training set once and build a hash table that maps a word to the number of times it's occured and also increment a counter of the total number of words. You can incrementally update this table as more spams come in, of course. And since the table can be saved and restored from disk without too much work, you only have to analyze a given spam message once.
I mean, I can see a seal leaking liquid oxygen, or some micro-crack in a weld... but computers? for crying out loud, it's one of the most common pieces of equipment on the planet.
Unfortunately, fault-tolerant, bug-free, efficient software is one of the most uncommon things on the planet.:)
Actually, using only the body isn't just a hack, it's a relatively new technique invented by Paul Graham that seems to produce excellent results. It makes a lot of sense: Spam is Spam because the body contains commercial or otherwise unwanted material--it's only natural that the most direct and accurate Spam filters are going to analyze the body. Bayesian classification like this is computationally tractable and appears to work.
You can read more about it here.
I wonder if you could elaborate for me a little bit.
You criticize ANSI Common Lisp for not standardizing threads, not
standardizing networking, and not defining declarations well. You
also claim that it is partially responsible for the downfall of Lisp. Then you
say that Scheme is the best variety of Lisp out there.
How can you reconcile your recommendation of Scheme with your
condemnation of Common Lisp? The Scheme standard (R5RS) does not
standardize type checking at all. Nor does it standardize
multiprocessing, nor networking, nor the compiler interface, etc.
There is greater variability between Scheme implementations then
between Common Lisp implementations on these issues.
You also claim that porting efficient code between Common Lisp
implementations is difficult. This is true. What's efficient in one
implementation can be innefficient in another. However, most vendors
supply their product for a wide variety of computers. Also, porting
the code without worrying about efficiency, is usually trivial, even
between different implementations on different platforms (assuming
CLIM or some other standardized interface was used). This means that you instantly get working code, even though it may not be as fast as it was on the originally implementation.
Compare this
with C, C++, etc. where porting between different machines, even with
the same compiler vendor, is often quite tricky. As for vendor
differences, care to port something from Visual C++?:)
I also would like to know what you consider vague about the condition
system. I've always considered it one of the strong points of the
language and easily graspable. I also disagree with your statement
that the ANSII Common Lisp standard is poorly written. I consider it
to be a superb example of technical writing. I use it day-to-day as
a reference when writing ANSI Common Lisp programs.
seems to work, because when you call the function in the Lisp read-eval-print loop (that's the name for the prompt you get when you typically start a Lisp system) it evaluates it, and prints "Hello, World!" because that is the string that the function returned.
Typically, the read-eval-print loop is only used for programming development. A
"Hello, World" program should write the string "Hello, World" to a stream, analoguous to doing a puts("Hello, World") in C. Thus, the example using WRITE-LINE is more correct.
The read-eval-print loop is one of the greatest features of Common Lisp development. It allows you to evaluate arbitrary bits and pieces of Lisp code and incrementally add and compile functions, methods, classes, etc. to your program. This means you can be building a (compiled) program without having to go through the write-compile-run-coredump-debug-repeat cycle.
It also makes debugging far easier, because you don't have to write nearly as much testing framework as you would in a more ``traditional'' compiled language. Often, testing a function is a matter of telling having the Lisp system you're using to compile it, and then calling the function on made-up arguments in the read-eval-print loop! This is so much nicer then having to write seperate programs to test your programs.
Crapping closing parens like that makes the language difficult to read without a text editor for matching. And it hurts my eyes;-).
In practice, Lisp programmers always use an editor that supports parenthesis matching. Something I've found after learning Lisp is that I don't notice the parenthesis at all; they're a non issue: I let emacs deal with them. Instead, I read code by how it's indented. Paranthesis are for the compiler, and indentation is for the programmer:)
But anyway I think it's an archaic language (it was invented in the 50's if I recall) and like anything invented nearly 50 years ago in the computer world, something better has evolved from it or was either created from scratch in a better way.
Lisp has evolved. ANSI Common Lisp is a very different language then what was used in the 50's. It has been continously evolving for nearly half a century.
I hate the gazillions of parenthenses and especially the poor interface given to me by DrScheme (of course again there might be something better but it's our teacher's restriction).
Nearly all serious Lisp development is done in an Emacs-like editor that has built-in support for writing Lisp programs. This support includes facilities that make keeping paranthesis balanced trivial.
I also don't think the language would have survived if it was not supported by universities morons who just don't want it to die. Leave it be! It's time is over!
I'd highly recommend you go to www.lisp.org and look at the hundreds of huge commercial applications that have been written in Common Lisp. It is not an obscure research language: If Common Lisp was only used by ``universities morons,'' would 2 major vendors (www.franz.com, www.xanalys.com) be able to make money off it? Incidently, both the preceeding sites--especially www.franz.com--list commercial customers who have been satisfied with developing software in Common Lisp.
Anyway... speaking about speed. We had a small project of doing fractals and compared it to a c++ program and the scheme program took nearly 20 times than the c++ to do the same recursion level.
It's very important to note that Scheme is not Common Lisp. Scheme is a very different language: Scheme is about having an elegant tool to solve problems; Lisp is about having a tool to elegantly solve problems. In particular Common Lisp is typically compiled to native code and allows the programmer to include type declarations. These two features alone can improve speed by a couple orders of magnitude. To be fair, some Schemes support these features but, AFAIK, it's not standardized.
Too damn right. And try parallel programing with lisp. There simply isn't such a thing. Sad, sad.
There is such a thing. All the major commercial implementations (Franz's Allegro Common Lisp, www.franz.com, Xanalys's LispWorks, www.xanalys.com, Macintosh Common Lisp, www.digitool.com) as well as one of the major free (Free as in honestly free: public domain) Common Lisps support multithreading using largely the same interface.
This just isn't true. All major Common Lisp environments, Commercial and Free, offer a painless way to call C functions. No recompilation of any kind needed, you just declare the C function, load the library, and call it.
As for GUI's, there's something called CLIM, the Common Lisp interface manager. It's a standardized Common Lisp GUI. There are at least 4 major implementations. Using it, you can write a GUI application that is Source-code compatible across anything Commons Lisp/CLIM runs on, which includes pretty much any PC operating system as well as a plethora of Unix workstations
In fact, Lisp is ideal for ``Industrial Strength''; application development. It's portable. It's (nearly always) compiled to native code. It offers superb exception handling. It has a package system. You can update running, deployed programs without stopping them. There are many other good reasons.
As for GTK specifically, there are no fewer then 2 Common Lisp GTK bindings out there.
Slashdot Mirror
Why would we limit ourselves to inanimate surfaces? I envision a day when I go to a seafood restaurant and the oysters have a self-updating "I've been out of water DD HH.MI.SS" display attached to their shells; the lobsters have a "My claws currently weight WW ounces each, and I was harvested only HH hours ago" display on their carapaces; and the waiters have dazzling, dynamic pieces of flair attached to their uniforms that vibrantly inform me how much they love their job.
Is anyone else thinking that Verizon will side with Google, et. al., and oppose the other telcos in this effort? Verizon's big push, the on they're basically betting the company on, is their "FIOS" fiber-to-the-home initiative. If they control the fiber going in to the home, they can stick their video infrastructure in their own CO's and (where necessary) use private broadband circuits (owned by them) to transfer data. They don't need priority on the internet to deliver their product well. So it would seem that it's in their best interest to keep this from happening, because a 2-tier internet (with the telcos at the top) would level the playing field and negate the advantage they have with the infrastructure they're putting in now for FIOS.
Basically, the only way that you can use an LGPL-licensed library in your program without getting "tainted" is if your program is designed to work with an unmodified version of the library and is distributed as source code or an unlinked set of binaries.
If you distribute your program has an executable that's dynamically linked with the library, then you need to include notices saying that you use the library, that the library is covered by the LGPL, supply a copy of the LGPL, etc.
If your program is statically linked, then you'd need to do all the above AND supply the source code for the library and the object files for your program so that the user could relink it against a modified version of the library if they so desired.
If you "slice and dice" the library and copy parts of it in your program, then your basically required act as if the library was GPL (not LGPL).
The LGPL is complicated!
Not the same thing. The mold you're talking about in MIR would have been in the crew compartment, which, unless there's something I don't know about Russians, wouldn't have been a vacuum. The lichens discussed in the article were in a sealed container that, once the craft was in space, was opened. So they were completely exposed to the vacuum of space.
Uh, since 1890, when the US Congress passed the Sherman Antitrust Act?
I'll definately grant that printer prices (at least for the consumer models) would go up if ink went down. I think the question no-one is asking is: What's so bad about cheap printers and expensive ink? Most of the people I know who buy personal printers don't use them much--ink is a rare purchase. Over the lifetime of the printer, I wouldn't be surprised if the current pricing scheme saved them money (it's certainly saved me money).
If you're going to be printing a lot, just pick up a used business-class printer. A decent laserjet isn't that expensive off of eBay.
I think a lot of the people who use RE's a lot would be well-served by brushing up on their recursive-descent parser writing skills. For only a little more time then it takes to write a regular expression, you can (if you know how) write a simple recursive-descent parser that:
I agree that Mozilla and the Linux kernel are very good pieces of software--I use them each for many hours each day. I don't have a problem with them: I have a problem with using only three projects has a sample size. They're attempting to make a precise model to describe the difference in debugging time between two different development methodologies. If they want to win me over, they'll need to show that it is mostly correct for a wide variety of both open and closed source projects.
No one will argue that there are some open source projects that are world-class, and has good or better then any closed source projects. Any statement stronger then that is going to need a stronger foundation then this paper can offer.
This was a paper written for a class on statistics. It was not a rigorous study. Their findings are based on a lot of assumptions. They have a very small sample set--they only test their model on Linux, fetchmail, and Mozilla. Many people, including myself, consider these the cream of the crop so far as OSS goes.
Before you praise it, I urge you to actually read the paper. Don't be intimidated by it--FUD is FUD, even if it's mixed with a heavy does of greek letters and charts.
Just look for the book with a black & white line drawing of a quarter-length bus on the front. (Apologies to anyone forced to learn QBasic for employment reasons...)
The solution is to replace e-mail, with something that requires authentication and encryption. Anyone have suggestions to what is out there already to solve this problem?
If there was, would it matter? SMTP may be an inherently insecure protocol, but the infrastructure that's been built up to support it is immense: clients and servers for more architectures then you can imagine, the training for both the users and administrators of those programs, the training for the help desk staffers of the ISP's that support the clients (most SMTP users aren't Linux junkies pining for the bleeding edge of technology--learning something new for them is tough), the time required to create, rigorously define, and refine the new protocols, etc.. The merits of the technology matter less then you'd think.
I think legislature is likely the best hope for eliminating spam--and I don't think good anti-spam legislature needs to make the FTC a domestic intelligence agency.
Likewise, don't confuse a specific product with a class of products. If there's a market for it (especially a corporate market), there's probably a vendor selling something that will meet your needs.
Also, don't look at list prices and scream: when you're buying for a corporation, you're rarely paying list price (unless you're only purchasing a few licenses).
Lisp has changed. A lot. It outgrew its "mathematical roots" very quickly--the first documented implementations had a lot of side-effecting functions that weren't based on mathematical formalisms. You might be surprised just how "unpure" the first Lisps were (and how the most common versions remain so to this day).
For example, so far as I know people never programmed in lisp on punch cardsThey did. Note that chapter 6.1 of the LISP 1.5 Programmer's Manual is called "Preparing a Card Deck". You might also want to read appendix J, and look at all the *very* side-effecty and non-mathematical functions present in this very early Lisp. :)
The problem is that this is going to screw over a whole lot of people before laws are enacted to end this legalized extortion.
What makes this especially ugly is that it's going to have a disproportionate impact on smaller web-based retailers, because they are going to have neither a legal department nor the hundreds of thousands of dollars a legal battle of this scope would cost--the only real choice will be to either pay the extortion money or not do business on the web. Everyone but the patent holder loses.
We don't know how to build large informational networks? I'd say the internet is a smashing success....
For example, in a Bayesian filter you're probably interested in word frequency. So you'd go over the training set once and build a hash table that maps a word to the number of times it's occured and also increment a counter of the total number of words. You can incrementally update this table as more spams come in, of course. And since the table can be saved and restored from disk without too much work, you only have to analyze a given spam message once.
Unfortunately, fault-tolerant, bug-free, efficient software is one of the most uncommon things on the planet. :)
Actually, using only the body isn't just a hack, it's a relatively new technique invented by Paul Graham that seems to produce excellent results. It makes a lot of sense: Spam is Spam because the body contains commercial or otherwise unwanted material--it's only natural that the most direct and accurate Spam filters are going to analyze the body. Bayesian classification like this is computationally tractable and appears to work. You can read more about it here.
I wonder if you could elaborate for me a little bit.
You criticize ANSI Common Lisp for not standardizing threads, not standardizing networking, and not defining declarations well. You also claim that it is partially responsible for the downfall of Lisp. Then you say that Scheme is the best variety of Lisp out there.
How can you reconcile your recommendation of Scheme with your condemnation of Common Lisp? The Scheme standard (R5RS) does not standardize type checking at all. Nor does it standardize multiprocessing, nor networking, nor the compiler interface, etc. There is greater variability between Scheme implementations then between Common Lisp implementations on these issues.
You also claim that porting efficient code between Common Lisp implementations is difficult. This is true. What's efficient in one implementation can be innefficient in another. However, most vendors supply their product for a wide variety of computers. Also, porting the code without worrying about efficiency, is usually trivial, even between different implementations on different platforms (assuming CLIM or some other standardized interface was used). This means that you instantly get working code, even though it may not be as fast as it was on the originally implementation.
Compare this with C, C++, etc. where porting between different machines, even with the same compiler vendor, is often quite tricky. As for vendor differences, care to port something from Visual C++? :)
I also would like to know what you consider vague about the condition system. I've always considered it one of the strong points of the language and easily graspable. I also disagree with your statement that the ANSII Common Lisp standard is poorly written. I consider it to be a superb example of technical writing. I use it day-to-day as a reference when writing ANSI Common Lisp programs.
This actually isn't quite true.
(define hello-world ()
"Hello, World!"))
seems to work, because when you call the function in the Lisp read-eval-print loop (that's the name for the prompt you get when you typically start a Lisp system) it evaluates it, and prints "Hello, World!" because that is the string that the function returned.
Typically, the read-eval-print loop is only used for programming development. A "Hello, World" program should write the string "Hello, World" to a stream, analoguous to doing a puts("Hello, World") in C. Thus, the example using WRITE-LINE is more correct.
The read-eval-print loop is one of the greatest features of Common Lisp development. It allows you to evaluate arbitrary bits and pieces of Lisp code and incrementally add and compile functions, methods, classes, etc. to your program. This means you can be building a (compiled) program without having to go through the write-compile-run-coredump-debug-repeat cycle.
It also makes debugging far easier, because you don't have to write nearly as much testing framework as you would in a more ``traditional'' compiled language. Often, testing a function is a matter of telling having the Lisp system you're using to compile it, and then calling the function on made-up arguments in the read-eval-print loop! This is so much nicer then having to write seperate programs to test your programs.
Crapping closing parens like that makes the language difficult to read without a text editor for matching. And it hurts my eyes ;-).
In practice, Lisp programmers always use an editor that supports parenthesis matching. Something I've found after learning Lisp is that I don't notice the parenthesis at all; they're a non issue: I let emacs deal with them. Instead, I read code by how it's indented. Paranthesis are for the compiler, and indentation is for the programmer :)
While not trying to put down lisp, it seems like what is desired here is something analogous to Python's docstrings
While not trying to put down Python, Lisp has had docstrings since long before Python had them. Where do you think it got the idea from?:)
But anyway I think it's an archaic language (it was invented in the 50's if I recall) and like anything invented nearly 50 years ago in the computer world, something better has evolved from it or was either created from scratch in a better way.
Lisp has evolved. ANSI Common Lisp is a very different language then what was used in the 50's. It has been continously evolving for nearly half a century.
I hate the gazillions of parenthenses and especially the poor interface given to me by DrScheme (of course again there might be something better but it's our teacher's restriction).
Nearly all serious Lisp development is done in an Emacs-like editor that has built-in support for writing Lisp programs. This support includes facilities that make keeping paranthesis balanced trivial.
I also don't think the language would have survived if it was not supported by universities morons who just don't want it to die. Leave it be! It's time is over!
I'd highly recommend you go to www.lisp.org and look at the hundreds of huge commercial applications that have been written in Common Lisp. It is not an obscure research language: If Common Lisp was only used by ``universities morons,'' would 2 major vendors (www.franz.com, www.xanalys.com) be able to make money off it? Incidently, both the preceeding sites--especially www.franz.com--list commercial customers who have been satisfied with developing software in Common Lisp.
Anyway... speaking about speed. We had a small project of doing fractals and compared it to a c++ program and the scheme program took nearly 20 times than the c++ to do the same recursion level.
It's very important to note that Scheme is not Common Lisp. Scheme is a very different language: Scheme is about having an elegant tool to solve problems; Lisp is about having a tool to elegantly solve problems. In particular Common Lisp is typically compiled to native code and allows the programmer to include type declarations. These two features alone can improve speed by a couple orders of magnitude. To be fair, some Schemes support these features but, AFAIK, it's not standardized.
Too damn right. And try parallel programing with lisp. There simply isn't such a thing. Sad, sad.
There is such a thing. All the major commercial implementations (Franz's Allegro Common Lisp, www.franz.com, Xanalys's LispWorks, www.xanalys.com, Macintosh Common Lisp, www.digitool.com) as well as one of the major free (Free as in honestly free: public domain) Common Lisps support multithreading using largely the same interface.
This just isn't true. All major Common Lisp environments, Commercial and Free, offer a painless way to call C functions. No recompilation of any kind needed, you just declare the C function, load the library, and call it.
As for GUI's, there's something called CLIM, the Common Lisp interface manager. It's a standardized Common Lisp GUI. There are at least 4 major implementations. Using it, you can write a GUI application that is Source-code compatible across anything Commons Lisp/CLIM runs on, which includes pretty much any PC operating system as well as a plethora of Unix workstations
In fact, Lisp is ideal for ``Industrial Strength''; application development. It's portable. It's (nearly always) compiled to native code. It offers superb exception handling. It has a package system. You can update running, deployed programs without stopping them. There are many other good reasons.
As for GTK specifically, there are no fewer then 2 Common Lisp GTK bindings out there.