Re: Larkin, Power BASIC cannot be THAT good:

John Larkin wrote:
On Mon, 08 Jun 2009 13:32:45 +0200, Fred Bartoli <" "> wrote:

John Larkin a écrit :
On Sun, 07 Jun 2009 21:21:53 -0500, AZ Nomad
<aznomad.3@xxxxxxxxxxxxxxxxxxx> wrote:

On Sun, 07 Jun 2009 18:40:47 -0700, John Larkin <jjSNIPlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 07 Jun 2009 19:44:45 -0500, AZ Nomad
<aznomad.3@xxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 7 Jun 2009 17:29:50 -0500, Tim Williams <tmoranwms@xxxxxxxxxxx> wrote:
"AZ Nomad" <aznomad.3@xxxxxxxxxxxxxxxxxxx> wrote in message news:slrnh2oa19.46c.aznomad.3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PowerBasic (the console compiler version) has a couple of nice
built-in PARSE commands.
Sheesh. It's a phone call for you. The 70's want their interpreted
language technology back.
Hah. Interpreters rule. Unbeaten for debugging, especially for the range of constructs you can reconstruct on-the-fly.
Yes, but there's been some progress made in the last forty years.
BASIC is a piece of *** and utterly unuseable unless stacked to the
gills with proprietary extensions.
And what's wrong with "proprietary extensions" if they get work done?
That's fine if you never reuse code. Just wonderful if you write
everything from scratch and never use third party code libraries.
.NET is hardly a universal, portable platform. If all you write is
text-mode ANSI C, sure, it's fairly portable... as long as you keep
your ints and longs and stuff under control.

I've got better things to do than write a doubly linked list package for
the hundreth time. I'd rather have a language where I can use
libraries to do the work use use code examples from others.

As an engineer, I'm more interested in number crunching, simulation,
graphics, generating embedded code images, stuff like that. There are
a few nice collections of Basic subroutines around - curve fitting,
FFTs, stuff like that - so I don't always write everything from
scratch. And I do often reuse code.

I haven't used a linked list in decades. PCs are so fast these days
you can waste enormous numbers of cycles on brute-force methods, like
linear searching, to save programming time.

Well done!
You've just got your ticket for a hiring interview at M$ ;-)

Yes. I expect someone just like Larkin is responsible for the glacially slow graphics and charting in XL2007 (and also for degrading the chart trend line polynomial fit to give the same wrong answer as LINEST).

But my linear searches are 50x as fast as whatever nonsense they are
doing.

Even if that were true then a decent Shell sort worst case O(N^1.5) algorithm would beat your poxy O(N^2) algorithm when N > 2500. In a real example with random unsorted data as input Shell's sort would be more like O(N^1.3).

And an O(Nlog2N) sort would beat it hollow at N > ~500
You really are clueless about algorithms and their relative speeds.

Linear search or sort by straight insertion is typically only faster for N<50. Hardware engineers tend to code the even slower Bubble sort. It may be fast enough for your small datasets but it doesn't scale well.

Regards,
Martin Brown
.

Quantcast