World: r3wp

Don't worry, I'll be sure to play with TRANSCODE/error until I can 
make it do magic tricks - it's already helped in LOAD :)

Go Hawley Go!

an accessor like /load ?    ;-)

Steeve.. how can I help you? :)

It would be fine to have AsmJIT integrated in REBOL as it could be 
used to speed up blitting as well.

What about JIT method for AGG I posted earlier?

that's it.. blitjit is based on asmjit

is that cross platform?

yep cross platform

Then we should order Cyphre to do few AGG tests :-)

Simulating AGG is not the main aim here. The first target is to replace 
rebcode in R3

ah, but you surely noticed what initiated this discussion? It was 
some test some guys did with the lib for AGG.

http://code.google.com/p/blitjit/- BlitJit is based upon ASMJit. 
I am all for RebCode replacement, especially as RebCode turned out 
to be rather slow to R2 version

i started my own thread :-)

HLA?

no

here

just wondering .. how many error free LOC should one expect from 
a REBOL programmer in an hour?

I'm guessing one line a minute.

That would be very high but it all depends on your definition of 
LOC written. Does it include undertanding (or even analysisng) the 
requirement, desigNing the script, coding, unit testing, system testing, 
acceptance testing and documentation?

When I first started work, our LOC metric included understanding 
the spec, flowcharting the program, coding (on paper - wihich was 
then punched onto cards), compiling the program, desk checking the 
program and unit testing.

We averaged 50 line of PL/1 code per day on that basis.

It is easier to write PL/1 code than Rebol because each line does 
much less.

50 lines per day?  wow.

With extrremely powerful languages like Rebol, LOC is even less reliable 
than less powerful languages. Are these comparable:

a: a + 1


repeat n 100 [if not error? try [close open probe join tcp://localhost: 
n] [print [n "is open"]]]

I'd rate the 2nd line as 5 lines

50 lines per day was twice the average for in-house companies which 
was one factor in the company's success.

I think lines of code is a pretty useless metric. Some lines are 
much more difficult to find than others.

and it is made less useful by the million different definitions of 
writing a line of code.

Graham: A good figure for you would be to count all the lines of 
code in Synapse-EMR and divide by the total number of hours you have 
spent working on it.

That's if the program you're comparing with is similar to the size 
and complexity of Synapse-EMR.

LOC: And what about code that you write, throw out and rewrite? LOC 
is not a useful productivity measuring method.

Much of the time is also spent on optimizing code = reducing code 
size.

If you start with 30 lines of code and end up with 10, that's still 
10 lines of production code ...

Yes.. and ? What does it tell you?

and tomorrow, that code may go away or be reduced to 3 lines, because 
you figured out an even better way to do it. LOC doesn't tell you 
anything.

Does it satisfy your need to have a simple answer? The answer to 
the question of which programmer is "better"?

Einstein must have been a really poor scientist, since his equations 
ended up being so small. :-)

I'd suggest that when you ask the question "How many lines of code 
a day do you produce on average?" and the respondent doesn't argue 
with you about the meaningless of the metric, that you should move 
on to someone else.

LOC is a bad measure of software productivity. As are most other 
alternative metrics, like, say function points:
http://en.wikipedia.org/wiki/Function_point_analysis

Quality of work (programming) might be measured by the amount of 
functionality divided by the amount of information produced to make 
this functionality.

So if you produce lots of LOC and get little functionality out of 
it, you're a bad programmer.

If you produce very little LOC and get lots of functionality out 
of it, you're a good programmer.

Readability probably play a role too, if the code has to be maintainable.

who cares bad or good the only goal is to do teh trick, satisfy the 
client and get the monney the rest is useless

judging coding since coding is an art is like judging painting .... 
can you say matis is better than Piccaso or Rambrant ?

what always amazed me in coding skills and in rebol most since i'm 
here to talk about rebol is the hability to do complexe thing the 
simpliest way possible

making complicated thing the complicated way is just loss of time

If you're going to measure KLOC, you have to measure it with historical 
data (e.g. the 100 lines that became 30 that became 10). And you 
have to account for design, testing, and domain understanding. Plus, 
do you have a well known target, or are you doing R&D?

Didn't Carl just post about a new metric?  http://www.rebol.net/wiki/Load_Mold_Sizes
 rebols don't count lines or semicolons, we loadmoldflatcompress.

such smaller indexers can be very good to learn and good basis if 
you need something more custom around data retrieval.. I was searching 
few times if there is anything like a text indexer written in REBOL 
but I only saw it today :)

Continuing a thread about Skimp and the Mailing List archive from 
the REBOLweek group...

We have 40K messages, but we index threads.....So only 9500 or so 
:-)

There is a skimp index per year. Each index has 27 files (header 
+ A, B,C etc). 
That's 400-odd files. Total 4.5 meg.

Not kept in memory....We're runnings a CGI application, so loaded 
afresh each time. (The opsys may be cacheing for us).