Dylan's future 
Author Message
 Dylan's future

As an amateur programmer I'm interested in Dylan. I would like to get to
know the language, but it seems Apple dropped its support for Dylan.

Can anyone tell me some about the future of Dylan.
(I.o.w: is it worth it learning the language because it will be
supported in the future)



Wed, 17 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:

> As an amateur programmer I'm interested in Dylan. I would like to get to
> know the language, but it seems Apple dropped its support for Dylan.

> Can anyone tell me some about the future of Dylan.
> (I.o.w: is it worth it learning the language because it will be
> supported in the future)

I don't know, but any language for which three teams begin work, one quits,
and the others still take this long to produce a working system for it,
perhaps isn't such an elegant language after all. My hopes for Dylan
have faded severely. For a language to succeed it must be at least possible
to produce a version which delivers on the promises. In fact it should
be easy enough that many vendors can produce a product. Java in spite
of its short sighted design is a language for which any not so talented BSCS
could write a simple implementation. I'm not trying to start flames, but
it just seems to me that Dylan has proven too hard to implement to be
successful. If C++ started out to be as hard to implement as it is now
it would probably never be where it is now either.


If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collid...



Wed, 17 Mar 1999 03:00:00 GMT  
 Dylan's future


   > As an amateur programmer I'm interested in Dylan. I would like to get to
   > know the language, but it seems Apple dropped its support for Dylan.
   >
   > Can anyone tell me some about the future of Dylan.
   > (I.o.w: is it worth it learning the language because it will be
   > supported in the future)

   I don't know, but any language for which three teams begin work, one quits,
   and the others still take this long to produce a working system for it,
   perhaps isn't such an elegant language after all.

I think it is wrong to attempt to connect "elegance" with the amount of time
it takes to produce a "working" system. For example, Mindy and Marlais are
working, if incomplete, implementations of a workable subset of Dylan, which
have been available for a while. Producing a full featured Dylan and an
accompanying programming environment is bound to take a long time. I imagine
most people want an optimizing compiler which produces executables which
are comparable to C/fortran/... That takes time. In any case, I think the
language is elegant, though I don't know why they abandoned the prefix
syntax.

In any case, the original poster was concerned with support, since Apple
dropped support for Dylan. IMO, if you are using Apple stuff, you are sort
of marginalized in the computer world anyways, so using a less popular
language shouldn't worry you. Besides, plenty of unsupported languages are
used, like Perl, Scheme, Python, etc. One decent, freely available (as in
free source) Dylan compiler would mean that you never worry about being
"orphaned". Just look at how much GNAT has done for the Ada community!
That is a kick-ass compiler, and it has allowed lots of people who wouldn't
have looked at Ada to give it a try.

   My hopes for Dylan have faded severely.

Mine too. I wish that one of the research teams had decided to just get
a decent compiler out first, and worried about the programming environment
later. That way users would have had a chance to experiment and maybe use
it for projects. I am happy that Marlais and Mindy are around, I just don't
find them usable for anything but learning basic Dylan.

   For a language to succeed it must be at least possible to produce a
   version which delivers on the promises. In fact it should be easy enough
   that many vendors can produce a product.

I don't know what you mean by "succeed". Is Perl successful? Tcl? Can
languages with no vendor be successful? Is Common Lisp successful? Eiffel?
Smalltalk?

   Java in spite of its short sighted design is a language for which any not
   so talented BSCS could write a simple implementation. I'm not trying to
   start flames, but it just seems to me that Dylan has proven too hard to
   implement to be successful.

I completely disagree with this. There has been no proof of implementation
difficulty. There are (incomplete) systems available. What I think is the
the problem is that there are no complete compilers out there, and we have
no idea when/if one will be released. It appears that all of the implementors
want to wait until they have full blown interactive environments working
before they release anything. I think it would be better to release a
command line compiler, even with some bugs, as long as performance of the
executable code generated is OK, for some reasonable definition of "OK".

