Unit tests ... not just for the young

ruby-talk
21

An odd translation, I must say. What's wrong with learning more
within one's chosen discipline?

···

On Thursday, June 10, 2004, 2:29:44 AM, Michael wrote:

On Thu, 10 Jun 2004 01:03:27 +0900, Sean O'Dell <sean@celsoft.com> wrote:

Ditto. When hiring an artist, should one be wary of people who want to be an
artist forever? When hiring a gardener, should one be wary of people who
want to garden forever? I don't see the logic in refusing to hire a person
because they love their work and want to keep doing it the rest of their
life.

This translates to me to not wanting to learn, and that I can do without.

22

Michael Campbell wrote:

Ditto. When hiring an artist, should one be wary of people who want to be an
artist forever? When hiring a gardener, should one be wary of people who
want to garden forever? I don't see the logic in refusing to hire a person
because they love their work and want to keep doing it the rest of their
life.

This translates to me to not wanting to learn, and that I can do without.

I think we're all talking past each other here.

My opinion is, I want to be a programmer as long as I possibly can. That
doesn't involve my skills or my job remaining static. It demands that
they change continually.

So it does NOT translate into stagnation or a lack of interest in
learning -- the exact opposite, I would say.

If you don't keep pace with technology and grow in your own field,
you won't BE a programmer in fifteen years.

Instead you'll be a manager of the breed I have had over and over --
ex-COBOL programmers who never heard of OOP and are now paper-pushers.
Except in 2020 you'd be an ex-Java programmer.

That is why I don't consider becoming a manager to be an "advancement"
even though it may be more salary or prestige. Most of the managers
I know became managers by being too tired or too stupid to keep up with
the industry changes.

Just my opinion...

Hal

···

On Thu, 10 Jun 2004 01:03:27 +0900, Sean O'Dell <sean@celsoft.com> wrote:

23

That doesn't follow. When you work in a field, you grow as a person and, if
you're good, you can advance the field itself. Open your mind up. You can
work the same job and still grow tremendously with it.

  Sean O'Dell

···

On Wednesday 09 June 2004 09:29, Michael Campbell wrote:

On Thu, 10 Jun 2004 01:03:27 +0900, Sean O'Dell <sean@celsoft.com> wrote:
> Ditto. When hiring an artist, should one be wary of people who want to
> be an artist forever? When hiring a gardener, should one be wary of
> people who want to garden forever? I don't see the logic in refusing to
> hire a person because they love their work and want to keep doing it the
> rest of their life.

This translates to me to not wanting to learn, and that I can do without.

24

In article <811f2f1c0406090929564fedc9@mail.gmail.com>,

Ditto. When hiring an artist, should one be wary of people who want to be an
artist forever? When hiring a gardener, should one be wary of people who
want to garden forever? I don't see the logic in refusing to hire a person
because they love their work and want to keep doing it the rest of their
life.

This translates to me to not wanting to learn, and that I can do without.

Not true at all. There are always new
techniques/languages/patterns/methodologies/algorithms to learn in our
field. There's certainly enough room for self-improvement for many years.
I don't see that it's bad to want to continue to improve your
level of craftsmanship.

I tend to agree with the idea that it takes a good 10 years to become
competent at software development. Why should we want to leave programming
just when we're getting good at it?

Phil

···

Michael Campbell <michael.campbell@gmail.com> wrote:

On Thu, 10 Jun 2004 01:03:27 +0900, Sean O'Dell <sean@celsoft.com> wrote:

25

I don't agree that side-interests make for a better programmer. If you're
hiring a programmer, you want someone who's main interest is programming. My
experience has been that the more a person loves programming, the better they
are at it. If we're discussing hiring a programmer, to do programming work,
I want the best programmer I can get for my money, so side-interests are one
of the things I DON'T want in a potential employee.

  Sean O'Dell

···

On Wednesday 09 June 2004 09:42, Tyler Zesiger wrote:

Sean O'Dell wrote:
>
> Ditto. When hiring an artist, should one be wary of people who want to
> be an artist forever? When hiring a gardener, should one be wary of
> people who want to garden forever? I don't see the logic in refusing to
> hire a person because they love their work and want to keep doing it the
> rest of their life.

When interviewing, I would probe for deeper ambitions. Someone who is,
or will be, a master artist will have ambitions beyond just doing their
own art all day. And if they don't, I'd try to see if the could be
coaxed into broadening their horizons.

For example, a master artist is the kind of guy I'd want involved in
arranging a movie set, or teaching, or *something* besides just churning
out art all day.

Same goes for the programmer. I'd want to hire a programmer that wants
to do more than just programming, even if his daily duties will still
involve a lot of that. The best programmers have more than one area of
expertise. Programming is just a tool to get something done. The guy who
has a good understanding of biology, or accounting, or whatever, will be
better at programming solutions to problems in those areas.

26

