(Correction: that petition link is pretty limp; it is the wrong petition. I can't find the real one with ~50k signatures, though I found two more small ones. Please forgive me.)
I can't locate sales figures for the 12" PB G4, but I can state anecdotally that I saw many of them, with satisfied owners. A reasonably fierce following, too. Conversely, I have not seen a single MB Air nor do I know anyone, including all members of a Mac users' mailing list I am on, who owns one or even wants to. I don't think Apple chose the most profitable market segment here.
"The people that are interested in [the MacBook Air] are not interested in buying it," said one reseller. "MacBook Air is too expensive; it's kind of a niche market product," said another. Still others characterized the notebook as a travelers companion for "high income people," or a tool for "executives."
Well, thank god someone around here can understand a comment that wasn't written in crayon. Perhaps I'm just underestimating the "Traveler who is too much of a pussy to lug around three extra pounds, yet does not wish to switch batteries mid-flight" market segment, but perhaps not.
Not all that nice. After roasting, beans need 8-12h in open air to emit CO2, otherwise you end up with sour coffee (due to carbonic acid). Also, after the CO2 evaporates, it's generally agreed that a rest period of 4-7 days brings out the best flavor in roasted beans. Two machines would have been a better choice.
Amherst is too far! I had a life in Cambridge and didn't want to give it up. Lowell was a not-too-painful commute and the engineering program is decent enough.
First, thanks for the second-guessing. You remind me of me, six or seven years ago.
Second, I assure you that nothing, but nothing sunk in during my three 18.03 attempts, except that I shouldn't stick around for #4. However, I remembered enough of the syllabi to recognize that the state school covered almost the exact same material. It was by no means the Dummies' guide you might like to think it was; it was merely taught by a professor who knew how to talk about math and connect with his students, rather than draw colored diagrams on the chalkboard and giggle (I'm looking at you, Prof. Toomre.)
Finally, I remind you of Hartley Rogers' multi-volume 18.02 textbook which was "published" by MIT CopyTech for about ten years before a real printer picked it up. Don't worry, I'm sure he wrote his own text because of all the bleeding-edge developments in multivariable calculus which occurred in the 1990s.
I don't mean to totally rip the place down. MIT has some great courses; 6.001 (Structure and Interpretation of Computer Programs) as taught by Abelson and Sussman is the greatest course I ever took in my life, without question. That said, however, MIT's greatest resource is its community. I learned far, far more outside an MIT classroom than inside it.
Bad professors were a big problem for me. I attended MIT and a state school. Most courses, especially on the bottom rungs, were taught much better at the state school. MIT, like many engineering schools, focuses on its professors' research more than their teaching skills. I failed MIT's differential equations course three times, yet earned an A at the state school. Did diff eq change sometime in the three intervening years, or the 35 miles from one school to the next?
Bad textbooks often follow from bad professors. Beware especially the profs who insist upon using their self-written textbook. That goes double for the ones which can't get the book published, and in turn force you to buy a crappy GBC-bound xerox from the campus duplication center.
I never had a good counselor. Good counselors can give you career advice. My counselors were already-overworked professors clamoring for tenure; not only did they lack the insight a good counselor could provide, but they also lacked much time.
I would not have the non-inflated grades any other way. I also don't trust grades to be a very good diagnostic figure for a student's effort, aptitude, or potential.
And as for homework... engineering is ingenuity (same root word), rooted in math and reality (which we usually call "physics"). The math bears repetition. It's not that I liked doing math exercises all the time, but now that I am on the other side, I fully appreciate its necessity. There were math concepts which I did not totally grasp until I had hammered on them for years.
Paul Graham's Prolog-in-Lisp trick from On Lisp is an inspiring example of embedding a DSL in a general-purpose language. However, when you say:
That could easily be done by implementing the solving strategies as functions in a general purpose language, especially if that language supports elegant representation of the inputs to your "logic programming library".
I do not agree with the boldfaced word. Just because it can be done by Paul Graham, in Lisp, doesn't mean Joe Bitslinger has a chance in hell of doing it in C#, or Java, or even Python or Perl or Ruby, or hell -- even Lisp herself. The bottom-up coding style of Lisp does not translate easily to most other languages, even the Lispy ones.
I think it's more suitable for the world at large to have a few good implementations of Prolog to choose from, and then to hook it into whatever general-purpose language is best for the overall task. I think we will see a lot more of this, and better performance thereof, as VMs are extended to support more languages and more interoperability between languages, as e.g. the Parrot VM from the Perl 6 fiasco aspires to do.
If you're Paul Graham, then you can do what you want; just because Stormtroopers use guns doesn't mean that the Jedi shouldn't use light sabers.
I'll leave you with Greenspun's Tenth Rule, and RTM's Corollary:
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Philip Greenspun
Oh, I don't know, you can make some pretty big programs with lanugages like PERL, Python, and Ruby. Also, Javascript is no slouch either, and it's based upon Self rather than Java.
no shit dude, way to ignore what I just said and listen to yourself yap
It's no more of a tarpit than your suggested "unpopular" functional languages.
I'm talking about the tarpit as a metaphor not for a particular language, but for the uselessness a discussion about computer languages takes on when Turing equivalency is brought up to imply practical equivalency. It doesn't, and never will, and anyone who says it does is probably trying to win an argument at all costs.
Okay, maybe "effortless" was a stretch. If the effort is performed behind the scenes (i.e. in the compiler or execution environment) then it can become pretty effortless to the programmer. In any case, parallelizing shared-nothing code is a much simpler problem than writing threadsafe code in languages with shared anything.
PERL, Ruby, Python, JavaScript (which is more based upon LISP than Java, despite the name), for instance. So, one could learn any of those languages and learn about functional programming from them. You don't have to learn about functional programming from languages that aren't very popular or commonly used.
You can get your feet wet, but to take advantage of many benefits to functional language (for instance, ML's superb type inference, or Erlang's formidable scalability), you need to go unpopular. You are correct, though; functional programming style fits in many languages which are not strictly functional.
I have to completely disagree with OP here. First, Logic Programming is based upon the idea of relations between sets of objects. These relations are usually expressed as equations of some form.
"rules of a system"
Logic programming turns up in many places: type inference (OCAML, CAML, ML, etc.), dependency analysis (the various make's and project builders), databases (think SQL), and spell checking.
All specialized tasks. You might embed Prolog in Word to perform spell checking; you don't write Word in Prolog.
All of this to one side, one can note that since the set of all functions is a subset of the set of all relations, lambda calculus can be no more powerful than relational programming. Therefore, Logic Programming is at least as capable of solving a problem as C or the like.
Functional languages seek to express all operations as a chain of functions which operate on data and return other data. "Function" is used in its mathematical sense here. Purely functional languages discourage state, and don't allow mutable variables. The lack of state and mutability give rise to some power; effortless parallelizability, for instance.
Logic languages are something different altogether. They provide a framework for defining the rules of a system, then searching for answers which fit the given rules. Logic programming is not useful for general-purpose tasks, but can hugely reduce programming time in tasks which are difficult to solve any other way.
or maybe you could actually learn what 'postfix' is.
to address the GP: it isn't clear (to me, at least) what the successor to Postfix will be. There is no successor thus far which makes Postfix look thoroughly old-fashioned.
In traditional webapps, we build systems that are stateful and transaction oriented. Thus is fundamentally a consequence of the way the web works.
Not so fast! I think you trivialize how well 90% of websites fit into a stateful, transaction-oriented architecture -- especially when hosting and serving requirements are factored in. I don't think that's a consequence of the way the web works, but rather the opposite; I think the way the web works is a consequence of the tools that power most of it.
Of course Seaside is not limited to crazy workflows and such; it just gets its chance to shine in situations like that, because the 90% solution falls apart quickly.
But, we are getting off the topic, here, which is, of course Ruby. OTOH, I think Ruby is just Smalltalk's bastard, warped stepchild, so maybe it's not so off-topic after all.;)
Smalltalk has so many children! Ruby and Objective-C are my favorites, but in general, I'm happy to see pure message-passing semantics wherever I run across them.
Call/cc can become useful in web applications where you have a batshit insane workflow. Seaside, the Smalltalk web framework, bets the farm on it. It's in other places like Perl's Jifty too.
Most of the web apps I write wouldn't benefit from this sort of treatment, so I haven't jumped in too far, but call/cc has its uses for sure.
Up until now, Adobe hasn't done much in terms of porting its applications to Linux, as its only product to have recieved any kind of Linux implementation is Flash.
Adobe FrameMaker has run on more than 10 Unixes over the years, including Linux. Consider this nit picked!
Slashdot Mirror
(Correction: that petition link is pretty limp; it is the wrong petition. I can't find the real one with ~50k signatures, though I found two more small ones. Please forgive me.)
I just posted a link above, reporting on the MB Air's shitty market performance to date. Here are a couple more.
http://www.crunchgear.com/2008/02/12/resellers-say-macbook-air-sales-arent-as-brisk-as-original-macbook/
http://www.pcpro.co.uk/news/165960/macbook-air-sales-deflated.html
I can't locate sales figures for the 12" PB G4, but I can state anecdotally that I saw many of them, with satisfied owners. A reasonably fierce following, too. Conversely, I have not seen a single MB Air nor do I know anyone, including all members of a Mac users' mailing list I am on, who owns one or even wants to. I don't think Apple chose the most profitable market segment here.
We're not talking about iPods and iPhones. Read: MacBook Air demand trails that of original Intel-based MacBook, with winners like:
Well, thank god someone around here can understand a comment that wasn't written in crayon. Perhaps I'm just underestimating the "Traveler who is too much of a pussy to lug around three extra pounds, yet does not wish to switch batteries mid-flight" market segment, but perhaps not.
I want it. They won't give it to me. Instead I get a manila envelope full of shit.
Not all that nice. After roasting, beans need 8-12h in open air to emit CO2, otherwise you end up with sour coffee (due to carbonic acid). Also, after the CO2 evaporates, it's generally agreed that a rest period of 4-7 days brings out the best flavor in roasted beans. Two machines would have been a better choice.
Amherst is too far! I had a life in Cambridge and didn't want to give it up. Lowell was a not-too-painful commute and the engineering program is decent enough.
UMass Lowell.
First, thanks for the second-guessing. You remind me of me, six or seven years ago.
Second, I assure you that nothing, but nothing sunk in during my three 18.03 attempts, except that I shouldn't stick around for #4. However, I remembered enough of the syllabi to recognize that the state school covered almost the exact same material. It was by no means the Dummies' guide you might like to think it was; it was merely taught by a professor who knew how to talk about math and connect with his students, rather than draw colored diagrams on the chalkboard and giggle (I'm looking at you, Prof. Toomre.)
Finally, I remind you of Hartley Rogers' multi-volume 18.02 textbook which was "published" by MIT CopyTech for about ten years before a real printer picked it up. Don't worry, I'm sure he wrote his own text because of all the bleeding-edge developments in multivariable calculus which occurred in the 1990s.
I don't mean to totally rip the place down. MIT has some great courses; 6.001 (Structure and Interpretation of Computer Programs) as taught by Abelson and Sussman is the greatest course I ever took in my life, without question. That said, however, MIT's greatest resource is its community. I learned far, far more outside an MIT classroom than inside it.
Maybe it doesn't get you laid. My mojo had a better uptime than my workstation...
Bad professors were a big problem for me. I attended MIT and a state school. Most courses, especially on the bottom rungs, were taught much better at the state school. MIT, like many engineering schools, focuses on its professors' research more than their teaching skills. I failed MIT's differential equations course three times, yet earned an A at the state school. Did diff eq change sometime in the three intervening years, or the 35 miles from one school to the next?
Bad textbooks often follow from bad professors. Beware especially the profs who insist upon using their self-written textbook. That goes double for the ones which can't get the book published, and in turn force you to buy a crappy GBC-bound xerox from the campus duplication center.
I never had a good counselor. Good counselors can give you career advice. My counselors were already-overworked professors clamoring for tenure; not only did they lack the insight a good counselor could provide, but they also lacked much time.
I would not have the non-inflated grades any other way. I also don't trust grades to be a very good diagnostic figure for a student's effort, aptitude, or potential.
And as for homework... engineering is ingenuity (same root word), rooted in math and reality (which we usually call "physics"). The math bears repetition. It's not that I liked doing math exercises all the time, but now that I am on the other side, I fully appreciate its necessity. There were math concepts which I did not totally grasp until I had hammered on them for years.
Paul Graham's Prolog-in-Lisp trick from On Lisp is an inspiring example of embedding a DSL in a general-purpose language. However, when you say:
That could easily be done by implementing the solving strategies as functions in a general purpose language, especially if that language supports elegant representation of the inputs to your "logic programming library".
I do not agree with the boldfaced word. Just because it can be done by Paul Graham, in Lisp, doesn't mean Joe Bitslinger has a chance in hell of doing it in C#, or Java, or even Python or Perl or Ruby, or hell -- even Lisp herself. The bottom-up coding style of Lisp does not translate easily to most other languages, even the Lispy ones.
I think it's more suitable for the world at large to have a few good implementations of Prolog to choose from, and then to hook it into whatever general-purpose language is best for the overall task. I think we will see a lot more of this, and better performance thereof, as VMs are extended to support more languages and more interoperability between languages, as e.g. the Parrot VM from the Perl 6 fiasco aspires to do.
If you're Paul Graham, then you can do what you want; just because Stormtroopers use guns doesn't mean that the Jedi shouldn't use light sabers.
I'll leave you with Greenspun's Tenth Rule, and RTM's Corollary:
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Philip Greenspun
"...Including Common Lisp." -- Robert Morris
Oh, I don't know, you can make some pretty big programs with lanugages like PERL, Python, and Ruby. Also, Javascript is no slouch either, and it's based upon Self rather than Java.
no shit dude, way to ignore what I just said and listen to yourself yap
It's no more of a tarpit than your suggested "unpopular" functional languages.
I'm talking about the tarpit as a metaphor not for a particular language, but for the uselessness a discussion about computer languages takes on when Turing equivalency is brought up to imply practical equivalency. It doesn't, and never will, and anyone who says it does is probably trying to win an argument at all costs.
So, what's your point?
talking to you sucks and I'm through with it
HTML
Okay, maybe "effortless" was a stretch. If the effort is performed behind the scenes (i.e. in the compiler or execution environment) then it can become pretty effortless to the programmer. In any case, parallelizing shared-nothing code is a much simpler problem than writing threadsafe code in languages with shared anything.
PERL, Ruby, Python, JavaScript (which is more based upon LISP than Java, despite the name), for instance. So, one could learn any of those languages and learn about functional programming from them. You don't have to learn about functional programming from languages that aren't very popular or commonly used.
You can get your feet wet, but to take advantage of many benefits to functional language (for instance, ML's superb type inference, or Erlang's formidable scalability), you need to go unpopular. You are correct, though; functional programming style fits in many languages which are not strictly functional.
I have to completely disagree with OP here. First, Logic Programming is based upon the idea of relations between sets of objects. These relations are usually expressed as equations of some form.
"rules of a system"
Logic programming turns up in many places: type inference (OCAML, CAML, ML, etc.), dependency analysis (the various make's and project builders), databases (think SQL), and spell checking.
All specialized tasks. You might embed Prolog in Word to perform spell checking; you don't write Word in Prolog.
All of this to one side, one can note that since the set of all functions is a subset of the set of all relations, lambda calculus can be no more powerful than relational programming. Therefore, Logic Programming is at least as capable of solving a problem as C or the like.
Welcome to the Turing tarpit.
Functional languages seek to express all operations as a chain of functions which operate on data and return other data. "Function" is used in its mathematical sense here. Purely functional languages discourage state, and don't allow mutable variables. The lack of state and mutability give rise to some power; effortless parallelizability, for instance.
Logic languages are something different altogether. They provide a framework for defining the rules of a system, then searching for answers which fit the given rules. Logic programming is not useful for general-purpose tasks, but can hugely reduce programming time in tasks which are difficult to solve any other way.
He did it so he could more easily troubleshoot support calls on his new "Unix" operating system.
or maybe you could actually learn what 'postfix' is.
to address the GP: it isn't clear (to me, at least) what the successor to Postfix will be. There is no successor thus far which makes Postfix look thoroughly old-fashioned.
Discuss.
God willing, math teachers will be the next to be freed from the chains of having to teach facts in school.
In traditional webapps, we build systems that are stateful and transaction oriented. Thus is fundamentally a consequence of the way the web works.
;)
Not so fast! I think you trivialize how well 90% of websites fit into a stateful, transaction-oriented architecture -- especially when hosting and serving requirements are factored in. I don't think that's a consequence of the way the web works, but rather the opposite; I think the way the web works is a consequence of the tools that power most of it.
Of course Seaside is not limited to crazy workflows and such; it just gets its chance to shine in situations like that, because the 90% solution falls apart quickly.
But, we are getting off the topic, here, which is, of course Ruby. OTOH, I think Ruby is just Smalltalk's bastard, warped stepchild, so maybe it's not so off-topic after all.
Smalltalk has so many children! Ruby and Objective-C are my favorites, but in general, I'm happy to see pure message-passing semantics wherever I run across them.
I never said Seaside was batshit insane, only the workflows of the apps which are well-suited to it. Seaside isn't insane, it's just esoteric.
Call/cc can become useful in web applications where you have a batshit insane workflow. Seaside, the Smalltalk web framework, bets the farm on it. It's in other places like Perl's Jifty too.
Most of the web apps I write wouldn't benefit from this sort of treatment, so I haven't jumped in too far, but call/cc has its uses for sure.
Up until now, Adobe hasn't done much in terms of porting its applications to Linux, as its only product to have recieved any kind of Linux implementation is Flash.
Adobe FrameMaker has run on more than 10 Unixes over the years, including Linux. Consider this nit picked!