For now however, I am using Java, Ada 95, and C. I'd like to use Dylan, but
the available interpreters are really for learning.

   If C++ started out to be as hard to implement as it is now it would
   probably never be where it is now either.

True, but as I said I disagree with your thesis about the unimplementability
of Dylan. I don't think following the path of C++ development will lead to
an elegant language.

-- Brian



Wed, 17 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:



...

>    For a language to succeed it must be at least possible to produce a
>    version which delivers on the promises. In fact it should be easy enough
>    that many vendors can produce a product.
>    Java in spite of its short sighted design is a language for which any not
>    so talented BSCS could write a simple implementation. I'm not trying to
>    start flames, but it just seems to me that Dylan has proven too hard to
>    implement to be successful.

> I completely disagree with this. There has been no proof of implementation
> difficulty. There are (incomplete) systems available. What I think is the
> the problem is that there are no complete compilers out there, and we have
> no idea when/if one will be released. It appears that all of the implementors
> want to wait until they have full blown interactive environments working
> before they release anything. I think it would be better to release a
> command line compiler, even with some bugs, as long as performance of the
> executable code generated is OK, for some reasonable definition of "OK".

It strikes me that Richard Gabriel's paper "Lisp: Good News, Bad News, How to Win Big"  
(available on line at: http://www.ai.mit.edu/articles/good-news/good-news.html) is directly
relevent to this discussion.  It deals directly with some of the reasons for why C tends to
beat out Lisp.  

I share much of the frustration in trying to get Lisp/Dylan to be more useful in industry.
But, having used/supported development in Harlequin's LispWorks on Unix (tm) for a while, I
must say I was both delighted with the environment and shocked at what was required to support
it.  We were using Sparcstation 5s with 96MB of memory, of necessity.  Certainly, the system
will run in less than that, but we were building a real product and needed debugging info,
etc.  If I were going to work exclusively in lisp, it would be a wonderful.  Realistically,
however, I also work with C/C++/Awk/Ksh/gnuemacs etc, and they are also quite useful.  I think
I know why Lisp environments tend to be monolithic, but the fact remains that 32MB was plenty
of RAM for people who didn't use Lisp.  People who buy the equipment and software see Lisp as
much more expensive than the rest of those tools.  I don't know about Harlequin's Dylan
environment, but I suspect it is similarly monolithic.  That will work against it.

I'm not willing to give up ksh/C/Awk/gnuemacs (note that I didn't include C++ in that list),
because I've got 20 years experience with those and similar tools, but I'd sure like to have
Lisp/Dylan on my desktop.  That means it can't require special/extra hardware, in general.

joe



Wed, 17 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:

> I'm not trying to start flames, but
> it just seems to me that Dylan has proven too hard to implement to be
> successful.

