Re: ANNOUNCE: GHC survey results
Hello Simon, Tuesday, June 28, 2005, 1:58:13 PM, you wrote: SM> http://www.haskell.org/ghc/survey2005-summary.html SM> There's a lot to take in, but it's an interesting read. Enjoy! thank you all, processing all the 600 answers was not easy work :) i have several comments regarding results of this survey: 1) GHCi compiles to bytecode several times faster than GHC makes unoptimized compilation. can unoptimized GHC compilation just create bytecode (as Ocaml does)? 2) is your plans to support x86-64 platform includes Windows (and all other sorts of Unix), or it's for Linux only? 3) many users complaining about non-compatibility between GHC versions. if they mean library interfaces changes then how about using Pesco's library versioning scheme? (see http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) 4) i definitely will poll for nightly snapshot build for Windows (if it's possible) and frequent releases of stable versions i think there is a plans to move toward the "real world". but it encounter the chicken&egg problem - the commercial programmers don't want to use Haskell because it's too far-from-earth, and you cannot make movements toward "real world" because there is almost no voices from non-academic world. of course i can't monopolize the right to say over all these programmers. but from my point of view several things can be done to be closer to commercial programs and programmers: 1) adding OO-like features in O'Haskell style. for readers that don't know it's about adding new variants to ADT types: type Figure = Circle ... type Figure |= Box ... and adding new fields to existing records: type Point = {x,y::Int} type ColoredPoint = Point extended with {c::Color} imho these extensions are great because it's both in Haskell and C++ style 2) adding "real-world" libraries. i think about libraries for string processing, regular expression handling, command-line processing, serializing, ASCIIZ strings, working with filesystem and running external commands, networking, web-oriented libraries (http/ftp/smtp/pop3, constructing/deconstructing emails), DBMS access i enumerated here only working libraries which i seen in MissingH, or written by Pesco, John Meacham, or Peter Simons 3) may be it is time to include some FFI-generating tool in GHC? many newcomers have some C/C++ libraries they need to communicate 4) some newcomers wrote what they want to say example programs and even tutorials in the package. i think that at least links to such sources/texts can be provided so that a newcomer can easily get a TASTE of Haskell 5) of course, you must add words about Pugo and Darcs in readme :) anyway, ADT is a vehicle of progress ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com
Re: Bulat's comments
1) adding OO-like features in O'Haskell style. for readers that don't know it's about adding new variants to ADT types:
type Figure = Circle ... type Figure |= Box ...
With ADTs you do pattern match on the constructor, but in OO style guides (see Fowler: Refactoring) you find that "switch statements" are considered bad design. Instead you would use the "Composite" design pattern interface Figure class Circle implements Figure class Box implements Figure this lets you add classes easily. Sure this is more verbose but it might be easier to maintain and extend. (Yes I know that mathematically a free algebra is a nice thing.)
and adding new fields to existing records:
type Point = {x,y::Int} type ColoredPoint = Point extended with {c::Color}
well I never would want to do that - and OO gurus do not recommend it either. See Gamma et al, Design patterns, Introduction, where they advise to use interface inheritance, but to avoid implementation inheritance. This is exactly the situation we have in Haskell. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Hello Johannes, Tuesday, June 28, 2005, 7:38:04 PM, you wrote:
type Figure = Circle ... type Figure |= Box ...
JW> interface Figure JW> class Circle implements Figure JW> class Box implements Figure this don't give ability to create polymorphic collections JW> well I never would want to do that - and OO gurus do not recommend JW> it either. See Gamma et al, Design patterns, Introduction, JW> where they advise to use interface inheritance, but to avoid JW> implementation inheritance. This is exactly the situation JW> we have in Haskell. you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments -- Best regards, Bulat mailto:bulatz@HotPOP.com
Bulat Ziganshin wrote:
JW> interface Figure JW> class Circle implements Figure JW> class Box implements Figure
this don't give ability to create polymorphic collections
You mean in Haskell? I would probably use existential types then. Something like data EFigure = forall f . Figure f => EFigure f and - as Georg Martius once pointed out - with an additional "instance Figure EFigure ..." to avoid at least some of the (un)boxing code. As a whole, this *does* look messy - Java programmers can nicely write the name of the interface when they mean some unspecified instance: Figure f = new Circle () ... Of course that's only so because their interfaces (type classes) are always unary predicates. I definitely would not give up multi parameter type classes from Haskell. But still the Java notation looks neat and concise. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Tue, 28 Jun 2005, Bulat Ziganshin wrote:
you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments
Not to forget to make learning easier for programmers of Perl, Ruby, Python, Rexx, Tcl, APL, C#, Java, Bash, Fortran, Pascal and so on by adding their most beloved features from their currently most beloved language ...
you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments
Not to forget to make learning easier for programmers of Perl, Ruby, Python, Rexx, Tcl, APL, C#, Java, Bash, Fortran, Pascal and so on by adding their most beloved features from their currently most beloved language ...
Please insert <straight-face> or <sarcasm> tags when making statements like this so we can know if you are joking or not ;)
On Tue, 28 Jun 2005, robert dockins wrote:
you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments
Not to forget to make learning easier for programmers of Perl, Ruby, Python, Rexx, Tcl, APL, C#, Java, Bash, Fortran, Pascal and so on by adding their most beloved features from their currently most beloved language ...
Please insert <straight-face> or <sarcasm> tags when making statements like this so we can know if you are joking or not ;)
B-]
participants (4)
-
Bulat Ziganshin -
Henning Thielemann -
Johannes Waldmann -
robert dockins