Interpreted languages, in general, are not faster than compiled languages. Period.
Lisp is not an interpreted language. Period. It is an interactive language. If an implementation decides to achieve this with an interpretor, that is possible. However, there are implementation for which all code is compiled. SBCL is such an implementation. I would include a snippet of the disassembly from SBCL but/code seems to think that posting such is using to many 'junk' characters.
Also, another nice fact. Wikipedia is not your research center. It is a place to start. If you are using it as a source for your research paper, you should get an F.
Yes, start with something more credible, like Fox News.
And God has three aspects: recursion, Î-calculus, and Turing machine. All others are mere shadows of the true Form. Kleene, Church, and Turing are the prophets.
You know, I've been hearing that term, Enterprise, thrown about for a while now and I *still* don't know what it's supposed to mean. Maybe Wikipedia can help.
Enterprise software is software intended to solve an enterprise problem (rather than a departmental problem) and often written using an Enterprise Software Architecture
Off to a good start. So, what is an enterprise? Merriam Webster thinks that it is one of the following:
a project or undertaking that is especially difficult, complicated, or risky
readiness to engage in daring or difficult action : initiative
a: a unit of economic organization or activity ; especially : a business organization b: a systematic purposeful activity
So, apparently, Enterprise Software can be software that helps one recite the alphabet backwards while drunk (difficult), pick random sex partners (risky), walk up to Mike Tyson to insult him (daring), or helps, for example, my little cousin run her lemonade stand (economic activity).
(ignore-errors (with-open-file (in *python*) (loop for symbol = (read in nil) while symbol)))
NIL
#<SB-INT:SIMPLE-READER-ERROR {10026C2661}>
(ignore-errors (with-open-file (in *c++*) (loop for symbol = (read in nil) while symbol)))
NIL
#<SB-INT:SIMPLE-READER-ERROR {1002DDF151}>
Personally, I can't read a lick of any of this but Python doesn't look any more readable than C++ to me. If there's a serious argument against this, it would be that a child of five would be able to read any Python code. Send somebody to fetch a child of five.
Well your other post said basically Lisp is for interesting
people, all the other who cares about syntax doesn't matter, what do
you expect me to answer to this??
Fair enough. I didn't mean to imply anything like that but perhaps
I went to far when I mentioned 80s perms.;-)
Lisp is probably very good for research as it free the
researcher from syntax, but for the other 99% of developpers who don't
do language research but who maintain existing programs in C, C++ or
Java, I doubt that you would convince them that syntax doesn't
matter.. That's why the next big programming language may be one of
those: D, Scala, Ruby or Python but not Lisp.
Well, I am one of the bulk of those programmers maintaining
an existing system. At least, that's what I do for my day job. And I
doubt that is likely to change anytime even within the next decade, if
I continue to stay with the same company. Our system is simply not
going to be rewritten in any new language unless it is the first to
introduce something amazing like a DWIM feature. In fact, if you
listen to some of the pundits, the next big programming
language just might be COBOL. Legacy inertia can often be the
immovable object standing in the way of the unresistable force of the
Next Big Thing. And I've personally gotten so sick of the YASL family
breeding like rabits that I won't bother looking at another one unless
it does something significantly different from all of its cousins.
But it seems I am guilty of having thrown another shovel full on
the steaming pile of myth that Lisp is only good for research. Practical Common
Lisp is full of excellent examples of using Lisp for "normal"
problems. My personal favorite exmaple is the way he uses macros to
help with the task of parsing
ID3 tags in MP3 files. Having had to deal with things like ASN.1
compilers in the past, I immediately fell in love with the way he
basically did the same thing as is done with ASN.1 but without ever
leaving Lisp.
I currently use Common Lisp (mostly SBCL and sometimes Clisp)
everyday for the kinds of tasks for which I would have reached for
Perl in the past. An Emacs user, I'm merely a "M-x slime" away from
wherever in Lisp I may want to be, including the entire mush of elisp
floating out there in the tubes of the internets. CL-PPCRE already gives me in Lisp
most of what I might have missed from Perl. Implemented entirely in
Common Lisp, it even out performs Perl's regular expression engine for
some benchmarks. But what I love about using Lisp for these kinds of
"write once" "scripting" tasks is that I have full access to all of
Lisp's features if I find it useful. For example, I've been able to
use Allegro Prolog for an install script of somewhat limited
intelligence. (I'll try posting code after this because I'm having
problems with/. formatting rules.)
As for AOP, personnaly I've never liked it (seems like a
mess for anything but logging), [...]
Okay, but the point wasn't so much AOP as it was how unnecessary it
is introduce a whole new programming language tool to get the same
functionality from Lisp. To introduce AOP into Java required mucking
about with the core of the Java language. In Lisp, "all" one needs to
do is crank out some macros and perhaps a few new meta-objects.
And so much of all of this is made possible by Lisp's macros which
are, in turn, so useful because of the very syntax which is what so
many people love to hate.
Hello? Pot? Yeah, this is kettle. I just called because I wanted to
tell you that you are so black.
Ah, but you did replay. Fortunately for me, the complete lack of
content in your comtemptuously unresponsive reply means that I can
ignore your humble proclamations of The Way Things Are.
Now, I wasn't claiming that all language exploration was, is, or ever
will be done exclusively in Lisp. However, the fact that Lisp syntax
so throughly supports macros and other forms of syntactic abstraction
makes it very good for exploration. Consider, for example, Context-Oriented
Programming. Pascal Costanza has been very active in this area of
language research, having worked on both ContextJ* and
ContextL, the former an implementation of aspect-oriented
programming in Java and the later being AOP in Lisp. He had the
following to say about AOP and Lisp:
It's no wonder that the Java crowd likes AOP so much. In Java, you
neither have macros, nor higher-order functions nor a serious
reflective and/or metaobject API. In other words, there are no
(convenient) ways to do metaprogramming, except for some mild versions
thereof in java.lang.reflect, or the cumbersome ways via inner
classes, or if you dare to do this, via hacking around with custom
class loaders. (Ah yes, together with annotations, Sun has also
introduced some tools to do program transformation...)
Compared to those options, tools like AspectJ, Spring AOP, and so on,
are a breeze. (And due to clever marketing, the Java people don't even
realize that they are using a (limited) subset of metaprogramming
techniques here.)
It's interesting to note that in C#/.NET world, AOP hasn't caught
on. I suspect that this is due to the inclusion of first-class methods
from the start.
Lispers and Schemers are, in general, not impressed by AOP because
macros, higher-order functions and, in CLOS, a full-fledged metaobject
protocol make metaprogramming very convenient and, after an admittedly
steep learning curve, very straightforward.
And it is exactly Lisp's homoiconic syntax which
makes macros so convienent in the language. In my apparently not so
humble opinion, Prolog is another one of the few homoiconic languages.
One of my favorite examples of the power of Lisp macros comes from Paradigms of Artificial
Intelligence Programming, in which Peter Norvig implements a
Prolog as Lisp compiler in Lisp which effectively introduces a new
dialiect of Lisp with support for unification. Franz weaponized it and now includes it
in their Lisp as Allegro
Prolog. How many languages allow for one to completely and
seamlessly embed another language in it?
Allegro Prolog does not attempt to be ISO compliant or implement the
entire language. Many standard Prolog arithmetic, predicate operators,
and I/O operators are not implemented, as they are a subset of the
standard Common Lisp operators
But they could, if they wanted to bother to write reader macros for
ISO Prolog syntax. But what's the point? They don't have the Prolog
syntax but they've got all of the Prolog semantics. So, yes, perhaps
Lisp will never become a mainstream programming language because it
has an atypical syntax that many programmers don't like. However, I
think that is being just a little bit full of one's own petty
preferences for things like {$@.->*!%?} over
() to dismiss all that flexiblity just because of syntax.
While I agree that no syntax is natural, it still remains that programmers like some syntax better than others, and even if it's only fashions they're quite strong: currently Lisp has no chance to become a widespread PL again due to its syntax (too bad though that it wasn't used for documents as XML's syntax is even worse).
Is it even worth responding to a post that starts with the admission that no syntax is natural, that programmer preference can be based on things as fickle as fashion, but somehow that which is as it is now must always be and that which once was will never come again? Or perhaps you mean to imply that Lisp syntax is bad syntax in some kind of Chomsky deep grammar sense, like 80s perms were so hideous that they will never come back in style. But I definitely don't want to leave the impression that I'm comparing Lisp syntax to 80s perms. And I certainly don't want to discuss fashion with anyone on/.
As John McCarthy explained in History of Lisp
The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised.
It wasn't that no one was technically able to realize the syntactic layer of meta-expressions. In fact, apparently someone from the Arc crowd has bothered to write a reader for M-expr syntax. As people started becoming familiar with the S-exprs, they found no benefit in continuing to work on M-exprs. Not to mention that the very lack of syntax is what makes Lisp macros so powerful.
So, I agree that Lisp will probably never become popular with anyone who would rather spend their time worrying about things like skinny ties or wide ties, tight pants or baggy pants, arrows or dots, or ~%$#@!, etc. Lisp will probably continue to be interesting to people who would rather focus on programming language semantics exactly because it frees one from almost all of the superfluous concerns of syntax. Oh, and when they're done, they could also easily add a nice syntactic layer on top of it, but they probably won't bother because who needs it? Besides, someone else will probably come along and "invent" a new language which will steal the ideas, but make sure it's wearing the right pants and has the right hair. Apparently, we have Python to thank for the return of significant whitespace, an idea which should have died with Fortran and punch cards. Talk about the 80s perm of programming language syntax.
I like S-Expressions as XML replacement a lot, since for representing simple structured data its quite nice. But it just doesn't lead to very readable code when it comes to programming, [...]
Readable. Clean. Two of the most useless words ever used in a discussion about programming. They both reek of the kind of plain spoken "I know it when I see it" sophistry which tries to mask ones own petty preferences with a false sense of "natural" consensus. Unfortunately, this phrase, "I know it when I see it," has stuck in vernacular while almost no one remembers that Potter Stewart later recanted his view in Miller v. California, in which he accepted that his prior view was simply untenable.
No programming language has ever been readable to anyone not already schooled in programming. No mathematical notation has ever been readable to anyone not already schooled in mathematics. This feckless obsession with syntax has got to be one of the biggest wastes of brain power since theologians debated how many angels could fit on the head of a pin. One of the examples of using the Lisp pretty printer published at around the same time as its introduction, if I my history is correct, was using the pretty printer to print a subset of Lisp as Pascal. Dylan already tried adding a more Algol-like syntax to Lisp. Paul Graham's Arc is yet another go at tacking some kind of level of extra syntax to Lisp. Qi has already added a sophisticated static typing system to Lisp. There is absolutely nothing new or interesting about any of this.
Lisp is a language that CompScis see for two months at University before leaving it behind. [...]
Not necessarily true. Search/. archives for Paul Graham for a "famous" example of someone successfully using Lisp in a commercial product. Personally, I find the Emacs dialect of Lisp to be unfortunately restrictive, lacking even lexical closures. The Common Lisp emulation package helps out quite a bit but then one is still left without things like loop or CLOS. And the addition of SLIME and things like slime-eval are also, IMO, quite useful. However, I'm keeping an eye on Climacs because I would love to have an Emacs written with/in Common Lisp.
C-h l runs the command view-lossage which is an interactive compiled Lisp function in `help.el'. It is bound to C-h l, M-? l, <f1> l, <help> l. (view-lossage)
Display last 100 input keystrokes.
To record all your input on a file, use `open-dribble-file'.
I've got one of the 3G iPhones and I like an awful lot about it,
especially the multi-touch screen and accelerometer. I also like how
seamlessly it integrates with Mac Mail, Address Book, etc. To be
honest, I'm really not all that concerned about the speed of page
renders or downloads. Of course, it always nice for things to run
faster, but having the right features which are "fast enough" is more
important.
So the thing that really pisses me off about the iPhone is the way
that there are so many features lacking because Apple/AT&T
artificially cripple the phone. I can't believe that it doesn't
support MMS messaging out of the box. That's just insane. Everytime
a friend sends me a MMS, it gets treated as if it were a legacy phone,
with an SMS message pointing me at a web-site from which I can view
the image. Legacy treatment on fscking iPhone. Another thing I find
severly annoying is that I can't use the iPhone's internet connection
from my laptop unless I'm willing to jail break the phone, which
carries it's own problems what with Apple trying to brick the phone
with every update if it's broken free.
It is this which is peaking my interest in my coworker's new G1 than
anything else. And that's too bad, because I really like a lot about
my iPhone but it seems like Apple/AT&T want to drive customers away
with bad business decisions.
Now, I don't think that the current situation will get as bad as the Great Depression, but...
Maybe somebody can help me with the history. The Great Depression started in 1929 and ended, variously, in the 1930s or 1940s. Television was commercially available in the 1930s, but I would doubt it was common to find one in peoples' homes. I could be wrong, but I would've thought that during the Great Depression, most people who could afford it would have been going to movie theaters, a strictly pay-per-view model.
I don't know about any of you, but I doubt I'll be browsing the internets on my iPhone if I'm waiting in line for food from a soup kitchen. But you are right, though, that not everything is done for a fee in hard times. In Grapes of Wrath, Rosasharn does not charge for her Roman Charity, so perhaps open source will save the day, though I don't know how much milk one can squeeze out of Linux.
I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language.
I disagree; keeping track of multiple revisions of data is an important AI topic and would be exactly the sort of thing the committee had in mind. Show me something utterly divorced from academic interests - an FPS game perhaps - and I'll be impressed.
Academics...
You keep using that word. I do not
think it means what you think it means.
The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.
I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language. I am personally not a big fan of Haskell, but neither am I a hater, and even I have used darcs.
A pure functional language would be a language where there are no side effects. I.e., you can't change the state of anything, you can only construct new things out of existing things. As this gives some problems with IO, Haskell, taking purity to the extreme, had to wait for the invention of Monads to be able to do IO. Yes, Haskell was not capable of IO (reading/writing) for years. Functional languages follow this pattern: side-effects are only permitted if there is no other way. Examples are Lisp and Scheme,...
Lisp does not require tail-call elimination and, therefore, one finds a large number of iteration forms: do, do*, do-all-symbols, do-external-symbols, do-symbols, dolist, dotimes, and loop. Scheme does require tail-call elimination and, therefore, Scheme programmers tend to use recursion, without assignment, quite extensively. Lisp programmers use loop and functions which modify values all the time. For example, McCLIM, a rather large lisp package:
$ find . -type f -name \*.lisp -print | wc -l
397
$ find . -type f -name \*.lisp -exec grep -l loop {} \; | wc -l
210
(Why in the world does the pre tag not work?) And this is quite typical of Lisp code in general. Lisp is not a functional programming language, though it can support a functional style. Scheme is nearer to be a functional language.
Spearhead an initiative to enable a culture of best practices, with the ultimate goal to be assessed as SEI CMM level 5, leveraging Digital Six Sigma to integrate continuous improvement.
Slashdot Mirror
(rolls eyes)
Interpreted languages, in general, are not faster than compiled languages. Period.
Lisp is not an interpreted language. Period. It is an interactive language. If an implementation decides to achieve this with an interpretor, that is possible. However, there are implementation for which all code is compiled. SBCL is such an implementation. I would include a snippet of the disassembly from SBCL but /code seems to think that posting such is using to many 'junk' characters.
Also, another nice fact. Wikipedia is not your research center. It is a place to start. If you are using it as a source for your research paper, you should get an F.
Yes, start with something more credible, like Fox News.
Study: 38 Percent Of People Not Actually Entitled To Their Opinion
And God has three aspects: recursion, Î-calculus, and Turing machine. All others are mere shadows of the true Form. Kleene, Church, and Turing are the prophets.
Off to a good start. So, what is an enterprise? Merriam Webster thinks that it is one of the following:
So, apparently, Enterprise Software can be software that helps one recite the alphabet backwards while drunk (difficult), pick random sex partners (risky), walk up to Mike Tyson to insult him (daring), or helps, for example, my little cousin run her lemonade stand (economic activity).
(ignore-errors (with-open-file (in *c++*) (loop for symbol = (read in nil) while symbol)))
Personally, I can't read a lick of any of this but Python doesn't look any more readable than C++ to me. If there's a serious argument against this, it would be that a child of five would be able to read any Python code. Send somebody to fetch a child of five.
We already have Encino Man.
Well your other post said basically Lisp is for interesting people, all the other who cares about syntax doesn't matter, what do you expect me to answer to this??
Fair enough. I didn't mean to imply anything like that but perhaps I went to far when I mentioned 80s perms. ;-)
Lisp is probably very good for research as it free the researcher from syntax, but for the other 99% of developpers who don't do language research but who maintain existing programs in C, C++ or Java, I doubt that you would convince them that syntax doesn't matter.. That's why the next big programming language may be one of those: D, Scala, Ruby or Python but not Lisp.
Well, I am one of the bulk of those programmers maintaining an existing system. At least, that's what I do for my day job. And I doubt that is likely to change anytime even within the next decade, if I continue to stay with the same company. Our system is simply not going to be rewritten in any new language unless it is the first to introduce something amazing like a DWIM feature. In fact, if you listen to some of the pundits, the next big programming language just might be COBOL. Legacy inertia can often be the immovable object standing in the way of the unresistable force of the Next Big Thing. And I've personally gotten so sick of the YASL family breeding like rabits that I won't bother looking at another one unless it does something significantly different from all of its cousins.
But it seems I am guilty of having thrown another shovel full on the steaming pile of myth that Lisp is only good for research. Practical Common Lisp is full of excellent examples of using Lisp for "normal" problems. My personal favorite exmaple is the way he uses macros to help with the task of parsing ID3 tags in MP3 files. Having had to deal with things like ASN.1 compilers in the past, I immediately fell in love with the way he basically did the same thing as is done with ASN.1 but without ever leaving Lisp.
I currently use Common Lisp (mostly SBCL and sometimes Clisp) everyday for the kinds of tasks for which I would have reached for Perl in the past. An Emacs user, I'm merely a "M-x slime" away from wherever in Lisp I may want to be, including the entire mush of elisp floating out there in the tubes of the internets. CL-PPCRE already gives me in Lisp most of what I might have missed from Perl. Implemented entirely in Common Lisp, it even out performs Perl's regular expression engine for some benchmarks. But what I love about using Lisp for these kinds of "write once" "scripting" tasks is that I have full access to all of Lisp's features if I find it useful. For example, I've been able to use Allegro Prolog for an install script of somewhat limited intelligence. (I'll try posting code after this because I'm having problems with /. formatting rules.)
As for AOP, personnaly I've never liked it (seems like a mess for anything but logging), [...]
Okay, but the point wasn't so much AOP as it was how unnecessary it is introduce a whole new programming language tool to get the same functionality from Lisp. To introduce AOP into Java required mucking about with the core of the Java language. In Lisp, "all" one needs to do is crank out some macros and perhaps a few new meta-objects.
And so much of all of this is made possible by Lisp's macros which are, in turn, so useful because of the very syntax which is what so many people love to hate.
Ah, but you did replay. Fortunately for me, the complete lack of content in your comtemptuously unresponsive reply means that I can ignore your humble proclamations of The Way Things Are.
Now, I wasn't claiming that all language exploration was, is, or ever will be done exclusively in Lisp. However, the fact that Lisp syntax so throughly supports macros and other forms of syntactic abstraction makes it very good for exploration. Consider, for example, Context-Oriented Programming. Pascal Costanza has been very active in this area of language research, having worked on both ContextJ* and ContextL, the former an implementation of aspect-oriented programming in Java and the later being AOP in Lisp. He had the following to say about AOP and Lisp:
And it is exactly Lisp's homoiconic syntax which makes macros so convienent in the language. In my apparently not so humble opinion, Prolog is another one of the few homoiconic languages. One of my favorite examples of the power of Lisp macros comes from Paradigms of Artificial Intelligence Programming , in which Peter Norvig implements a Prolog as Lisp compiler in Lisp which effectively introduces a new dialiect of Lisp with support for unification. Franz weaponized it and now includes it in their Lisp as Allegro Prolog . How many languages allow for one to completely and seamlessly embed another language in it?
But they could, if they wanted to bother to write reader macros for ISO Prolog syntax. But what's the point? They don't have the Prolog syntax but they've got all of the Prolog semantics. So, yes, perhaps Lisp will never become a mainstream programming language because it has an atypical syntax that many programmers don't like. However, I think that is being just a little bit full of one's own petty preferences for things like {$@.->*!%?} over () to dismiss all that flexiblity just because of syntax.
While I agree that no syntax is natural, it still remains that programmers like some syntax better than others, and even if it's only fashions they're quite strong: currently Lisp has no chance to become a widespread PL again due to its syntax (too bad though that it wasn't used for documents as XML's syntax is even worse).
Is it even worth responding to a post that starts with the admission that no syntax is natural, that programmer preference can be based on things as fickle as fashion, but somehow that which is as it is now must always be and that which once was will never come again? Or perhaps you mean to imply that Lisp syntax is bad syntax in some kind of Chomsky deep grammar sense, like 80s perms were so hideous that they will never come back in style. But I definitely don't want to leave the impression that I'm comparing Lisp syntax to 80s perms. And I certainly don't want to discuss fashion with anyone on /.
As John McCarthy explained in History of Lisp
It wasn't that no one was technically able to realize the syntactic layer of meta-expressions. In fact, apparently someone from the Arc crowd has bothered to write a reader for M-expr syntax. As people started becoming familiar with the S-exprs, they found no benefit in continuing to work on M-exprs. Not to mention that the very lack of syntax is what makes Lisp macros so powerful.
So, I agree that Lisp will probably never become popular with anyone who would rather spend their time worrying about things like skinny ties or wide ties, tight pants or baggy pants, arrows or dots, or ~%$#@!, etc. Lisp will probably continue to be interesting to people who would rather focus on programming language semantics exactly because it frees one from almost all of the superfluous concerns of syntax. Oh, and when they're done, they could also easily add a nice syntactic layer on top of it, but they probably won't bother because who needs it? Besides, someone else will probably come along and "invent" a new language which will steal the ideas, but make sure it's wearing the right pants and has the right hair. Apparently, we have Python to thank for the return of significant whitespace, an idea which should have died with Fortran and punch cards. Talk about the 80s perm of programming language syntax.
Thanks for the information about loop. I hadn't noticed it had been added. Now all we need is CLOS and conditions with restarts.
Elegant and powerful? Sure. But Readable? No way.
I like S-Expressions as XML replacement a lot, since for representing simple structured data its quite nice. But it just doesn't lead to very readable code when it comes to programming, [...]
Readable. Clean. Two of the most useless words ever used in a discussion about programming. They both reek of the kind of plain spoken "I know it when I see it" sophistry which tries to mask ones own petty preferences with a false sense of "natural" consensus. Unfortunately, this phrase, "I know it when I see it," has stuck in vernacular while almost no one remembers that Potter Stewart later recanted his view in Miller v. California, in which he accepted that his prior view was simply untenable. No programming language has ever been readable to anyone not already schooled in programming. No mathematical notation has ever been readable to anyone not already schooled in mathematics. This feckless obsession with syntax has got to be one of the biggest wastes of brain power since theologians debated how many angels could fit on the head of a pin. One of the examples of using the Lisp pretty printer published at around the same time as its introduction, if I my history is correct, was using the pretty printer to print a subset of Lisp as Pascal. Dylan already tried adding a more Algol-like syntax to Lisp. Paul Graham's Arc is yet another go at tacking some kind of level of extra syntax to Lisp. Qi has already added a sophisticated static typing system to Lisp. There is absolutely nothing new or interesting about any of this.
Lisp is a language that CompScis see for two months at University before leaving it behind. [...]
Not necessarily true. Search /. archives for Paul Graham for a "famous" example of someone successfully using Lisp in a commercial product. Personally, I find the Emacs dialect of Lisp to be unfortunately restrictive, lacking even lexical closures. The Common Lisp emulation package helps out quite a bit but then one is still left without things like loop or CLOS. And the addition of SLIME and things like slime-eval are also, IMO, quite useful. However, I'm keeping an eye on Climacs because I would love to have an Emacs written with/in Common Lisp.
C-h l runs the command view-lossage
which is an interactive compiled Lisp function in `help.el'.
It is bound to C-h l, M-? l, <f1> l, <help> l.
(view-lossage)
Display last 100 input keystrokes.
To record all your input on a file, use `open-dribble-file'.
[back]
My favorite Emacs trick is defun.
So the thing that really pisses me off about the iPhone is the way that there are so many features lacking because Apple/AT&T artificially cripple the phone. I can't believe that it doesn't support MMS messaging out of the box. That's just insane. Everytime a friend sends me a MMS, it gets treated as if it were a legacy phone, with an SMS message pointing me at a web-site from which I can view the image. Legacy treatment on fscking iPhone. Another thing I find severly annoying is that I can't use the iPhone's internet connection from my laptop unless I'm willing to jail break the phone, which carries it's own problems what with Apple trying to brick the phone with every update if it's broken free.
It is this which is peaking my interest in my coworker's new G1 than anything else. And that's too bad, because I really like a lot about my iPhone but it seems like Apple/AT&T want to drive customers away with bad business decisions.
Maybe somebody can help me with the history. The Great Depression started in 1929 and ended, variously, in the 1930s or 1940s. Television was commercially available in the 1930s, but I would doubt it was common to find one in peoples' homes. I could be wrong, but I would've thought that during the Great Depression, most people who could afford it would have been going to movie theaters, a strictly pay-per-view model.
I don't know about any of you, but I doubt I'll be browsing the internets on my iPhone if I'm waiting in line for food from a soup kitchen. But you are right, though, that not everything is done for a fee in hard times. In Grapes of Wrath, Rosasharn does not charge for her Roman Charity, so perhaps open source will save the day, though I don't know how much milk one can squeeze out of Linux.
HAL: How do you feel today, Dave? You don't look well.
HAL: Why aren't you wearing any pants, Dave? Is that vomit on your t-shirt?
Personally, I really like Peter Norvig's eassy, "How To Teach Yourself Programming in Ten Years"
I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language.
I disagree; keeping track of multiple revisions of data is an important AI topic and would be exactly the sort of thing the committee had in mind. Show me something utterly divorced from academic interests - an FPS game perhaps - and I'll be impressed.
Academics... You keep using that word. I do not think it means what you think it means.
The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.
I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language. I am personally not a big fan of Haskell, but neither am I a hater, and even I have used darcs.
A pure functional language would be a language where there are no side effects. I.e., you can't change the state of anything, you can only construct new things out of existing things. As this gives some problems with IO, Haskell, taking purity to the extreme, had to wait for the invention of Monads to be able to do IO. Yes, Haskell was not capable of IO (reading/writing) for years. Functional languages follow this pattern: side-effects are only permitted if there is no other way. Examples are Lisp and Scheme, ...
Lisp does not require tail-call elimination and, therefore, one finds a large number of iteration forms: do, do*, do-all-symbols, do-external-symbols, do-symbols, dolist, dotimes, and loop. Scheme does require tail-call elimination and, therefore, Scheme programmers tend to use recursion, without assignment, quite extensively. Lisp programmers use loop and functions which modify values all the time. For example, McCLIM, a rather large lisp package:
$ find . -type f -name \*.lisp -print | wc -l
397
$ find . -type f -name \*.lisp -exec grep -l loop {} \; | wc -l
210
(Why in the world does the pre tag not work?) And this is quite typical of Lisp code in general. Lisp is not a functional programming language, though it can support a functional style. Scheme is nearer to be a functional language.
Spearhead an initiative to enable a culture of best practices, with the ultimate goal to be assessed as SEI CMM level 5, leveraging Digital Six Sigma to integrate continuous improvement.
<insert what="maniacal laughter">
Seriously. Personally, I'm always annoyed when somebody writes something about me like "Hunky stud writes C++ code..." That's Dr. hunky stud.
I said: "Doctor, I've broken my arm in several places."
Doctor: "Then don't go to those places."
$ ls
bar file 1 file 2 foo homer?like?duff
bar.titles file 1.titles file 2.titles foo.titles homer?like?duff.titles
$ IFS=$'\n'; grep -l beer `find . -name \*.titles -prune -o -print`
duffmer
As opposed to
LAMP-USER> !$(find
"/home/dkick/tmp/duff
"
#<SB-IMPL::PROCESS
LAMP-USER> (remove "titles" (list-directory "/home/dkick/tmp/duff/")
(#P"/home/dkick/tmp/duff/bar" #P"/home/dkick/tmp/duff/file 1"
#P"/home/dkick/tmp/duff/file 2" #P"/home/dkick/tmp/duff/foo"
#P"/home/dkick/tmp/duff/homer^Mlike^Mduff")
LAMP-USER>