No I haven't. Eiffel and Dylan are two other languages I've noted floating in the zeitgeist as worth exploring. I'm mainly focusing on Ruby and Emacs Lisp at the moment. I tried Smalltalk via Squeak, but found Squeak very bizarre, so I moved onto lisp/scheme for amusement for now. Actually, Ruby blocks as an example of higher-order-functions led me through about six hours of reading ruby-python discussions, which led me to lisp comparisions, which lead to scheme, etc. Hyperlinks are evil :). That said, Ruby does seem to be a truly inspired melding all the different language capabilities.

Has Dylan ever been used for production software?

Nick

Tyler Zesiger wrote:

···

Have you checked out Dylan? It's a bit of an improvement over smalltalk supposedly. I've been looking it over, and I like it so far.

Nicholas Van Weerdenburg wrote:

Then I realized Java sucks, so I'm now learning ruby, python, lisp, smalltalk and scheme. Now I am just confused, and wonder how civilization ever happened :).

[snip]

Nick

Jean-Hugues ROBERT wrote:

... snipped...

At my company, we have two career tracks (called ladders):
Technical and Managerial.

You can be either an individual contributor, or a manager. :slight_smile:
Some tech people are team leads or may have direct reports,
but they are not considered managers -- I'm not sure
where the line is drawn.

As for myself, I can't bring myself to aspire to a manager
position yet. Maybe when I am older (like 80). There
are some multi talented people out there, but I wonder if
a good programmer can really aspire to a managerial postion.

To be a good programmer, you really have to love what you do.
How could someone aspire to move away from something they
really love?

--
Jim Freeze
No matter what other nations may say about the United States,
immigration is still the sincerest form of flattery.

I started a company in 1987. I believe that by 1993 we must
have been 15 people. I was a programmer. A version 2 of our
major product was starting. A year after I realized that there
was an issue. Informal communication was not working anymore.
Bug fixing was constantly delayed. Deadlines were missed.
I then realize that there was a need for somebody to organize
thing so that the product would survive. That is when I
became a manager I guess. A few years latter I was hired as
VP Engineerer of some startup. After the Internet bubble
explosion I worked fixing my old house. Now I am back to
programming. I have always loved that. But at some point I
really felt like there was a need for a manager, I loved
the result of programming (The Product) more than my
contributions to it and I kind of put aside my programming
pleasure to help the product succeed. That worked, very
well, I don't regret it at all.

Not mentioning the fact that as VP Engineerer, I was making
more money that will ever be possible for a programmer in
my country, France. I needed that money to fix my old house.

This story may give you some ideas about why somebody would
move away from something she/he really like.

Yours,

JeanHuguesRobert

-------------------------------------------------------------------------

Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17

27

In article <200406091038.40447.sean@celsoft.com>,

Sean O'Dell wrote:
>
> Ditto. When hiring an artist, should one be wary of people who want to
> be an artist forever? When hiring a gardener, should one be wary of
> people who want to garden forever? I don't see the logic in refusing to
> hire a person because they love their work and want to keep doing it the
> rest of their life.

When interviewing, I would probe for deeper ambitions. Someone who is,
or will be, a master artist will have ambitions beyond just doing their
own art all day. And if they don't, I'd try to see if the could be
coaxed into broadening their horizons.

For example, a master artist is the kind of guy I'd want involved in
arranging a movie set, or teaching, or *something* besides just churning
out art all day.

Same goes for the programmer. I'd want to hire a programmer that wants
to do more than just programming, even if his daily duties will still
involve a lot of that. The best programmers have more than one area of
expertise. Programming is just a tool to get something done. The guy who
has a good understanding of biology, or accounting, or whatever, will be
better at programming solutions to problems in those areas.

I don't agree that side-interests make for a better programmer. If you're
hiring a programmer, you want someone who's main interest is programming. My
experience has been that the more a person loves programming, the better they
are at it. If we're discussing hiring a programmer, to do programming work,
I want the best programmer I can get for my money, so side-interests are one
of the things I DON'T want in a potential employee.

