I'm an atheist, but if you could please convey this line of reasoning to anyone who has ever used the phrase "God needs" in a sentence, it would be greatly appreciated. "God wants you to" has been used as justification for some of the most heinous acts ever committed.
I 100% agree. I've found that Christians as individuals in general tend to be far too confident in their efforts to interpret the Bible.
But as for me, even if I believed in god, I wouldn't waste a moment of my life trying to second-guess him, so I'd end of living exactly the same way I do now.
I can see that point of view. For me, as a Christian, I believe that while the Bible may not give us all the answers we're looking for--or if parts of it are not even true, if taken literally--it will get me where I want to go, both in this life and the next (if there is one). This is not to say that there are not other reasons to believe in the Bible other than a blind and unquestioning faith, but rather, just because it's impossible to understand fully doesn't mean it's not useful to understand in part. (Whoa, sorry about all the negatives in that sentence.)
Oh, and the problem with the 'lesser of two evils' earthquake hypothesis is that there's no reason why the tectonic stress couldn't also have been let out through hundreds of itty-bitty tremors over a period of years. That it was instead 'saved up' for centuries and released via one of the most powerful earthquakes in recorded history suggests either apathy, malevolence, or nonexistence.
What if a 9.0 magnitude earthquake was itty-bitty compared to the unprecedented 18.0 magnitude (the Richter scale is exponential, isn't it?) earthquake that would have struck central India in 2014 had this one not occurred? What if the next would-be Hitler was killed in that earthquake? What if at the pearly gates, anyone who was killed in a natural disaster automatically gets into heaven?
We could go on and on in circles forever. The problem is that with as little information and perspective as we have, I am free to concoct whatever hypothetical situations I want to--since you are the one trying to prove the existence/non-existence of God with this argument. Again, I am not saying "look at this earthquake, isn't God so darn loving!?!?" I'm just saying you won't get there from here, by that road.
I actually think a more interesting theory is that God is (self-)constrained not to interfere. He lets the laws of physics play out, he lets humans commit heinous crimes... but all the time, he's keeping score. He steps in the minimum amount necessary to set up the rules, but after that he mostly observes. (See Parable of the Weeds.) In fact, if you look at Biblical history, you see that most of the time there are no miracles being performed, despite the need of God's followers--they are bunched up in clusters around certain turning points (Moses, Elijah, Jesus, the Apostles). Anyway, I think it's interesting, who knows if there's any truth to it.
We can't understand God so all his actions must be good, or at least the least cruel and evil because God by definition is loving. In this line of logic there is nothing said God can do that is not loving, even if it resllts in untold suffering, cruelty and death, because everything he does is loving because he is loving.
No, not must, but might. In no way do I think this line of reasoning can prove the existence of an all-powerful, all-loving God; I am merely arguing that you cannot disprove it this way.
Also, I didn't say "because everything he does is loving because he is loving". I said, or at least meant to say, that with sufficient imagination you can come up with hypothetical constraints or preconditions or possible postconditions to make any action be construed as plausible for a loving omnipotent god.
I can't talk for Kirshna or Ganeesh or Zoroaster, but the Judeao-Christian-Islamic God of the Bible\Koran is incredibly cruel and arbitrary, by (if you believe these holy books are the "breathed word or God") his own admission. Killing hundreds of innocent people, including children, giving virgins over for soldiers to have their way with etc all seems pretty cruel to me and not the actions of a "loving" god.
It's true that the Christian Bible (can't speak for the others) has some passages and practices, generally in the Old Testament, that are difficult for our modern mores and sensibilities to relate to. The Old Testament is all about sin's devestating influence on the world, and man's inability to overcome it alone. However, this is balanced by the New Testament's message of the incarnation, sacrifice, and resurrection of the Messiah, who overcomes sin for all (or some significant fraction of) mankind. Furthermore, there are instances even in the Old Testament where God shows incredible mercy and patience (Genesis 18:16-30, Jonah 4, and basically all of his dealings with the people of Israel).
Sorry to be vague, but I'm not familiar with specific instances in the Bible where God ordered the slaughter of innocents or raping of virgins. If you point them out, I'll attempt to analyze them... (if I remember to check Slashdot that is.)
Not necessarily, depending on whether there is an afterlife and what determines your fate therein. That's even assuming that the earthquake wasn't actually a good outcome out of all the possible outcomes; for example, what if the earthquake released tectonic pressure that otherwise would've built up and killed millions instead of hundreds of thousands?
I for one think the "If an omnipotent, loving God exists, why does he let bad things happen?" line of argument is a red herring. It's impossible for us to understand the actions of a being with an infinite perspective, if one exists--or to look at it another way, you can always argue the other side, no matter how disastrous and cruel the world might seem to be.
...but I get about 125 spams a day, and about 20 real e-mails. I'm pretty sure my e-mail address has been harvested from at least the following sources:
domain name registrations
online fora and blog comments
usenet
Yeah, I leave my real e-mail address in all of those places. I used to be more careful, but SpamBayes is so good, spam just isn't a problem for me.
I spent a few months this year writing probably one of the most complicated and hairy Firefox extensions out there. The documentation in XUL-land, including (or especially) the books, is pretty poor. There's plenty of info, but an astonishing amount of it is outdated, and there's nobody to tell you what pages are outdated and what pages are not. There are pages on mozilla.org that are years old and say "this information is subject to change, watch this space".
For example, the most difficult thing for me was trying to figure out how to package up my XUL/JS in a form that Firefox would take it. All the tutorials talked about install.js, installed-chrome.txt, and regxpcom, all of which are outdated. (Hint: Since Firefox 0.9, install.rdf is the key to the whole thing, so any tutorial that doesn't mention it is outdated.)
Once you've gotten the basics (probably by reading the O'Reilly book--the Nigel MacFarlane book may have a lot of useful info, but it was so poorly written I couldn't get through it), you really want to do yourself a favor and install Venkman, the Javascript debugger. The only place I've been able to find that has this little gem for Firefox is here.
Then, as you inevitably run into walls trying to get things done in the browser, cozy up to the source. There's not much you can do with XUL/JS that hasn't already been done in the Firefox source, and the search tools available on LXR will often lead you right to them.
Though AOL financed an organization behind a competing browser called Firefox, Pearce-Parkins said the company stuck with IE so users won't have to make "a leap of faith."
As if installing anything from AOL isn't a leap of faith already...
No kidding. I'm not a Perl fan, but if Guido van Rossum is on the list of nominees, Larry Wall really ought to be as well.
Re:Someone please tell me what I gain over Python?
on
RAD with Ruby
·
· Score: 2, Interesting
The advantages right now are mostly not pragmatic, but aesthetic. Programming with anonymous functions, closures, and higher order functions is more convenient in Ruby. The OO model seems better thought out.
JVM implementation: http://jruby.sourceforge.net/
Win32 support: http://www.rubycentral.com/book/win32.ht ml
Object DB: http://www.garret.ru/~knizhnik/dybase.html (I don't know anything about this one, just found it on Google)
List comprehension: Ruby blocks are a more general (and IMO more elegant) mechanism. For example,
[x*2 for x in mylist]
becomes
mylist.map{|x| x*2}
Note that in the Ruby version, x*2 doesn't need to be a simple expression; it could be any number of statements, and the return value would be used. So you could do this (using do/end instead of curly braces):
user_ids.map do |user_id|
result = webservice.lookup(user_id)
if result.success
return result
else
return nil
end end
That's a pretty stupid example, but you get the idea.
It's not controversial, I think, that Python's bigger userbase and greater number of libraries give it an edge over Ruby for many real-world projects. But Ruby is suitable for a surprisingly large number of situations, and some people feel strongly that the elegance of the language makes it worth using whenever possible.
There has been a fair amount of discussion about what makes a LL, and I don't think it came to any conclusion. But here's some interesting points of view.
I think there is a lot more agreement about what isn't lightweight.
If a language is statically typed and doesn't have type inferencing, it's probably not lightweight. If a language does not have a freely available implementation, it's probably not lightweight.
Any language that requires you to type this much to implement "Hello World" is definitely not lightweight:
using System;
namespace MyProject { public class MyClass { public static void Main(string[] args) { Console.WriteLine("Hello World!"); } } }
I think one good way to look at it is whether you feel like the programming language gets in the way of what you're trying to express. If you're constantly adding characters to placate a compiler, if you're forced to define an object when what you really want is to write a simple script, if you're forced to do all sorts of arcane tricks to interop with other languages (especially C), all of these things work against you as a programmer and add "weight" to the program and to the process.
By these criteria, I think most programmers would consider Perl a lightweight language...
I attended last year's LL3 and the words "Visual" and "Basic" were never uttered together. On the other hand there was a whole lot of talk about "Scheme", "Haskell", "continuation passing style", and "macros" (the hygienic kind).
Sorry, but I think the Python example is a lot more readable. I'll admit I've never programmed Ruby, but even if I hadn't programmed Python I'd be able to look at the Python code and figure out what it did. I can't say the same for the Ruby code. The "|var| var.something" syntax is rather non-intuitive, I think.
It may be rather non-intuitive for a programmer with a C/VB/Java background (which, admittedly, is almost all of us) but a functional programmer will feel right at home.
Anyway, once you get used to the block syntax (and it doesn't take long), the above is very readable. Blocks are worth taking the time to get used to; they're a great answer for a very large number of common problems, not just iteration and list comprehensions.
I personally think the design of Java's DateTime/Calendar is widely misunderstood and highly underrated.
Java's DateTime represents an unambiguous instant in time. Delphi's TDateTime doesn't, as it has no information about timezones. This is, to me, a serious omission (and one that Microsoft's.NET DateTime class shares).
The design of Java's DateTime/Calendar was clearly meant to accomodate other calendars--while Gregorian may be what 99.99% of the programming world needs today, it's just like Sun to try for 99.99999%. You may not agree with the inconvenience it causes to those who just want to work with dates using Gregorian, but at least recognize that there is a flexibility/ease-of-use tradeoff equation here. You could take an instant in time (DateTime), manipulate it with a GregorianCalendar, then pass it off to a LunarCalendar (if you have one) and manipulate it some more.
Stuff like this is exactly what I don't like about Python--introducing inconsistency for the sake of making a narrow scenario very slightly nicer.
But then, obviously thousands of programmers love Python, probably because of stuff like this.
Core Data looks cool. It addresses the need I spoke of in GGGP post, but I don't see enough info to tell how it stacks up against the whole of WinFS.
It does seem like comparing Spotlight + Core Data to WinFS is much more meaningful than comparing Spotlight alone to WinFS. Hopefully Spotlight and Core Data will be tightly integrated with each other; it would be a shame if not.
While schematized semi-structured DAGs of data may be overkill for many applications, you might be surprised how often something like this is needed, and how few developers actually have the skill to build it when it is necessary.
It is not uncommon for Windows developers to use a Jet database as their "file format", and just rename the extension to something else. Right off the top of my head I can think of three [1,2,3] apps that do this. CityDesk and ContentSaver would both be much better served by something like WinFS, as their data are not particularly relational in nature. Jet is also not easily fulltext searchable, doesn't give you eventing, is not scalable past 2GB...
The team behind Chandler (Mitch Kapor et al) have probably spent at least a man-year or two working on a repository with similar features to those intended for WinFS. From what I've heard, it's a nice piece of work, and they're hoping other developers will use it (i.e. not just for Chandler).
I myself spent much of last year working on a similar repository for version 1.0 of my company's application. It was an expensive task, but the result was well worth it, as our 2.0 product adds very different functionality and yet was easily built on the same storage foundation.
You can bet many others have tackled subsets of WinFS functionality for their applications. (Sleepycat's customer list would probably lead you to many of them.) The problem with everyone doing this on their own is not only duplication of effort, but it essentially closes the door on interoperability, since each implementation is in effect another proprietary file format. Not to mention that some of these problems are truly subtle and difficult, such as allowing concurrent access to sub-file-level items (fine-grained locks), replication and synchronization, etc.
[1] Diebold GEMS - http://www.diebold.com/dieboldes/GEMS.htm
[2] Fog Creek CityDesk - http://www.fogcreek.com/CityDesk/index.html
[3] Macropool ContentSaver - http://www.macropool.com/en/index.html
Slashdot Mirror
I 100% agree. I've found that Christians as individuals in general tend to be far too confident in their efforts to interpret the Bible.
But as for me, even if I believed in god, I wouldn't waste a moment of my life trying to second-guess him, so I'd end of living exactly the same way I do now.
I can see that point of view. For me, as a Christian, I believe that while the Bible may not give us all the answers we're looking for--or if parts of it are not even true, if taken literally--it will get me where I want to go, both in this life and the next (if there is one). This is not to say that there are not other reasons to believe in the Bible other than a blind and unquestioning faith, but rather, just because it's impossible to understand fully doesn't mean it's not useful to understand in part. (Whoa, sorry about all the negatives in that sentence.)
Oh, and the problem with the 'lesser of two evils' earthquake hypothesis is that there's no reason why the tectonic stress couldn't also have been let out through hundreds of itty-bitty tremors over a period of years. That it was instead 'saved up' for centuries and released via one of the most powerful earthquakes in recorded history suggests either apathy, malevolence, or nonexistence.
What if a 9.0 magnitude earthquake was itty-bitty compared to the unprecedented 18.0 magnitude (the Richter scale is exponential, isn't it?) earthquake that would have struck central India in 2014 had this one not occurred? What if the next would-be Hitler was killed in that earthquake? What if at the pearly gates, anyone who was killed in a natural disaster automatically gets into heaven?
We could go on and on in circles forever. The problem is that with as little information and perspective as we have, I am free to concoct whatever hypothetical situations I want to--since you are the one trying to prove the existence/non-existence of God with this argument. Again, I am not saying "look at this earthquake, isn't God so darn loving!?!?" I'm just saying you won't get there from here, by that road.
I actually think a more interesting theory is that God is (self-)constrained not to interfere. He lets the laws of physics play out, he lets humans commit heinous crimes... but all the time, he's keeping score. He steps in the minimum amount necessary to set up the rules, but after that he mostly observes. (See Parable of the Weeds.) In fact, if you look at Biblical history, you see that most of the time there are no miracles being performed, despite the need of God's followers--they are bunched up in clusters around certain turning points (Moses, Elijah, Jesus, the Apostles). Anyway, I think it's interesting, who knows if there's any truth to it.
No, not must, but might. In no way do I think this line of reasoning can prove the existence of an all-powerful, all-loving God; I am merely arguing that you cannot disprove it this way.
Also, I didn't say "because everything he does is loving because he is loving". I said, or at least meant to say, that with sufficient imagination you can come up with hypothetical constraints or preconditions or possible postconditions to make any action be construed as plausible for a loving omnipotent god.
I can't talk for Kirshna or Ganeesh or Zoroaster, but the Judeao-Christian-Islamic God of the Bible\Koran is incredibly cruel and arbitrary, by (if you believe these holy books are the "breathed word or God") his own admission. Killing hundreds of innocent people, including children, giving virgins over for soldiers to have their way with etc all seems pretty cruel to me and not the actions of a "loving" god.
It's true that the Christian Bible (can't speak for the others) has some passages and practices, generally in the Old Testament, that are difficult for our modern mores and sensibilities to relate to. The Old Testament is all about sin's devestating influence on the world, and man's inability to overcome it alone. However, this is balanced by the New Testament's message of the incarnation, sacrifice, and resurrection of the Messiah, who overcomes sin for all (or some significant fraction of) mankind. Furthermore, there are instances even in the Old Testament where God shows incredible mercy and patience (Genesis 18:16-30, Jonah 4, and basically all of his dealings with the people of Israel).
Sorry to be vague, but I'm not familiar with specific instances in the Bible where God ordered the slaughter of innocents or raping of virgins. If you point them out, I'll attempt to analyze them... (if I remember to check Slashdot that is.)
Not necessarily, depending on whether there is an afterlife and what determines your fate therein. That's even assuming that the earthquake wasn't actually a good outcome out of all the possible outcomes; for example, what if the earthquake released tectonic pressure that otherwise would've built up and killed millions instead of hundreds of thousands?
I for one think the "If an omnipotent, loving God exists, why does he let bad things happen?" line of argument is a red herring. It's impossible for us to understand the actions of a being with an infinite perspective, if one exists--or to look at it another way, you can always argue the other side, no matter how disastrous and cruel the world might seem to be.
domain name registrations
online fora and blog comments
usenet
Yeah, I leave my real e-mail address in all of those places. I used to be more careful, but SpamBayes is so good, spam just isn't a problem for me.
For example, the most difficult thing for me was trying to figure out how to package up my XUL/JS in a form that Firefox would take it. All the tutorials talked about install.js, installed-chrome.txt, and regxpcom, all of which are outdated. (Hint: Since Firefox 0.9, install.rdf is the key to the whole thing, so any tutorial that doesn't mention it is outdated.)
Once you've gotten the basics (probably by reading the O'Reilly book--the Nigel MacFarlane book may have a lot of useful info, but it was so poorly written I couldn't get through it), you really want to do yourself a favor and install Venkman, the Javascript debugger. The only place I've been able to find that has this little gem for Firefox is here.
Then, as you inevitably run into walls trying to get things done in the browser, cozy up to the source. There's not much you can do with XUL/JS that hasn't already been done in the Firefox source, and the search tools available on LXR will often lead you right to them.
And here are some source files you're definitely going to need to look at:
browser main window
browser menus and commands
browser main logic
Also, shamelessly unzip and dissect other people's XPI's; they probably won't mind anyway.
As if installing anything from AOL isn't a leap of faith already...
No kidding. I'm not a Perl fan, but if Guido van Rossum is on the list of nominees, Larry Wall really ought to be as well.
The advantages right now are mostly not pragmatic, but aesthetic. Programming with anonymous functions, closures, and higher order functions is more convenient in Ruby. The OO model seems better thought out.
t ml
JVM implementation: http://jruby.sourceforge.net/
Win32 support:
http://www.rubycentral.com/book/win32.h
Object DB: http://www.garret.ru/~knizhnik/dybase.html (I don't know anything about this one, just found it on Google)
List comprehension: Ruby blocks are a more general (and IMO more elegant) mechanism. For example,
[x*2 for x in mylist]
becomes
mylist.map{|x| x*2}
Note that in the Ruby version, x*2 doesn't need to be a simple expression; it could be any number of statements, and the return value would be used. So you could do this (using do/end instead of curly braces):
user_ids.map do |user_id|
result = webservice.lookup(user_id)
if result.success
return result
else
return nil
end
end
That's a pretty stupid example, but you get the idea.
It's not controversial, I think, that Python's bigger userbase and greater number of libraries give it an edge over Ruby for many real-world projects. But Ruby is suitable for a surprisingly large number of situations, and some people feel strongly that the elegance of the language makes it worth using whenever possible.
LL1 Call for Participation
Anton van Straaten
I think there is a lot more agreement about what isn't lightweight.
If a language is statically typed and doesn't have type inferencing, it's probably not lightweight. If a language does not have a freely available implementation, it's probably not lightweight. Any language that requires you to type this much to implement "Hello World" is definitely not lightweight:
I think one good way to look at it is whether you feel like the programming language gets in the way of what you're trying to express. If you're constantly adding characters to placate a compiler, if you're forced to define an object when what you really want is to write a simple script, if you're forced to do all sorts of arcane tricks to interop with other languages (especially C), all of these things work against you as a programmer and add "weight" to the program and to the process.
By these criteria, I think most programmers would consider Perl a lightweight language...
I attended last year's LL3 and the words "Visual" and "Basic" were never uttered together. On the other hand there was a whole lot of talk about "Scheme", "Haskell", "continuation passing style", and "macros" (the hygienic kind).
-shipping is good too; tends not to have a lot of false positives.
(Not rhetorical... I'm really asking.)
It may be rather non-intuitive for a programmer with a C/VB/Java background (which, admittedly, is almost all of us) but a functional programmer will feel right at home.
Anyway, once you get used to the block syntax (and it doesn't take long), the above is very readable. Blocks are worth taking the time to get used to; they're a great answer for a very large number of common problems, not just iteration and list comprehensions.
Java's DateTime represents an unambiguous instant in time. Delphi's TDateTime doesn't, as it has no information about timezones. This is, to me, a serious omission (and one that Microsoft's .NET DateTime class shares).
The design of Java's DateTime/Calendar was clearly meant to accomodate other calendars--while Gregorian may be what 99.99% of the programming world needs today, it's just like Sun to try for 99.99999%. You may not agree with the inconvenience it causes to those who just want to work with dates using Gregorian, but at least recognize that there is a flexibility/ease-of-use tradeoff equation here. You could take an instant in time (DateTime), manipulate it with a GregorianCalendar, then pass it off to a LunarCalendar (if you have one) and manipulate it some more.
Ruby
Stuff like this is exactly what I don't like about Python--introducing inconsistency for the sake of making a narrow scenario very slightly nicer. But then, obviously thousands of programmers love Python, probably because of stuff like this.
;)
I'll save you guys the suspense: It's a closeup of Tara Reid's boob.
From what I can tell, it's rather less useful if you don't have a laptop in the same room where the Airport Express is plugged in.
Core Data looks cool. It addresses the need I spoke of in GGGP post, but I don't see enough info to tell how it stacks up against the whole of WinFS.
It does seem like comparing Spotlight + Core Data to WinFS is much more meaningful than comparing Spotlight alone to WinFS. Hopefully Spotlight and Core Data will be tightly integrated with each other; it would be a shame if not.
Got a link?
Thanks a bunch!
Can someone please post the md5sums of the official packages? In particular I'm looking for the one for the win32 installer, "Firefox Setup 1.0.exe".
While schematized semi-structured DAGs of data may be overkill for many applications, you might be surprised how often something like this is needed, and how few developers actually have the skill to build it when it is necessary.
It is not uncommon for Windows developers to use a Jet database as their "file format", and just rename the extension to something else. Right off the top of my head I can think of three [1,2,3] apps that do this. CityDesk and ContentSaver would both be much better served by something like WinFS, as their data are not particularly relational in nature. Jet is also not easily fulltext searchable, doesn't give you eventing, is not scalable past 2GB...
The team behind Chandler (Mitch Kapor et al) have probably spent at least a man-year or two working on a repository with similar features to those intended for WinFS. From what I've heard, it's a nice piece of work, and they're hoping other developers will use it (i.e. not just for Chandler).
I myself spent much of last year working on a similar repository for version 1.0 of my company's application. It was an expensive task, but the result was well worth it, as our 2.0 product adds very different functionality and yet was easily built on the same storage foundation.
You can bet many others have tackled subsets of WinFS functionality for their applications. (Sleepycat's customer list would probably lead you to many of them.) The problem with everyone doing this on their own is not only duplication of effort, but it essentially closes the door on interoperability, since each implementation is in effect another proprietary file format. Not to mention that some of these problems are truly subtle and difficult, such as allowing concurrent access to sub-file-level items (fine-grained locks), replication and synchronization, etc.
[1] Diebold GEMS - http://www.diebold.com/dieboldes/GEMS.htm
[2] Fog Creek CityDesk - http://www.fogcreek.com/CityDesk/index.html
[3] Macropool ContentSaver - http://www.macropool.com/en/index.html
Well, you're half right, at least.