From: Norbert_Paul on
Well I aint living on the street yet, and my turn from Java to Lisp looks
quite dangerous when watching mainstream. So Lisp might equally drag me
on the street instead of protecting from living there.

Tim Bradshaw wrote:
> On 2010-05-15 15:47:33 +0100, Norbert_Paul said:
>
>> And yet an even more verbose "No." to my initial question.
>
> Actually, an explanation of why so many Java people end up living on the
> street.
>

From: Scott L. Burson on
On May 15, 10:57 am, Antony <spam+lisp_dot_li...(a)gmail.com> wrote:
>
> I could not find (maybe I looked
> wrong) a [...] dynamic
> array where I could set an arbitrary element and have the array grow
> automatically and fill the unfilled indexes with defaults.

Heh -- FSet has this :)

-- Scott
From: Tim Bradshaw on
On 2010-05-15 22:22:07 +0100, Norbert_Paul said:

> Well I aint living on the street yet, and my turn from Java to Lisp looks
> quite dangerous when watching mainstream. So Lisp might equally drag me
> on the street instead of protecting from living there.

True. Lisp people have always lived on the street. Somehow it's
easier when you've never known anything else, I find (well, of course,
some of us older people can remember the gutter as well). Things are
looking up though - it's just way easier scavenging for unsecured wifi
to post to usenet than it used to be breaking into phone cabinets, not
to mention lugging a vt52 around was a serious pain.

From: Scott L. Burson on
On May 8, 6:11 am, Norbert_Paul <norbertpauls_spam...(a)yahoo.com>
wrote:
> Scott L. Burson wrote:
> >> But remember: "Premature optimization is the root of all evil".  ...
>
> But remember what I said in my initial post.

I think we should draw a distinction here between time complexity and
linear speedup. Replacing a cubic algorithm with a quadratic one, or
quadratic with n log n, is not premature optimization if you know
you're going to run on a large data set sooner or later. But doing
something whose only possible benefit is some amount of linear speedup
does, in most situations, count as premature optimization --
particularly if one doesn't know the amount of speedup to be gained or
even where the program is spending its time.

Since FSet uses balanced trees, using it will cause no _complexity_
problems. Taking a program written using FSet and converting it to
use imperative collections can't speed up the program by more than a
logarithmic factor -- and in most cases, the speedup will be linear.
(*)

This leaves us with one burning question: just how big a linear
speedup would be expected from this conversion? After all, if it were
10x or even 2x, people would be understandably inclined to avoid FSet
despite this argument. I have to admit I don't really know, but I
would be surprised if it were over 20% in a real program, i.e. one
that has other things to do besides just manipulate collections.

(*) Two notes: (1) Some kinds of code will actually get slower,
because the conversion from functional to imperative collections will
force many copying steps. But such programs are fairly rare. (2) I
think the likeliest way for logarithm slowdown to result from FSet use
is because LOOKUP on a seq takes log time, not constant time as ELT on
an array would. But most sequence indexing operations are done as a
part of iterating over the sequence; true random access is relatively
rare. FSet's DO-SEQ macro, as well as its seq iterators, do provide
amortized constant time access per element, so if you're using seqs
and performance is an issue, using those for iteration, rather than
repeated LOOKUPs, is recommended.

> This is very interesting: Functional balanced trees! So I'll have a
> closer look at them.

Have you had a chance to take a look yet?

-- Scott
From: Tamas K Papp on
On Sat, 15 May 2010 23:22:07 +0200, Norbert_Paul wrote:

> Well I aint living on the street yet, and my turn from Java to Lisp
> looks quite dangerous when watching mainstream. So Lisp might equally
> drag me on the street instead of protecting from living there.

You mean that learning something new somehow jeopardizes your job?
You must be working for the government :-)

Tamas
First  |  Prev  |  Next  |  Last
Pages: 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: scheme problem
Next: lisp student job offer