http://freeshells.ch/~revence/simple.txt

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Woah... That's quite a lot of raving. ._.

His message seems fairly complex. Maybe it's incorrect?

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote

> http://freeshells.ch/~revence/simple.txt

The simple fact is any argument for Haskell and against other languages will
be valid when - scratch that - *if*  people start writing killer
applications, a killer OSs, APIs and killer games in Haskell.

Ah, I stand corrected, here's a killer game:

http://www.geocities.jp/takascience/haskell/monadius_en.html   <g>

from

http://www.haskell.org/haskellwiki/Applications (2nd on list)

I cannot imagine what Haskell will bring us in another 20 years. "A
scientist's toy box" is aptly where Haskell belongs.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://freeshells.ch/~revence/simple.txt

  He says that if you need to use arrays, the language is wrong.
That would make haskell wrong, because it supports arrays. (The question
would be: *Why* does it support arrays if, according to him, arrays are
completely unnecessary?)

  He also refers to this:

http://freeshells.ch/~revence/no-c.txt

  He is quite wrong at many places:

  He says that if everything you care about is speed, then you should use
assembly. This is completely wrong. 99.999% of programmers cannot beat a
good C compiler in speed by writing assembly directly. It's way too
complicated (especially with today's processor architectures with all their
multiple pipelines and whatnot).
  Even if you knew how to beat the C compiler by writing assembly directly,
you would be writing for *one* processor architecture only. Your code will
most probably become slower then the C version quite soon, probably in one
or two new processor versions.
  By writing in C you are making fast code for *all* possible processor
architectures which have a decent C compiler. This is simply *impossible*
to do by writing assembly (one reason being that you simply cannot predict
the future and know how processors will develop).
  So the answer is no: You cannot beat a C compiler by writing assembly.
Even if you beat it *now*, you will lose in the near future.

  "If it's speed you want, use macros, not functions." This guy must have
smoked something really bad.

  He also says that optimizing memory usage is complete nonsense. Clearly
he has never made programs which require handling humongous amounts of
data very fast. If he ever has to, and he is running out of memory, he
will have to start hand-optimizing with his beloved haskell using its
ugly byte arrays.

-- 
                                                          - Warp

Post a reply to this message

> His message seems fairly complex. Maybe it's incorrect?

It's simpler to ignore rants, but not always the correct solution.

Computers were created to automate complex and repetitive
tasks.  Therefore it follows that the more complex and
repetitive a task is to accomplish the more suitable it is to
being implemented on a computer.

In everyday life we typically reduce a task into smaller steps.

So if Darren is walking to China to deliver a letter, he'll
put one foot in front of the other, camp in various parks,
eat at countless burger stands, and probably buy
several pairs of shoes on the way. He would do all the work.

He might reduce the problem, and replace walking on
foot with driving his car, this shortens the time and means
less stops. He now lets the car do most of the work.

He might then replace the long drive with an airplane flight,
again, less time. Now the airlines do most of the work.

He might mail a letter instead. Now the postal service
uses some delivery trucks and a plane to deliver the letter,
they do most of the work.

He might use E-mail instead. Now the work is done by
computers and a few technicians.

Now let's say that Darren's friend in China is a really
attractive woman... a peviously unstated factor in his
deciding to take a trip to China. Now it can be seen
the best solution is not always the simple one, if you
allow for outside factors.

In terms of programming, an outside factor might be things
like available memory, disk space, or computation speed.
When memory comes into play you might need destructive
updates to arrays, etc.  The simplest solution isn't always
the best.

For example...
fac n = product [1..n]

This is simple code, but not always the quickest...

Here's a memoized version, it uses more memory
in order to gain speed...
fac :: Integer -> Integer
fac n = facList!!(fromInteger n)

facList = [fac' m | m <- [0..]]

fac' n | n == 0    = 1
       | otherwise = n * fac (n-1)

You can check the performance by mapping
a factorial over a list and taking the sum.  On
my machine the first one takes about 104 sec
to factorial numbers in a list [1..4000], the second
one does that in about 0.5 sec. Essentially the first
runs in O(n^2) time, and the second in O(n), but
has higher memory usage, it's a trade-off based on
outside factors, which one to use in which situation.

Post a reply to this message

"somebody" <som### [at] somewherecom> wrote:
> Ah, I stand corrected, here's a killer game:
>
> http://www.geocities.jp/takascience/haskell/monadius_en.html   <g>

You're not applying this guy's law of simplicity. Maybe his verse on features
will convince you of the value of Monadius:

"[Pet Peeve: Why do you add features to your software that, even though they
will
benefit 80% of your users, will kill the simplicity feature, from which 100% of
your users benefit? Features don't come for free - they feed on user comfort and
simplicity in use of the program and in code for as long as they exist. They are
insatiable parasites. Fight features, defend simplicity.]"

Clearly, Monadius is the best game in the world.

Tom

Post a reply to this message

Tim Attwood wrote:
> So if Darren is walking to China to deliver a letter,

> He might reduce the problem, and replace walking on
> foot with driving his car,

Being in the USA, I'd say both of these could be classified as "wrong" 
regardless of complexity. ;-)  [glub!]

> Now let's say that Darren's friend in China is a really
> attractive woman... 

Or, maybe my wife's relatives?  Don't get me slapped...

> When memory comes into play you might need destructive
> updates to arrays, etc.  

Which is only a problem if your compiler isn't smart enough, or 
disallows providing the appropriate hints. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://freeshells.ch/~revence/simple.txt

Sounds like an adolescent in love for Scheme and wanting the world to be all
about closures, tail-recursion and no explicit typing.  Until getting a bit
older and realizing it's not the world that should change to suit our needs,
but instead we should adapt to survive.

why is he comparing high level languages to high level assembly anyway?
Besides, the always-close-after-open thing in languages like C is a non-issue
when you use code templates and the likes...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Besides, the always-close-after-open thing in languages like C is a non-issue
> when you use code templates and the likes...

  In a way his approach to opening and reading the contents of a file seems
too simplistic:

  I agree: If what you are going to do is to read the entire contents of
the file into a string which you can then manipulate, the language offering
you a simple, easy and completely safe way to do this is a good thing.
  Given that languages like haskell use lazy evaluation, even if you are
only going to read part of the file and not the entire file, the haskell
compiler might probably be able to optimize it so that only that part of
the file is indeed read.

  However, I'm wondering what happens with huge files (which won't fit
in memory) and which you read thoroughly. It could be, for example, a
video file (which could be, for example, 3 gigabytes big, while your
computer has only eg. 1 gigabyte of RAM).
  The usual way of doing this is to read a bunch of data from the file
(for example some megabytes), process it, discard it, read a new bunch
of data from the file, etc.

  What I'm wondering is what a language like haskell will do in this case,
even though it has lazy evaluation. In fact, lazy evaluation is of no
help here because you are, after all, reading the entire file. If you
use the completely abstract way you could end up having the haskell
program trying to read the entire file into memory, thus running out of it.

  You have to somehow be able to tell it that you are only going to need
small bunches at a time, and after they have been processed, they can be
discarded. I wonder if there's a really abstract way of saying this in
haskell, or whether you need to go to ugly low-level specifics.

-- 
                                                          - Warp

Post a reply to this message

>> When memory comes into play you might need destructive
>> updates to arrays, etc.
>
> Which is only a problem if your compiler isn't smart enough, or disallows 
> providing the appropriate hints. :-)

The point is that there is no way for a compiler to decide.
Sometimes one is better, and sometimes another. It's up
to the programmer to pick what is correct. If a programmer
picks incorrect, it usually ends up being more complex
instead of simpler.

Post a reply to this message