What's difficult to implement about Dylan? The detailed description
of the macro facility in the draft of the reference manual is a bit
confusing in my view (supposedly that's better in the final version;
I've ordered it, but it isn't there yet), but beyond that, I don't
know anything in Dylan which would be particularly difficult for an
implementor. (If I'll find the time, I might even implement a simple
Dylan to C compiler myself - but don't hold your breath ;-)




Thu, 18 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:


>> I'm not trying to start flames, but
>> it just seems to me that Dylan has proven too hard to implement to be
>> successful.
>What's difficult to implement about Dylan? The detailed description
>of the macro facility in the draft of the reference manual is a bit
>confusing in my view (supposedly that's better in the final version;
>I've ordered it, but it isn't there yet), but beyond that, I don't
>know anything in Dylan which would be particularly difficult for an
>implementor. (If I'll find the time, I might even implement a simple
>Dylan to C compiler myself - but don't hold your breath ;-)

I didn't implement a Dylan system, but I think some points for the
delay are quite obvious:

While Dylan's sealed classes are a way to combine static binding and
dynamic languages, it will for sure be hard to implement in a
compiler. I once looked into Objective-C to try to enable static
binding for Objects of fixed classes. I didn't get very far, the
problem requires handling heavy interactitions between the front-end
of the compiler and whatever will produce code. I assume in Dylan
you'll face even more complexity to track down a method call to the
class definition.

I assume neither CMU nor Harlequin will release a compiler without
support for sealed classes. A system with bad performance, but
supposed to be release-quality withh destroy any hope for Dylan within
a few months. Apples TR was OK, marked as what is was.

The second reason for the delay is probably that both groups try to
build a compiler and a good developement system at once. While I think
it wouldn't hurt Dylan to have a compiler without an environment in
the market, a later implementation of the environment may require
changes to the compiler with incompatiblities for the user.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

"As far as I'm concerned,  if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:
>While Dylan's sealed classes are a way to combine static binding and
>dynamic languages, it will for sure be hard to implement in a
>compiler. I once looked into Objective-C to try to enable static
>binding for Objects of fixed classes. I didn't get very far, the
>problem requires handling heavy interactitions between the front-end
>of the compiler and whatever will produce code. I assume in Dylan
>you'll face even more complexity to track down a method call to the
>class definition.

I think the problem of implementing sealing in a language like
Objective-C is tied to file-based nature of the compilation process. The
compiler only has knowledge of the world outlined in the current
translation unit, leading to ugly hacks like C++ name mangling to deal
with cross-translation unit type safety. Dylan implementations which
share this model (such as Mindy or Marlais) certainly face the problems
you ran into with Objective-C.

However...

Quote:
>The second reason for the delay is probably that both groups try to
>build a compiler and a good developement system at once. While I think
>it wouldn't hurt Dylan to have a compiler without an environment in
>the market, a later implementation of the environment may require
>changes to the compiler with incompatiblities for the user.

...the development system provides the compiler with a wealth of
information about the program being built, allowing it to generate
(hopefully) better code. I think it is important for the compiler to take
advantage of the information kept by the environment, and vice versa.
Apple Dylan does this, and I presume DylanWorks does too.

    -tre

--
Tom Emerson                                                 Cambridge R&D
Senior Software Engineer                             Apple Computer, Inc.



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:


>> I'm not trying to start flames, but
>> it just seems to me that Dylan has proven too hard to implement to be
>> successful.
>What's difficult to implement about Dylan? The detailed description
>of the macro facility in the draft of the reference manual is a bit
>confusing in my view (supposedly that's better in the final version;
>I've ordered it, but it isn't there yet), but beyond that, I don't
>know anything in Dylan which would be particularly difficult for an
>implementor. (If I'll find the time, I might even implement a simple
>Dylan to C compiler myself - but don't hold your breath ;-)

I didn't implement a Dylan system, but I think some points for the
delay are quite obvious:

While Dylan's sealed classes are a way to combine static binding and
dynamic languages, it will for sure be hard to implement in a
compiler. I once looked into Objective-C to try to enable static
binding for Objects of fixed classes. I didn't get very far, the
problem requires handling heavy interactitions between the front-end
of the compiler and whatever will produce code. I assume in Dylan
you'll face even more complexity to track down a method call to the
class definition.

I assume neither CMU nor Harlequin will release a compiler without
support for sealed classes. A system with bad performance, but
supposed to be release-quality withh destroy any hope for Dylan within
a few months. Apples TR was OK, marked as what is was.

The second reason for the delay is probably that both groups try to
build a compiler and a good developement system at once. While I think
it wouldn't hurt Dylan to have a compiler without an environment in
the market, a later implementation of the environment may require
changes to the compiler with incompatiblities for the user.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

"As far as I'm concerned,  if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future


Quote:

> I don't know, but any language for which three teams begin work, one quits,
> and the others still take this long to produce a working system for it,
> perhaps isn't such an elegant language after all. My hopes for Dylan
> have faded severely.

Ditto here, but I think there are some other factors which led to
problems in Apple's implementation:

- Optimistic projections about memory pricing and CPU speed

If memory prices had come down the way hard disk prices did, the 20-meg
requirement for the TR wouldn't have been so onerous. A friend of mine
just purchased 128 MB for his PowerMac for under $1,000. Unfortunately
for the shipability of Apple's implementation, it didn't until late this
year, and it was too late.

- Wrong choice for a development environment

The Dylan team mostly consisted of Lisp hackers, and it made sense that
they would want to build Apple Dylan in Macintosh Common Lisp. But
there wasn't a native CL in time, and despite their best efforts at
optimization, Apple Dylan on 68K was agonizingly slow. The version
built on the native CL is much faster, using the "throw a faster CPU at
it" approach to optimization, but it still isn't very zippy as these
things go.

- Feature and Design Thrash

I don't know much of the history of Dylan within Apple, but I'm sure
it would make Steven King's unabridged The Stand look like a Reader's
Digest Condensed Book. There were the days in which Dylan was going
to be the language for Newton. And then it wasn't. It was going to
be prefix, with Lisp syntax. And then it wasn't. There must be more
here. It didn't enjoy an incremental growth and design like C++.

- An Awful Lot to get right for the first release

In addition to trying to get a reasonable core language defined, the
Apple Dylan team had to ship:

   - a class library for writing Mac applications

   - Creole

   - a really cool new browser

   - a PowerPlant Builder-like UI toolkit

That's an awful lot to get working in a first release. If they had
targeted, for example, the core language with the cool browser and
search engines and standard i/o for 1.0, that would have given people
a chance to play with the core language. Unfortunately for various
reasons it was probably impossible, at least politically, to ship a
product lacking in tools that competing products already had.

Another approach would be to do like Sun did and create a bare-bones,
but source-code licensable, "reference" implementation. If Apple had
done this and released a generic "reference" Dylan, say, written in
ANSI C without GUI support, other companies could have put in the
investment of, and risk of, building the full-featured tools. (For
a good example, consider Sun's Java SDK and Roaster, Cafe, etc.)

- A Moving Target

The emergence of OpenDoc didn't make things easier, because by the time
the product shipped, developers wanted more out of their tools.

I wasn't privy to the internal machinations that ultimately killed
the Dylan project within Apple, but I'd be interested in hearing
from any ex-Cambridge lab members on what _they_ thought went wrong
and why.

-Paul-

Paul R. Potts - Project Engineering Lead - Health Media Research Lab



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future


Quote:


...

>While Dylan's sealed classes are a way to combine static binding and
>dynamic languages, it will for sure be hard to implement in a
>compiler.

  Sealing doesn't neccessarily get you a static binding.  I look at
  sealing as a mechanism to limit the scope of the "global" analysis
  needed to determine is a dynamic call is static ( or a two/three way
  branch.).  Even if the number of different class instances is two or
  three you may be able to construct a location "unique" dispatch meachanism
  that is much much faster than the normal one. For example:

         "if arg1 and arg2 are small-integers" then branch to small-int-version
         "else if arg1 is small-integer" then branch to small-int1-version
         "else" branch to  big-int-version.  

  [ Usually, a two way branch is going to be faster than a virtual table lookup
    ( i.e. C++ ) let alone a multi-method virtual dispatch. ]

  Or you may hard code
  a dispatch to the "most common" class and leave the others to dispatch
  virtually. For example:

        "if arg1 and arg2 are small-integers" then branch to small-int-version
        else virtual distpatch...

  In order to make these sorts of optimizations a global ( meaning all of the
  program's source ) analysis has to be preformed.  For very large programs
  if you can limit the range in which you have to look then this would seem to
  be extremely beneficial.  Sealing is a "delimits" these types of analysis
  to the current module. Or course if the module is quite large then
  this won't scale well either.

  Some folks at University of Washing have an optimizer that does
  this type of optimization among others.

http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html

  At some point I should have a Dylan "front-end" hooked up to to their
  back end. However, this is taking longer than I thought it would....
  ... so don't even ask for an estimated time of arrival. ( not so much
  a Dylan per se, but having N projects all running concurrently. )

Quote:
>I assume neither CMU nor Harlequin will release a compiler without
>support for sealed classes. A system with bad performance, but
>supposed to be release-quality withh destroy any hope for Dylan within
>a few months. Apples TR was OK, marked as what is was.

  Actually the biggest  "bang-for-the-buck" that they could probably
  implement would be to do profile guided optimizations.   Of course this
  would mean that code would run slow at first and then get faster
  as you played with it and did a recompile.... which some folks don't
  wish to do.

Quote:
>The second reason for the delay is probably that both groups try to
>build a compiler and a good developement system at once.

  This definately seems true.   Although I'm not sure how "happy" folks
  would be with a "batch" compiler. It would seem to be difficult to
  get a compiler that compiled "FAST" code in a rapid fashion if it has to
  start off from the "blank state" condition.  If you slow the
  edit-compile-test loop long enough folks get unhappy, but if the
  code runs real slow they're still not happy.

  I think you could work around this problem is a "project management"
  systems wrapped around the compiler but we're back to developing a
  "good development environment" again.

--

Lyman S. Taylor            "There is something unexplainable here, Scully,

                                                Fox Mulder - X-Files



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future


Quote:

> IMO, if you are using Apple stuff, you are sort
> of marginalized in the computer world anyways, so using a less popular
> language shouldn't worry you.

I'm worried about using a less popular language, _because_ as an Apple
user, I'm already marginalized enough.  If I were a wintel user, I'd be
enough less concerned with simple survival that I might entertain
investing a non-mainstream language.

Quote:
> I completely disagree with this. There has been no proof of implementation
> difficulty. There are (incomplete) systems available.

Personally, I'd take the lack of existing complete implementations as
prima facie evidence of implementation difficulty.

--
John Brewer             Senior Software Engineer             Spyglass, Inc.
    Opinions expressed do not necessarily reflect those of my employer.
   Heck, I'm old enough to remember the _first_ time Apple was "doomed".



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future



...

Quote:
>Ditto here, but I think there are some other factors which led to
>problems in Apple's implementation:

>- Optimistic projections about memory pricing and CPU speed

>If memory prices had come down the way hard disk prices did, the 20-meg
>requirement for the TR wouldn't have been so onerous.

  Not to object, but even the Microsoft overestimated the "drop" in
  memory prices. Least NT would have prentrated further by now.
  Additionally, if the scope of "Dylan The Language" the language itself
  doesn't necessitate the gee-whiz-bang environment.

  [ One problem was probably wishing to release an environment just as
        gee-whiz-bang as Apple's. ]

Quote:
>- Wrong choice for a development environment

>The Dylan team mostly consisted of Lisp hackers, and it made sense that
>they would want to build Apple Dylan in Macintosh Common Lisp. But
>there wasn't a native CL in time, and despite their best efforts at
>optimization, Apple Dylan on 68K was agonizingly slow. The version

  Errr. if most of the folks were serious Lisp hackers. How would they
  have been more productive relegated to using.... C/C++/Assembler?

  Also, is the tech release "optimized"? It would have made more sense
  to me to write version 0 of the environment in MCL. Then write version 1
  in Dylan. [ Sort of how CMU is writing there's on top of Mindy and
  Harlequin is writing theirs on top of... ].  I thought the point of
  what they had was to get a working, mostly bug free,  version.

  [ Aiming specifically at PPC based macintosh isn't exactly smart at
    this stage in the game since there are still more 68K macs out there
    than PPC based ones. Although that ratio is changing.  ]

  [ I won't mention the fact that interaction effect that Dylan/MCL
    were probably competing for limited development dollars... which wouldn't
    help either. ]

Quote:
>- Feature and Design Thrash

>I don't know much of the history of Dylan within Apple, but I'm sure

  Of course if "thrashing" was to take place MCL is probably a better
  choice....

Quote:

>- An Awful Lot to get right for the first release

  ... true ...

Quote:
>Another approach would be to do like Sun did and create a bare-bones,
>but source-code licensable, "reference" implementation. If Apple had
>done this and released a generic "reference" Dylan, say, written in
>ANSI C without GUI support, other companies could have put in the

  ... of course they could have released/licensed the Common Lisp code too. :-)
  Decoupled from the GUI of course. Not sure if you can actually do
  that though ( you can ... just not sure if they wrote the code that
  way ).

  The fact is that because Dylan requires a runtime environment ( gc, dynamic
  dispatch, etc. ) most C/C++/Pascal compiler vendors aren't going to touch
  it with a ten foot pole. So the fact they can't read Lisp isn't all that
  important.  It think Common Lisp is just about as portable as ANSI C.

  [ Of course the best solution would be to release dylan code along with
    some sort of cross compiler... :-) ]

--

Lyman S. Taylor            "There is something unexplainable here, Scully,

                                                Fox Mulder - X-Files



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future

    Brian> I think it is wrong to attempt to connect "elegance" with the
    Brian> amount of time it takes to produce a "working" system. For
    Brian> example, Mindy and Marlais are working, if incomplete,
    Brian> implementations of a workable subset of Dylan, which have been
    Brian> available for a while. Producing a full featured Dylan and an
    Brian> accompanying programming environment is bound to take a long
    Brian> time.

This is something I have never understood about Dylan implementation. All
(most) of the language features, as designed, had at least been implemented
once if not many times in the Lisp community. What possible language
features, in isolation or combination, could lead to only ONE native code
implementation.

Call me obtuse, but if you have Mindy how much farther do you need to go?
And Mindy's been out what, a year or two now.

--

                         Cause I know the time, cause I'm gettin' mine
Gotta have house...      I get on the mix late in the night..."



Fri, 19 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:

>I'm worried about using a less popular language, _because_ as an Apple
>user, I'm already marginalized enough.  If I were a wintel user, I'd be
>enough less concerned with simple survival that I might entertain
>investing a non-mainstream language.

This is a serious issue.
I was just told today that this department will be replacing the office
Macs with PCs.
I was told this by the _same_ person who told me he we were only going
to install Windows 95 on the staff PC server, leaving the students
with Windows 3.1.1.  Why?  Because we can't afford to double the memory
on all the machines we bought last year and the year before.
And the man who told me this said that if he had a free choice, he'd
junk all the PCs and switch to Macs, because we have PCs, UNIX machines,
and Macs on our net, and whenever there's a foul-up, it's the PCs or the
UNIX boxes, not the Macs.
But it has been decided that it is too expensive to maintain 3 environments
(7% cuts to university funding this budget year, more next year; the Liberal
government wants to make Australia an internationally competitive nation by
reducing access to tertiary education, and no, it doesn't make sense to me
either)
and students without PC experience don't get jobs,
and staff without UNIX access would scream blue {*filter*}.
Oh well, perhaps I'll be able to pick up a Mac II cheap....

Does Dylan run under MAE?

--
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.*-*-*.com/ %7Eok; RMIT Comp.Sci.



Sat, 20 Mar 1999 03:00:00 GMT  
 Dylan's future

Quote:

> Personally, I'd take the lack of existing complete implementations as
> prima facie evidence of implementation difficulty.

Personally, I'd take such shallow reasoning as prima facie evidence
of someone not understanding the various different factors/priorities
which might influence the availability of software.

Why is it so difficult to become informed first, before spreading wild
guesses?




Sat, 20 Mar 1999 03:00:00 GMT  
 
 [ 88 post ]  Go to page: [1] [2] [3] [4] [5] [6]

 Relevant Pages 

1. Dylan's future

2. Dylan's Future?

3. Design Patterns (was Re: Dylan's Future?)

4. Dylan's Future? / How to save Dylan at this late...

5. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

6. Future of Dylan?

7. Future of Dylan?

8. Future of Dylan

9. Future of Dylan?

10. Future of Harlequin Dylan

11. About the future of Dylan

12. XPOST: About the future of Dylan

 

 
Powered by phpBB® Forum Software