Nobody's calling you a crook until you break legality and morality. People using this service are breaking both.
It's not a question of legality versus morality; if it were, doing the right thing would be illegal. In this case, though, doing the wrong thing is what's illegal.
I do agree that the industry here is trying to take your rights away. But this site has nothing to do with that effort, nor any other; it's simply some moneygrubbers violating copyright for profit.
Cost is a means of allocating scarce resources, as I'm sure you've heard. Some of this plan requires specific, scarce resources, and thus will raise costs; others, though, will effectively reduce scarcity in other resources, and will thus be useful to the people needing them.
The ethical part of the argument needs to be heard, of course; but pragmatically and immediately, this plan makes sense.
Joy is just another language; I'm not convinced it's done right any more than Forth is. The interesting thing on that page isn't Joy itself; it's the conceptual background which the author builds up to describe a set of languages which lack application of functions to parameters.
But, other than being implementable in just a few kilobytes, what's the advantage of the Joy approach? It seems to be a rather tortuous way to write functional programs.
An excellent question. I could answer it by giving a list of advantages, but I think that would be beside the point.
I do not wish to imply that there are no disadvantages, nor that concatenative language are 'better' than (traditional) applicative ones. I simply wish to demonstrate that the differences between the two camps are real and useful, not mere obfuscation for its own sake. Concatenative languages should be an object of study, and more languages should at least include a concatenative subset, just as many languages now include a purely applicative subset.
Note your own saying -- Forth is fun. Why shouldn't we use languages which are fun? Why is Forth fun, and would it be possible to separate its fun from some of the admittedly inconvenient features?
My goal has been to try to answer those questions.
I'm not going to try to do that in this short space; but I will note a few convenient features of concatenative languages.
All of their typographical rewriting rules apply regardless of the semantics of the words making up the program(s). It doesn't matter whether the words modify state, do I/O, or anything else. So, concatenative languages can ALWAYS be typographically analysed. This is a HUGE improvement versus applicative languages, which contain a number of rewriting rules that only apply in special semantic cases (for example, the famous "referential transparency", which only applies in a very narrow context). This reduces many refactorings to a simple case of cut'n'paste. It also helps explain why Forth engages the mind in a way other low-level languages cannot: in spite of its native low level, it's easy to reason about its programs.
The textual nature of the rewriting rules makes metaprogramming in concatenative languages very easy (as I mentioned elsewhere, it's no accident that reliable Postscript can be generated easily by even C programs; imagine how much more powerful programs can be generated by a language aware of its own rewriting rules.
The data structure required to represent code is very simple. In Lisp it's a tree; the forks represent parameters of a function call. In concatenative languages it's merely a list: one action, then another, then another.
The only known means to make a language concatenative is to use a stack. This happens to not only make implementing the language trivial; it also makes a number of very useful results trivial.
Compiling requires no parsing, only lexing.
Strong polymorphic static typechecking can be done in the compiling pass, with no lookahead or behind.
Dataflow analysis is already done by the programmer, so the compiler can use the intelligence of the programmer to help it do its job of resource allocation. Urgently needed items are at the top of the stack; less urgently needed ones are at the bottom. Cache the top of stack in registers; page the bottom out; put the items between in varying speeds of memory, depending on depth in the stack. The only task for the compiler is to know the resources of the computer it'll be running on, so it can allocate the caches properly.
If you'd like a better answer, please ask the question on the concatenative language mailing list. It's a very good question, and will get an answer from many, including myself.
I never heard of the term "concatenative languages", can you give a good reference?
Sure thing. Check out the main Joy page. The mailing list linked to from that page is also a very good resource.
I have programmed in both Forth and PostScript; they are incrementally compiled languages with a postfix syntax and no static typing.
Non-incremental Forth compilers are not uncommon; most people never use Postscript incrementally. A strongly statically typed variant of Forth exists (strongForth). And finally, although both do use RPN, they do not have a true postfix syntax; they lack syntax of any kind. Postfix syntax _requires_ that operators appear after their operands; RPN doesn't require operators and operands to have any static relationship.
The important distinction that the two languages share is that
1. any concatenation of valid programs produces another valid program and 2. any dissection of a valid program produces two valid programs.
(Condition #2 is the equivalent of "referential transparancy" in lambda-based languages: it's nice to have for reasoning, but there are some handy things to have which make it impossible sometimes.)
Concatenativity implies a whole different set of rewriting rules, some of which are quite powerful compared to the applicative/lambda rewriting rules. It turns out to be a whole different way of thinking.
And as a bonus, the implementation is very simple, fast, and highly optimizable. Because data is managed by the programmer on a stack, the compiler doesn't have to guess what datum is more important than which other one; the stack provides a total ordering, and if the compiler can simply provide faster access to the top of the stack things speed up a lot.
Well, I'm impressed! That is indeed almost exactly what I was hoping for.
I'm going to be spending some time reading the draft. The intro slideshow lacked something I was hoping for, though: it's based almost entirely on the lambda (variable passing) model. Are all your concepts built around that, or do you have some dataflow programming (as in APL/J/K) or concatenative programming (as in Forth/Postscript/Joy)? If so, your book would be of immense use to me, since I'm attempting to research the properties of concatenative languages (a shamefully neglected area of computer science).
Thanks for the book! I hope I can afford the hardcopy when it comes out... That looks like it'll be an INCREDIBLY massive tome. I'm not even going to be able to print it out, it's so massive.
I'm not an old APLer; I was kind of a language collector, who tried and failed to learn APL because of its keyboard. J was much easier:-). K I still don't know, mainly because of its proprietariness; I'm not willing to put that much effort into any language, no matter how cool (and K is really, really cool) unless I can use it when and where I want to.
But as you can tell, I recognise and salute useful uniqueness; K has that, in spades. It may be a derivative of APL, but it's the most creative derivative of any language I've seen. (J is a close second.)
It makes me wish I needed kdb, to give me an excuse to learn the language even though it's proprietary. kdb is an insanely cool killer app. KILLER!!!!!! Astounding. Amazing. And utterly simple, thanks to K.
But K also has another advantage, which would make it useful in the context of this question: it's capable of being used in a manner like Scheme and other Algol-like languages. This makes teaching it take a LOT less time than J or APL would take, but you can still get to the real useful differences and make them fun.
I think the authors of SICP realized there were other models out there,
I agree -- they did a brilliant job. There's no way they could have noticed and documented so clearly so many of the problems with lambda notation if they hadn't known the other ways of looking at things. Nonetheless, they didn't choose to document those other models, and a wise teacher doing what he's asking for will want to document.
and I think they might disagree with the statement that lambda calculus have almost nothing to do with how computers work.
Then they'd be utterly ignorant. They probably never read the part of SICP which discusses the problems with various models of lambda computation;-). See below.
Sussman was a co-author on several papers, the titles of which approximated: "Lambda: The ultimate goto instruction." I think Sussman and Abelson know a lot more about cs than you give them credit for.
What you say here tends to discredit them, if it were true. I happen to know that they're smarter than that -- they DO know that lambda isn't a good model for computation, and they spend quite a bit of space in SICP teaching that.
Lambda isn't anything close to the ultimate goto. Continuations are. Shudder. But no matter.
Why isn't lambda a good computational model? Quite simply, because computers don't work merely by applying parameters to functions. They work by assigning values to locations. The reality of computing is almost entirely non-functional (in the sense that it's impossible to write a truly "pure" function, one with no variable modifications). Lambda notation has led inevitably to the false idea that the only way to write analysable programs is to avoid state modification; thus, a false dichotomy between OO and functional programming.
Calling a function isn't _really_ the same thing as passing it parameters, although C and Lisp make it look that way. Calling a function is actually pushing the current continuation on the return stack and jumping to the address of the new function. Passing a parameter is an entirely separate action.
The only languages I know which actually model that correctly are Forth, Postscript, and Joy. Thus, a Forth program can be both functional _and_ OO; it can be both functional and imperative. The only thing it can't be is both declarative and imperative (except in the silly sense of declaring a sequence of actions, naturally).
There's much more on this at the Joy page, whose URL I can't remember but which is linked from the Summary at the Concatenative Languages eGroup.
Agreed. This one's _essential_. In fact, I would go so far as to say I've seen no other choice; if you want to learn both how to program and how to think about programming, this is the only book which combines both.
The only problem, as I point out in another message, is that they almost totally ignore other conceptual models of programming; lambda calculus is thoroughly explored, but combinatorial logic and similar models, as demonstrated impurely by APL/J/K and purely by Forth/Postscript/Joy, are almost ignored. A good teacher would, IMO, base a class on SICP, but augment with two of the above languages and a discussion of their paradigms.
The granddaddy of this type has to be MIT Press' SICP. It's a programming intro, but it teaches you lambda calculus as well as the problems with lambda calculus.
Lambda isn't everything, and a good teacher should also cover some languages which use it lightly (J and K) as well as a language which doesn't use it at all (Forth, Postscript, Joy) -- but it's good to have as a starter. SICP doesn't teach 'conceptual models', though; I don't think that the authors even realised there were other conceptual models out there. Most people don't, since most people don't even know that lambda calculus has almost nothing to do with how computers work, but is rather just the way most programming languages have been designed, in imitation of Fortran.
But I can't slam SICP. It may not cover other conceptual models, but it does a BANG-up job of covering the one it acknowledges, and even points out the weaknesses.
Weaknesses had been discovered before that, IIRC; but the cracking used to take too long to be really practical. The revealed key just was a little shortcut which let some people watch DVDs even though the cracking wasn't complete.
Now that key is repealed, and fortunately for people wanting to watch DVDs on Linux, the algorithm is also cracked. Every time you put a DVD in your open-source player, the player cracks the key. That's why there's often a pause before the disc starts playing.
-Billy
Re:Development Processes be damned..
on
Bitter Java
·
· Score: 2
I agree that Lisp &c are great languages and C++ is a crock, but you're wrong that the only programmers using DPs are C++ and Java programmers. They're simply the only ones who have a commonly known shared vocabulary for talking about their language's needed design patterns.
As you can see from the discussion of the Visitor pattern, design patterns are native to languages; Lisp removes the need for the Visitor pattern with CLOS's multiple dispatch. However, by doing that Lisp doesn't reduce the total number of design patterns available to it; instead, it makes higher-level design patterns easier to express.
So in a sense some of the DPs you see in the book are meant to cover language weaknesses -- but before you get to proud about not having _those_ weaknesses, remember Godel's principle: you also have weaknesses. C++ is not a weaker language simply because it needs the Visitor design pattern; it's weaker for many other reasons, involving complexity and impetuous design (or lack of design).
Consider before you assume that DPs are signs of weakness: Smalltalk also uses DPs, and Smalltalk is _far_ from being a weak language.
One caveat: make sure your browsing app supports the Handera's hi-res. Scaling just doesn't cut it for semi-graphical and graphical apps.
Oh, and games. If you play a lot of games, check to see whether the current versions support the Handera -- if they don't, you probably won't want to play them on a HE. If you still want the game, the Sony CLIE line is very good, and still high-res (even though Handera's the more reliable company).
Makes sense to me. AFAIK, there are no known resistant strains of bacteria, but it's probably not impossible to be resistant, and sooner or later we're going to create an environment where such resistant bacteria will thrive. I don't want to be near that environment:-).
Of course, who knows how nasty the 'antibacterial' agent is to you, either. I don't.
-Billy (who DOES support the use of soap -- odd, perhaps I'm hypocritical or simply a luddite)
You're not as clever as you want to be. There is no Latin plural for 'virus', since virus is a collective noun (meaning something like 'scum'). Now that 'virus' has an singular meaning, it has to be pluralised, and since it doesn't have a plural in its native language, its adoptive language has to give it one.
Thus, 'viruses' is acceptable, and the original poster is far from a 'dumbass'. Wait, never mind -- you weren't calling names, you were only signing your name.;-)
This seems to prove that the biggest part of lambda calculus isn't needed, doesn't it? Hardly a "win".
I do like combinatorial calculus, though; especially in non-applicative form. You know, the form where functions don't get applied to their parameters; instead, functions get applied to the stack, which contains the result of previous functions. (That is, function composition becomes the fundamental operation.) Lots of interesting results.
Currying is also interesting, but is more studied:-).
Maybe that depends on your accent -- the classical Greek I was taught had a hard Chi, kind of like a breathed kappa, or 'kh'. The h sound alone wasn't possible.
Facinating! I'll have to try to recreate that. Was there any microwave damage?
I know that I've done it before without complete submersion -- perhaps I was just (un)lucky, or perhaps only the tip matters, or maybe it only hurts if there's sharpened metal (that's a general rule with MWs -- area doesn't matter, only edge).
Thanks for the pointers -- and I think I'll have to say that newbies should start by submerging their threads. At least until we figure out why yours exploded.
Anyhow, this is probably my favorite demonstration; quick, easy, cheap.
I've sparked metal in the microwave before (aluminum foil or an old CD). What's the danger? What exactly is going to "explode"?
True, you don't want to do it heavily or with an otherwise empty microwave; the magnetron has enough heating problems anyhow (hear that noisy fan?); but that's why you also use a dish of water, to give the microwaves something to be absorbed by. Note that the water isn't conductive (we're not adding salt), so there's no reason for it to innately prevent sparks.
I'm going to have to try this with my spare microwave. While hiding behind a concrete wall, holding a panic switch. I'm a pyro, not an idiot:-).
Quite true! It's interesting that the resulting light show is _not_ monochomatic, as you might expect -- it flashes through many colors. Definitely worth doing.
I'm not sure whether it matters that the threaded end is submerged (or even touching the water), though. I've always had it that way, but only because that's how the bulb sits. Maybe I'll have to try...
I'm gonna use my +1 bonus to retract my previous post. Thanks for pointing out what I missed, guys. The KDE ad was cool, but it went on to actually talk about useful stuff.
I hope the judge pays more attention than I did.:-)
when did we get the RIGHT to acquire and possess? i always thought life, liberty and the pursuit of happiness were our rights.
Those rights are not ever given in the U.S. Constitution (from which I assume you're trying to quote). They're assumed to be preexistant. As you point out, the third one isn't mentioned even in the preamble; however, it was included in the rough drafts, and removed for PR reasons (no, I'm serious -- check your history). Whether they're named or not, the rights are not considered something which is given to us; rather, they are innate; and property was considered one of the fundamental rights (consider the amendment which mentions privacy in one's own home; how can you have privacy in your home if you do not have a home?).
how can you use the words moral and capitalism in the same sentence without a punchline?
Capitalism is the least moral form of economy, with the exception of all other forms of economy.
Okay, that WAS a punch line. Let me try again.
Capitalism provides a framework against which moral judgements can be made. All of the other economic systems which have been proposed have failed to do so; most of them have instead provided absolute declarations of morality, without any means of checking.
This means to me that capitalism doesn't contain a science of morality; it doesn't make declarations like "stealing is bad". Instead, it predicts what happens when people do specific things (including stealing in all its different forms).
Randian economics isn't capitalism, by the way; it's capitalism plus a specific set of ethical principles (most of which I happen to find abhorrent and silly, since I do not subscribe to the principle that might makes right).
I hit that while looking for names I recognised. I was amazed by how much of a flak piece it seemed at first, and even more amazed when the flak didn't stop.
The/whole thing/ was an ad for KDE.
Well, they stopped for one sentence to say "We don't think the settlement will stop MS from crushing us," but they didn't say a word about/why/, nor about how to construct one which did stop the crushing process.
As an ad, it was pretty and will reach an interestingly large audience (I'm a huge fan of that!). As a legal document, its value is essentially that of the statement "I'm afraid of Microsoft, and would continue to be afraid after this agreement were enacted." That's not good.
I really don't know why they selected it for publishing -- surely there were better choices, right? Can anyone tell me why?
-Billy
This is huge for MPEG4
on
Video with Depth
·
· Score: 5, Informative
I don't believe nobody has posted about MPEG4. This is very interesting for that -- film using this, and you can encode into MPEG4 format with/huge/ compression almost automatically. The hard part about MPEG4 is object detection; this makes that almost free.
Thanks, Larry. I'm glad to hear that BK has all the abilities of Aegis (and therefore my recollection is mistaken); I've been eagerly following it for a long time, and have been on the bk-users mailing list since the beginning. It's a great looking product.
I respectfully disagree with you about supporting TestFirst. I agree completely that it can be done, but I believe that if you try it, you'll find that doing it/right/ is a substantial task. See Aegis for more information. This isn't a shortcoming of Bitkeeper, of course; it's merely the nature of good tools (i.e. a good tool takes some effort to get right).
I'm glad to hear that you now support the http protocol. I shall have to try installing again; the last several times I installed it didn't work, because my stinking firewall blocked it (I really don't like our firewall). I also don't like the fact that all the Bitkeeper web-browsable repositories use a non-standard port; this means that my firewall blocks them, even though they're presumably ordinary HTML/http servers (they are, right?).
Slashdot Mirror
Nobody's calling you a crook until you break legality and morality. People using this service are breaking both.
It's not a question of legality versus morality; if it were, doing the right thing would be illegal. In this case, though, doing the wrong thing is what's illegal.
I do agree that the industry here is trying to take your rights away. But this site has nothing to do with that effort, nor any other; it's simply some moneygrubbers violating copyright for profit.
-Billy
Cost is a means of allocating scarce resources, as I'm sure you've heard. Some of this plan requires specific, scarce resources, and thus will raise costs; others, though, will effectively reduce scarcity in other resources, and will thus be useful to the people needing them.
The ethical part of the argument needs to be heard, of course; but pragmatically and immediately, this plan makes sense.
-Billy
Joy is just another language; I'm not convinced it's done right any more than Forth is. The interesting thing on that page isn't Joy itself; it's the conceptual background which the author builds up to describe a set of languages which lack application of functions to parameters.
:-).
But, other than being implementable in just a few kilobytes, what's the advantage of the Joy approach? It seems to be a rather tortuous way to write functional programs.
An excellent question. I could answer it by giving a list of advantages, but I think that would be beside the point.
I do not wish to imply that there are no disadvantages, nor that concatenative language are 'better' than (traditional) applicative ones. I simply wish to demonstrate that the differences between the two camps are real and useful, not mere obfuscation for its own sake. Concatenative languages should be an object of study, and more languages should at least include a concatenative subset, just as many languages now include a purely applicative subset.
Note your own saying -- Forth is fun. Why shouldn't we use languages which are fun? Why is Forth fun, and would it be possible to separate its fun from some of the admittedly inconvenient features?
My goal has been to try to answer those questions.
I'm not going to try to do that in this short space; but I will note a few convenient features of concatenative languages.
All of their typographical rewriting rules apply regardless of the semantics of the words making up the program(s). It doesn't matter whether the words modify state, do I/O, or anything else. So, concatenative languages can ALWAYS be typographically analysed. This is a HUGE improvement versus applicative languages, which contain a number of rewriting rules that only apply in special semantic cases (for example, the famous "referential transparency", which only applies in a very narrow context). This reduces many refactorings to a simple case of cut'n'paste. It also helps explain why Forth engages the mind in a way other low-level languages cannot: in spite of its native low level, it's easy to reason about its programs.
The textual nature of the rewriting rules makes metaprogramming in concatenative languages very easy (as I mentioned elsewhere, it's no accident that reliable Postscript can be generated easily by even C programs; imagine how much more powerful programs can be generated by a language aware of its own rewriting rules.
The data structure required to represent code is very simple. In Lisp it's a tree; the forks represent parameters of a function call. In concatenative languages it's merely a list: one action, then another, then another.
The only known means to make a language concatenative is to use a stack. This happens to not only make implementing the language trivial; it also makes a number of very useful results trivial.
Compiling requires no parsing, only lexing.
Strong polymorphic static typechecking can be done in the compiling pass, with no lookahead or behind.
Dataflow analysis is already done by the programmer, so the compiler can use the intelligence of the programmer to help it do its job of resource allocation. Urgently needed items are at the top of the stack; less urgently needed ones are at the bottom. Cache the top of stack in registers; page the bottom out; put the items between in varying speeds of memory, depending on depth in the stack. The only task for the compiler is to know the resources of the computer it'll be running on, so it can allocate the caches properly.
If you'd like a better answer, please ask the question on the concatenative language mailing list. It's a very good question, and will get an answer from many, including myself.
Slashdot just isn't really appropriate
-Billy
I never heard of the term "concatenative languages", can you give a good reference?
Sure thing. Check out the main Joy page. The mailing list linked to from that page is also a very good resource.
I have programmed in both Forth and PostScript; they are incrementally compiled languages with a postfix syntax and no static typing.
Non-incremental Forth compilers are not uncommon; most people never use Postscript incrementally. A strongly statically typed variant of Forth exists (strongForth). And finally, although both do use RPN, they do not have a true postfix syntax; they lack syntax of any kind. Postfix syntax _requires_ that operators appear after their operands; RPN doesn't require operators and operands to have any static relationship.
The important distinction that the two languages share is that
1. any concatenation of valid programs produces another valid program
and
2. any dissection of a valid program produces two valid programs.
(Condition #2 is the equivalent of "referential transparancy" in lambda-based languages: it's nice to have for reasoning, but there are some handy things to have which make it impossible sometimes.)
Concatenativity implies a whole different set of rewriting rules, some of which are quite powerful compared to the applicative/lambda rewriting rules. It turns out to be a whole different way of thinking.
And as a bonus, the implementation is very simple, fast, and highly optimizable. Because data is managed by the programmer on a stack, the compiler doesn't have to guess what datum is more important than which other one; the stack provides a total ordering, and if the compiler can simply provide faster access to the top of the stack things speed up a lot.
-Billy
Well, I'm impressed! That is indeed almost exactly what I was hoping for.
I'm going to be spending some time reading the draft. The intro slideshow lacked something I was hoping for, though: it's based almost entirely on the lambda (variable passing) model. Are all your concepts built around that, or do you have some dataflow programming (as in APL/J/K) or concatenative programming (as in Forth/Postscript/Joy)? If so, your book would be of immense use to me, since I'm attempting to research the properties of concatenative languages (a shamefully neglected area of computer science).
Thanks for the book! I hope I can afford the hardcopy when it comes out... That looks like it'll be an INCREDIBLY massive tome. I'm not even going to be able to print it out, it's so massive.
-Billy
Grin. Thanks!
:-). K I still don't know, mainly because of its proprietariness; I'm not willing to put that much effort into any language, no matter how cool (and K is really, really cool) unless I can use it when and where I want to.
I'm not an old APLer; I was kind of a language collector, who tried and failed to learn APL because of its keyboard. J was much easier
But as you can tell, I recognise and salute useful uniqueness; K has that, in spades. It may be a derivative of APL, but it's the most creative derivative of any language I've seen. (J is a close second.)
It makes me wish I needed kdb, to give me an excuse to learn the language even though it's proprietary. kdb is an insanely cool killer app. KILLER!!!!!! Astounding. Amazing. And utterly simple, thanks to K.
But K also has another advantage, which would make it useful in the context of this question: it's capable of being used in a manner like Scheme and other Algol-like languages. This makes teaching it take a LOT less time than J or APL would take, but you can still get to the real useful differences and make them fun.
-Billy
I think the authors of SICP realized there were other models out there,
;-). See below.
I agree -- they did a brilliant job. There's no way they could have noticed and documented so clearly so many of the problems with lambda notation if they hadn't known the other ways of looking at things. Nonetheless, they didn't choose to document those other models, and a wise teacher doing what he's asking for will want to document.
and I think they might disagree with the statement that lambda calculus have almost nothing to do with how computers work.
Then they'd be utterly ignorant. They probably never read the part of SICP which discusses the problems with various models of lambda computation
Sussman was a co-author on several papers, the titles of which approximated: "Lambda: The ultimate goto instruction." I think Sussman and Abelson know a lot more about cs than you give them credit for.
What you say here tends to discredit them, if it were true. I happen to know that they're smarter than that -- they DO know that lambda isn't a good model for computation, and they spend quite a bit of space in SICP teaching that.
Lambda isn't anything close to the ultimate goto. Continuations are. Shudder. But no matter.
Why isn't lambda a good computational model? Quite simply, because computers don't work merely by applying parameters to functions. They work by assigning values to locations. The reality of computing is almost entirely non-functional (in the sense that it's impossible to write a truly "pure" function, one with no variable modifications). Lambda notation has led inevitably to the false idea that the only way to write analysable programs is to avoid state modification; thus, a false dichotomy between OO and functional programming.
Calling a function isn't _really_ the same thing as passing it parameters, although C and Lisp make it look that way. Calling a function is actually pushing the current continuation on the return stack and jumping to the address of the new function. Passing a parameter is an entirely separate action.
The only languages I know which actually model that correctly are Forth, Postscript, and Joy. Thus, a Forth program can be both functional _and_ OO; it can be both functional and imperative. The only thing it can't be is both declarative and imperative (except in the silly sense of declaring a sequence of actions, naturally).
There's much more on this at the Joy page, whose URL I can't remember but which is linked from the Summary at the Concatenative Languages eGroup.
-Billy
Agreed. This one's _essential_. In fact, I would go so far as to say I've seen no other choice; if you want to learn both how to program and how to think about programming, this is the only book which combines both.
The only problem, as I point out in another message, is that they almost totally ignore other conceptual models of programming; lambda calculus is thoroughly explored, but combinatorial logic and similar models, as demonstrated impurely by APL/J/K and purely by Forth/Postscript/Joy, are almost ignored. A good teacher would, IMO, base a class on SICP, but augment with two of the above languages and a discussion of their paradigms.
-Billy
The granddaddy of this type has to be MIT Press' SICP. It's a programming intro, but it teaches you lambda calculus as well as the problems with lambda calculus.
Lambda isn't everything, and a good teacher should also cover some languages which use it lightly (J and K) as well as a language which doesn't use it at all (Forth, Postscript, Joy) -- but it's good to have as a starter. SICP doesn't teach 'conceptual models', though; I don't think that the authors even realised there were other conceptual models out there. Most people don't, since most people don't even know that lambda calculus has almost nothing to do with how computers work, but is rather just the way most programming languages have been designed, in imitation of Fortran.
But I can't slam SICP. It may not cover other conceptual models, but it does a BANG-up job of covering the one it acknowledges, and even points out the weaknesses.
-Billy
Weaknesses had been discovered before that, IIRC; but the cracking used to take too long to be really practical. The revealed key just was a little shortcut which let some people watch DVDs even though the cracking wasn't complete.
Now that key is repealed, and fortunately for people wanting to watch DVDs on Linux, the algorithm is also cracked. Every time you put a DVD in your open-source player, the player cracks the key. That's why there's often a pause before the disc starts playing.
-Billy
I agree that Lisp &c are great languages and C++ is a crock, but you're wrong that the only programmers using DPs are C++ and Java programmers. They're simply the only ones who have a commonly known shared vocabulary for talking about their language's needed design patterns.
As you can see from the discussion of the Visitor pattern, design patterns are native to languages; Lisp removes the need for the Visitor pattern with CLOS's multiple dispatch. However, by doing that Lisp doesn't reduce the total number of design patterns available to it; instead, it makes higher-level design patterns easier to express.
So in a sense some of the DPs you see in the book are meant to cover language weaknesses -- but before you get to proud about not having _those_ weaknesses, remember Godel's principle: you also have weaknesses. C++ is not a weaker language simply because it needs the Visitor design pattern; it's weaker for many other reasons, involving complexity and impetuous design (or lack of design).
Consider before you assume that DPs are signs of weakness: Smalltalk also uses DPs, and Smalltalk is _far_ from being a weak language.
-Billy
My experience as well.
One caveat: make sure your browsing app supports the Handera's hi-res. Scaling just doesn't cut it for semi-graphical and graphical apps.
Oh, and games. If you play a lot of games, check to see whether the current versions support the Handera -- if they don't, you probably won't want to play them on a HE. If you still want the game, the Sony CLIE line is very good, and still high-res (even though Handera's the more reliable company).
-Billy
Makes sense to me. AFAIK, there are no known resistant strains of bacteria, but it's probably not impossible to be resistant, and sooner or later we're going to create an environment where such resistant bacteria will thrive. I don't want to be near that environment :-).
Of course, who knows how nasty the 'antibacterial' agent is to you, either. I don't.
-Billy (who DOES support the use of soap -- odd, perhaps I'm hypocritical or simply a luddite)
You're not as clever as you want to be. There is no Latin plural for 'virus', since virus is a collective noun (meaning something like 'scum'). Now that 'virus' has an singular meaning, it has to be pluralised, and since it doesn't have a plural in its native language, its adoptive language has to give it one.
;-)
Thus, 'viruses' is acceptable, and the original poster is far from a 'dumbass'. Wait, never mind -- you weren't calling names, you were only signing your name.
-Billy
I'm sure the money factor was analyzed much more closely and accurately than the "principal of the thing"
;-)
Isn't the "principal of the thing" all about money? As opposed to the principle of the thing?
-Billy
This seems to prove that the biggest part of lambda calculus isn't needed, doesn't it? Hardly a "win".
:-).
I do like combinatorial calculus, though; especially in non-applicative form. You know, the form where functions don't get applied to their parameters; instead, functions get applied to the stack, which contains the result of previous functions. (That is, function composition becomes the fundamental operation.) Lots of interesting results.
Currying is also interesting, but is more studied
-Billy
Maybe that depends on your accent -- the classical Greek I was taught had a hard Chi, kind of like a breathed kappa, or 'kh'. The h sound alone wasn't possible.
-Billy
Facinating! I'll have to try to recreate that. Was there any microwave damage?
I know that I've done it before without complete submersion -- perhaps I was just (un)lucky, or perhaps only the tip matters, or maybe it only hurts if there's sharpened metal (that's a general rule with MWs -- area doesn't matter, only edge).
Thanks for the pointers -- and I think I'll have to say that newbies should start by submerging their threads. At least until we figure out why yours exploded.
Anyhow, this is probably my favorite demonstration; quick, easy, cheap.
-Billy
I've sparked metal in the microwave before (aluminum foil or an old CD). What's the danger? What exactly is going to "explode"?
:-).
True, you don't want to do it heavily or with an otherwise empty microwave; the magnetron has enough heating problems anyhow (hear that noisy fan?); but that's why you also use a dish of water, to give the microwaves something to be absorbed by. Note that the water isn't conductive (we're not adding salt), so there's no reason for it to innately prevent sparks.
I'm going to have to try this with my spare microwave. While hiding behind a concrete wall, holding a panic switch. I'm a pyro, not an idiot
-Billy
Quite true! It's interesting that the resulting light show is _not_ monochomatic, as you might expect -- it flashes through many colors. Definitely worth doing.
I'm not sure whether it matters that the threaded end is submerged (or even touching the water), though. I've always had it that way, but only because that's how the bulb sits. Maybe I'll have to try...
-Billy
I'm gonna use my +1 bonus to retract my previous post. Thanks for pointing out what I missed, guys. The KDE ad was cool, but it went on to actually talk about useful stuff.
:-)
I hope the judge pays more attention than I did.
-Billy
when did we get the RIGHT to acquire and possess? i always thought life, liberty and the pursuit of happiness were our rights.
Those rights are not ever given in the U.S. Constitution (from which I assume you're trying to quote). They're assumed to be preexistant. As you point out, the third one isn't mentioned even in the preamble; however, it was included in the rough drafts, and removed for PR reasons (no, I'm serious -- check your history). Whether they're named or not, the rights are not considered something which is given to us; rather, they are innate; and property was considered one of the fundamental rights (consider the amendment which mentions privacy in one's own home; how can you have privacy in your home if you do not have a home?).
how can you use the words moral and capitalism in the same sentence without a punchline?
Capitalism is the least moral form of economy, with the exception of all other forms of economy.
Okay, that WAS a punch line. Let me try again.
Capitalism provides a framework against which moral judgements can be made. All of the other economic systems which have been proposed have failed to do so; most of them have instead provided absolute declarations of morality, without any means of checking.
This means to me that capitalism doesn't contain a science of morality; it doesn't make declarations like "stealing is bad". Instead, it predicts what happens when people do specific things (including stealing in all its different forms).
Randian economics isn't capitalism, by the way; it's capitalism plus a specific set of ethical principles (most of which I happen to find abhorrent and silly, since I do not subscribe to the principle that might makes right).
-Billy
I hit that while looking for names I recognised. I was amazed by how much of a flak piece it seemed at first, and even more amazed when the flak didn't stop.
/whole thing/ was an ad for KDE.
/why/, nor about how to construct one which did stop the crushing process.
The
Well, they stopped for one sentence to say "We don't think the settlement will stop MS from crushing us," but they didn't say a word about
As an ad, it was pretty and will reach an interestingly large audience (I'm a huge fan of that!). As a legal document, its value is essentially that of the statement "I'm afraid of Microsoft, and would continue to be afraid after this agreement were enacted." That's not good.
I really don't know why they selected it for publishing -- surely there were better choices, right? Can anyone tell me why?
-Billy
I don't believe nobody has posted about MPEG4. This is very interesting for that -- film using this, and you can encode into MPEG4 format with /huge/ compression almost automatically. The hard part about MPEG4 is object detection; this makes that almost free.
-Billy
Thanks, Larry. I'm glad to hear that BK has all the abilities of Aegis (and therefore my recollection is mistaken); I've been eagerly following it for a long time, and have been on the bk-users mailing list since the beginning. It's a great looking product.
/right/ is a substantial task. See Aegis for more information. This isn't a shortcoming of Bitkeeper, of course; it's merely the nature of good tools (i.e. a good tool takes some effort to get right).
I respectfully disagree with you about supporting TestFirst. I agree completely that it can be done, but I believe that if you try it, you'll find that doing it
I'm glad to hear that you now support the http protocol. I shall have to try installing again; the last several times I installed it didn't work, because my stinking firewall blocked it (I really don't like our firewall). I also don't like the fact that all the Bitkeeper web-browsable repositories use a non-standard port; this means that my firewall blocks them, even though they're presumably ordinary HTML/http servers (they are, right?).
-Billy