I have a project of converting some old cobol app part code, 46372
lines .
So after 25 years my boss told me that i can write it in whatever I
want.
(Actually I finally become the one who makes thisdecision in this
quarter of century).
So since I didn't write almost nothing in lisp since cltl1 I could
use some guidance:
1. Size of the lisp image vs the c exe.
2 How long does a rewrites usually takes from c to lisp ?
I must have it operational til december.
The speed and memory issues doesn't worry me, but for historical
reasons
a lot of our data goes on floppy.
J.T.
jeremia wrote:
> I have a project of converting some old cobol app part code, 46372
> lines .
> So after 25 years my boss told me that i can write it in whatever I
> want.
> (Actually I finally become the one who makes thisdecision in this
> quarter of century).
> So since I didn't write almost nothing in lisp since cltl1 I could
> use some guidance:
> 1. Size of the lisp image vs the c exe.
>
> 2 How long does a rewrites usually takes from c to lisp ?
> I must have it operational til december.
>
> The speed and memory issues doesn't worry me, but for historical
> reasons
> a lot of our data goes on floppy.
>
> J.T.
It would be much easier to give you some answer if you give us some
data
about your experience with lisp. Did you wrote the cobol code yourself
or reading somebody's else code.What drums and bells you want( I assume
to put, like
menus, GUI etc and do you plan to use commercial vendor code or free
implementation.
I work a little bit on some cobol fixing before mil bug and the
language really sucks so
4X smaller lisp code at least to be expected maybe more
·············@hotmail.com wrote:
.
>
> It would be much easier to give you some answer if you give us some
> data
> about your experience with lisp.
This one is tricky to answer. I haven't use it profesionally ever in my
life.
> Did you wrote the cobol code yourself
> or reading somebody's else code.
The whole code is either written by me or under mine supervision,so I
know how it works well inside-out.
>What drums and bells you want( I assume to put, like
> menus, GUI etc and
Keep the internal logic and add mouse driven look.
> do you plan to use commercial vendor code or free implementation.
The vendor definately, I just didn't decided which one : I downloaded
allegro ide and it looks fine , I'll try later scieneer and lispworks
staff.
> I work a little bit on some cobol fixing before mil bug and the
> language really sucks so
> 4X smaller lisp code at least to be expected maybe more
The cobol is feeding my family for the past quarter century , and it's
doing it's job very well so keep your remarks Lisp is just more fun to
work for.
Gee waiting 25 years to code in lisp, that must be bad man.
But better now than never.
Sorry I just don't know a damn about cobol and I really don't want to
learn
about it.
Anyway don't forgeth to post what the end result will look like I just
love those kind of information.
bobi
jeremia wrote:
> ·············@hotmail.com wrote:
> .
> >
> > It would be much easier to give you some answer if you give us some
> > data
> > about your experience with lisp.
>
> This one is tricky to answer. I haven't use it profesionally ever in my
> life.
> > Did you wrote the cobol code yourself
> > or reading somebody's else code.
> The whole code is either written by me or under mine supervision,so I
> know how it works well inside-out.
> >What drums and bells you want( I assume to put, like
> > menus, GUI etc and
> Keep the internal logic and add mouse driven look.
>
> > do you plan to use commercial vendor code or free implementation.
> The vendor definately, I just didn't decided which one : I downloaded
> allegro ide and it looks fine , I'll try later scieneer and lispworks
> staff.
>
'couse you decided to use vendor making the controls would be easy
the rest depends on how good are you with lisp.
Still might be good idea to hire some Lisp consultant , just in case
you get stuck or something, if company pays the bills.
Antoan
jeremia wrote:
> ·············@hotmail.com wrote:
> .
> >
> > It would be much easier to give you some answer if you give us some
> > data
> > about your experience with lisp.
>
> This one is tricky to answer. I haven't use it profesionally ever in my
> life.
> > Did you wrote the cobol code yourself
> > or reading somebody's else code.
> The whole code is either written by me or under mine supervision,so I
> know how it works well inside-out.
Good. I am guessing also the thing is running now every day. I had a
task just massively overhauling a system, not changing language and
luckily not its output. When you get to alpha testing, copy the
production files every day and run the Lisp version against that. You
will need a comaprison program because (I lied) there was some change
to the output, so an ignorant diff won't work, but not so much that a
program could not compare them. When you get a difference, you might
have to fix your alpha, or with luck just the comparer to tell it about
some intended difference. When this thing runs every day without a
problem you at least have some measure of confidence.
> >What drums and bells you want( I assume to put, like
> > menus, GUI etc and
> Keep the internal logic and add mouse driven look.
>
> > do you plan to use commercial vendor code or free implementation.
> The vendor definately, I just didn't decided which one : I downloaded
> allegro ide and it looks fine ,
make sure you get the runtime licensing terms in writing up front if
you go with Franz. careful, it's a double auction. (thx, Michael!)
> I'll try later scieneer and lispworks
> staff.
> > I work a little bit on some cobol fixing before mil bug and the
> > language really sucks so
> > 4X smaller lisp code at least to be expected maybe more
>
> The cobol is feeding my family for the past quarter century , and it's
> doing it's job very well so keep your remarks Lisp is just more fun to
> work for.
Cobol is a fine language. copy-replacing puts it one up on Java and
Python, and evaluate puts it one up on <gasp!> common lisp....
actually, there is a helluvan exercise for the Lisp Final Exam: a
two-dimensional COND macro.
kenny