I'm not sure what you're arguing... that C deserves a gold star? Sure. C deserves a gold star. (Though I'm not happy with C's happy-go-lucky attitude towards program safety.) That C is the most relevant important skill for programmers to have today? No. Definitely not.
Unlike buildings, we shouldn't start from scratch every time we write a new program; we ought to build up and only program the new stuff that's specific to our program and nothing else. C is terrible at that, which is why God gave us Lisp and the wisdom to use it. I have yet to hear anyone make a cogent argument as to why Lisp is inferior to C for general-purpose application coding (not systems-level stuff; e.g., why Excel, Word, Notepad, the calculator, Netscape, etc ought to be coded in C or C++ instead of CL or Scheme). And it's not like I haven't asked.
Well, the scheme standard doesn't define a record type. Every usable Scheme implementation extends the standard with one, and they can in fact be defined with library functions in standard Scheme (based around vectors or lists, which are provided by the standard). But it does make scheme code less portable than it ought to be, because you're right, everybody wants to use structures for things.
As for designing programming languages, I encourage you to design one for yourself. There are books on the subject -- you might want to see if you can find a library that has a copy of Essentials of Programming Languages, it'll introduce you to a lot of the decisions you'll need to make as well as giving you ideas for how to implement whatever you decide to do.
Scheme does not have any construct called "loop" defined in the standard, nor do any implementations I know of define one. R5RS (the scheme standard) does specify that scheme implementations should define in their standard libraries (!) two iteration constructs, one called "do" and the other a variant of "let" (in practice often called "let loop," which might be what you're thinking of). The standard explicitly says that these should be in the library, not primitive Scheme syntax. In practice, neither iteration construct is used all that often by experienced Schemers (I've been programming in Scheme for 5 years and I actually didn't know about the "do" macro until I looked it up just now).
So you might be wondering: How the heck do experienced Schemers loop over things if they don't use those loop constructs? And anyway, how are they implemented in the library if there are no more primitive loop constructs around?
The answer is recursion -- functions that call themselves. Scheme is all about recursion; the specification even forces implementations to make certain efficiency guarantees about it so that Schemers can recur to their hearts' content without incurring runtime penalties over looping. For instance, in C, you'd probably count the size of a list like so:
int list_size(List* l) {
int count = 0;
while (l != NULL) {
count++;
l = l->next;
}
return count; }
So, you might be thinking: 'That's nice. So it's just a funny way of saying "for" that I don't understand very well and doesn't seem to have any advantages.' A lot of people have that impression and get turned off to Scheme because of it. But it's not true: for one thing, see how much prettier my second Scheme definition is than my first? It's more compact, and once you get used to it, easier to write, read, and debug. Furthermore, it's more directly applicable to many programming situations, particularly when they involve complex data. Read all about it in How to Design Programs, an excellent introductory textbook on Scheme and programming.
And nope, the Scheme standard defines no record or structure type. Look through the standard yourself, you won't find it there. This is in fact pretty frustrating to the Scheme community.
As for assembly, first of all, remember that every processor has its own assembly language and they're not all the same. That said, jump is not the same as a loop. Jump means "go straight to some other point in my program and keep going," which is more general than loop (but can be used to implement loop).
Scheme doesn't have for / next, while / do, or records/structures in its standard (though records are implemented in every useable implementation). Besides, high-power Lisp programming is all about macros, which don't even exist in any serious way in any other language (C macros are a joke in comparison; read On Lisp by Paul Graham for good reasons why). Your usual functional programming suspects -- Haskell, ML, etc -- as well as hard-core OO languages eschew most uses of the control operators you list in general.
I just meant that any language you're likely to ever use as a "real programming language" is Turing-complete, not that every possible language is. (Of course, that's a lie: no language on a real computer is Turing-complete, as computers have finite state, but gads, let's not be technical.)
If I here one more person pontificate about god-damn Turing-completeness, I'm gonna beat my poor innocent co-worker Gustavo here to a bloody pulp.
Once and for all: YES, EVERY DAMN LANGUAGE AND ITS MOTHER IS TURING-COMPLETE. Turing-machine language is Turing-complete. Unlambda is Turing-complete. Life is Turing-complete. Programming in one is not, however, anything like programming in the other. They are NOT "the same" any more than my co-worker Gustavo is the same as a chicken, though they're both DNA-complete.
If what you're interested in is actually programming in a language as opposed to proving theorems about it, Turing-completeness is almost entirely irrelevant. There are distinct, major, definite benefits to using one Turing-complete language over another.
That's not really reading between the lines so much as reading the lines themselves, don't you think? And while I think there are more fundamental problems with HTTP than the ones he mentions, I think he's essentially right: HTTP wasn't really designed to do what we want to do with it, so we ought to use another protocol instead.
You are confused. There are such things as s-expressions, which are, loosely, any sort of balanced nested parenthesis thingy:
((() ((hi) (there mr)) slashdot) guy () () ())
is one, for example. Lisp (and Scheme, a dialect of Lisp) both a) represents programs as a particular subset of s-expressions, which we'll call the set of s-programs (which makes sense, right? Every program is a piece of data, but not every piece of data is a program), and b) has facilities for very easily manipulating s-expressions -- they are Lisp's favorite datatype (the name LISP comes from "LISt Processor," in fact, and s-expressions are really just a way of writing down lists). The appeal of using Lisp dialects to process XML is based not on the fact that those programs are S-expressions, but that they process S-expressions easily -- and, as it turns out, XML expressions can be trivially converted to S-expressions -- let's say that there's a subset of s-expressions called X-expressions, and there's a trivial bidirectional mapping between X-expressions and XML expressions.
So, let's say you want to write a program that reads and/or writes XML to communicate with the world. You can just write your program as a normal old S-expression-manipulating program, like Lispers have been doing since 1958, and then right where you read in the data, you call some function that reads an XML datum instead, and right where you write it out, you call some function that writes an XML expression. Now you can still use all the XML-processing gizmos you already have, but you can also write your own XML-processing gizmos really easily. In fact, I've been involved for some time in a Web programming language project, and that's how we manipulate XHTML: we read in XHTML expressions, manipulate them with Scheme code that's easy to write because the XHTML-to-S-expression mapping is so thin, and then write out XHTML expressions to the web browser. None of the other XML-based tools in the chain (the web browser, XML editors you use to generate the web page templates, et cetera) need to know or care about the fact that my implementation is in Scheme.
The only smugness you hear from the Lisp people (and this is where the faux comparisons between Lisp and XML come in) stems from the fact that Lispers have been storing their data the way XML does, only more cleanly and with less typing, for years. Now XML comes along and everybody thinks it's going to usher in world peace and change the way we put our pants on. Well, dammit, Lispers were already putting their pants on a different way, thank you very much!
I don't think you correctly understand what the OP was saying. What he said, translated into CS-ese, was "The set of XML expressions is isomorphic to the set of Lisp s-expressions," a true statement. What you heard was, "The set of XML expressions is isomorphic to the set of Scheme programs," which is clearly not at all true -- as you point out, XML (and s-expressions) can be used to describe any sort of data, while valid Scheme programs are much more constrained and can only describe a particular set of computations (though the cool thing about Lisp is that programs are themselves represented as a subset of the very same sort of data that Lisp programs are best at manipulating, which is why Lisp macros are so incredibly more powerful than C macros). However, there's a trivial map from XML expressions to S-expressions, and Lisp loves S-expressions more than any other kind of data, which means that Lisp loves XML expressions almost as much.
C's ability to declare functions is a good tool for abstraction, but doesn't come close to the power of abstraction you can get in Scheme/Lisp.
For example, there is a standard library function in Scheme (and every other halfway-functional language in existence) called map. map takes a function and any number of lists, and returns a new list such that element X of the returned list is the result of applying the given function to element X of each of the input lists. So, for instance,
(map + (list 1 2 3) (list 4 5 6))
is (list 5 7 9)
In Scheme, the function map is extremely easy to write -- it's certainly appropriate for a student in a beginning programming course taught in Scheme after about five or so weeks. In C, even if you substitute arrays for lists, map as described would be a real pain to implement -- I challenge you, in fact, to write a version that's as general as the Scheme version. And, if you're really up for a challenge, find someone who's had as much experience in Scheme as you have in C, and race.:)
Of course, nobody misses map in C (well, nobody who isn't indoctrinated in functional programming, anyway). C programmers just idiomatically write for or while loops instead. And, surprise surprise, C programmers are always making silly little mistakes that cost time -- "Oops! I got that termination condition wrong!" "Oops! I incremented the wrong counter!" "Oops! I forgot to initialize that variable to zero!" "Oops! I forgot to allocate memory for the return array!" Sure, they're mistakes that C programmers learn to catch quickly because they happen so frequently. But my 5-week-educated Scheme programmer will never have any of those bugs, and won't ever have to spend any time finding or fixing them.
1) you should use lisp because its emacs friendly.
Among other, much more important things.
2)we use notation thats different then what mathmaticians use, but is better
Better for a programming language, yes. If you're really in love with having to know what's left versus right associative, try ML. Not that you'd like it, judging from your comments.
3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.
Of course not. That would be stupid. Lisp programmers (or more likely Lisp implementors) feel that adding a constant slowdown is acceptable when it leads to markedly sped-up program development. All engineers do this: you don't design your CPU chips by thinking about NMOS and PMOS, and you generally don't even think about NAND and NOR gates either (one level of abstraction up). You could probably make a faster chip if you hand-optimized all that logic, but it would take 10 years to make the damn thing and you'd never be sure there wasn't some crazy obscure bug lurking in it.
4)bracket intense sphagetti code is a good thing.
Of course not. Lisp programs have a beautiful organization when programmed in the proper style. You're just not familiar with it.
5)old guys can be even more fanatical about an obscure language then 'lee7 w4rez d00dz'
No argument there. But fanatical in a good way.
6)its bad that the most powerfully, rich, and technological nation on the planet had a cultural influence on the computer industry.
Reading comprehension was never your strong suit in high school, was it?
7)LAMBDA is just a way to maintain lisp leetness
Or, there's no good reason to change it, so why break all the existing code and bother all the existing programmers? Besides, if you really care about it, FUNCTION instead of LAMBDA is a macro-definition away.
Try spending more of your effort trying to figure out what it is about Lisp and Scheme that make people like it rather than wasting it on knee-jerk vitriol.
Maybe your teacher really is a moron, but you're sounding just like one of the many many people (myself included, once upon a time) who get upset with Scheme because it actually forces them to understand programming at a deep level as opposed to just banging out code that they only understand poorly. Ask yourself, if you can't hand-evaluate a program, how can you claim you know what it does? Maybe (probably) you're "fighting with the language" exactly because you don't understand this area as well as you cood. Particularly in Scheme, learning the semantics in detail is an extremely worthwhile exercise, as Scheme's semantics are very simple [thanks in part to those parentheses you hate so much]. Vague understandings of the semantics of any language lead to programs that you only vaguely understand, and that only work sorta-kinda. If you aspire to be that kind of programmer, quit now and do something else.
And about your fractal program, I suspect that your Scheme algorithm was a worse algorithm than the C++ version. Newcomers to Scheme frequently do things like accidentally computing recursions more frequently than necessary, and if you're seeing that big a speed difference it's very likely that's what's going on. Also, DrScheme imposes a pretty big (constant factor) speed penalty itself due to all of the debugging support it provides. If you ran your program directly in MzScheme you'd gain significant speed savings, but nothing compared to optimizing the algorithm to remove inefficiencies.
1. Java is Turing-complete. As is every programming language you're ever likely to run into. Rule of thumb. How the implementation happens to run the code (VM, compiled to assembly, hand-evaluated with pencil and paper) is irrelevant.
Actually, the PLT Scheme distribution comes with a tool called MrSpidey that does implicit static type analysis on your Scheme programs. It allows recursive types and all that fun stuff. The only problem is it doesn't work well when you use some of PLT Scheme's more advanced features, such as its class system.
... It took just three lines of code for Grossman to breach Hotmail filters and access Passport ID and credit card data. The second time it took just one line.
You can also get rid of the watermark by flipping all the zero's to one's, so looks like watermarking isn't a problem after all!
Seriously, real watermarks are designed to be tough to destroy without degrading the audio substantially -- for example, I believe all of the "SDMI challenge" watermark schemes could survive being played over speakers and re-recorded by a microphone. So sure, you can apply your own watermark to the file, but that's not likely to "step on" the other watermark unless yours is so lossy that it destroys the original signal.
On the other hand, many people (including myself and additionally some people who actually know what they're talking about) believe that it just isn't possible to create a watermark that CD players, Windows, etc can detect but that can't be removed by anyone who can arbitrarily permute the file. Furthermore, it ought to always be possible to remove the watermark and not degrade the original data any more than the original watermarking process did. --
-jacob
Q. By participating in the challenge, weren't you helping the record companies impose restrictive technology on
music lovers?
and...
Q. By participating in the challenge, weren't you helping pirates steal copyrighted music, impoverishing musicians
and songwriters?
We believe our success against all four watermarking technologies, and our sharing of those results with other researchers, will
not help anyone impose or steal anything.
On the one hand, this information cannot be used to make restrictive technology. If anything, it suggests that all of the proposed
technology is incapable of being restrictive.
On the other hand, this information cannot be used by pirates if the technologies are never deployed. This is why it is best to
perform analysis on a security system before it is released.
Q. Still, wouldn't it have been better for SDMI had you not analyzed their system?
SDMI invited the public to analyze their technologies (to "crack them" said their invitation,) setting up a web site and hiring
people to assist. Also, any weaknesses in SDMI's technology would have existed even if we hadn't looked for them---analysts
do not create flaws, but merely detect them---and if the SDMI system had been deployed as is, pirates would have found and
exploited those weaknesses, regardless of our actions.
The study of information security is based on two equally important components: the design of security systems, and the analysis
of (attempts to break) those security systems. One occasionally encounters the misconception that analysis is destructive and
evil, and that people performing analysis are attackers who wish to exploit those systems. Rather, analysis is a critical
component of the development process. Without it, one would never know if systems were well-designed, and one would never
learn how to design better systems.
Q. Still, wouldn't it have been better for opponents of SDMI if you let SDMI go ahead and deploy a flawed
technology, so music lovers could teach them a lesson by copying music despite the technology?
Of course not. This is scientific research: it is not our goal to engage in tactics such as tricking the industry into choosing a flawed
system. Our goal is simply to analyze security systems and share our results openly with the scientific community.
Again, researchers who crack cryptosystems and security systems are not motivated by a desire to exploit these flaws later.
They are merely subjecting systems to analysis, motivated instead by a desire to increase the existing body of knowledge about
security systems.
Secondly, if the technology is cracked in deployment, rather than on the drawing board, everyone loses to some extent. The
recording industry obviously, device manufacturers most certainly, but even opponents of SDMI. Even pirates! To an opponent
of SDMI, even a broken, circumventable SDMI system is worse than no SDMI system at all.
Absolutely. If you can't handle using character 13 rather than character 59 to end a statement and character 100 rather than character 123 to start a block, you'll be totally screwed when you see the way prolog does it.
Does everybody on slashdot think that the only salient feature of Python is that it doesn't use curly braces?
Get over it!
I am being quite serious. If that modest syntax change is enough to keep you from considering a language, you're doomed as a programmer to linguistic provencialism that will keep you from seeing some really elegant ways to simplify and modularize your code. Ever programmed in Erlang? Haskell? Scheme? Prolog? You might end up preferring a more mainstream language after all is said and done, but the experience of seeing the new ways of doing things will certainly make those mainstream programs better.
You'll never get that experience, though, if you get scared by the syntactic differences between those languages and C (which are vast). So do yourself a favor and try to see beyond a language's syntax.
When you look at it in the abstract, in a "look at the bug in this fragment" sort of a way, it's obvious. But I've lost at least an hour or so to debugging that sort of thing, and back when I used to be a lab assistant for a beginning programming class I saw people making that error all the time. --
-jacob
God, how many more unfounded assertions about how bad university education sucks can you get in one post? As for how much it costs: at my school (Rice University in Houston) tuition is around $10,000 a year. It costs, on average, ~$50-70,000 to educate a Rice student for a year, meaning that the university itself is coughing up most of the cash. Though the numbers vary, the trend holds true for most prestigious universities in the US (I don't have any information about community colleges, etc).
Also at Rice, the faculty is well-paid but not ridiculously paid for the most part. And while there are some professors who don't like to teach particular topics to which they have been assigned, by far the majority of my professors have been both amazingly intelligent and dedicated to communicating their knowledge and skills to their pupils. Again, Rice is by no means alone on that front.
I can't speak for everyone, but as for myself, I certainly have not gotten the education that my father got at school- my education has been ten times better, by his accounting and mine. --
-jacob
Umm... no. A language is syntax and semantics. It may be that a particular vendor provides a nice library for a particular language, but that doesn't mean jack for the language itself. Syntax and semantics.
And if you think that syntax and semantics are irrelevant: you're wrong.
1) Lego Mindstorms... 2) Games games games... 3) Simulation... 4) Simple AI...
That reminds me: I think that having a class-wide RealTimeBattle competition would be awesome. RealTimeBattle kind of incorporates all of these four elements: you have a computer-simulated robot that competes with other computer-simulated robots in a simulated world where they (what else?) try to blow each other up. Really easy to make a dumb robot, really hard to make a great robot. I have always thought that RTB would be a great way to suck kids into liking CS.
IIRC, RTB is GPLed but currently only runs on Linux. On the other hand, the robots can be written in anything (server spawns child processes and talks to them via stdin/stdout) and I bet it wouldn't be too much of a trick to write a "wrapper" robot that ran on Linux and just forwarded requests and responses over a TCP connection, so the robots themselves could be running on a Windows or Mac box. -- -jacob
Slashdot Mirror
I'm not sure what you're arguing ... that C deserves a gold star? Sure. C deserves a gold star. (Though I'm not happy with C's happy-go-lucky attitude towards program safety.) That C is the most relevant important skill for programmers to have today? No. Definitely not.
Unlike buildings, we shouldn't start from scratch every time we write a new program; we ought to build up and only program the new stuff that's specific to our program and nothing else. C is terrible at that, which is why God gave us Lisp and the wisdom to use it. I have yet to hear anyone make a cogent argument as to why Lisp is inferior to C for general-purpose application coding (not systems-level stuff; e.g., why Excel, Word, Notepad, the calculator, Netscape, etc ought to be coded in C or C++ instead of CL or Scheme). And it's not like I haven't asked.
Well, the scheme standard doesn't define a record type. Every usable Scheme implementation extends the standard with one, and they can in fact be defined with library functions in standard Scheme (based around vectors or lists, which are provided by the standard). But it does make scheme code less portable than it ought to be, because you're right, everybody wants to use structures for things.
As for designing programming languages, I encourage you to design one for yourself. There are books on the subject -- you might want to see if you can find a library that has a copy of Essentials of Programming Languages, it'll introduce you to a lot of the decisions you'll need to make as well as giving you ideas for how to implement whatever you decide to do.
Scheme does not have any construct called "loop" defined in the standard, nor do any implementations I know of define one. R5RS (the scheme standard) does specify that scheme implementations should define in their standard libraries (!) two iteration constructs, one called "do" and the other a variant of "let" (in practice often called "let loop," which might be what you're thinking of). The standard explicitly says that these should be in the library, not primitive Scheme syntax. In practice, neither iteration construct is used all that often by experienced Schemers (I've been programming in Scheme for 5 years and I actually didn't know about the "do" macro until I looked it up just now).
So you might be wondering: How the heck do experienced Schemers loop over things if they don't use those loop constructs? And anyway, how are they implemented in the library if there are no more primitive loop constructs around?
The answer is recursion -- functions that call themselves. Scheme is all about recursion; the specification even forces implementations to make certain efficiency guarantees about it so that Schemers can recur to their hearts' content without incurring runtime penalties over looping. For instance, in C, you'd probably count the size of a list like so:
int list_size(List* l) {
int count = 0;
while (l != NULL) {
count++;
l = l->next;
}
return count;
}
In scheme, you could define it the same way:
(define (list-count lst)
(let ((count 0))
(let loop ((r lst))
(if (null? lst)
count
(begin
(set! count (add1 count))
(loop (cdr r)))))))
... but that would be awful scheme. More advanced schemers would write
(define (list-count lst)
(cond
((null? lst) 0)
(else (add1 (list-count (cdr lst))))))
or even:
(define (list-count lst) (foldr add1 0 lst))
So, you might be thinking: 'That's nice. So it's just a funny way of saying "for" that I don't understand very well and doesn't seem to have any advantages.' A lot of people have that impression and get turned off to Scheme because of it. But it's not true: for one thing, see how much prettier my second Scheme definition is than my first? It's more compact, and once you get used to it, easier to write, read, and debug. Furthermore, it's more directly applicable to many programming situations, particularly when they involve complex data. Read all about it in How to Design Programs , an excellent introductory textbook on Scheme and programming.
And nope, the Scheme standard defines no record or structure type. Look through the standard yourself, you won't find it there. This is in fact pretty frustrating to the Scheme community.
As for assembly, first of all, remember that every processor has its own assembly language and they're not all the same. That said, jump is not the same as a loop. Jump means "go straight to some other point in my program and keep going," which is more general than loop (but can be used to implement loop).
Scheme doesn't have for / next, while / do, or records/structures in its standard (though records are implemented in every useable implementation). Besides, high-power Lisp programming is all about macros, which don't even exist in any serious way in any other language (C macros are a joke in comparison; read On Lisp by Paul Graham for good reasons why). Your usual functional programming suspects -- Haskell, ML, etc -- as well as hard-core OO languages eschew most uses of the control operators you list in general.
I just meant that any language you're likely to ever use as a "real programming language" is Turing-complete, not that every possible language is. (Of course, that's a lie: no language on a real computer is Turing-complete, as computers have finite state, but gads, let's not be technical.)
" ... but they all have if, then, else, for / next, while / do, records/structures, and many other features that are similar ... "
No. Every mainstream language, maybe, but not all languages by a longshot.
If I here one more person pontificate about god-damn Turing-completeness, I'm gonna beat my poor innocent co-worker Gustavo here to a bloody pulp.
Once and for all: YES, EVERY DAMN LANGUAGE AND ITS MOTHER IS TURING-COMPLETE. Turing-machine language is Turing-complete. Unlambda is Turing-complete. Life is Turing-complete. Programming in one is not, however, anything like programming in the other. They are NOT "the same" any more than my co-worker Gustavo is the same as a chicken, though they're both DNA-complete.
If what you're interested in is actually programming in a language as opposed to proving theorems about it, Turing-completeness is almost entirely irrelevant. There are distinct, major, definite benefits to using one Turing-complete language over another.
That's not really reading between the lines so much as reading the lines themselves, don't you think? And while I think there are more fundamental problems with HTTP than the ones he mentions, I think he's essentially right: HTTP wasn't really designed to do what we want to do with it, so we ought to use another protocol instead.
goddammit.
((() ((hi) (there mr)) slashdot) guy () () ())
is one, for example. Lisp (and Scheme, a dialect of Lisp) both a) represents programs as a particular subset of s-expressions, which we'll call the set of s-programs (which makes sense, right? Every program is a piece of data, but not every piece of data is a program), and b) has facilities for very easily manipulating s-expressions -- they are Lisp's favorite datatype (the name LISP comes from "LISt Processor," in fact, and s-expressions are really just a way of writing down lists). The appeal of using Lisp dialects to process XML is based not on the fact that those programs are S-expressions, but that they process S-expressions easily -- and, as it turns out, XML expressions can be trivially converted to S-expressions -- let's say that there's a subset of s-expressions called X-expressions, and there's a trivial bidirectional mapping between X-expressions and XML expressions.
So, let's say you want to write a program that reads and/or writes XML to communicate with the world. You can just write your program as a normal old S-expression-manipulating program, like Lispers have been doing since 1958, and then right where you read in the data, you call some function that reads an XML datum instead, and right where you write it out, you call some function that writes an XML expression. Now you can still use all the XML-processing gizmos you already have, but you can also write your own XML-processing gizmos really easily. In fact, I've been involved for some time in a Web programming language project, and that's how we manipulate XHTML: we read in XHTML expressions, manipulate them with Scheme code that's easy to write because the XHTML-to-S-expression mapping is so thin, and then write out XHTML expressions to the web browser. None of the other XML-based tools in the chain (the web browser, XML editors you use to generate the web page templates, et cetera) need to know or care about the fact that my implementation is in Scheme.
The only smugness you hear from the Lisp people (and this is where the faux comparisons between Lisp and XML come in) stems from the fact that Lispers have been storing their data the way XML does, only more cleanly and with less typing, for years. Now XML comes along and everybody thinks it's going to usher in world peace and change the way we put our pants on. Well, dammit, Lispers were already putting their pants on a different way, thank you very much!
I don't think you correctly understand what the OP was saying. What he said, translated into CS-ese, was "The set of XML expressions is isomorphic to the set of Lisp s-expressions," a true statement. What you heard was, "The set of XML expressions is isomorphic to the set of Scheme programs," which is clearly not at all true -- as you point out, XML (and s-expressions) can be used to describe any sort of data, while valid Scheme programs are much more constrained and can only describe a particular set of computations (though the cool thing about Lisp is that programs are themselves represented as a subset of the very same sort of data that Lisp programs are best at manipulating, which is why Lisp macros are so incredibly more powerful than C macros). However, there's a trivial map from XML expressions to S-expressions, and Lisp loves S-expressions more than any other kind of data, which means that Lisp loves XML expressions almost as much.
C's ability to declare functions is a good tool for abstraction, but doesn't come close to the power of abstraction you can get in Scheme/Lisp.
For example, there is a standard library function in Scheme (and every other halfway-functional language in existence) called map. map takes a function and any number of lists, and returns a new list such that element X of the returned list is the result of applying the given function to element X of each of the input lists. So, for instance,
(map + (list 1 2 3) (list 4 5 6))is
(list 5 7 9)
In Scheme, the function map is extremely easy to write -- it's certainly appropriate for a student in a beginning programming course taught in Scheme after about five or so weeks. In C, even if you substitute arrays for lists, map as described would be a real pain to implement -- I challenge you, in fact, to write a version that's as general as the Scheme version. And, if you're really up for a challenge, find someone who's had as much experience in Scheme as you have in C, and race. :)
Of course, nobody misses map in C (well, nobody who isn't indoctrinated in functional programming, anyway). C programmers just idiomatically write for or while loops instead. And, surprise surprise, C programmers are always making silly little mistakes that cost time -- "Oops! I got that termination condition wrong!" "Oops! I incremented the wrong counter!" "Oops! I forgot to initialize that variable to zero!" "Oops! I forgot to allocate memory for the return array!" Sure, they're mistakes that C programmers learn to catch quickly because they happen so frequently. But my 5-week-educated Scheme programmer will never have any of those bugs, and won't ever have to spend any time finding or fixing them.
1) you should use lisp because its emacs friendly.
Among other, much more important things.
2)we use notation thats different then what mathmaticians use, but is better
Better for a programming language, yes. If you're really in love with having to know what's left versus right associative, try ML. Not that you'd like it, judging from your comments.
3)Lisp programmer feel that speed is un-important because there is enough processor speed. (that little comment made me want to put my fist through my monitor) clearly not made by an engineer.
Of course not. That would be stupid. Lisp programmers (or more likely Lisp implementors) feel that adding a constant slowdown is acceptable when it leads to markedly sped-up program development. All engineers do this: you don't design your CPU chips by thinking about NMOS and PMOS, and you generally don't even think about NAND and NOR gates either (one level of abstraction up). You could probably make a faster chip if you hand-optimized all that logic, but it would take 10 years to make the damn thing and you'd never be sure there wasn't some crazy obscure bug lurking in it.
4)bracket intense sphagetti code is a good thing.
Of course not. Lisp programs have a beautiful organization when programmed in the proper style. You're just not familiar with it.
5)old guys can be even more fanatical about an obscure language then 'lee7 w4rez d00dz'
No argument there. But fanatical in a good way.
6)its bad that the most powerfully, rich, and technological nation on the planet had a cultural influence on the computer industry.
Reading comprehension was never your strong suit in high school, was it?
7)LAMBDA is just a way to maintain lisp leetness
Or, there's no good reason to change it, so why break all the existing code and bother all the existing programmers? Besides, if you really care about it, FUNCTION instead of LAMBDA is a macro-definition away.
Try spending more of your effort trying to figure out what it is about Lisp and Scheme that make people like it rather than wasting it on knee-jerk vitriol.
Maybe your teacher really is a moron, but you're sounding just like one of the many many people (myself included, once upon a time) who get upset with Scheme because it actually forces them to understand programming at a deep level as opposed to just banging out code that they only understand poorly. Ask yourself, if you can't hand-evaluate a program, how can you claim you know what it does? Maybe (probably) you're "fighting with the language" exactly because you don't understand this area as well as you cood. Particularly in Scheme, learning the semantics in detail is an extremely worthwhile exercise, as Scheme's semantics are very simple [thanks in part to those parentheses you hate so much]. Vague understandings of the semantics of any language lead to programs that you only vaguely understand, and that only work sorta-kinda. If you aspire to be that kind of programmer, quit now and do something else. And about your fractal program, I suspect that your Scheme algorithm was a worse algorithm than the C++ version. Newcomers to Scheme frequently do things like accidentally computing recursions more frequently than necessary, and if you're seeing that big a speed difference it's very likely that's what's going on. Also, DrScheme imposes a pretty big (constant factor) speed penalty itself due to all of the debugging support it provides. If you ran your program directly in MzScheme you'd gain significant speed savings, but nothing compared to optimizing the algorithm to remove inefficiencies.
1. Java is Turing-complete. As is every programming language you're ever likely to run into. Rule of thumb. How the implementation happens to run the code (VM, compiled to assembly, hand-evaluated with pencil and paper) is irrelevant.
2. Sun's Java compiler is written in Java.
Actually, the PLT Scheme distribution comes with a tool called MrSpidey that does implicit static type analysis on your Scheme programs. It allows recursive types and all that fun stuff. The only problem is it doesn't work well when you use some of PLT Scheme's more advanced features, such as its class system.
From the article:
You can also get rid of the watermark by flipping all the zero's to one's, so looks like watermarking isn't a problem after all!
Seriously, real watermarks are designed to be tough to destroy without degrading the audio substantially -- for example, I believe all of the "SDMI challenge" watermark schemes could survive being played over speakers and re-recorded by a microphone. So sure, you can apply your own watermark to the file, but that's not likely to "step on" the other watermark unless yours is so lossy that it destroys the original signal.
On the other hand, many people (including myself and additionally some people who actually know what they're talking about) believe that it just isn't possible to create a watermark that CD players, Windows, etc can detect but that can't be removed by anyone who can arbitrarily permute the file. Furthermore, it ought to always be possible to remove the watermark and not degrade the original data any more than the original watermarking process did.
--
-jacob
Your claim that the researchers were just helping out the RIAA has been made to the researchers many times.
From the faq:
--
-jacob
Absolutely. If you can't handle using character 13 rather than character 59 to end a statement and character 100 rather than character 123 to start a block, you'll be totally screwed when you see the way prolog does it.
--
-jacob
Does everybody on slashdot think that the only salient feature of Python is that it doesn't use curly braces?
Get over it!
I am being quite serious. If that modest syntax change is enough to keep you from considering a language, you're doomed as a programmer to linguistic provencialism that will keep you from seeing some really elegant ways to simplify and modularize your code. Ever programmed in Erlang? Haskell? Scheme? Prolog? You might end up preferring a more mainstream language after all is said and done, but the experience of seeing the new ways of doing things will certainly make those mainstream programs better.
You'll never get that experience, though, if you get scared by the syntactic differences between those languages and C (which are vast). So do yourself a favor and try to see beyond a language's syntax.
--
-jacob
When you look at it in the abstract, in a "look at the bug in this fragment" sort of a way, it's obvious. But I've lost at least an hour or so to debugging that sort of thing, and back when I used to be a lab assistant for a beginning programming class I saw people making that error all the time.
--
-jacob
God, how many more unfounded assertions about how bad university education sucks can you get in one post? As for how much it costs: at my school (Rice University in Houston) tuition is around $10,000 a year. It costs, on average, ~$50-70,000 to educate a Rice student for a year, meaning that the university itself is coughing up most of the cash. Though the numbers vary, the trend holds true for most prestigious universities in the US (I don't have any information about community colleges, etc).
Also at Rice, the faculty is well-paid but not ridiculously paid for the most part. And while there are some professors who don't like to teach particular topics to which they have been assigned, by far the majority of my professors have been both amazingly intelligent and dedicated to communicating their knowledge and skills to their pupils. Again, Rice is by no means alone on that front.
I can't speak for everyone, but as for myself, I certainly have not gotten the education that my father got at school- my education has been ten times better, by his accounting and mine.
--
-jacob
Umm... no. A language is syntax and semantics. It may be that a particular vendor provides a nice library for a particular language, but that doesn't mean jack for the language itself. Syntax and semantics.
And if you think that syntax and semantics are irrelevant: you're wrong.
(Sorry to sound like a curmudgeon.)
--
-jacob
1) Lego Mindstorms...
2) Games games games...
3) Simulation...
4) Simple AI...
That reminds me: I think that having a class-wide RealTimeBattle competition would be awesome. RealTimeBattle kind of incorporates all of these four elements: you have a computer-simulated robot that competes with other computer-simulated robots in a simulated world where they (what else?) try to blow each other up. Really easy to make a dumb robot, really hard to make a great robot. I have always thought that RTB would be a great way to suck kids into liking CS.
IIRC, RTB is GPLed but currently only runs on Linux. On the other hand, the robots can be written in anything (server spawns child processes and talks to them via stdin/stdout) and I bet it wouldn't be too much of a trick to write a "wrapper" robot that ran on Linux and just forwarded requests and responses over a TCP connection, so the robots themselves could be running on a Windows or Mac box.
--
-jacob