Larkin, Power BASIC cannot be THAT good:

[Bob Larter]

Only if you look at it from a technical or academic perspective. From a
business perspective, the process is quite well tuned.

Like anything, performance and reliability are worth whatever the market
is willing to pay for them, no more and no less. If the market prefers
cheap crap over paying for quality, you get cheap crap.

Hence Microsoft - the McDonalds of the software industry.

 

[Bob Larter]

How about PostScript? Manual available here:

http://www.adobe.com/devnet/postscript/pdfs/PLRM.pdf

Great for printed graphics, less useful for on-screen graphics.

 

[Bob Larter]

It makes PIC assembler look intuitive.

Oh, steady on! - It's not *that* bad!

PostScript was designed to minimise
the burden on the interpreter, not the programmer.

True, but it's no harder to cope with than an RPN calculator, & I'm sure
that most people here would have no trouble with one of those.

 

[Bob Larter]

Hence the use of floating-point math for everything?

As I've said here before, PostScript is FORTH with FP & graphics.

 

[Bob Larter]

No it isn't. A 32 bit fixed point or scaled integer can represent and
specify a position with 1 micron resolution over a 4km range.

Indeed, & that's best-practice in FORTH, for example. But the main
reason that PS uses FP is for device independence, so that the same
image will output correctly to any device, regardless of the page size
or resolution.

 

[Bob Larter]

I'd like to see a high-level language similar to Python become a popular
choice for embedded programming... these days it still tends to be either C or
various proprietary flavors of BASIC. I suppose some of this is driven by how
little RAM many microcontrollers have (e.g., many Atmel AVRs now have >64kB of
flash ROM by <4kB of RAM... ouch!)

Hell, the first machine I programmed (NatSemi SC/MP) had only 256 bytes
of RAM, & the first machine I owned had 4KB of RAM, & an MS ROM BASIC in
8KB of ROM.

 

[Bob Larter]

Yeah, but if I rip out all the introspection and class-based stuff, then I
can.

I suppose at that point I've severely crippled the language, though.


But years ago "hello, world" *didn't* take up a megabyte, even in C (and C's
at a disadvantage in that most people would use printf -- which is large --
and that would tend to pull in all of stdio and stdlib, which are large...
languages that at least had basic I/O built-in such as Pascal would do better,
I'd think).

Here's a quick list, stolen from http://mbishop.esoteriq.org/hellosize.html:
a.. Ada - 19K
b.. Asm - 432B
c.. C - 8.9K
d.. C++ - 9.5K
e.. C# - 11K
f.. Common Lisp - 25MB
g.. D - 230K
h.. F# - 11K
i.. Fortran - 9.3K
j.. Haskell - 358K
k.. Java - 12K
l.. Modula-3 - 11K
m.. Oberon-2 - 13K
n.. Objective-C - 8.9K
o.. OCaml - 121K
p.. Pascal - 107K
q.. Scheme - 15K
r.. Standard ML - 166K
C is doing quite well there -- so is Objective-C, for that matter.

Nearly all of that is due to the particular languages implementation of
its equivalent to printf+io.h.

 

[Bob Larter]

Good business decision.

<checks it out>

Oh, that's excellent. ;^)

 

[Bob Larter]

Not sure if VBA can call DLLs.

It can. I wrote a VB app to pull data from a Borland C++ DLL which ran a
laser-scanning confocal microscope back in '95 or so.

 

[Bob Larter]

And that's not counting the GUI, or the non win/dos versions.

Hell, I grew up up with the MS 8KB ROM BASIC versions, & they're not
compatible with *anything*.

 

[Bob Larter]

I don't know about them, but to my knowledge ffmpeg and mplayer use a
lot of asm.

As far as I know, there isn't much of automatic vectorization in C
compilers either, so any non-trivial use of SSE and such needs hand
coded assembly.

OTOH, I think there was a fairly recent "survey" on slashdot about
assembly. The result was that few slashdot readers use it, but then I
read it as "slashdot reading perl and php coders don't use assembly".
Kind of no brainer...

Well, Slashdot readers are mostly idiots anyway.

 

