Tuesday, July 27, 2004
Interestingly, Van Allen (of the Van Allen Belt fame) now questions human spaceflight:
Space Science Pioneer Van Allen Questions Human Spaceflight
The quick no-bullshit translation of this kind of crap is ALWAYS the same:
"Please spend more money on my kind of programs!"
I just sat in on a NASA talk about robotic exploration. Now, it's true that
a robotic probe can do a great flyby of a moon. But when it comes to
actual planetary science, the quote went:
"A robotic probe can do in an afternoon what a human geologist
can do in 45 seconds."
What really irritates me about the kind of evil we're encountering
in the anti-space-exploration movement is its upending of basic
human values. Your tax dollars, my tax dollars are going to fund
both space exploration and space science. But space science
is fundamentally USELESS unless it serves some human goal.
In other words, if we're not going to GO there, don't waste my
money futzing around taking PICTURES of there, because,
"at the end of the day", all you're trying to do is kill human
spaceflight so you can keep taking money from me to pay
for your comfortable academic chair.
Get a life.
-the Centaur
Space Science Pioneer Van Allen Questions Human Spaceflight
The quick no-bullshit translation of this kind of crap is ALWAYS the same:
"Please spend more money on my kind of programs!"
I just sat in on a NASA talk about robotic exploration. Now, it's true that
a robotic probe can do a great flyby of a moon. But when it comes to
actual planetary science, the quote went:
"A robotic probe can do in an afternoon what a human geologist
can do in 45 seconds."
What really irritates me about the kind of evil we're encountering
in the anti-space-exploration movement is its upending of basic
human values. Your tax dollars, my tax dollars are going to fund
both space exploration and space science. But space science
is fundamentally USELESS unless it serves some human goal.
In other words, if we're not going to GO there, don't waste my
money futzing around taking PICTURES of there, because,
"at the end of the day", all you're trying to do is kill human
spaceflight so you can keep taking money from me to pay
for your comfortable academic chair.
Get a life.
-the Centaur
Thursday, July 22, 2004
Mmm... sweet reasoning eases the pain.
Unfairenheit 9/11 - The lies of Michael Moore. By Christopher Hitchens
Unfairenheit 9/11 - The lies of Michael Moore. By Christopher Hitchens
Sunday, July 11, 2004
What the hell? Visual Basic has gotten C++ style generics?
Visual Basic: Visual Basic 2005: Defining and Using Generics in Visual Basic 2005
Will wonders never cease? What's next, lambdas, continuations,
and currying? I'm almost scared to look. List comprehensions
I could handle, but if they go for APL-style array operations
I'm going to go have to have a little lie down for a while.
Visual Basic: Visual Basic 2005: Defining and Using Generics in Visual Basic 2005
Will wonders never cease? What's next, lambdas, continuations,
and currying? I'm almost scared to look. List comprehensions
I could handle, but if they go for APL-style array operations
I'm going to go have to have a little lie down for a while.
Friday, June 11, 2004
Now, this is somewhat sick ... as soon as you
provide a nice feature for your users, like a
wiki, you run into asinine people who will
abuse it for their own purposes (follow the
Nigritude Ultramarine and the Wiki Sandbox Effect
This is why shopping centers have "no skateboarding"
signs and the BP on North Avenue closed off part
of its parking lot where the motorcycle clubs used
to pull in for their pit stops ... not because any one
person doing it is bad, but when enough people
take advantage, things get screwed up.
At least this guy realized what he was doing was wrong:
Wiki Sandbox Morals
provide a nice feature for your users, like a
wiki, you run into asinine people who will
abuse it for their own purposes (follow the
Nigritude Ultramarine and the Wiki Sandbox Effect
This is why shopping centers have "no skateboarding"
signs and the BP on North Avenue closed off part
of its parking lot where the motorcycle clubs used
to pull in for their pit stops ... not because any one
person doing it is bad, but when enough people
take advantage, things get screwed up.
At least this guy realized what he was doing was wrong:
Wiki Sandbox Morals
Thursday, June 03, 2004
Why isn't there a naming convention for APIs?
I was working on an API and had trouble picking a name for
a particular operation (which we'll call, say, "getCurrentText"
for sake of argument). TheFullyExplicitName was a little long
and unwieldy and I hve vry strng f3l'ns agst Un*x stle abbrs,
so I wanted to derive a simple text name that fits with the
rest of the API (read, readLine, isMoreNeeded).
So I ferret around on the web and find a few interesting
resources:
Java Collections API Design FAQ
API Design with Java
but no good resource for overall API names.
It seems to me there should be a standard lexicon of API
names. Just as there are standards for names in given languages
(e.g., getX/setX in Java, get/set properties in C#, -p predicates
in Lisp, isX for predicates in Java-like languages, etc.) there should
be standard names we can use for APIs with standard definitions
read/write or read/print
open/close
clear
iterator/hasNext/next
and so on. I guess there need to be two parts to this library:
the semantic list of terms that are common to many APIs, and
standard names that have maximum usage across the API's
semantic contents.
Anyway, just rambling.
I was working on an API and had trouble picking a name for
a particular operation (which we'll call, say, "getCurrentText"
for sake of argument). TheFullyExplicitName was a little long
and unwieldy and I hve vry strng f3l'ns agst Un*x stle abbrs,
so I wanted to derive a simple text name that fits with the
rest of the API (read, readLine, isMoreNeeded).
So I ferret around on the web and find a few interesting
resources:
Java Collections API Design FAQ
API Design with Java
but no good resource for overall API names.
It seems to me there should be a standard lexicon of API
names. Just as there are standards for names in given languages
(e.g., getX/setX in Java, get/set properties in C#, -p predicates
in Lisp, isX for predicates in Java-like languages, etc.) there should
be standard names we can use for APIs with standard definitions
read/write or read/print
open/close
clear
iterator/hasNext/next
and so on. I guess there need to be two parts to this library:
the semantic list of terms that are common to many APIs, and
standard names that have maximum usage across the API's
semantic contents.
Anyway, just rambling.
Apparently it does.
Hm... trying out the Google toolbar, because annoyance level on popups just hit max.
Google Toolbar Installed
And it has a Blogger feature. Intriguing. Wonder if this works.
Google Toolbar Installed
And it has a Blogger feature. Intriguing. Wonder if this works.
Wednesday, May 12, 2004
Ok, I don't have a lot of time to post --- we're in the middle of a software release and things are pretty tight. But I just fiddled around with alternate blogging software only to find that my expensive hosting provider (sounds something like "Worthfink") is on a version of Perl so old that the OddMuse software (used to run the excellent Georgia Tech Taido wiki) will not run.
So blogger gets a second chance.
12:23pm hit return.
So blogger gets a second chance.
12:23pm hit return.
Tuesday, March 16, 2004
More on languages...
Most of my concerns last time were about syntax, which might strike you
as superficial. So before I get any further into syntax, let me recognize
the importance of a clean underlying language model.
There's a lot of value to a pure language model. A clear low-level imperative
model enables languages like C and FORTRAN to be translated into efficient
machine code, making them good system and scientific computation languages,
respectively. A clear object model enables packaging vast quantities of code
into rich libraries for reuse, making Smalltalk and Java good languages for
experimentation and rapid development, respectively. Pure functional
orientation makes correctness proofs and parallel transforms easy,making
Haskell and Objective Caml darlings of the language design movement.
And pure logical design makes it easy to specify what you want to do,
rather than how, and that makes languages like Prolog and Mercury
popular in certain artificial intelligence circles.
But, in my mind, pragmatics ultimately trumps all. There's a reason
C++ was built on top of C, a reason Java has bare-metal types,
a reason Lisp has (progn) and (loop), a reason Prolog has cut.
Programmers have to be able to use the language to solve useful
problems, or the language is a toy.
Now, this isn't intended to denigrate language designers who have
taken one element of the paradigm to the max while at the same
time focusing on pragmatic concerns like execution efficiency,
expressiveness, and ease of use. But, to be frank, most language
designers who do leap onto the fundamentalist imperative / functional
/ logic / object-oriented bandwagon don't even bother to address
such concerns --- because they are fundamentally incompatible
with the programmatic consequences of the delusions and lies that
their religious views force them to adopt.
Which brings us back to syntax. Time and time again, I've heard
language designers say "I don't like such-and-so features, so I'm not
going to put them into my language." Balderdash. That's not a valid
reason to do something in a programming language that
other programmers are supposed to use; it's just childish
foolishness. Oh, you don't wan't multi-line comments, nested comments,
or function types in your language? Too bad. Grow the fuck up.
What's a good reason to do something in a language? It's about the
consequences. Multiple inheritance was omitted from Java because
it caused problems in the semantics and construction of C++ which
made it difficult for programmers to construct correct programs. Similarly,
at the syntactic level Java uses a separate assignment and equality
symbol and removes the equivalence of integers and booleans
to prevent a class of common programmer errors.
On the flip side, having expressive syntactic notations like the slice syntax,
list comprehensions and hash table constructors makes it possible for
programmers to write programs that accomplish a great deal concisely.
Lisp, my favorite language, makes it hard to write concise programs
because of its over-reliance on parentheses as its single list / grouping
/ code block / function definition / macro / what have you construct.
I understand completely why ultimately a real Lisp dialect has to be
reducible to something like an s-expression comprising functions and
data. But programmers should not have to write
all of those s-expressions if there's a more concise way to represent
it, nor should they have to rely on squinting at flashing parens and
reformatting indentation in their syntax-aware graphical editor just
to know whether or not they've written the right number of enclosing
parens on whatever godawful cond-lambda-reduce-map construct
they had to construct to get their job done.
So my plan moving forward: collect examples of syntax I like, and
show how they might reduce to s-expressions in a variant of Lisp.
Ultimately I want to push this back to collecting examples of semantic
features I like, and derive a clean model that would be both expressive,
interpretable, compilable and efficient.
Most of my concerns last time were about syntax, which might strike you
as superficial. So before I get any further into syntax, let me recognize
the importance of a clean underlying language model.
There's a lot of value to a pure language model. A clear low-level imperative
model enables languages like C and FORTRAN to be translated into efficient
machine code, making them good system and scientific computation languages,
respectively. A clear object model enables packaging vast quantities of code
into rich libraries for reuse, making Smalltalk and Java good languages for
experimentation and rapid development, respectively. Pure functional
orientation makes correctness proofs and parallel transforms easy,making
Haskell and Objective Caml darlings of the language design movement.
And pure logical design makes it easy to specify what you want to do,
rather than how, and that makes languages like Prolog and Mercury
popular in certain artificial intelligence circles.
But, in my mind, pragmatics ultimately trumps all. There's a reason
C++ was built on top of C, a reason Java has bare-metal types,
a reason Lisp has (progn) and (loop), a reason Prolog has cut.
Programmers have to be able to use the language to solve useful
problems, or the language is a toy.
Now, this isn't intended to denigrate language designers who have
taken one element of the paradigm to the max while at the same
time focusing on pragmatic concerns like execution efficiency,
expressiveness, and ease of use. But, to be frank, most language
designers who do leap onto the fundamentalist imperative / functional
/ logic / object-oriented bandwagon don't even bother to address
such concerns --- because they are fundamentally incompatible
with the programmatic consequences of the delusions and lies that
their religious views force them to adopt.
Which brings us back to syntax. Time and time again, I've heard
language designers say "I don't like such-and-so features, so I'm not
going to put them into my language." Balderdash. That's not a valid
reason to do something in a programming language that
other programmers are supposed to use; it's just childish
foolishness. Oh, you don't wan't multi-line comments, nested comments,
or function types in your language? Too bad. Grow the fuck up.
What's a good reason to do something in a language? It's about the
consequences. Multiple inheritance was omitted from Java because
it caused problems in the semantics and construction of C++ which
made it difficult for programmers to construct correct programs. Similarly,
at the syntactic level Java uses a separate assignment and equality
symbol and removes the equivalence of integers and booleans
to prevent a class of common programmer errors.
On the flip side, having expressive syntactic notations like the slice syntax,
list comprehensions and hash table constructors makes it possible for
programmers to write programs that accomplish a great deal concisely.
Lisp, my favorite language, makes it hard to write concise programs
because of its over-reliance on parentheses as its single list / grouping
/ code block / function definition / macro / what have you construct.
I understand completely why ultimately a real Lisp dialect has to be
reducible to something like an s-expression comprising functions and
data. But programmers should not have to write
all of those s-expressions if there's a more concise way to represent
it, nor should they have to rely on squinting at flashing parens and
reformatting indentation in their syntax-aware graphical editor just
to know whether or not they've written the right number of enclosing
parens on whatever godawful cond-lambda-reduce-map construct
they had to construct to get their job done.
So my plan moving forward: collect examples of syntax I like, and
show how they might reduce to s-expressions in a variant of Lisp.
Ultimately I want to push this back to collecting examples of semantic
features I like, and derive a clean model that would be both expressive,
interpretable, compilable and efficient.