I agree! I don't think I've made my objection to Lisp's syntax
clear. It's basically all parens. When I was regularly using Lisp,
auto-indentation was fine, but there was no color. Perhaps that would help
me. But the simple fact that it's all parens I find leads to poor
readability.
What it has is so logical and uniform that it gives huge power to
macros, and allows editors to sensibly indent programs to reveal their
semantic structure.
"Uniform" is both good and bad. A language should be
sufficently uniform so that it is easy to understand and predict, but not so
uniform that after a few hours of coding the whole screen looks the same.
Common Lisp lets you totally redefine the language's syntax anyway, if you
don't like it. Want to write your math expressions using infix notation?
Download the infix package, that lets you write #I'sin(x)+y^2' if you don't
like (+ (sin x) (expt y 2))
I actually don't like this. The language should dictate the
syntax. One of the reasons that I prefer Java over C++ is that C++ let's
programmers rewrite the language a little too much. Java's developers were
smart enough to create a language that allows you to extend the language, but
not rewrite it forcing the next guy that needs to read your code to learn your
language.
The very logic that you supposedly find appealing in Lisp drives
inevitably toward the syntax that Lisp uses: code and list data have the same
representation, so that the same operators that you use manipulate lists also
lets you manipulate programs!!! That is the essence of macros.
The code == data aspect of Lisp is very cool. I've been sold on that
since I first learned about it. But I just wish that it didn't have to
imply the syntax that it has. I want it all.
C++ is an example of a language that misses that great chance. How do
you manipulate programs in C++? You either use the C-style preprocessor, which
is so limited that it is deprecated in favor of things like inline functions,
or you use templates, which introduce a whole new meta-language and a
corresponding layer of complexity, and is living is such an over-syntaxified
environment that you must remember to leave that extra space in <<
or the parser will barf on you.
The C preprocessor is horrible. It leads to some of the worst
readability known to man. Too many programmers have #defined too many
things to make their program not even look like C or C++. That's why it's
another feature left out of Java.
I'm not a big fan of templates either. Again, another feature left out
of Java. For smaller projects that need efficiency, they are fine.
But for larger projects they can really clog up the works. If you have,
say, 1000 or so classes which represent basic objects in your system, and of you
need a smart Ptr for each, and you need, say 20 container classes, suddenly you
have 40,000 classes. Compile times go through the roof, not to mention
binary sizes and the number and size of your symbols, making debugging a royal
pain. But this is a fundamental problem with templates for any language.
Templates do have akward syntax, but only because of typing. This is
what they are for. I don't recall Lisp having this same problem with
macros since everything was basically left typeless.
Arguments about syntax are going to favor Lisp over C++. Consider
trigraphs, for God's sake.
That's not fair. Just because C and C++ offer a way of specifying
characters on lame keyboards doesn't mean that the language's syntax is poor.
I find it hard to believe that anyone would prefer the syntax of C++
templates, for instance, over CLOS.
Are you refering to the OO qualities of CLOS? I prefer C++ classes over
CLOS. Do you mean to compare templates with macros?
I've been working on a new wireless technology as well. It's based on
Electrometoridyne Sinusoidal Pulsation technology.
The best part about this technology is that it doesn't interfere at all
with any other signals. This completely solves the limited spectrum
problem.
Instead of using 0's and 1's to represent the data being transfered, it uses
a much better digital representation. All data is represented by the
following symbols: a square, a circle, a triangle, and a set of three
horizontal wavy lines. Thus, it can represent 2 bits with one symbol, and
this leads to an increase in bandwidth.
The only problem is that the error rate is quite high. I'm working on
an error correction scheme, but this seems to just be putting off the problem.
If anyone has some suggestions, please let me know. Or better yet, just
concentrate really hard on what you think I should do.
And solar is by far one of the most expensive sources of electricity.
Expensive today, yes. But solar has a great deal of potential for the future. I'm not an expert in solar power, but I understand that there are approximately 8000 people living off the grid in California. Here's a popular site which is really the front for a subscription magazine which explains how you can get your house off the grid.
However, I'm not sure how well that would work were I live: Seattle.
Fill it up at any corner station and drive a 1000 miles on a tank
I take it you're refering to methanol. Question: what is the best way to produce methanol? Is there an environmentally friendly way to produce methanol?
You are assuming that the typical (i.e. popular) process of choosing a
language in which to program weighs both the difficulty of learning and
benefits of both C++ and Lisp. I think that assumption is false.
This may be true in some cases, but not in all. In the company I work
for, we are well aware of the challenges of C++ and only use it on large
projects in which highly skilled develops are employed. For the rest of
our projects we use a wide range of languages, though I don't believe that Lisp
is one of them. But the bottom line is that we try to match the project
with a language based on how it will be used, who will be using it, and what it
needs to do.
I believe rather that most programmers *fail* to recognize how difficult
C++ is to use well, and in fact don't use C++ well, whether they know it or
not. Most programmers have never attempted to learn to use Lisp well
(I'm not talking about Scheme, and I'm not talking about the "Lisp is
interpreted and has only one data structure" 1950's view of the
language), so they have no way of measuring the difficulty anyhow.
This is absolutely true of amatuer programmers. But I think you are
selling short the many professionals that make the important descisions in the
software industry. Perhaps I have a poor view of this situation since I
have only worked with outstanding companies, but from my perspective, there is
no failure to correctly recognize the trade offs.
It sounds like we both agree that C++ is more challenging to use well.
So there are two implications to this:
A common argument as to why Lisp is not more popular is because it is too
challenging to use well. I don't believe this based on the fact that
other more popular languages are just as hard, if not harder, to use
well. In fact, one of the things I like about Lisp is how logical it
is. I personally think that it is easy to use well, as long as you are
smart enough to, for example, understand how to map a function on a list of
lists. If it weren't for that damn syntax.
Despite the fact that C++ is more challenging to use than Lisp, it is more
often choosen by the software industry. This indicates that a large
number of people agree that the complexities of C++ are worth it.
It will be interesting to see what happens in the future. I just hope
that Lisp is not in mine. Perhaps Lisp2 with better syntax, but I don't
see that happening.
I still think that hydrogen fuel cells are the way to go. This thing requires 220 pounds of stuff so that it can travel 62 miles? That just doesn't cut it.
You can produce hydrogen from water and sun light. Hydogen fuel cells have vastly greater power per pound yeilds than this lame power system, and the exhaust is pure water vapor.
Some of us code because it's *fun*. I resent the author saying I'm an
incompetent coder because I haven't made a dime off of the free software I've
released.
Agreed. He's just doing his best to put down Free Software. I
wish he would stick to more logical arguments.
Some of us are employed as software engineers because we write software
to provide a specific service. I don't see this ever going away.
Ok, some of us. What about the rest of us? Fortunately, I
think I'm one of the safe ones. I think.
What really struck a nerve with me is how this guy equates $$$ with
competence
Again, more silliness by the author.
and turning this into a moral argument; that if someone writes software
as a hobby, he's a bad (or at least socially irresponsible) person.
Is that so far off?
Who, exactly, does Free Software help the most? It would seem to mostly
be rich people. We're not saving starving homeless people with Free
Software.
Who, exactly, does Free Software hurt the most? US!
I'm not suggesting that all Free Software is bad. But it makes sense
that some is. So the important question is: what are the questions
that we should ask ourselves about Free Software that can help us determine if a
particular project is beneficial or destructive?
If you don't understand the point I'm trying to make, you never will.
People that say this are typically dogmatic. You dogmatic?
The reason I went to college was to learn how to learn.
I couldn't agree with you more. It's unfortunate that so many students
graduate without learning this lesson.
I went to college to
get an EDUCATION, not training for a job.
Don't agree with you here. Training for a particular job was not my
main goal, becomming educated was. But the courses in my major that I took
exposed me to the tools that I needed to succeed at a my job in the short
term. My education and my commitment to learning will ensure my long term
success.
Paragraph three outlines the principle reason why no one should go to college
just to get a job and make lots of money.
Ah, because their ability to make a living could be sabatoged by other people
out to have some fun? People acting without the foresight to understand
that the same thing might happen to them?
What open source and free software means to me is that not everything has a
monitary value. There is something intrinsically valueable in having an
operating system that doesn't belong to one company or person. There is
something incredibly valueable to science and free thought in a software system
that enables people to communicate these ideals without having to pay royalties
to express them.
As with most things in life, Free Software is not all good.
There are definitely research advantages in a world in which Free Software is
abundant. But my only point is that this needs to be moderated because of
the cost of Free Software.
Answer this one simple question: How would you feel if you were laid
off from your job in which you developed an application that does X. You
were laid off because a Free Software project also developed an application that
does X. Your company, even though they made a superior product, could not
compete with free, and decided to give up and drop this project because it was
costing them more than it was making them.
Here is an interesting article on the same subject, except that it was writen
in 1998. I actually think this article does a better job of expressing
Microsoft's view.
I'm not a Microsoft supporter, but I'm not a Microsoft basher either.
This article raises some interesting questions that I think deserve at least
some thought. If you read it with a definite bias against Microsoft, then
you may miss some of these points because the author is definitely biased toward
Microsoft. Try to look past that.
The main point is, let's say you are a developer working at a company
developing a product which does X. Does it then make sense for you to go
home after work and work on a Free Software project which does X? No, it
doesn't. In fact, you'd be a little pissed off at the developers that were
working on a Free Software project which does X. It doesn't matter if your
company's project is superior or not. The fact is that free is free, and
the Free Software project has a big advantage when it comes to
price. True, competition is great. But your company had better
develop one kiss ass project to be worth actually spending money, and they had
better do it for as little cost as possible. This is all great for
consumers. But most of us are not consumers. How is this good
for us?
Douglas Boling
Free Software. Is it Worth the Cost?
The latest trendy thing in software circles is actually a revival of an old dream: software, freely written and distributed, with accompanying source code available for all to
see and modify. While anything "free" these days seems like a great deal, free software should be looked at from a somewhat different perspective.
The concept of free software has been around for decades. I'm not talking about the illegal pirating of copyrighted software.
Instead, free software advocates want software to simply be available for free, along with the source code for that software.
This allows other programmers to make contributions to the code and pass it on, again for free.
While free distribution is a great marketing tool (think about all those samples you get in the mail), what does it say about the product itself?
Frankly, it says that the product (or the effort that went into making the product) has no value. Is that what you software engineers out there want?
The software industry is unusual because it incurs high development costs, but has almost no production costs.
It has survived and thrives today--even if the business model does drive accountants crazy--by pricing
the product to cover the development and maintenance cost in addition to some margin to provide a bit of profit for the company.
If, however, you gave away all software, how would you pay the creators of that software?
You destroy the subtle motives that only cash can bring--motives such as food
on the table, a warm place to sleep, and so forth. What you're left with is a bunch of amateur coders who
need to have real jobs to make ends meet. Are these the type of people you want developing the software products your business depends on?
This isn't to say that some, if not a fair majority, of the current "free" software out there isn't good. In fact, some is downright great.
But most of this software was created by students and folks in academia.
The reason these folks are in college studying software engineering is to get lucrative jobs out in the software industry.
Ironically, these folks are sowing the seeds of their own destruction. If they actually succeed in making software free, no one will be willing to employ them to create a product with no
value. Soon, students will stop studying software development in college since there won't be a way to make a career out of it.
All those young, eager students will have to turn to something less respectable, like studying
law.
Richard Stallman, creator of the Free Software Foundation (FSF), has promoted free software for years, and is the mind behind many of the GNU software tools.
The FSF has even created a legal tool they call "copyleft" to protect the freedom of their software.
A product that is copylefted is copyrighted, but can be modified by anyone as long as they don't charge for their contributions.
The source code for the new changes must be made available for others to see and learn from.
The FSF position is that software is more akin to speech than a physical product to be sold.
That's a noble concept... for the nineteenth century. In fact, if you take
Stallman's position to the logical conclusion, all intellectual property--from patents, to books, to music and art--should be free.
If intellectual property isn't property, then just what is property? Why not just give away cars, houses, and everything else?
With all the talk about freely shareable source and not charging for software, it's ironic that Stallman, the godfather of open-source, free software, and a recipient of a
MacArthur "genius" grant for his work in this area, is starting to complain about Linux, the most visible free software available today.
Stallman has reportedly said that since Linux uses many GNU tools, it should be called "GNU-Linux."
I'm sure Richard is correct, but it brings up an interesting dilemma.
If software is free, why does it matter who takes credit for it? After all, aren't we all just one big, happy family contributing to a great, shared codebase for all of
humankind? Why should it matter that someone uses some code from someone else?
The way I see it, "credit," better known as fame, is just another method of payment.
If the big kahuna of the FSF wants free software, he shouldn't demand the payment of fame for its use.
Or is it the money that's the problem? Some folks are just plain anticapitalist.
I'm not saying that Stallman is anticapitalist, I'm saying the whole free software movement is.
But understand my distinction. Giving away software is a great marketing tool.
It's hard to compete if your competition is free. That's something that a number of companies have discovered.
Now it's Microsoft's turn with Windows NT versus Linux. Still, if all software was free, none of us would have a job.
In short, I'm not against software being given away. I just want the folks who write that software to be paid--and paid handsomely--for writing it.
That is the proper model for the industry. So the next time you think about using some free software, consider its cost to the software industry.
The opinions expressed herein are those of Douglas Boling and should not be construed as the opinions of Microsoft Corporation.
From the May 1999 issue of Microsoft Internet Developer. Get it at your local newsstand, or better yet, subscribe.
It's called price dumping, and it's usually illegal within certain industries but I don't think the software-industry is one of them. Or perhaps it's only illegal when it is used as a weapon against weaker competitors? IANAL and thank god for that!
Unless you're talking about something else, it really is called "price fixing".
To my knowledge the software industry has no special immunity that would make price fixing not illegal. I'm curious why you would believe otherwise. I can't cite the law, but I understand it to be a fundamentally illegal activity, just like abusing a monopoly.
In fact, price fixing has many of the same features as a monopoly since it leads multiple corporations to come together and act as one monopoly.
Here's a site with information about price fixing.
Price fixing occurs when multiple corps collude to not compete and set a price higher than a normal free market would dictate. How would the GPL lead to this? It doesn't make sense.
I thought everyone jumps up and down because Microsoft released IE for free, and 'killed Netscape' in the process?
This is a standard Monopolizing tactic. Microsoft hopes to make more money in the long run by putting their competition out of business. This way, they can ultimately charge a much greater price, or perhaps more importantly, control what the browser actually does and does not do.
But the same argument does not hold for the GPL since there would be no point in the future when someone would raise the price of a GPL'd application.
It sounds like you are saying that there should not be any open source.
It makes sense that some projects should be closed source in order to protect proprietary secrets. But it also make sense that some projects should be open source.
But it doesn't really matter what you or I think. There will always be open source projects because building useful things is fun. It's that simple.
Walking around with your eyes closed is more challenging than walking with your eyes open. It doesn't mean you are smarter when you do so.
Your response to my statement is not logical. I agree with your statement above in isolation, but it fails to engage with what I said. The fact is that C++ is a more challenging language to learn to use well than is Lisp. If Lisp was equal to C++ in all other ways, then Lisp should be a popularly chosen language by the software industry. But it is not a language favored by the software industry. Not even close. So apparently, not only does the entire software industry favor C++, but they feel that the advantages that C++ has to offer out-weight the disadvanage that it is a more challenging language to master.
I use "let" all the time for this kind of mathematical stuff, and also more ordinary common-expression elimination.
Then you are a better Lisp coder than most.
What do you mean by vanilla Lisp?
It's basically Lisp with out the new fancy features added.
I still don't like Lisp's syntax, which is too bad because I do like many of the features. I was very happy when anonymous functions were added to Java.
It is obvious from your numerous posts on this thread that you are
extremely anti-lisp.
I think I got a little carried away with the volume of my posts. Point
taken. I'm not extremely anti-lisp; I just don't think it's the overall
best language.
You managed to make come up with a few logical flaws yourself. The first
is the assumption that lisp is a learning tool only.
Two points:
I'm not sure that would be a logical flaw. It would simply be a
false statement.
I never say what you claim: that Lisp is a learning tool only. I
agree that it's a real language that can do real work. The issue at
hand is if it is the best language to do real work, and also if that can be
logically supported by the author's claim (see below).
Second is that football players train for football by doing pushups. Not
sure but I think they use pushups (maybe) for strength/stamina; to play
football better they practice PLAYING FOOTBALL.
What you are saying doesn't make sense. Are you saying that football
players do not train for playing football by doing push ups? That the act
of doing push ups is somehow external to increasing their ability to suceed at
football?
I used this example because I thought its meaning would be so clear.
Athletes train for their activity by doing many things: strength training,
endurance training, streching, etc. Actually doing the activity that they
train for is just one part of their training.
My argument with the author's point is that it really just doesn't make any
sense: he states that because X is an excellent training tool, then X must be an
excellent tool to use for the real thing. But this is clearly a false
statement. If you still don't see why, let me know and I'll try a
different analogy.
While I think lisp is a fabulous language I will agree that there are
several reasons not to use lisp:
1. nearly impossible to find lisp talent.
2. commercial lisp products are extremely expensive.
3. few available libraries
None of these change the fact that lisp is extremely powerful, and *can* be
used for real work, *and* may in some cases be the best tool for the job.
I think we agree for the most part. No language is the best choice for
everything. Most languages have domains in which they are superior.
Though we may disagree on which domains Lisp is superior. Even if the
problems with Lisp that are associated with its general lack of popularitly were
solved, I'm not convinced that Lisp would be superior over C++ and Java for
writing large complex systems. My fundamental problem with Lisp is
readability. Can you honestly say that you enjoy reading Lisp code over
Java?
Perhaps there are many people out there that really do. But all I can
say is that I don't, and every developer that I've worked with on large Lisp
projects feels the same way.
So, perhaps you feel differently. Have you worked on a very large Lisp
project? I would sinceerely like to find just one person that has writen a
very large Lisp project and likes it. Everyone that I've met that supports
Lisp has yet to do so and have at most writen medium sized projects which at
most amount to a few tens of thousands of lines. The zealousness in my posting
is a reaction to the fact that I'm tired of hearing from these people how great
Lisp is when they have yet to do anything serious with it.
I got news for you pal, the rest of the world *IS* that dumb.
I made it clear that the these failures were not due to the developers involved.
The developers involved on these projects were some of the best developers I've ever worked with. Both projects were at Bell Labs, where being highly intelligent, having a high level of software engineering skill, and a deep appreciation for languages, is the norm for the department I was in.
Additionally, you never come out and say it, but it sounds like you are saying that Lisp is more complex than C++, and thus, this is the reason that it goes unused. Are you sure you want to make this claim? Please tell me why you feel this way.
What features are you thinking of, that would help you manage large
pieces of software? How do you find the Lisp package system deficient?
Lisp packages are fine.
My main beef with Lisp is simply its syntax. The two main things about
its sytax that I can articulate are:
Parens everywhere. Parens, parens, parens. The syntax is
simple and easy to learn, but when you're dealing with large chucks of code
that are all look the same, readability drops.
Functional return style: Lisp encourages the following style:
(defun f (x y z)
(* 2.6 (- (g y) 2) (h (/ z 2) x)))
I doesn't matter that you can label intermediate results in Lisp
because nobody does it. And even if you do, it's still ugly and
typeless.
I don't know about you, but I wouldn't think of starting a large software
engineering project using a language that doesn't have OOP. I have found
object models to really help aid the design and understanding of large
projects. Lack of OOP is of course another problem I have with vanilla
Lisp, but thanks to CLOS, that's less of an issue. But since I don't like
the fundamental syntax, no matter what features are band-aided onto Lisp, I will
still not like it.
So I should ask you, what do you not like about Java? Do you find it
deficient?
Apparently not as skilled as you were led to believe
No, the problem was not him.
But this was just one test. To really get a good understanding, many more competitions like this should be conducted: with different people and different projects.
So, we've done our job. Go and try it for yourself and add to the knowledge. If you do, please email me the results.
So -- when you say that the code is being rewritten in C++ because your shop can't maintain it, what you are saying is that you can't understand the elegant design, so you will replace it with something simpler (you hope), and will ultimately find that the resulting program is far more brittle, and harder to maintain.
I used to be a Lisp advocate, but no longer. I've been there, done
that, and it was a waste of time.
Lisp is a very elegant language in the small. But Lisp simply doesn't have
the features which help you manage large complex pieces of software. C++
and Java are not a silver bullet, but they are far better than Lisp when it
comes to features which help control code complexity. This is why we use
them, not because there is some conspiracy, or a basic failure in economics.
Your claim is that most developers are too stupid to use Lisp. But C++
is vastly more challenging than Lisp. If you disagree, then you don't
really know both languages. Despite the fact that C++ is more challenging
to use than Lisp, it is consistently chosen over Lisp. Thus, it's hard to
believe that we're consistently making the wrong choice: choosing an inferior
language which is more complex to use.
Qwerty was the first keyboard layout of its kind. There may have been preliminary versions, but I don't think these were ever produced in quantity.
The first full featured typewriter that was developed had one key for each symbol: no shift. Because it had so many keys, operators used the hunt and peck method because there wasn't a good way to touch-type.
I've heard that the Qwerty layout didn't have touch typing in mind when it was developed, but it didn't take long for someone to figure it out. Shortly after, the inventor of touch typing (forget his name) beat the raigning typing speed champ and the age of touch typing on the qwerty was born.
I'm not sure if that story is true. It's hard to believe that Qwerty wasn't developed for touch typing.
The biggest mistake I believe this author makes is the fact that he makes it
sound like Lisp is universally the best language to use except for a few edge
cases. Lisp may very well be a good short-term choice for this narrow
problem domain, but to assume that the rest of the world is so dumb that they
would overlook the massive competitive advantage alleged by the author is
ridiculous.
Lisp is definitely good at rapid prototyping. I have been involved with
two major projects which were initially written in Lisp. But after a
while, as they grew in size, both projects became unmanageable. This was
not because the developers involved were not skilled. Ultimately, each
project needed to call a time out, and each was rewritten in C++ to regain
control.
The same will happen for the project that is discussed in this article.
The author is just lucky that it didn't happen at a bad time.
This article is riddled with logical
flaws. Here are just a few:
If a painter were offered a brush that would make him a better painter, it seems to me that he would want to use it in all his
paintings, wouldn't he?
There is a big difference between using something because it helps you train
for the real thing, and using something for the real thing. Using this
same logic, football players should suddenly drop and start doing push ups on the field
after the ball is snapped.
Software is a very competitive business, prone to natural monopolies.
This short sentence manages to contradict itself.
When you choose technology, you have ignore what other people are doing,
and consider only what
will work the best.
But in the process of considering what will work best, you need to consider
what other people are doing. Businesses do not operate in a vacuum.
Slashdot Mirror
Long distance, yes. But I think the idea is short-range use, for example as a replacement to BlueTooth (less than 100 meters).
If it does penetrate walls well, and there is little interference, then it would be a perfect replacement for BlueTooth.
I agree! I don't think I've made my objection to Lisp's syntax clear. It's basically all parens. When I was regularly using Lisp, auto-indentation was fine, but there was no color. Perhaps that would help me. But the simple fact that it's all parens I find leads to poor readability.
"Uniform" is both good and bad. A language should be sufficently uniform so that it is easy to understand and predict, but not so uniform that after a few hours of coding the whole screen looks the same.
I actually don't like this. The language should dictate the syntax. One of the reasons that I prefer Java over C++ is that C++ let's programmers rewrite the language a little too much. Java's developers were smart enough to create a language that allows you to extend the language, but not rewrite it forcing the next guy that needs to read your code to learn your language.
The code == data aspect of Lisp is very cool. I've been sold on that since I first learned about it. But I just wish that it didn't have to imply the syntax that it has. I want it all.
The C preprocessor is horrible. It leads to some of the worst readability known to man. Too many programmers have #defined too many things to make their program not even look like C or C++. That's why it's another feature left out of Java.
I'm not a big fan of templates either. Again, another feature left out of Java. For smaller projects that need efficiency, they are fine. But for larger projects they can really clog up the works. If you have, say, 1000 or so classes which represent basic objects in your system, and of you need a smart Ptr for each, and you need, say 20 container classes, suddenly you have 40,000 classes. Compile times go through the roof, not to mention binary sizes and the number and size of your symbols, making debugging a royal pain. But this is a fundamental problem with templates for any language.
Templates do have akward syntax, but only because of typing. This is what they are for. I don't recall Lisp having this same problem with macros since everything was basically left typeless.
That's not fair. Just because C and C++ offer a way of specifying characters on lame keyboards doesn't mean that the language's syntax is poor.
Are you refering to the OO qualities of CLOS? I prefer C++ classes over CLOS. Do you mean to compare templates with macros?
I've been working on a new wireless technology as well. It's based on Electrometoridyne Sinusoidal Pulsation technology.
The best part about this technology is that it doesn't interfere at all with any other signals. This completely solves the limited spectrum problem.
Instead of using 0's and 1's to represent the data being transfered, it uses a much better digital representation. All data is represented by the following symbols: a square, a circle, a triangle, and a set of three horizontal wavy lines. Thus, it can represent 2 bits with one symbol, and this leads to an increase in bandwidth.
The only problem is that the error rate is quite high. I'm working on an error correction scheme, but this seems to just be putting off the problem.
If anyone has some suggestions, please let me know. Or better yet, just concentrate really hard on what you think I should do.
Your system isn't running an smtp server.
Let me know were'd you'd like me to reply.
But my fiancee doesn't appreciate it when I burp like my dog does. And my dog actually likes it when I throw food at him.
Expensive today, yes. But solar has a great deal of potential for the future. I'm not an expert in solar power, but I understand that there are approximately 8000 people living off the grid in California. Here's a popular site which is really the front for a subscription magazine which explains how you can get your house off the grid.
However, I'm not sure how well that would work were I live: Seattle.
I take it you're refering to methanol. Question: what is the best way to produce methanol? Is there an environmentally friendly way to produce methanol?
This may be true in some cases, but not in all. In the company I work for, we are well aware of the challenges of C++ and only use it on large projects in which highly skilled develops are employed. For the rest of our projects we use a wide range of languages, though I don't believe that Lisp is one of them. But the bottom line is that we try to match the project with a language based on how it will be used, who will be using it, and what it needs to do.
This is absolutely true of amatuer programmers. But I think you are selling short the many professionals that make the important descisions in the software industry. Perhaps I have a poor view of this situation since I have only worked with outstanding companies, but from my perspective, there is no failure to correctly recognize the trade offs.
It sounds like we both agree that C++ is more challenging to use well.
So there are two implications to this:
It will be interesting to see what happens in the future. I just hope that Lisp is not in mine. Perhaps Lisp2 with better syntax, but I don't see that happening.
I still think that hydrogen fuel cells are the way to go. This thing requires 220 pounds of stuff so that it can travel 62 miles? That just doesn't cut it.
You can produce hydrogen from water and sun light. Hydogen fuel cells have vastly greater power per pound yeilds than this lame power system, and the exhaust is pure water vapor.
Here's an article about the Mercedes-Benz NEBUS.
I'd rather have dinner with my dog and play with my fiancee.
Agreed. He's just doing his best to put down Free Software. I wish he would stick to more logical arguments.
Ok, some of us. What about the rest of us? Fortunately, I think I'm one of the safe ones. I think.
Again, more silliness by the author.
Is that so far off?
Who, exactly, does Free Software help the most? It would seem to mostly be rich people. We're not saving starving homeless people with Free Software.
Who, exactly, does Free Software hurt the most? US!
I'm not suggesting that all Free Software is bad. But it makes sense that some is. So the important question is: what are the questions that we should ask ourselves about Free Software that can help us determine if a particular project is beneficial or destructive?
People that say this are typically dogmatic. You dogmatic?
I couldn't agree with you more. It's unfortunate that so many students graduate without learning this lesson.
Don't agree with you here. Training for a particular job was not my main goal, becomming educated was. But the courses in my major that I took exposed me to the tools that I needed to succeed at a my job in the short term. My education and my commitment to learning will ensure my long term success.
Ah, because their ability to make a living could be sabatoged by other people out to have some fun? People acting without the foresight to understand that the same thing might happen to them?
As with most things in life, Free Software is not all good. There are definitely research advantages in a world in which Free Software is abundant. But my only point is that this needs to be moderated because of the cost of Free Software.
Answer this one simple question: How would you feel if you were laid off from your job in which you developed an application that does X. You were laid off because a Free Software project also developed an application that does X. Your company, even though they made a superior product, could not compete with free, and decided to give up and drop this project because it was costing them more than it was making them.
How would you feel?
Think this can't happen?
Here is an interesting article on the same subject, except that it was writen in 1998. I actually think this article does a better job of expressing Microsoft's view.
I'm not a Microsoft supporter, but I'm not a Microsoft basher either. This article raises some interesting questions that I think deserve at least some thought. If you read it with a definite bias against Microsoft, then you may miss some of these points because the author is definitely biased toward Microsoft. Try to look past that.
The main point is, let's say you are a developer working at a company developing a product which does X. Does it then make sense for you to go home after work and work on a Free Software project which does X? No, it doesn't. In fact, you'd be a little pissed off at the developers that were working on a Free Software project which does X. It doesn't matter if your company's project is superior or not. The fact is that free is free, and the Free Software project has a big advantage when it comes to price. True, competition is great. But your company had better develop one kiss ass project to be worth actually spending money, and they had better do it for as little cost as possible. This is all great for consumers. But most of us are not consumers. How is this good for us?
Unless you're talking about something else, it really is called "price fixing".
To my knowledge the software industry has no special immunity that would make price fixing not illegal. I'm curious why you would believe otherwise. I can't cite the law, but I understand it to be a fundamentally illegal activity, just like abusing a monopoly.
In fact, price fixing has many of the same features as a monopoly since it leads multiple corporations to come together and act as one monopoly.
Here's a site with information about price fixing.
Price fixing occurs when multiple corps collude to not compete and set a price higher than a normal free market would dictate. How would the GPL lead to this? It doesn't make sense.
This is a standard Monopolizing tactic. Microsoft hopes to make more money in the long run by putting their competition out of business. This way, they can ultimately charge a much greater price, or perhaps more importantly, control what the browser actually does and does not do.
But the same argument does not hold for the GPL since there would be no point in the future when someone would raise the price of a GPL'd application.
It sounds like you are saying that there should not be any open source.
It makes sense that some projects should be closed source in order to protect proprietary secrets. But it also make sense that some projects should be open source.
But it doesn't really matter what you or I think. There will always be open source projects because building useful things is fun. It's that simple.
Your response to my statement is not logical. I agree with your statement above in isolation, but it fails to engage with what I said. The fact is that C++ is a more challenging language to learn to use well than is Lisp. If Lisp was equal to C++ in all other ways, then Lisp should be a popularly chosen language by the software industry. But it is not a language favored by the software industry. Not even close. So apparently, not only does the entire software industry favor C++, but they feel that the advantages that C++ has to offer out-weight the disadvanage that it is a more challenging language to master.
Then you are a better Lisp coder than most.
It's basically Lisp with out the new fancy features added.
I still don't like Lisp's syntax, which is too bad because I do like many of the features. I was very happy when anonymous functions were added to Java.
I think I got a little carried away with the volume of my posts. Point taken. I'm not extremely anti-lisp; I just don't think it's the overall best language.
Two points:
What you are saying doesn't make sense. Are you saying that football players do not train for playing football by doing push ups? That the act of doing push ups is somehow external to increasing their ability to suceed at football?
I used this example because I thought its meaning would be so clear. Athletes train for their activity by doing many things: strength training, endurance training, streching, etc. Actually doing the activity that they train for is just one part of their training.
My argument with the author's point is that it really just doesn't make any sense: he states that because X is an excellent training tool, then X must be an excellent tool to use for the real thing. But this is clearly a false statement. If you still don't see why, let me know and I'll try a different analogy.
I think we agree for the most part. No language is the best choice for everything. Most languages have domains in which they are superior.
Though we may disagree on which domains Lisp is superior. Even if the problems with Lisp that are associated with its general lack of popularitly were solved, I'm not convinced that Lisp would be superior over C++ and Java for writing large complex systems. My fundamental problem with Lisp is readability. Can you honestly say that you enjoy reading Lisp code over Java?
Perhaps there are many people out there that really do. But all I can say is that I don't, and every developer that I've worked with on large Lisp projects feels the same way.
So, perhaps you feel differently. Have you worked on a very large Lisp project? I would sinceerely like to find just one person that has writen a very large Lisp project and likes it. Everyone that I've met that supports Lisp has yet to do so and have at most writen medium sized projects which at most amount to a few tens of thousands of lines. The zealousness in my posting is a reaction to the fact that I'm tired of hearing from these people how great Lisp is when they have yet to do anything serious with it.
I got news for you pal, the rest of the world *IS* that dumb.
I made it clear that the these failures were not due to the developers involved.
The developers involved on these projects were some of the best developers I've ever worked with. Both projects were at Bell Labs, where being highly intelligent, having a high level of software engineering skill, and a deep appreciation for languages, is the norm for the department I was in.
Additionally, you never come out and say it, but it sounds like you are saying that Lisp is more complex than C++, and thus, this is the reason that it goes unused. Are you sure you want to make this claim? Please tell me why you feel this way.
Lisp packages are fine.
My main beef with Lisp is simply its syntax. The two main things about its sytax that I can articulate are:
I don't know about you, but I wouldn't think of starting a large software engineering project using a language that doesn't have OOP. I have found object models to really help aid the design and understanding of large projects. Lack of OOP is of course another problem I have with vanilla Lisp, but thanks to CLOS, that's less of an issue. But since I don't like the fundamental syntax, no matter what features are band-aided onto Lisp, I will still not like it.
So I should ask you, what do you not like about Java? Do you find it deficient?
Apparently not as skilled as you were led to believe
No, the problem was not him.
But this was just one test. To really get a good understanding, many more competitions like this should be conducted: with different people and different projects.
So, we've done our job. Go and try it for yourself and add to the knowledge. If you do, please email me the results.
I used to be a Lisp advocate, but no longer. I've been there, done that, and it was a waste of time.
Lisp is a very elegant language in the small. But Lisp simply doesn't have the features which help you manage large complex pieces of software. C++ and Java are not a silver bullet, but they are far better than Lisp when it comes to features which help control code complexity. This is why we use them, not because there is some conspiracy, or a basic failure in economics.
Your claim is that most developers are too stupid to use Lisp. But C++ is vastly more challenging than Lisp. If you disagree, then you don't really know both languages. Despite the fact that C++ is more challenging to use than Lisp, it is consistently chosen over Lisp. Thus, it's hard to believe that we're consistently making the wrong choice: choosing an inferior language which is more complex to use.
Qwerty was the first keyboard layout of its kind. There may have been preliminary versions, but I don't think these were ever produced in quantity.
The first full featured typewriter that was developed had one key for each symbol: no shift. Because it had so many keys, operators used the hunt and peck method because there wasn't a good way to touch-type.
I've heard that the Qwerty layout didn't have touch typing in mind when it was developed, but it didn't take long for someone to figure it out. Shortly after, the inventor of touch typing (forget his name) beat the raigning typing speed champ and the age of touch typing on the qwerty was born.
I'm not sure if that story is true. It's hard to believe that Qwerty wasn't developed for touch typing.
The biggest mistake I believe this author makes is the fact that he makes it sound like Lisp is universally the best language to use except for a few edge cases. Lisp may very well be a good short-term choice for this narrow problem domain, but to assume that the rest of the world is so dumb that they would overlook the massive competitive advantage alleged by the author is ridiculous.
Lisp is definitely good at rapid prototyping. I have been involved with two major projects which were initially written in Lisp. But after a while, as they grew in size, both projects became unmanageable. This was not because the developers involved were not skilled. Ultimately, each project needed to call a time out, and each was rewritten in C++ to regain control.
The same will happen for the project that is discussed in this article. The author is just lucky that it didn't happen at a bad time.
This article is riddled with logical flaws. Here are just a few:
There is a big difference between using something because it helps you train for the real thing, and using something for the real thing. Using this same logic, football players should suddenly drop and start doing push ups on the field after the ball is snapped.
This short sentence manages to contradict itself.
But in the process of considering what will work best, you need to consider what other people are doing. Businesses do not operate in a vacuum.