![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
You remember the days when programmers struggled to fit as much program
as possible into 64 KB of RAM?
I just realised something. The Haskell program I wrote the other day?
It's 1.5 MB in size. This single executable program is actually *too
big* to fit on a single [high-density] floppy disk.
The worrying part is, it doesn't even *do* anything! It's just a wrapper
around a seperate program...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> wrote:
> I just realised something. The Haskell program I wrote the other day?
> It's 1.5 MB in size. This single executable program is actually *too
> big* to fit on a single [high-density] floppy disk.
Is there *any* programming language designed after the early 80's which
actually cares about memory usage?
(No need to mention the obscure languages designed for embedded systems
because in those cases they are forced to care.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Is there *any* programming language designed after the early 80's which
> actually cares about memory usage?
Ada? FORTH?
My take on it is that if you're concerned about memory usage, use one of
the languages that's good at memory usage. How many of them do you need?
What's missing that would make life a lot easier that you can
nevertheless fit into a small memory footprint? If you don't have a lot
of memory, chances are your program isn't big enough to need a really
sophisticated and/or unusual language to code it in. Pick one like C,
C++, Ada, BASIC, or FORTRAN, and use it. If you need something
"stronger", use LISP or FORTH or Smalltalk.
Fitting Mathematica, Prolog, or Haskel into 64K just isn't worth it -
there isn't enough data to be processed that you need particularly
sophisticated processing methods.
Sure, languages like Java waste memory if you allocate each integer as a
separate object, so you make an array of integers to hold your bitmap,
and deal with the minor pain that architectural decision entails.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > Is there *any* programming language designed after the early 80's which
> > actually cares about memory usage?
> Ada?
1983.
> FORTH?
1970's.
> Sure, languages like Java waste memory if you allocate each integer as a
> separate object, so you make an array of integers to hold your bitmap,
> and deal with the minor pain that architectural decision entails.
What if you want objects with two or three integers inside them?
Or an integer and a floating point value?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>> Ada?
> 1983.
Ada-95, then? ;-)
>> FORTH?
> 1970's.
Oh. Yeah, OK, it was around a lot longer than I knew. Standardized a lot
later, tho. Thanks. :-)
>> Sure, languages like Java waste memory if you allocate each integer as a
>> separate object, so you make an array of integers to hold your bitmap,
>> and deal with the minor pain that architectural decision entails.
>
> What if you want objects with two or three integers inside them?
> Or an integer and a floating point value?
You still put it in an array, or two parallel arrays. Or use C# instead.
Don't attribute Java's limitations to every safe/GCed language :-)
I think the basic problem is that after the early 80's, people weren't
designing programming languages based on 8-bit processors with 16-bit
address spaces. I mean, C and FORTRAN were considered terribly wasteful
of resources back when 1K of RAM was a lot of memory. :-)
I guess most people doing that stuff figured memory-restricted languages
were pretty much a solved problem. Pick from C, Fortran, COBOL, Ada,
FORTH, Assembler, Pascal, BASIC, APL, LISP, Algol, PL/1, C++, ... as you
like. Why make another like that? What's missing? All those languages
ran comfortably in and could do considerable (for the time) computation
on a 64K machine. If you don't have the memory to run Excel, write it in
APL. If you don't have the memory to run Perl, write it in COBOL. If
Prolog is too big, use LISP.
It seems obvious to me that if one is interesting in developing new
languages, it's a good idea to target the machines with new
capabilities. You want to solve in your language the kinds of problems
that don't come up when you only have small machines, like how to
efficiently organize terabytes of data spread over a dozen cities in a
way that you never, ever have an outage.
Of course, you also have things like befunge, brainfuck, intercal, and
all the other joke languages which can nevertheless be interpreted with
a handful of memory. :-) I suspect this isn't what you meant, tho.
And of course you have problems that push the limits of big machines
too. Video games, artificial intelligence, physics simulations (of
various accuracies), data mining (say, google), etc. But a lot of those
kinds of problems can be broken into a more-core part that you write in
a difficult efficient language and a less-core part that you write in a
more powerful less efficient language. Which is kind of the same all the
way down the stack - C is a lot easier than VHDL to get some piece of
functionality out of, but you might need a dozen C instructions to do
what one custom VHDL blob of gates could do in a couple of clock cycles.
Why is software less reliable than hardware? One reason is that software
is used to do the stuff that is far too complex to do in hardware. Why
do people build languages like Java or Erlang or Haskel that compile
down to C? To build the systems you couldn't build in C because it's too
low-level conceptually, lacking vital flexibility.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 13-Jul-08 22:34, Warp wrote:
> Orchid XP v8 <voi### [at] dev null> wrote:
>> I just realised something. The Haskell program I wrote the other day?
>> It's 1.5 MB in size. This single executable program is actually *too
>> big* to fit on a single [high-density] floppy disk.
>
> Is there *any* programming language designed after the early 80's which
> actually cares about memory usage?
POV-Ray?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel <a_l### [at] hotmail com> wrote:
> > Is there *any* programming language designed after the early 80's which
> > actually cares about memory usage?
> POV-Ray?
Except that POV-Ray isn't a programming language but a renderer.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Is there *any* programming language designed after the early 80's which
> actually cares about memory usage?
HTML
(Dodges tomatos!)
--
----> If you cut here, you'll ruin your monitor. <----
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> You remember the days when programmers struggled to fit as much program
> as possible into 64 KB of RAM?
>
> I just realised something. The Haskell program I wrote the other day?
> It's 1.5 MB in size. This single executable program is actually *too
> big* to fit on a single [high-density] floppy disk.
>
> The worrying part is, it doesn't even *do* anything! It's just a wrapper
> around a seperate program...
>
Have you ever heard of premature optimization?
Don't bother solving a problem until it's a problem. Sure, modern
programs use WAY more resources than older ones... but is it even a problem?
Unless you're running out of memory on your computer, don't even try to
optimize it for size.
Let's face it: on a modern computer with, say, 3Gb of RAM, if you have a
program that's running out of memory, are you going to care about
a) The data structures using up 4Gb of RAM that you need to optimize, or
b) The default libraries linked in using .0015 Gb of RAM?
...Chambers
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mueen Nawaz wrote:
> Warp wrote:
>> Is there *any* programming language designed after the early 80's which
>> actually cares about memory usage?
>
> HTML
>
> (Dodges tomatos!)
>
>
If you mean, it's designed to care about using AS MUCH AS POSSIBLE? ;)
...Chambers
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |