Most patents are filed with the
hope that they'll make the inventor money. Either through direct licensing or through
(ugh) lawsuits later. So most folks regard
the cost of a search and the legal costs of
filing as a cost as doing business.
If you don't want to spend the money to get a
patent, I have to wonder if you plan to make
any money from it. Is this a
Patent Granted on Sideways Swinging sort thing?
Our lawnmower broke -- it's an electric, rechargeable Craftsman mulcher mower, and it
seems the battery won't charge any longer. So, now we have to find a new lawnmower.
That's hardly environmentally friendly. And
it also doesn't speak well for the technical
ability of a slashdotter. The obvious thing to
do is not to buy a new lawnmower, but to replace
the rechargeable battery.
Why does/. always consider stolen credit card numbers a consumer/yro problem? Stolen numbers that are used are nearly always reimbursed by the company
Yeah, but it can be a bit of a pain. It
takes at least a phone call, and in some cases
it'll require cooperating with police, insurance companies, random companies you've
never dealt with before but who lost money, and
swearing affidavits, something that can require
considerable time.
It's also indicative of the poor security that
many (most?) corporations give to personal
data, which is a true "consumer/yro" issue.
This is only a problem if you built Apache with mod_ssl and
a buggy version of OpenSSL, right?
Or installed a standard Linux distro wthat by
default puts a buggy Apache+mod_ssl+OpenSSL binary in...
It's a shame that so much stuff comes "with"
all the popular linux distributions. Ideally
a server should be stripped down to the bare
minimum of what's truly needed, not loaded up
with all sorts of junk, otherwise you spend
all your time patching up the junk as it gets exploited.
Both employment and grad school will want you to specialize so
impressing them with how broad your education is probably won't work.
Two points:
Some organizations are looking for breadth. Not the organizations who are looking
for drones who code C all day, but organizations
that are looking for truly talented leaders.
CS and Math isn't a lot breadth:-). CS and
Eastern European history is, CS and African Lit
is, CS and Civil Engineering is!
Yes, the GOF has a certain world view. That
view doesn't embrace relational databases as
the solution to every problem.
I disagree that there are no disclaimers
that describe the limitations of OO and GOF. There are profuse apologies for
the difficulty of persistent data in OO designs
everywhere I see. Beautiful OO stuff becomes
ugly the instance you add persistence. And databases are perhaps the other extreme -
persistence comes naturally, but everything
else is made ugly.
But clearly any real-world application has
a little bit of beauty from both and a little
bit of ugliness from both.
GOF patterns are for people who don't know how to properly use a database
That statement, my dear sir, is a glowing example
of a specific anti-pattern: Golden Hammer.
Yes, relational databases are one way of solving
a problem. The instant you decide that it's the
only way to solve the problem, you become part
of the problem.
To me, the most amazing scientific mind-change is
continental drift. In the
60's the concept was regarded by serious
geologists as completely
wacko and off the wall; by the time I took
my first science classes in the 70's it had
gone to the point of being "obvious even to kids - look at the way the continents fit together
if you slide them about". Of course, accurate
range-finding was what convinced even the
most stuck-in-the-mud geologists.
Re:How Object-Oriented is Perl
on
Ask Larry Wall
·
· Score: 2
Perl has been accused of not being object-oriented because it only supports one of The Three Pillars(encapsulation, the other two being
inheritance and polymorphism)
I disagree with the above entirely. Perl
OO is excellent at inheritance and polymorphism,
and it's not so good if you're anal-retentive
about encapsulation.
You can do effective encapsulation in Perl, but
it's a bit like driving your car wearing handcuffs that you've decided to put on yourself.
OO Perl inheritance and polymporhism are wonderful compared to, say, C++ or Java. The
lack of compile-time checking gives you incredible flexibility.
Perl newbies are obvious. They don't take
advantage of hash keys, and generally write Perl
just like they were coding in C (e.g. if/then/else
to do multi-way cases, lack of good exception
handling, for(;;) loops when a foreach loop
is much more clear, etc.)
They also "re-invent the wheel" with everything
where an obvious CPAN module application would have made
life easier for everyone involved.
A good chunk of professors and lecturers get this
wrong, along with discreet vs discrete. I'm not sure whether
they do this out of true bad spelling or to watch
those of us in the classroom familiar with
inside jokes do our snickering:-).
There's already a good amount of snickering in
a physics or math class already, what with phrases
like angle of deviation and
barrier penetration getting
tossed around:-)
Asteroid hunting should be part of the basic curriculum for astronomy programs, if it isn't already.
Traditional asteroid hunting is a truly
obsessive-compulsive kind of thing. I mean, it's
good that somebody does it, but the last thing
we want to do is turn introductory astronomy
courses into the sort of brainwashing exercise
it would take to produce these people.
Besides, many of the existing asteroid hunters
undoubtedly don't want any more competition.
It's good that many things that formerly
required CPAN modules (e.g. recursive-descent
packages) will be "built-in" to Perl 6. But
will all the syntax changes mean that there
will be a delay between the release of Perl 6
and all the CPAN modules catching up?
CPAN is a powerful resource. If all those modules
get left behind, I fear we may end up with a
more eloquent language in Perl 6 but with
substantially less usability.
My point was that many good programmers are not great at conversation and might not be able to answer questions competently in an interview environment, but may be excellent at their job.
Then I'd expect them to at least use some of
the lingo of the specialty in struggling with
the question, and to expend at least a little
bit of effort in coming to a level where the
communications is two-way. I honestly don't want to work
with someone who cannot (or will not) engage in a meaningful
discussion about their work.
There's a difference between coming up with the 'right' algorithm on the spot, and being able to find it in a reasonable time. I regard myself as slow but thorough -- I'd fail at such a question.
But at least you could present some candidate
methods and say why they may not be up to the
task. I wouldn't expect the *right* answer
on the spot every time, but I'd expect the
candidate to show some familiarity with the
available tools and methods.
I agree with many of your points, but disagree
with this:
That's because you assume that someone
who can answer questions quickly and proficiently is a good programmer. Wrong!
Why do I disagree? Because 99% of programming is
either understanding existing algorithms and
data structures in code or implementing
them. If a programmer/designer cannot quickly
see that a design pattern or algorithm solves
the problem, they can spend literally weeks
fumbling around until they come up with it.
And if they do not recognize common solutions in
the code, they are likely to give up on
understanding the code.
Yes, there is a small fraction of problem space
that few if any folks have ever seen before, and
there creativity and original thinking count for
a lot. But everyone has gotta know their bread-and-butter.
Energia was actually launched and could carry 22000 kg to Geosynchronous orbit or 88000 kg to LEO.
The Atlas V has about one fifthteenth the payload capacity in its
most fully decked-out configuration (551).
See also this page for nuclear propulsion mods to Saturn V's.
If battery conservation is important, stay away from the inverter- a large portion of the power will go away as heat- look
into switching power supplies
But inverters are switching power supplies. And good ones are 80 to 90% efficient.
I do agree it may seem silly to run two switchers
in series, but it's a very economical way to do
the job with commonly-available (read: you can
get the stuff at Wal-Mart) components.
a documentary based on the premise that all that had been proposed in the early 1950's in Colliers actually came to pass
Oh, yes. One of my favorite documentaries is
by Steven Spielberg and is based on the premise
that an alien was stranded on earth and
befriended a human boy to help him get back home. Man, that documentary footage of those
flying bikes is still vivid in my head.
This is a dumb article, because what they're really saying is "These morons could have gotten by with Windows 95 and the ODBC dBase IV driver as their, err, relational database driver, so they used that instead of Oracle".
Most applications don't need relational abilities
at all. Simple key-value databases like
BerkeleyDB
meet the needs of probably 99% of applications.
I now feel
I want to move into Science to use my skills in a productive, 'big picture' kind of way, rather than
just helping a client get more rich through financial services.
Wanting to improve the "big picture" for many
people, rather than just earn bucks for your
employer, is an admirable goal. But you might
be dissatisfied with a job in science/academia because
very often the objectives are arcane and specialized
and do not have any obvious "big picture" payoff.
Think about what you could do to help a
government agency, charity, church, organization
achieve their goals via IT. There's a lot of
unexploited opportunities for computers and the
web in these realms. Many of these organizations
are technologically backwards, which means
two things:
There are many opportunities to do obvious things. You may end up viewed as a technological savior just for coming in with
relatively basic skills and knowing how to
apply them.
But there will be some (or much) organizational inertia
against taking advantage of these opportunities.
This can lead to frustration.
Slashdot Mirror
I recently put together a web and mail server based on a mini-ITX motherboard with a Via C3 processor on it. It cost less than $300 altogether and installing Linux was a breeze.
If you don't want to spend the money to get a patent, I have to wonder if you plan to make any money from it. Is this a Patent Granted on Sideways Swinging sort thing?
That's hardly environmentally friendly. And it also doesn't speak well for the technical ability of a slashdotter. The obvious thing to do is not to buy a new lawnmower, but to replace the rechargeable battery.
Yeah, but it can be a bit of a pain. It takes at least a phone call, and in some cases it'll require cooperating with police, insurance companies, random companies you've never dealt with before but who lost money, and swearing affidavits, something that can require considerable time.
It's also indicative of the poor security that many (most?) corporations give to personal data, which is a true "consumer/yro" issue.
Or installed a standard Linux distro wthat by default puts a buggy Apache+mod_ssl+OpenSSL binary in...
It's a shame that so much stuff comes "with" all the popular linux distributions. Ideally a server should be stripped down to the bare minimum of what's truly needed, not loaded up with all sorts of junk, otherwise you spend all your time patching up the junk as it gets exploited.
Two points:
I disagree that there are no disclaimers that describe the limitations of OO and GOF. There are profuse apologies for the difficulty of persistent data in OO designs everywhere I see. Beautiful OO stuff becomes ugly the instance you add persistence. And databases are perhaps the other extreme - persistence comes naturally, but everything else is made ugly.
But clearly any real-world application has a little bit of beauty from both and a little bit of ugliness from both.
That statement, my dear sir, is a glowing example of a specific anti-pattern: Golden Hammer.
Yes, relational databases are one way of solving a problem. The instant you decide that it's the only way to solve the problem, you become part of the problem.
To me, the most amazing scientific mind-change is continental drift. In the 60's the concept was regarded by serious geologists as completely wacko and off the wall; by the time I took my first science classes in the 70's it had gone to the point of being "obvious even to kids - look at the way the continents fit together if you slide them about". Of course, accurate range-finding was what convinced even the most stuck-in-the-mud geologists.
I disagree with the above entirely. Perl OO is excellent at inheritance and polymorphism, and it's not so good if you're anal-retentive about encapsulation.
You can do effective encapsulation in Perl, but it's a bit like driving your car wearing handcuffs that you've decided to put on yourself.
OO Perl inheritance and polymporhism are wonderful compared to, say, C++ or Java. The lack of compile-time checking gives you incredible flexibility.
Perl newbies are obvious. They don't take advantage of hash keys, and generally write Perl just like they were coding in C (e.g. if/then/else to do multi-way cases, lack of good exception handling, for(;;) loops when a foreach loop is much more clear, etc.)
They also "re-invent the wheel" with everything where an obvious CPAN module application would have made life easier for everyone involved.
A good chunk of professors and lecturers get this wrong, along with discreet vs discrete. I'm not sure whether they do this out of true bad spelling or to watch those of us in the classroom familiar with inside jokes do our snickering :-).
There's already a good amount of snickering in a physics or math class already, what with phrases like angle of deviation and barrier penetration getting tossed around :-)
Traditional asteroid hunting is a truly obsessive-compulsive kind of thing. I mean, it's good that somebody does it, but the last thing we want to do is turn introductory astronomy courses into the sort of brainwashing exercise it would take to produce these people.
Besides, many of the existing asteroid hunters undoubtedly don't want any more competition.
CPAN is a powerful resource. If all those modules get left behind, I fear we may end up with a more eloquent language in Perl 6 but with substantially less usability.
Then I'd expect them to at least use some of the lingo of the specialty in struggling with the question, and to expend at least a little bit of effort in coming to a level where the communications is two-way. I honestly don't want to work with someone who cannot (or will not) engage in a meaningful discussion about their work.
But at least you could present some candidate methods and say why they may not be up to the task. I wouldn't expect the *right* answer on the spot every time, but I'd expect the candidate to show some familiarity with the available tools and methods.
Yes, there is a small fraction of problem space that few if any folks have ever seen before, and there creativity and original thinking count for a lot. But everyone has gotta know their bread-and-butter.
Huh? The bc I know is definitely an interpreter, not a compiler. Threaded code?
Is this something different? Or am I supposed to not take these technical articles literally?
See also this page for nuclear propulsion mods to Saturn V's.
But inverters are switching power supplies. And good ones are 80 to 90% efficient.
I do agree it may seem silly to run two switchers in series, but it's a very economical way to do the job with commonly-available (read: you can get the stuff at Wal-Mart) components.
Oh, yes. One of my favorite documentaries is by Steven Spielberg and is based on the premise that an alien was stranded on earth and befriended a human boy to help him get back home. Man, that documentary footage of those flying bikes is still vivid in my head.
Most applications don't need relational abilities at all. Simple key-value databases like BerkeleyDB meet the needs of probably 99% of applications.
Wanting to improve the "big picture" for many people, rather than just earn bucks for your employer, is an admirable goal. But you might be dissatisfied with a job in science/academia because very often the objectives are arcane and specialized and do not have any obvious "big picture" payoff.
Think about what you could do to help a government agency, charity, church, organization achieve their goals via IT. There's a lot of unexploited opportunities for computers and the web in these realms. Many of these organizations are technologically backwards, which means two things:
- There are many opportunities to do obvious things. You may end up viewed as a technological savior just for coming in with
relatively basic skills and knowing how to
apply them.
- But there will be some (or much) organizational inertia
against taking advantage of these opportunities.
This can lead to frustration.
Good luck!