[Rich Grise]

Hence Microsoft - the McDonalds of the software industry.

Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too!

Cheers!
Rich

 

[Rich Grise]

And you can order one, and have it handed to you on a tray with a
Coke, faster than Windows will start up.

Admittedly, I don't go there very much - there's an In-N-Out a couple
more blocks down the street.

Cheers!
Rich

 

[Nobody]

True, but it's no harder to cope with than an RPN calculator, & I'm sure
that most people here would have no trouble with one of those.

Not for simple arithmetic, but it starts to get awkward if you're writing
a non-trivial piece of software.

It's probably not so bad if you use either PostScript or Forth day in, day
out, but I find that I end up having to put a comment describing the
current stack contents between every line of code. That, and having every
non-trivial function store its arguments in a dictionary so that I can
reference them by name.

 

[Rich Grise]

On a sunny day (Fri, 19 Jun 2009 11:06:03 -0700) it happened John Larkin


Yes, but windows will start faster then it takes to resize a reiserfs from 830 to 600 GB:

What sane person resizes a file system? While it has DATA on it???

Thanks,
Rich

 

[Rich Grise]

On a sunny day (Fri, 19 Jun 2009 11:06:03 -0700) it happened John Larkin


Yes, but windows will start faster then it takes to resize a reiserfs from 830 to 600 GB:

grml: ~ # resize_reiserfs -s 600G /dev/sda8
resize_reiserfs 3.6.19 (2003 www.namesys.com)

From wiki:

ReiserFS was the default file system in Novell's SUSE Linux Enterprise
until Novell decided to move to ext3 on October 12, 2006 for future
releases. [1] Although the change was rumored to be a result of
principal author Hans Reiser being charged with the murder of his wife
(he was later convicted[2] ) two days earlier, SUSE stated that the
timing of the announcement was coincidental and unrelated.[3]

Reiser is also the default install for Slackware. I've been using it
ever since Patrick Volkerding approved it for Slack systems. ;-)

I've never lost data at a power outage, knock wood. ;-) ;-)

Cheers!
Rich

 

[Martin Brown]

It's an interpreter.

Not necessarily. Lisp compilers date back to the 1980s - I worked on
one. They were among the earliest incremental compilers.

I cannot recall exactly what the Procyon Common Lisp compiler for the
Mac made of "Hello World" but it would probably have been under 100kb.

WCL on a SPARC manages it in about 40kb. See for example:
http://www.ai.sri.com/~delacaze/alu-site/alu/table/systems.htm

And there were Lisp implementations on the BBC Micro that had to fit
into the 64kb address space of the puny 6502.

Regards,
Martin Brown

 

[Rich the Cynic]

.

If you want small and fast, that is the one, it is debian based.
I have modified it so it is now more 'Panteltje Linux'.
Maybe I should ... hehe

Why not? Write some whiz-bang install scripts! Just do X, gpm,
the network adapter and all that schtuff automagically, to make
as easy to install as Winblows, and Aunt-Tilly friendly. ;-)

Cheers!
Rich

 

[Rich Grise]

On a sunny day (Fri, 19 Jun 2009 21:32:00 GMT) it happened Rich Grise


OK Richman, I will try to explain it to you, so you will be a bit wiser.
As the very large file system fills up with hundreds of gigabytes,
it becomes slower and slower.
To keep speed usable it is better to have several smaller partitions,
with separate file systems, so the balanced trees for reiserfs do not grow into the sky.
As it is slow with 66 % fill, I could resize it to say 67%, and then resize that partition to 67 %,
and then make a new partition of 33 %, and accessing data on that new one would be then be faster,
Filling this one up to 100 % would slow down almost to a halt.
Actually I would like to try ext4 file system on the newly created partition,
to see how it behaves with huge files.

Oh. I'd have just verified that I have everything backed up, and used
fdisk.

To each his own, I guess. ;-)

Cheers!
Rich

 

[krw]

Hey! Don't knock Mac's! They're good, nutritious food, and tasty, too!

Saying that McDonalds sells good food is like saying that RadioShaft
sells good electronics.