Side interests (or perhaps I should call it multi-disciplinary
training) will certainly make for more employment opportunities going
forward. Most programming jobs can and will eventually be sent offshore
(and yes, this definately sucks but there doesn't seem to be much that
can be done before it's too late). However, people who can program well
AND know (biology|chemistry|geology|medicine|genetics|physics|chip
design,etc..) will continue to be in
demand. Its not that you're diminishing your programming skills by
studying another discipline, its more like you're applying your
programming skills to that discipline (and at the same time increasing
your programming skills). There are many more interesting problems out
there than just those found in IT (in fact many IT problems look quite
mundane when compared with those that need to be solved in other fields).

Phil

···

Sean O'Dell <sean@celsoft.com> wrote:

On Wednesday 09 June 2004 09:42, Tyler Zesiger wrote:

28

Ruby and Dylan kind of remind me of each other. They were both conceived at about the same time. Dylan is designed to be a "production" language, capable of replacing C/C++. I'm just barely getting into it, but I liked it better than Eiffel, and it seems to have a great future even though it's largely ignored so far. It consistently ranks well in the ICFP lanugages contest - Programming Languages @ Penn - But as far as I know, there's not much production code written using Dylan.

Apple had financial troubles and dropped the Dylan project. Bob Dylan won millions of dollars out of a lawsuit over the fact that Dylan was distributed on a CD with the word "Dylan" on the front. And Dylan seems to be only now catching up to where it should have been in the mid 1990's.

Anyways, Dylan, Ruby, and Scheme are the languages I've decided to be worthwhile, in that order (Besides C/C++ of course). They seem to be the best designed languages out there, without being too obscure or immature. All three of them are ready for production. Dylan doesn't have a lot of libraries available for it yet, but it can use C libraries, so it's not a huge issue. Ruby can work with C as well, through SWIG, so it's not a show stopper for Ruby either.

Dylan currently has two compilers available, and they both generate C code before using another compiler to produce an executable binary, so compilation times will be really slow until the last C compilation step is eliminated.

One of them is called Functional Developer, or just FunDev for short, and it's a Windows only ex-commercial product that depends on MSVC for it's final C compilation step. FunDev will probably be open-sourced soon. Gwydion Dylan is the open source compiler that's available, and it'll run on anything that's *nix, as well as windows with some extra work through Cygwin or MinGW. It depends on GCC for it's final C compilation step.

The #dylan channel on the freenode IRC network is quite active, but there's only about 15 to 20 people in it at any given time, with a spike in activity every time Dylan gets slasdotted. I first found out about Dylan through slashdot.

So, to sum up, I'm still digging deeper, but I suspect Dylan and Ruby will be what I will use most, with maybe some Scheme thrown in when it's convenient. Other languages that are interesting, but I doubt I will use are Eiffel, Ocaml, and Modula-3. I've decided to ignore those just because Dylan and Ruby cover the spectrum pretty well by themselves, for production code. Scheme is the "fun" language that I can twiddle with when I get around to it. Maybe I'll change my mind later, but that's my thinking so far.

Any other languages will probably have to be backwards compatible with C or C++, as Dylan and Ruby are, before I'll give them any heed, since I'm mostly interested in languages that are ready to work.

Nicholas Van Weerdenburg wrote:

···

No I haven't. Eiffel and Dylan are two other languages I've noted floating in the zeitgeist as worth exploring. I'm mainly focusing on Ruby and Emacs Lisp at the moment. I tried Smalltalk via Squeak, but found Squeak very bizarre, so I moved onto lisp/scheme for amusement for now. Actually, Ruby blocks as an example of higher-order-functions led me through about six hours of reading ruby-python discussions, which led me to lisp comparisions, which lead to scheme, etc. Hyperlinks are evil :). That said, Ruby does seem to be a truly inspired melding all the different language capabilities.

Has Dylan ever been used for production software?

Nick

Tyler Zesiger wrote:

Have you checked out Dylan? It's a bit of an improvement over smalltalk supposedly. I've been looking it over, and I like it so far.

Nicholas Van Weerdenburg wrote:

Then I realized Java sucks, so I'm now learning ruby, python, lisp, smalltalk and scheme. Now I am just confused, and wonder how civilization ever happened :).

[snip]

Nick

Jean-Hugues ROBERT wrote:

... snipped...

At my company, we have two career tracks (called ladders):
Technical and Managerial.

You can be either an individual contributor, or a manager. :slight_smile:
Some tech people are team leads or may have direct reports,
but they are not considered managers -- I'm not sure
where the line is drawn.

As for myself, I can't bring myself to aspire to a manager
position yet. Maybe when I am older (like 80). There
are some multi talented people out there, but I wonder if
a good programmer can really aspire to a managerial postion.

To be a good programmer, you really have to love what you do.
How could someone aspire to move away from something they
really love?

--
Jim Freeze
No matter what other nations may say about the United States,
immigration is still the sincerest form of flattery.

I started a company in 1987. I believe that by 1993 we must
have been 15 people. I was a programmer. A version 2 of our
major product was starting. A year after I realized that there
was an issue. Informal communication was not working anymore.
Bug fixing was constantly delayed. Deadlines were missed.
I then realize that there was a need for somebody to organize
thing so that the product would survive. That is when I
became a manager I guess. A few years latter I was hired as
VP Engineerer of some startup. After the Internet bubble
explosion I worked fixing my old house. Now I am back to
programming. I have always loved that. But at some point I
really felt like there was a need for a manager, I loved
the result of programming (The Product) more than my
contributions to it and I kind of put aside my programming
pleasure to help the product succeed. That worked, very
well, I don't regret it at all.

Not mentioning the fact that as VP Engineerer, I was making
more money that will ever be possible for a programmer in
my country, France. I needed that money to fix my old house.

This story may give you some ideas about why somebody would
move away from something she/he really like.

Yours,

JeanHuguesRobert

-------------------------------------------------------------------------

Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17

29

As an employee, side-interests are good. As an employer, side-interests are a
potential distraction from the job-at-hand.

  Sean O'Dell

···

On Wednesday 09 June 2004 13:08, Phil Tomson wrote:

In article <200406091038.40447.sean@celsoft.com>,

Sean O'Dell <sean@celsoft.com> wrote:
>
>I don't agree that side-interests make for a better programmer. If you're
>hiring a programmer, you want someone who's main interest is programming.
> My experience has been that the more a person loves programming, the
> better they are at it. If we're discussing hiring a programmer, to do
> programming work, I want the best programmer I can get for my money, so
> side-interests are one of the things I DON'T want in a potential
> employee.

Side interests (or perhaps I should call it multi-disciplinary
training) will certainly make for more employment opportunities going
forward. Most programming jobs can and will eventually be sent offshore
(and yes, this definately sucks but there doesn't seem to be much that
can be done before it's too late). However, people who can program well
AND know (biology|chemistry|geology|medicine|genetics|physics|chip
design,etc..) will continue to be in
demand. Its not that you're diminishing your programming skills by
studying another discipline, its more like you're applying your
programming skills to that discipline (and at the same time increasing
your programming skills). There are many more interesting problems out
there than just those found in IT (in fact many IT problems look quite
mundane when compared with those that need to be solved in other fields).

30

In article <40C898AF.8000706@zesiger.com>,

Ruby and Dylan kind of remind me of each other. They were both conceived
at about the same time. Dylan is designed to be a "production" language,
capable of replacing C/C++. I'm just barely getting into it, but I liked
it better than Eiffel, and it seems to have a great future even though
it's largely ignored so far. It consistently ranks well in the ICFP
lanugages contest - Programming Languages @ Penn - But
as far as I know, there's not much production code written using Dylan.

Apple had financial troubles and dropped the Dylan project. Bob Dylan
won millions of dollars out of a lawsuit over the fact that Dylan was
distributed on a CD with the word "Dylan" on the front. And Dylan seems
to be only now catching up to where it should have been in the mid 1990's.

Now days Apple uses Objective C quite a lot. They don't seem to be doing
anything with Dylan anymore.

Anyways, Dylan, Ruby, and Scheme are the languages I've decided to be
worthwhile, in that order (Besides C/C++ of course). They seem to be the
best designed languages out there, without being too obscure or
immature. All three of them are ready for production. Dylan doesn't have
a lot of libraries available for it yet, but it can use C libraries, so
it's not a huge issue. Ruby can work with C as well, through SWIG, so
it's not a show stopper for Ruby either.

Dylan currently has two compilers available, and they both generate C
code before using another compiler to produce an executable binary, so
compilation times will be really slow until the last C compilation step
is eliminated.

One of them is called Functional Developer, or just FunDev for short,
and it's a Windows only ex-commercial product that depends on MSVC for
it's final C compilation step. FunDev will probably be open-sourced
soon. Gwydion Dylan is the open source compiler that's available, and
it'll run on anything that's *nix, as well as windows with some extra
work through Cygwin or MinGW. It depends on GCC for it's final C
compilation step.

The #dylan channel on the freenode IRC network is quite active, but
there's only about 15 to 20 people in it at any given time, with a spike
in activity every time Dylan gets slasdotted. I first found out about
Dylan through slashdot.

So, to sum up, I'm still digging deeper, but I suspect Dylan and Ruby
will be what I will use most, with maybe some Scheme thrown in when it's
convenient. Other languages that are interesting, but I doubt I will use
are Eiffel, Ocaml, and Modula-3. I've decided to ignore those just
because Dylan and Ruby cover the spectrum pretty well by themselves, for
production code. Scheme is the "fun" language that I can twiddle with
when I get around to it. Maybe I'll change my mind later, but that's my
thinking so far.

Any other languages will probably have to be backwards compatible with C
or C++, as Dylan and Ruby are, before I'll give them any heed, since I'm
mostly interested in languages that are ready to work.

You should probably check out Objective C - it's used in actual production
code (See the Cocoa framework from Apple). ObjC can be used as a more
dynamically typed language or as a statically typed language or both so
it's rather flexible in that way. It's C with some added OO
functionality (I tend to like the ObjC OO philosophy better than
C++'s, though I've only played with ObjC a little) and recently added
exceptions. I'm not sure that anyone is
using Dylan for 'work' anymore, so I'm not sure if it's 'ready to work'.

Phil

···

Tyler Zesiger <mailing-lists@zesiger.com> wrote:

31

Thanks for the indepth reply.

Ocaml also seems to have an interesting buzz, and does well on programming contests. It looked sortof weird to me. The other language I hear of a lot is Haskell. Modula-3 I have know very little about, and see little mention of.

So, for now it's Ruby, Emacs Lisp, Scheme, Python for me, in that order. I'll defintely spend a few hours checking out Dylan and seeing if it bumps the mix. I agree with you Scheme assessment- I have no real reason to learn it, but it's just cool, different, and fun.

Nick

Tyler Zesiger wrote:

···

Ruby and Dylan kind of remind me of each other. They were both conceived at about the same time. Dylan is designed to be a "production" language, capable of replacing C/C++. I'm just barely getting into it, but I liked it better than Eiffel, and it seems to have a great future even though it's largely ignored so far. It consistently ranks well in the ICFP lanugages contest - Programming Languages @ Penn - But as far as I know, there's not much production code written using Dylan.

Apple had financial troubles and dropped the Dylan project. Bob Dylan won millions of dollars out of a lawsuit over the fact that Dylan was distributed on a CD with the word "Dylan" on the front. And Dylan seems to be only now catching up to where it should have been in the mid 1990's.

Anyways, Dylan, Ruby, and Scheme are the languages I've decided to be worthwhile, in that order (Besides C/C++ of course). They seem to be the best designed languages out there, without being too obscure or immature. All three of them are ready for production. Dylan doesn't have a lot of libraries available for it yet, but it can use C libraries, so it's not a huge issue. Ruby can work with C as well, through SWIG, so it's not a show stopper for Ruby either.

Dylan currently has two compilers available, and they both generate C code before using another compiler to produce an executable binary, so compilation times will be really slow until the last C compilation step is eliminated.

One of them is called Functional Developer, or just FunDev for short, and it's a Windows only ex-commercial product that depends on MSVC for it's final C compilation step. FunDev will probably be open-sourced soon. Gwydion Dylan is the open source compiler that's available, and it'll run on anything that's *nix, as well as windows with some extra work through Cygwin or MinGW. It depends on GCC for it's final C compilation step.

The #dylan channel on the freenode IRC network is quite active, but there's only about 15 to 20 people in it at any given time, with a spike in activity every time Dylan gets slasdotted. I first found out about Dylan through slashdot.

So, to sum up, I'm still digging deeper, but I suspect Dylan and Ruby will be what I will use most, with maybe some Scheme thrown in when it's convenient. Other languages that are interesting, but I doubt I will use are Eiffel, Ocaml, and Modula-3. I've decided to ignore those just because Dylan and Ruby cover the spectrum pretty well by themselves, for production code. Scheme is the "fun" language that I can twiddle with when I get around to it. Maybe I'll change my mind later, but that's my thinking so far.

Any other languages will probably have to be backwards compatible with C or C++, as Dylan and Ruby are, before I'll give them any heed, since I'm mostly interested in languages that are ready to work.

Nicholas Van Weerdenburg wrote:

No I haven't. Eiffel and Dylan are two other languages I've noted floating in the zeitgeist as worth exploring. I'm mainly focusing on Ruby and Emacs Lisp at the moment. I tried Smalltalk via Squeak, but found Squeak very bizarre, so I moved onto lisp/scheme for amusement for now. Actually, Ruby blocks as an example of higher-order-functions led me through about six hours of reading ruby-python discussions, which led me to lisp comparisions, which lead to scheme, etc. Hyperlinks are evil :). That said, Ruby does seem to be a truly inspired melding all the different language capabilities.

Has Dylan ever been used for production software?

Nick

...( rest of replieds removed)

32

In article <200406091338.52797.sean@celsoft.com>,

···

Sean O'Dell <sean@celsoft.com> wrote:

On Wednesday 09 June 2004 13:08, Phil Tomson wrote:

As an employee, side-interests are good. As an employer, side-interests are a
potential distraction from the job-at-hand.

I guess it just depends on who the employer is. If the employer is a
biotech company they'll be quite happy to find a good programmer that has
a 'side interest' in genetics, for example. They would probably favor
someone like that over another candidate who is a great programmer, but
has no knowledge or interest in genetics.

Phil

33

I like Donald Knuth's focus. He doesn't do email because to takes too much time away from the "The Art of Computer Programming". See http://www-cs-faculty.stanford.edu/~knuth/email.html for a discussion.

Edsger Dijkstra, in an interview, stated he didn't use a computer ( http://www.geekchic.com/repliq5.htm ). Now that is removing the ultimate distraction for a computer scientist!

Both Dijkstra and Knuth are into playing music as a main hobby (there have been some recent music-programming threads of late).

The Wikipedia article on Knuth offer's a solution to recent discussions of version numbering:
"Version numbers of his TeX software approach pi, that is versions increment in the style 3, 3.1, 3.14 and so on, version numbers of Metafont approach e similarly"

Sean O'Dell wrote:

···

On Wednesday 09 June 2004 13:08, Phil Tomson wrote:

In article <200406091038.40447.sean@celsoft.com>,

Sean O'Dell <sean@celsoft.com> wrote:
   

I don't agree that side-interests make for a better programmer. If you're
hiring a programmer, you want someone who's main interest is programming. My experience has been that the more a person loves programming, the
better they are at it. If we're discussing hiring a programmer, to do
programming work, I want the best programmer I can get for my money, so
side-interests are one of the things I DON'T want in a potential
employee.
     

Side interests (or perhaps I should call it multi-disciplinary
training) will certainly make for more employment opportunities going
forward. Most programming jobs can and will eventually be sent offshore
(and yes, this definately sucks but there doesn't seem to be much that
can be done before it's too late). However, people who can program well
AND know (biology|chemistry|geology|medicine|genetics|physics|chip
design,etc..) will continue to be in
demand. Its not that you're diminishing your programming skills by
studying another discipline, its more like you're applying your
programming skills to that discipline (and at the same time increasing
your programming skills). There are many more interesting problems out
there than just those found in IT (in fact many IT problems look quite
mundane when compared with those that need to be solved in other fields).
   
As an employee, side-interests are good. As an employer, side-interests are a potential distraction from the job-at-hand.

Sean O'Dell

34

Phil Tomson wrote:

In article <40C898AF.8000706@zesiger.com>,

Ruby and Dylan kind of remind me of each other. They were both conceived at about the same time. Dylan is designed to be a "production" language, capable of replacing C/C++. I'm just barely getting into it, but I liked it better than Eiffel, and it seems to have a great future even though it's largely ignored so far. It consistently ranks well in the ICFP lanugages contest - Programming Languages @ Penn - But as far as I know, there's not much production code written using Dylan.

Apple had financial troubles and dropped the Dylan project. Bob Dylan won millions of dollars out of a lawsuit over the fact that Dylan was distributed on a CD with the word "Dylan" on the front. And Dylan seems to be only now catching up to where it should have been in the mid 1990's.

Now days Apple uses Objective C quite a lot. They don't seem to be doing anything with Dylan anymore.

[snip]

You should probably check out Objective C - it's used in actual production code (See the Cocoa framework from Apple). ObjC can be used as a more dynamically typed language or as a statically typed language or both so it's rather flexible in that way. It's C with some added OO functionality (I tend to like the ObjC OO philosophy better than C++'s, though I've only played with ObjC a little) and recently added exceptions. I'm not sure that anyone is using Dylan for 'work' anymore, so I'm not sure if it's 'ready to work'.

Phil

I think Dylan's close enough to being ready to work, for me. I'm not concerned that it isn't as well supported because my timeline is a bit farther out, and I think it's doing well. I'm more concerned about the joy of programming than meeting deadlines, at least at this stage. So, the newer, better designed languages appeal to me more. The libraries, commercial products, and community support will follow I'm sure, though being a decade old language, I don't think I can call myself an early adopter for Dylan.

As an aside, I'm fairly new to programming, and it might be beneficial to have to learn to roll my own libraries for Dylan, rather than just plugging something else in that was written and debugged 10 years ago. I'll be able to contribute something simple but significant, without being overshadowed by those that came before me.

···

Tyler Zesiger <mailing-lists@zesiger.com> wrote:

35

Oh yeah, I forgot to mention Haskell. I liked what I read about it, but after reading the objectives on Haskell, it seems a bit too "head in the clouds" for me. I may revisit it later, along with the other languages I mentioned. Ocaml does have quite a buzz around it, I've noticed that too.

Just curious - If you're doing Ruby, why bother with Python? And if you're doing Scheme, why bother with Lisp?

Nicholas Van Weerdenburg wrote:

···

Thanks for the indepth reply.

Ocaml also seems to have an interesting buzz, and does well on programming contests. It looked sortof weird to me. The other language I hear of a lot is Haskell. Modula-3 I have know very little about, and see little mention of.

So, for now it's Ruby, Emacs Lisp, Scheme, Python for me, in that order. I'll defintely spend a few hours checking out Dylan and seeing if it bumps the mix. I agree with you Scheme assessment- I have no real reason to learn it, but it's just cool, different, and fun.

Nick

Tyler Zesiger wrote:

Ruby and Dylan kind of remind me of each other. They were both conceived at about the same time. Dylan is designed to be a "production" language, capable of replacing C/C++. I'm just barely getting into it, but I liked it better than Eiffel, and it seems to have a great future even though it's largely ignored so far. It consistently ranks well in the ICFP lanugages contest - Programming Languages @ Penn - But as far as I know, there's not much production code written using Dylan.

Apple had financial troubles and dropped the Dylan project. Bob Dylan won millions of dollars out of a lawsuit over the fact that Dylan was distributed on a CD with the word "Dylan" on the front. And Dylan seems to be only now catching up to where it should have been in the mid 1990's.

Anyways, Dylan, Ruby, and Scheme are the languages I've decided to be worthwhile, in that order (Besides C/C++ of course). They seem to be the best designed languages out there, without being too obscure or immature. All three of them are ready for production. Dylan doesn't have a lot of libraries available for it yet, but it can use C libraries, so it's not a huge issue. Ruby can work with C as well, through SWIG, so it's not a show stopper for Ruby either.

Dylan currently has two compilers available, and they both generate C code before using another compiler to produce an executable binary, so compilation times will be really slow until the last C compilation step is eliminated.

One of them is called Functional Developer, or just FunDev for short, and it's a Windows only ex-commercial product that depends on MSVC for it's final C compilation step. FunDev will probably be open-sourced soon. Gwydion Dylan is the open source compiler that's available, and it'll run on anything that's *nix, as well as windows with some extra work through Cygwin or MinGW. It depends on GCC for it's final C compilation step.

The #dylan channel on the freenode IRC network is quite active, but there's only about 15 to 20 people in it at any given time, with a spike in activity every time Dylan gets slasdotted. I first found out about Dylan through slashdot.

So, to sum up, I'm still digging deeper, but I suspect Dylan and Ruby will be what I will use most, with maybe some Scheme thrown in when it's convenient. Other languages that are interesting, but I doubt I will use are Eiffel, Ocaml, and Modula-3. I've decided to ignore those just because Dylan and Ruby cover the spectrum pretty well by themselves, for production code. Scheme is the "fun" language that I can twiddle with when I get around to it. Maybe I'll change my mind later, but that's my thinking so far.

Any other languages will probably have to be backwards compatible with C or C++, as Dylan and Ruby are, before I'll give them any heed, since I'm mostly interested in languages that are ready to work.

Nicholas Van Weerdenburg wrote:

No I haven't. Eiffel and Dylan are two other languages I've noted floating in the zeitgeist as worth exploring. I'm mainly focusing on Ruby and Emacs Lisp at the moment. I tried Smalltalk via Squeak, but found Squeak very bizarre, so I moved onto lisp/scheme for amusement for now. Actually, Ruby blocks as an example of higher-order-functions led me through about six hours of reading ruby-python discussions, which led me to lisp comparisions, which lead to scheme, etc. Hyperlinks are evil :). That said, Ruby does seem to be a truly inspired melding all the different language capabilities.

Has Dylan ever been used for production software?

Nick

...( rest of replieds removed)

36

Emacs Lisp makes Lisp interesting whereas Scheme is interesting for general use. Or at least that is my current impression. I'm still amused that GNUs version of Scheme is named "Guile". That's just brilliant.

Python seems worth learning because of it's current industry footprint. Also, I figured it would be interesting to see what all the Ruby-Python comparison was first hand. That said, I like that Ruby is more expression oriented, and I'm rather addicted to blocks.

Blocks have made me feel that I may have missed something important that is offered by functional programming languages (my entire career has been essentially OO). A Ruby-Python comparison that lead to a few articles on Lisp and higher-order functions made me think that learning Lisp/Scheme would significantly enhance my journey to programming enlightenment, largely because of their strengths in this area.

Nick

Tyler Zesiger wrote:

···

Oh yeah, I forgot to mention Haskell. I liked what I read about it, but after reading the objectives on Haskell, it seems a bit too "head in the clouds" for me. I may revisit it later, along with the other languages I mentioned. Ocaml does have quite a buzz around it, I've noticed that too.

Just curious - If you're doing Ruby, why bother with Python? And if you're doing Scheme, why bother with Lisp?

Nicholas Van Weerdenburg wrote:

Thanks for the indepth reply.

Ocaml also seems to have an interesting buzz, and does well on programming contests. It looked sortof weird to me. The other language I hear of a lot is Haskell. Modula-3 I have know very little about, and see little mention of.

So, for now it's Ruby, Emacs Lisp, Scheme, Python for me, in that order. I'll defintely spend a few hours checking out Dylan and seeing if it bumps the mix. I agree with you Scheme assessment- I have no real reason to learn it, but it's just cool, different, and fun.

Nick

Tyler Zesiger wrote:

Ruby and Dylan kind of remind me of each other. They were both conceived at about the same time. Dylan is designed to be a "production" language, capable of replacing C/C++. I'm just barely getting into it, but I liked it better than Eiffel, and it seems to have a great future even though it's largely ignored so far. It consistently ranks well in the ICFP lanugages contest - Programming Languages @ Penn - But as far as I know, there's not much production code written using Dylan.

Apple had financial troubles and dropped the Dylan project. Bob Dylan won millions of dollars out of a lawsuit over the fact that Dylan was distributed on a CD with the word "Dylan" on the front. And Dylan seems to be only now catching up to where it should have been in the mid 1990's.

Anyways, Dylan, Ruby, and Scheme are the languages I've decided to be worthwhile, in that order (Besides C/C++ of course). They seem to be the best designed languages out there, without being too obscure or immature. All three of them are ready for production. Dylan doesn't have a lot of libraries available for it yet, but it can use C libraries, so it's not a huge issue. Ruby can work with C as well, through SWIG, so it's not a show stopper for Ruby either.

Dylan currently has two compilers available, and they both generate C code before using another compiler to produce an executable binary, so compilation times will be really slow until the last C compilation step is eliminated.

One of them is called Functional Developer, or just FunDev for short, and it's a Windows only ex-commercial product that depends on MSVC for it's final C compilation step. FunDev will probably be open-sourced soon. Gwydion Dylan is the open source compiler that's available, and it'll run on anything that's *nix, as well as windows with some extra work through Cygwin or MinGW. It depends on GCC for it's final C compilation step.

The #dylan channel on the freenode IRC network is quite active, but there's only about 15 to 20 people in it at any given time, with a spike in activity every time Dylan gets slasdotted. I first found out about Dylan through slashdot.

So, to sum up, I'm still digging deeper, but I suspect Dylan and Ruby will be what I will use most, with maybe some Scheme thrown in when it's convenient. Other languages that are interesting, but I doubt I will use are Eiffel, Ocaml, and Modula-3. I've decided to ignore those just because Dylan and Ruby cover the spectrum pretty well by themselves, for production code. Scheme is the "fun" language that I can twiddle with when I get around to it. Maybe I'll change my mind later, but that's my thinking so far.

Any other languages will probably have to be backwards compatible with C or C++, as Dylan and Ruby are, before I'll give them any heed, since I'm mostly interested in languages that are ready to work.

Nicholas Van Weerdenburg wrote:

No I haven't. Eiffel and Dylan are two other languages I've noted floating in the zeitgeist as worth exploring. I'm mainly focusing on Ruby and Emacs Lisp at the moment. I tried Smalltalk via Squeak, but found Squeak very bizarre, so I moved onto lisp/scheme for amusement for now. Actually, Ruby blocks as an example of higher-order-functions led me through about six hours of reading ruby-python discussions, which led me to lisp comparisions, which lead to scheme, etc. Hyperlinks are evil :). That said, Ruby does seem to be a truly inspired melding all the different language capabilities.

Has Dylan ever been used for production software?

Nick

...( rest of replieds removed)

37

And while you're planning your trip, let me remind you to not skip the
Forth corner. It will probably rough going first, when you're coming
from heavyweight environments like Lisp etc., but there is precious
knowledge to be found over there.

s.

···

On Sun, 13 Jun 2004 14:23:33 +0900, Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:

Blocks have made me feel that I may have missed something important that
is offered by functional programming languages (my entire career has
been essentially OO). A Ruby-Python comparison that lead to a few
articles on Lisp and higher-order functions made me think that learning
Lisp/Scheme would significantly enhance my journey to programming
enlightenment, largely because of their strengths in this area.

38

Hello Stefan,

Blocks have made me feel that I may have missed something important that
is offered by functional programming languages (my entire career has
been essentially OO). A Ruby-Python comparison that lead to a few
articles on Lisp and higher-order functions made me think that learning
Lisp/Scheme would significantly enhance my journey to programming
enlightenment, largely because of their strengths in this area.

And while you're planning your trip, let me remind you to not skip the
Forth corner. It will probably rough going first, when you're coming
from heavyweight environments like Lisp etc., but there is precious
knowledge to be found over there.

Right i whish that everyone who writtes a bytecode compiler first look
at forth and collect arguments why he/she does not use the directly threaded
interpreter model of forth, even if it makes it necessary to do some
assembly code. Writting the core of a virtual machine in something
like C just don't look very ambitious. The penalty you get over forth
is at least 100%.

In the good old year 1996 if written an emacs compatible lisp
interpreter with the forth technologie and it was about 10 times
faster then emacs lisp.

···

On Sun, 13 Jun 2004 14:23:33 +0900, > Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

39

interesting, thanks, but before I dive in some forth internals, there
is a quick overview somewhere?

It's worth noticing that we had an effort to write a ruby VM based on
vmgen[1] that, If I understand correctly is the tool by witch Gforth
is built.

And I am quite sure that there was a presentation from matz in which
he talked about some forth vm as a model for rite. But It seem I can't
find it anywhere, so feel free to think I'm mad.

[1]
http://www.nongnu.org/carbone/

···

il Mon, 14 Jun 2004 03:16:46 +0900, Lothar Scholz <mailinglists@scriptolutions.com> ha scritto::

Right i whish that everyone who writtes a bytecode compiler first look
at forth and collect arguments why he/she does not use the directly threaded
interpreter model of forth, even if it makes it necessary to do some
assembly code. Writting the core of a virtual machine in something
like C just don't look very ambitious. The penalty you get over forth
is at least 100%.

In the good old year 1996 if written an emacs compatible lisp
interpreter with the forth technologie and it was about 10 times
faster then emacs lisp.