They need to know that it's currently illegal, which is not the same thing as immoral.
They need to know that the ethical aspects of copying are highly controversial, and that words like ``piracy'' and ``intellectual property'' are nothing but propaganda terms used by people who hold a particular point of view about copying.
Lastly, they need to understand the consequences of getting caught.
Then they can make an informed decision whether or not to engage in copying, and on what scale.
This is what Linux was developed to get away from. I started using Linux in 1993 not because it was better than proprietary Unix systems, but because of the freely redistributable source code.
Finally there was something that really delivered on the promise of freedom. Unix gave you a platitude about freedom embossed on a license plate; Linux gave you the actual freedom.
So people who are comparing OS X and Linux nearly a decade later simply don't get the point. Taking BSD code and making a proprietary layer on top of that is old hat. What do you think SunOS was?
OS X is another SunOS, another Ultrix, another NeXTStep. From the point of view of someone who values freedom, not only technical excellence, it is just as irrelevant as these predecessors.
That's all, not proof positive that Microsoft
(not MicroSoft, by the way) make quality products.
I wouldn't call this a level playing field either. Why not? Because of differences in the vendors' attitudes to the discovery of these problems.
Microsoft wants to sweep these problems under the rug; keep them as secret as possible and even criminalize those who discover them and make them known. They have a poor track record when it comes to timely releases for patches, and alerting their user base.
Do you, for instance, remember
this slashdot story?
The article is misleading; these are not dangerous toys, only toys that someone considers politically incorrect. Nothing is mentioned about any specific dangers that the toys present, only that the toys have links to violent videogames and television shows.
Some of them shoot foam missiles; big deal! I think that a foot high robot that fires at room intruders is rather endearing.;)
Dangerous toys are things with parts that small children can choke on, stuff up their nose, or otherwise injure themselves with: sharp corners, fast-moving, massive projectiles, etc. Also, things containing dangerous substances, such as lead-based jewelry for children.
There is little connection between these properties and violence. Even in the category of fast moving things that can injure: this area is probably dominated by sporting equipment. Better not be getting your kid that hockey stick!
The usual argument for "OO syntax" is that the non-OO syntax for what is in reality an object (the file fi) "pollutes the name space" (creates lots of names of things at the global level).
That is really just a lexical problem of symbol management. Global symbol clashes are avoided by the use of packages. Lexical scoping has little or nothing to do with object orientation. Using C to emulate object oriented programming suffers from that problem because C has no namespaces or packages; programmers resort to conventions like adding a common prefix to related identifiers.
Object orientation is the semantics. Semantics
is tied to syntax, but not to any particular syntax; there is no ``object oriented syntax''. Syntax allows you to group some expressions together to express some semantic relationship.
Languages hit the wall when they have a hard-wired syntax, with hard-wired semantics.
Ruby is no exception. It's a whole lot of syntactic sugar for a bunch of non-programmable semantics. It was obsolete before it was conceived. Moreover, the author has a very limited view of what object oriented programming is, and suffers from a fundamental confusion that OO is somehow syntactically determined. This if from one of his slides:
//OOP
fi = File::new("sample.dat", "r")
fi.binmode = true
line = fi.readline()
fi.close
// Non-OOP
fi = fopen("sample.dat", "r")
fbinmode(fi, true)
line = freadline(fi)
fclose(fi)
So, in other words, something is object oriented if it uses the notation object.method(arg), but not object oriented if it uses the notation method(object, arg). Is this guy for real?
It takes a certain level of experience to see through the facade of curly braces, vertical bars, squiggles, splats, hashes, cokebottles and whatnot. Such devices, despite looking impressively cryptic and terse, do not imply any special power; they are designed to dazzle and seduce the undergraduate mind.
The real power arises when the same expression, whether it uses lots of syntactic sugar or not, can mean absolutely anything that the programmer wants, not only what the language designer wants it to mean.
Re:O'Reilly's ``Freedom zero'' is a vacuous.
on
Freedom or Power?
·
· Score: 1
This is the worst rambling I've seen in quite some time. You'd think with all the typing you did, you would have been able to say something. Apparently not.
Yet it takes you even more typing to demonstrate that you have no reading comprehension. Sigh.
O'Reilly's ``Freedom zero'' is a vacuous.
on
Freedom or Power?
·
· Score: 2
We could equally say that freedom zero is the choice whether to rob or not to rob that convenience store across the street, and that criminals and non-criminals alike are exercising that freedom in different ways.
The underlying substrate for all human behavior is the freedom to do anything, from donating one's time to worthwy humanitarian causes to commanding troops into heinous acts of genocide. Is that range of choices part of freedom zero?
Or maybe the real freedom zero substrate is simply the laws of physics.
Stallman's definition is superior because it doesn't regress into absurd starting points; freedom is defined as a very high level intelligent behavior rooted in certain ethical principles, and that's that. That freedom is supported by lower level freedoms which allow the intelligent substrate to make choices, but these freedoms are not interesting, because these lower freedoms support all human activity alike.
What evidence do you have that the software is going to run better on Windows? What does it mean to run better on Windows? Can you cite an example of an educational software package that does run on Windows and Linux, but runs ``better'' on Windows? What experience do you have with this? Or are you just guessing again?
Secondly, you are backpedalling now. First you said that it's about the applications, such as educational applications.
Now you are saying that ``schools WANT Windows and don't want Linux''.
So which is it, educational applications? Or the operating systems?
Regarding what people want: how *can* they want any alternatives, when those alternatives are shut out from the market by a monopoly? Of course Windows is what many people want. You can't want what you haven't seen. That's a consequence of the monopolistic practices which are supposed to be *punished* here, remember?
You can run some Windows applications on Linux, using various methods. Chances are that at least some of the educational software will run.
Have you investigated what educational software does or does not run under the various solutions for running Windows apps on Linux?
Microsoft doesn't care about providing a platform for educational software; they want the kids to be hooked on their proprietary operating system and applications. Mass indoctrination of future Microserfs is the key to their survival. So this action can hardly be called an act of restitution for anti-competitive behavior.
I didn't see anything in the proposal about Microsoft not being allowed to provide their software, only that they also allow a competitor to provide software.
It's not a proposal for *only* Red Hat to provide the software, but for Red Hat to *also* provide software.
If competitors are excluded from the action, then it can hardly be called restitution for anti-competitive behavior!
The term ``Bourne Shell'' is historic; it refers to the original program written by Stephen Bourne and some more or less direct derivatives.
The modern thing is simply the POSIX shell command language; If you write in the POSIX language, avoiding the quirks and extensions in the proprietary implementation you are using, your script should be highly portable to GNU bash and vice versa.
Similarly, if you want to write a new shell, your best bet is to use the standard as the guide rather than to clone the behavior of the legacy Bourne shell.
In C and C++ parentheses influence the way the expression is parsed and hence the order in which operations are performed. They don't determine the order in which operands are evaluated.
So when you have, say
f() + (g() + h())
the functions can be called in any of the six possible orders; which order is chosen is unspecified. But there is no question that the addition on the right must be done first, in the abstract semantics.
It so happens that in C, the expresssion
a + b + c
has exactly the same meaning as
(a + b) + c
this is due to the left associativity of the + operator.
The compiler is not free to add the b + c first, if it could make some kind of difference, like a change in the result, or an exception that would otherwise not happen. The result has to be ``as if'' the abstract semantics were followed.
So for instance if a, b and c are integers, and overflow is reversible (as it is with most two's complement machines) then the addition can be done in either order. If they are floating point types, then it cannot be reordered, because floating point addition is not associative: a + (b + c) is semantically not equal to (a + b) + c.
If your compiler treats a + b + c as a + (b + c) and produces the wrong result, it's a broken (nonconforming) C or C++ implementation, as the case may be.
Common Lisp is lexically scoped. Dynamic scope is available in the form of the ``special'' declaration. If you want dynamic scoping, you must explicitly request it like this:
So now with this declaration you have effectively created a local ``override'' for a global variable. If some form you evaluate from within this context refers to the identifier *dynamically-scoped-var* it will resolve to the one declared here, not the global one (unless there is a local declaration there which shadows that reference, of course).
Once upon a time, in dialects of Lisp preceding ANSI Common Lisp, this dynamic behavior was the norm. Dynamic scoping is tremendously useful, so it is retained in the form of special variables.
Some ``old timer'' Lisp users should take a second look at the current state of Lisp, because important details change.
have nothing to do with Windows, and they predate it. For example, the reason there is Linux is because people wanted a free clone of their favorite environment, which obviously wasn't Windows, and because they wanted to engage in fun hacking. That environment they wanted to clone wasn't seriously buggy or unstable; the motivation wasn't that the world needed a ``crash proof'' operating system. Only that it could use a free one.
The results have had the unexpected benefit of providing an alternative to users who are not happy with Windows for whatever reason. That there are such users, and that some of them are loud Microsoft bashers is entirely Microsoft's fault, and has nothing to do with the free software.
Gates is trying to promote the view that free software is only reaction to ``big, bad'' Microsoft, and therefore the motivation behind this software is not legitimate outside of the context of Microsoft. By extension, it's not legitimate in the context of a ``kinder, gentler'' Microsoft either.
When I started using Linux, it was because it could connect to the Internet and support multiple logged in users. At that time, Windows had no credible protocol stack for connecting to the Internet, and still cannot support multiple users today. Windows was so beneath consideration in 1992 that it wasn't even on the mental radar of any hacker. Though it has improved, the predominant consumer version still remains an unstable, unreliable crock that can't be trusted with any application needing more than a solid half a day of uptime. The industrial version of Windows is better in that regard, but that's completely besides the point. To the early adopters, Linux had to prove that it worked as well as, say, SunOS. Or reasonably well to be used in many of the same ways. Not that it crashed less than Windows; who with a clue would have been impressed with that?
So given the state of Windows when some of this free software was germinating, to call it a reaction to Windows is pathetically laughable at best. Or it would be pathetically laughable if uttered by some Anonmous Coward on Slashdot. But someone like Gates must be treated seriously; when he says so, it is a blatant, dangerous lie.
Writing a language preprocessor for C is a large granularity decision. It's going to impact how you build the program; it will have to correctly lexically analyze C source, generate syntactically correct C and so on. Writing a Lisp macro is a small, casual decision that is part of the normal flow of Lisp development; the macro is just part of your program.
Suppose you have 10 C programmers working on a project, and each of them wants to invent a few language features. So you end up with 10 translators, which require each source file to be passed through a 10 stage filter. Can you imagine that? What if there are subtle dependencies on the order of the filters, or if the output of one breaks the other? Or does not transparently pass through the language features understood by the next one? The scenario is almost unimaginable; quite likely, the very idea will be rejected as braindamaged early in the project.
In Lisp, the 10 programmers can easily have their own macro libraries contained in their modules of the program. They can use each other's macros easily, even nest them in the same code. There is nothing special to do, no code preprocessing to set up; it's not any different from using a library of functions.
Firstly, I'm a much more experienced C programmer than a Lisp programmer. Yet, the limitations of C compared to Lisp are painfully obvious to me.
Yes, C supports the fundamental unit of program abstraction known as the function. But that does not make up for the various other drawbacks.
Why C takes longer to write is because the programmer must deal with every detail of the computation---other than some machine-specific details such as allocating values to machine registers, explicitly managing the passing of parameters, or manually scaling pointer displacements based on types.
Firstly, there is the memory management. Every significantly large C program which uses dynamic memory, unless it is correctly written by a miraculous fluke, will suffer from failures due to premature deallocation of memory and memory leaks. It's not possible to create a significant data abstraction of C without encumbering it with memory management burden. A typical abstract datatype (ADT) module will have create and destroy functions which call malloc and free. The user of these functions inherits all of the responsibility that comes with malloc and free: the avoidance of premature deallocations and concerns about leaks. There are many things you can't do effectively without a garbage collector: the entire technique of functional programming is made impractically difficult. When you don't have to worry about memory allocation, you gain productivity.
Secondly, there is the strict, static type system. Static type systems get in the way of certain types of programming. Here is an example. It's not unusual for parsers written in C to use a union type to represent the items stored in a parse tree, and to use integer tags to identify what is present. What is that, if not an emulation of dynamic typing?
This brings us to my last point. Compiler writing is incorporated into the Lisp programming style, and the dynamic typing supports it directly. In Lisp, in addition to the use of functions as an abstraction mechanism, you have macros. These are not like C macros which work with tokens of the program text; they are operators that work on data structures; data structures which typically represent some programming construct and are translated into some other data structure, which represents Lisp code that will be substituted for the macro and evaluated in its place.
The techniques for abstraction provided by Lisp macros are squarely out of reach of the programmer working in C, who is stuck with a fixed set of langauge features, and a lame preprocessor that can perform some very simplistic emulations of new language features.
What if you want to embed a whole new language in C? You have to write an external processor that works with the raw text of your source code. This is exemplified by ``embedded SQL''.
If prefix notations for arithmetic really bother you, you can write a Lisp macro which translates infix to postfix, something like:
(infix x / sqrt ( x * x + y * y))
whose expansion might be
(/ x (sqrt (+ (* x x) (* y y))))
Really, if some way of programming bothers you, you can write a little compiler which translates from a notation that you find more suitable.
That's a fundamental concept in Lisp; that it's easy for programmers to write little compilers for new language features; compilers which are incorporated right into programs, and whose target language is Lisp.
The truth of the matter is that the closing parentheses don't matter one bit. What programmers read is the indentation. This is true across programming languages. Whether you are working in Lisp, Python or C, you use whitespace clues to determine program structure (in the case of Python, the language sees it the same way).
If a C program is properly formatted using one of the popular styles, then you can remove all of the braces and its meaning is still obvious; you can put the braces back automatically, or nearly so.
I've experimented with a C formatting style in which closing braces are stacked like in Lisp, and it didn't make one bit of difference to the readability of the code.
In a way, the closing brackets, braces or parentheses are for the compiler, not for the reader; the programmer simply has to ensure that they balance.
In some implementations of Lisp long ago, there was feature known as superbrace. If you wrote a right square bracket, it would close all outstanding open parentheses. I think there was one additional rule; the superbrace closing would stop upon encountering a matching open right bracket.
So you could write something like:
(defun hello() [let (foo bar) (a (b] ((c d(e)]
The first ] will properly close the outstanding parentheses all the way back to the [let. The second one will balance back to the (defun.
The superbrace did not catch on; it's not part of modern Lisp. That's could be because programmers simply didn't perceive enough of a benefit from the feature.
Comments are easily placed in Lisp code. And also, there is a way to embed documentation into functions and some other objects via the documentation string feature. This allows information about a function to be dynamically retrieved. The following illustrates how comments are written in the predominant Lisp code formatting style:
;;;
;;; This function computes the factorial of its
;;; argument x. The argument must be a
;;; non-negative integer. If the argument is 0
;;; or 1, the result is 1. Otherwise the result
;;; is the product (x)(x-1)(x-2)... 2.
;;;
(defun fact (x) "Computes the factorial function"
(case x
The comp.lang.lisp FAQ has a few pointers on style, including use of whitespace, comment placement, how many semicolons to use for what comments and the like.
Most planets in the visible Universe are probably lifeless rocks, not supporting any life at all, let alone intelligent life. It's obvious that life has lost the great battle for the planet surface. So we should do the honorable thing and just extinguish life on Earth, instead of continuining this pompous charade of assumed superiority. It will happen anyway; we are just delaying the inevitable.
Slashdot Mirror
They need to know that it's currently illegal, which is not the same thing as immoral.
They need to know that the ethical aspects of copying are highly controversial, and that words like ``piracy'' and ``intellectual property'' are nothing but propaganda terms used by people who hold a particular point of view about copying.
Lastly, they need to understand the consequences of getting caught.
Then they can make an informed decision whether or not to engage in copying, and on what scale.
Finally there was something that really delivered on the promise of freedom. Unix gave you a platitude about freedom embossed on a license plate; Linux gave you the actual freedom.
So people who are comparing OS X and Linux nearly a decade later simply don't get the point. Taking BSD code and making a proprietary layer on top of that is old hat. What do you think SunOS was?
Take a look at some family trees:
here
here
OS X is another SunOS, another Ultrix, another NeXTStep. From the point of view of someone who values freedom, not only technical excellence, it is just as irrelevant as these predecessors.
I wouldn't call this a level playing field either. Why not? Because of differences in the vendors' attitudes to the discovery of these problems.
Microsoft wants to sweep these problems under the rug; keep them as secret as possible and even criminalize those who discover them and make them known. They have a poor track record when it comes to timely releases for patches, and alerting their user base.
Do you, for instance, remember this slashdot story?
What about this?
The article is misleading; these are not dangerous toys, only toys that someone considers politically incorrect. Nothing is mentioned about any specific dangers that the toys present, only that the toys have links to violent videogames and television shows.
;)
Some of them shoot foam missiles; big deal! I think that a foot high robot that fires at room intruders is rather endearing.
Dangerous toys are things with parts that small children can choke on, stuff up their nose, or otherwise injure themselves with: sharp corners, fast-moving, massive projectiles, etc. Also, things containing dangerous substances, such as lead-based jewelry for children.
There is little connection between these properties and violence. Even in the category of fast moving things that can injure: this area is probably dominated by sporting equipment. Better not be getting your kid that hockey stick!
The usual argument for "OO syntax" is that the non-OO syntax for what is in reality an object (the file fi) "pollutes the name space" (creates lots of names of things at the global level).
That is really just a lexical problem of symbol management. Global symbol clashes are avoided by the use of packages. Lexical scoping has little or nothing to do with object orientation. Using C to emulate object oriented programming suffers from that problem because C has no namespaces or packages; programmers resort to conventions like adding a common prefix to related identifiers.
Object orientation is the semantics. Semantics
is tied to syntax, but not to any particular syntax; there is no ``object oriented syntax''. Syntax allows you to group some expressions together to express some semantic relationship.
Languages hit the wall when they have a hard-wired syntax, with hard-wired semantics.
Ruby is no exception. It's a whole lot of syntactic sugar for a bunch of non-programmable semantics. It was obsolete before it was conceived. Moreover, the author has a very limited view of what object oriented programming is, and suffers from a fundamental confusion that OO is somehow syntactically determined. This if from one of his slides:
//OOP
fi = File::new("sample.dat", "r")
fi.binmode = true
line = fi.readline()
fi.close
// Non-OOP
fi = fopen("sample.dat", "r")
fbinmode(fi, true)
line = freadline(fi)
fclose(fi)
So, in other words, something is object oriented if it uses the notation object.method(arg), but not object oriented if it uses the notation method(object, arg). Is this guy for real?
It takes a certain level of experience to see through the facade of curly braces, vertical bars, squiggles, splats, hashes, cokebottles and whatnot. Such devices, despite looking impressively cryptic and terse, do not imply any special power; they are designed to dazzle and seduce the undergraduate mind.
The real power arises when the same expression, whether it uses lots of syntactic sugar or not, can mean absolutely anything that the programmer wants, not only what the language designer wants it to mean.
Yet it takes you even more typing to demonstrate that you have no reading comprehension. Sigh.
We could equally say that freedom zero is the choice whether to rob or not to rob that convenience store across the street, and that criminals and non-criminals alike are exercising that freedom in different ways.
The underlying substrate for all human behavior is the freedom to do anything, from donating one's time to worthwy humanitarian causes to commanding troops into heinous acts of genocide. Is that range of choices part of freedom zero?
Or maybe the real freedom zero substrate is simply the laws of physics.
Stallman's definition is superior because it doesn't regress into absurd starting points; freedom is defined as a very high level intelligent behavior rooted in certain ethical principles, and that's that. That freedom is supported by lower level freedoms which allow the intelligent substrate to make choices, but these freedoms are not interesting, because these lower freedoms support all human activity alike.
What evidence do you have that the software is going to run better on Windows? What does it mean to run better on Windows? Can you cite an example of an educational software package that does run on Windows and Linux, but runs ``better'' on Windows? What experience do you have with this? Or are you just guessing again?
Secondly, you are backpedalling now. First you said that it's about the applications, such as educational applications.
Now you are saying that ``schools WANT Windows and don't want Linux''.
So which is it, educational applications? Or the operating systems?
Regarding what people want: how *can* they want any alternatives, when those alternatives are shut out from the market by a monopoly? Of course Windows is what many people want. You can't want what you haven't seen. That's a consequence of the monopolistic practices which are supposed to be *punished* here, remember?
You can run some Windows applications on Linux, using various methods. Chances are that at least some of the educational software will run.
Have you investigated what educational software does or does not run under the various solutions for running Windows apps on Linux?
Microsoft doesn't care about providing a platform for educational software; they want the kids to be hooked on their proprietary operating system and applications. Mass indoctrination of future Microserfs is the key to their survival. So this action can hardly be called an act of restitution for anti-competitive behavior.
I didn't see anything in the proposal about Microsoft not being allowed to provide their software, only that they also allow a competitor to provide software.
It's not a proposal for *only* Red Hat to provide the software, but for Red Hat to *also* provide software.
If competitors are excluded from the action, then it can hardly be called restitution for anti-competitive behavior!
The modern thing is simply the POSIX shell command language; If you write in the POSIX language, avoiding the quirks and extensions in the proprietary implementation you are using, your script should be highly portable to GNU bash and vice versa.
Similarly, if you want to write a new shell, your best bet is to use the standard as the guide rather than to clone the behavior of the legacy Bourne shell.
If you don't know what is standard and what is not, try the draft Single Unix Specification online.
Search for ``shell command language''.
``Compositing a source and destination image using a mask.''
And, undoubtedly, it was done decades before by image processing researchers.
In C and C++ parentheses influence the way the expression is parsed and hence the order in which operations are performed. They don't determine the order in which operands are evaluated.
So when you have, say
f() + (g() + h())
the functions can be called in any of the six possible orders; which order is chosen is unspecified. But there is no question that the addition on the right must be done first, in the abstract semantics.
It so happens that in C, the expresssion
a + b + c
has exactly the same meaning as
(a + b) + c
this is due to the left associativity of the + operator.
The compiler is not free to add the b + c first, if it could make some kind of difference, like a change in the result, or an exception that would otherwise not happen. The result has to be ``as if'' the abstract semantics were followed.
So for instance if a, b and c are integers, and overflow is reversible (as it is with most two's complement machines) then the addition can be done in either order. If they are floating point types, then it cannot be reordered, because floating point addition is not associative: a + (b + c) is semantically not equal to (a + b) + c.
If your compiler treats a + b + c as a + (b + c) and produces the wrong result, it's a broken (nonconforming) C or C++ implementation, as the case may be.
Common Lisp is lexically scoped. Dynamic scope is available in the form of the ``special'' declaration. If you want dynamic scoping, you must explicitly request it like this:
...))
(let (*dynamically-scoped-var*)
(declare (special *dynamically-scoped-var*))
So now with this declaration you have effectively created a local ``override'' for a global variable. If some form you evaluate from within this context refers to the identifier *dynamically-scoped-var* it will resolve to the one declared here, not the global one (unless there is a local declaration there which shadows that reference, of course).
Once upon a time, in dialects of Lisp preceding ANSI Common Lisp, this dynamic behavior was the norm. Dynamic scoping is tremendously useful, so it is retained in the form of special variables.
Some ``old timer'' Lisp users should take a second look at the current state of Lisp, because important details change.
have nothing to do with Windows, and they predate it. For example, the reason there is Linux is because people wanted a free clone of their favorite environment, which obviously wasn't Windows, and because they wanted to engage in fun hacking. That environment they wanted to clone wasn't seriously buggy or unstable; the motivation wasn't that the world needed a ``crash proof'' operating system. Only that it could use a free one.
The results have had the unexpected benefit of providing an alternative to users who are not happy with Windows for whatever reason. That there are such users, and that some of them are loud Microsoft bashers is entirely Microsoft's fault, and has nothing to do with the free software.
Gates is trying to promote the view that free software is only reaction to ``big, bad'' Microsoft, and therefore the motivation behind this software is not legitimate outside of the context of Microsoft. By extension, it's not legitimate in the context of a ``kinder, gentler'' Microsoft either.
When I started using Linux, it was because it could connect to the Internet and support multiple logged in users. At that time, Windows had no credible protocol stack for connecting to the Internet, and still cannot support multiple users today. Windows was so beneath consideration in 1992 that it wasn't even on the mental radar of any hacker. Though it has improved, the predominant consumer version still remains an unstable, unreliable crock that can't be trusted with any application needing more than a solid half a day of uptime. The industrial version of Windows is better in that regard, but that's completely besides the point. To the early adopters, Linux had to prove that it worked as well as, say, SunOS. Or reasonably well to be used in many of the same ways. Not that it crashed less than Windows; who with a clue would have been impressed with that?
So given the state of Windows when some of this free software was germinating, to call it a reaction to Windows is pathetically laughable at best. Or it would be pathetically laughable if uttered by some Anonmous Coward on Slashdot. But someone like Gates must be treated seriously; when he says so, it is a blatant, dangerous lie.
Writing a language preprocessor for C is a large granularity decision. It's going to impact how you build the program; it will have to correctly lexically analyze C source, generate syntactically correct C and so on. Writing a Lisp macro is a small, casual decision that is part of the normal flow of Lisp development; the macro is just part of your program.
Suppose you have 10 C programmers working on a project, and each of them wants to invent a few language features. So you end up with 10 translators, which require each source file to be passed through a 10 stage filter. Can you imagine that? What if there are subtle dependencies on the order of the filters, or if the output of one breaks the other? Or does not transparently pass through the language features understood by the next one? The scenario is almost unimaginable; quite likely, the very idea will be rejected as braindamaged early in the project.
In Lisp, the 10 programmers can easily have their own macro libraries contained in their modules of the program. They can use each other's macros easily, even nest them in the same code. There is nothing special to do, no code preprocessing to set up; it's not any different from using a library of functions.
Firstly, I'm a much more experienced C programmer than a Lisp programmer. Yet, the limitations of C compared to Lisp are painfully obvious to me.
Yes, C supports the fundamental unit of program abstraction known as the function. But that does not make up for the various other drawbacks.
Why C takes longer to write is because the programmer must deal with every detail of the computation---other than some machine-specific details such as allocating values to machine registers, explicitly managing the passing of parameters, or manually scaling pointer displacements based on types.
Firstly, there is the memory management. Every significantly large C program which uses dynamic memory, unless it is correctly written by a miraculous fluke, will suffer from failures due to premature deallocation of memory and memory leaks. It's not possible to create a significant data abstraction of C without encumbering it with memory management burden. A typical abstract datatype (ADT) module will have create and destroy functions which call malloc and free. The user of these functions inherits all of the responsibility that comes with malloc and free: the avoidance of premature deallocations and concerns about leaks. There are many things you can't do effectively without a garbage collector: the entire technique of functional programming is made impractically difficult. When you don't have to worry about memory allocation, you gain productivity.
Secondly, there is the strict, static type system. Static type systems get in the way of certain types of programming. Here is an example. It's not unusual for parsers written in C to use a union type to represent the items stored in a parse tree, and to use integer tags to identify what is present. What is that, if not an emulation of dynamic typing?
This brings us to my last point. Compiler writing is incorporated into the Lisp programming style, and the dynamic typing supports it directly. In Lisp, in addition to the use of functions as an abstraction mechanism, you have macros. These are not like C macros which work with tokens of the program text; they are operators that work on data structures; data structures which typically represent some programming construct and are translated into some other data structure, which represents Lisp code that will be substituted for the macro and evaluated in its place.
The techniques for abstraction provided by Lisp macros are squarely out of reach of the programmer working in C, who is stuck with a fixed set of langauge features, and a lame preprocessor that can perform some very simplistic emulations of new language features.
What if you want to embed a whole new language in C? You have to write an external processor that works with the raw text of your source code. This is exemplified by ``embedded SQL''.
If prefix notations for arithmetic really bother you, you can write a Lisp macro which translates infix to postfix, something like:
(infix x / sqrt ( x * x + y * y))
whose expansion might be
(/ x (sqrt (+ (* x x) (* y y))))
Really, if some way of programming bothers you, you can write a little compiler which translates from a notation that you find more suitable.
That's a fundamental concept in Lisp; that it's easy for programmers to write little compilers for new language features; compilers which are incorporated right into programs, and whose target language is Lisp.
The truth of the matter is that the closing parentheses don't matter one bit. What programmers read is the indentation. This is true across programming languages. Whether you are working in Lisp, Python or C, you use whitespace clues to determine program structure (in the case of Python, the language sees it the same way).
If a C program is properly formatted using one of the popular styles, then you can remove all of the braces and its meaning is still obvious; you can put the braces back automatically, or nearly so.
I've experimented with a C formatting style in which closing braces are stacked like in Lisp, and it didn't make one bit of difference to the readability of the code.
In a way, the closing brackets, braces or parentheses are for the compiler, not for the reader; the programmer simply has to ensure that they balance.
In some implementations of Lisp long ago, there was feature known as superbrace. If you wrote a right square bracket, it would close all outstanding open parentheses. I think there was one additional rule; the superbrace closing would stop upon encountering a matching open right bracket.
So you could write something like:
(defun hello() [let (foo bar) (a (b] ((c d(e)]
The first ] will properly close the outstanding parentheses all the way back to the [let. The second one will balance back to the (defun.
The superbrace did not catch on; it's not part of modern Lisp. That's could be because programmers simply didn't perceive enough of a benefit from the feature.
Comments are easily placed in Lisp code. And also, there is a way to embed documentation into functions and some other objects via the documentation string feature. This allows information about a function to be dynamically retrieved. The following illustrates how comments are written in the predominant Lisp code formatting style:
... 2.
;; if n is zero or 1, return 1
;; otherwise compute factorial recursively
;;;
;;; This function computes the factorial of its
;;; argument x. The argument must be a
;;; non-negative integer. If the argument is 0
;;; or 1, the result is 1. Otherwise the result
;;; is the product (x)(x-1)(x-2)
;;;
(defun fact (x) "Computes the factorial function"
(case x
((0 1) 1)
(otherwise (* x (fact (1- x))))))
The comp.lang.lisp FAQ has a few pointers on style, including use of whitespace, comment placement, how many semicolons to use for what comments and the like.
If protocols and interfaces are IP, then free software is in trouble.
Most planets in the visible Universe are probably lifeless rocks, not supporting any life at all, let alone intelligent life. It's obvious that life has lost the great battle for the planet surface. So we should do the honorable thing and just extinguish life on Earth, instead of continuining this pompous charade of assumed superiority. It will happen anyway; we are just delaying the inevitable.
MAPS only maintains a database that provides information to others, who seek that information.
That database expresses an opinion: in the opinion of MAPS, the networks listed in the database are suspected of passing through or generating spam.
Shouldn't this be protected by the First Amendment?
The UNIX world already had a worm that recursively exploited security holes and spread, back in 1988.
THAT was the worm to learn from, not Code Red!