Artem Gr wrote:
> 2) FAQ-style / searchable documentation.
> I've wrote a small Felix program half a year ago (2006-09), but it 
> required me to shovel the whole documentation at least twice, just to 
> find the pieces i needed (and the program is only 7kb long, a lot 
> smaller than the documentation i had to read). The existing 
> documentation is systematic, but isn't helpful when i need to solve 
> particular problem. Searchable documentation is a win. Since Felix 
> documentation is automatically generated, i would highly recommend 
> generating a CHM bundle (it is automatically searchable, fast and 
> convenient) and adding a Google search on the site documentation.
>   

Thats a good idea for the blog. I'll see if I can add it.

> In Haskell we have practically no full documentation, instead there is 
> the Report and a lot of tutorials (and GHC User's Guide). It might be 
> not as convenient when developing, but it makes the language so much 
> more attractive to the new user. Felix is much easier than Haskell 
> (being imperative, no monads, etc) and yet it is much harder to write a 
> small program in Felix than in Haskell. The problem is, the 
> "http://felix.sourceforge.net/doc/tutorial/introduction/en_flx_tutorial_top.html";
>  
> is not really a tutorial. Rather it's a documentation by example. 
> Tutorial must concentrate on something (like IO, or Felix-C++ linking, 
> or whatever) and explain this something at large (repeating the same 
> thing several times in different ways, if necessary) so that after 
> reading the reader feels the area covered, feels himself confident in 
> that area of the language. Having several tutorials written by different 
> peoples on the same subject helps much to this effect.
>   

I'd like to write up some tutorials.

> P.S. I'm going to try using Felix from inside a Java application via 
> JNI, and if i succeed with all the linking troubles (to which i haven't 
> found any documentation so far), i might write a WiKi page / tutorial on 
> that.
>   

Cool!

> 3) News feed (aka BLOG) with recent additions. Mailing list is for 
> solving problems, BLOG is for keeping in touch with community. BLOG 
> might contain essentially what Haskell "News" at 
> "http://www.haskell.org/haskellwiki/Haskell"; does, that is, highlights 
> on SOME of the mailing list threads.
>
> Google groups seems more user-friendly than sourceforge to me, though i 
> prefer GMANE most, and i doubt it is possible to view a Google group 
> through GMANE? If it /is/ possible, then go for google-groups. It is 
> certaintly not user-friendly to just direct the user into 
> http://lists.sourceforge.net/lists/listinfo/felix-language, as it is 
> done currently on http://felix.sourceforge.net/, instead, there should 
> be links both to GMANE, Google groups and whatever else there is. GMANE, 
> IMHO, is very convenient, given the number and quality of interfaces 
> (NNTP for subscription, WEB for cursory reading / search) and should be 
> advertised.
>   

Already in the works regarding google groups. I've already set up the 
blog to automatically link posts with the google group page. 
Unfortunately in the process I found a bug in groups that can prevent 
people from posting to it via email, and I'm not sure if they've fixed 
it yet. Then I got distracted by other things... :)

> 4) About core language developers (the Pending Death thread).
> (From my profane point of view).
> Haskell have them because it's a research platform. And even then, it's 
> backed by a research institure and Microsoft Research. Most other 
> languages i know are either script "kiddy" languages and thus can 
> attract a much larger audience (Perl, PHP, Ruby) or were industry-backed 
> at first (Java, C++). The "kiddy" languages are given the opportunity to 
> mature and grow a community because they are "kiddy" - the first 
> implementation is naive, easy to implement and thus much effort is going 
> into libraries, documentation, usability; the industry-backed languages 
> can grow because peoples don't bother waiting for co-developers, they 
> just sell their languages to a corporate user-base, who do applications 
> and proprietary libraries, part of which becomes free, and one day we 
> have a mature language. But even that doesn't guarantee there will be 
> co-developers soon. Felix is close to "mature" part, it is important, i 
> think, to write the specification and concentrate on stability and 
> usability (which includes documentation, tutorials, web infrastructure, 
> more integration/interoperability libraries/guides, OS packages).
>   

Felix is in an odd state of maturity. Since we have no users, we can 
play around with the language some without busting too much. For 
instance, typeclasses were added as an experiment as skaller figured out 
an easy way to add them. Other times we'll rename functions and add 
sugar to make things more clear.

> 5) Felix is in the unfortunate space between safe languages, including 
> the "kiddy" scripting ones, complicated languages, like Haskell with 
> GADTs, and the C++, where it is easy to "shot thyself in the foot". I 
> think it is very important to provide a way of running Felix under a 
> managed runtime. Modern language user expect stack traces and safety 
> from it's language!.. C++ audience is diminishing, not growing, because 
> pure C++ lacks that safety. Felix should took pains, *if it is 
> possible*, to provide easy, either out-of-the-box, or supported 
> (automatically tested) and docummented compilation of Felix into .NET 
> managed DLL's (Visual C++ targeting CLR) and maybe LLVM bytecode. What 
> should be implemented under such targets is save SIGSEGV exception 
> handling and recovery, exception stack traces (not necessary 
> method-level)... Is it possible with current Felix design?
>   

One of my long standing goals is to make an llvm backend to felix. I 
think the design of felix allows it to be retargetable. I think we'd 
still be able to have c++ compatibility too, but I haven't gotten too 
far with that. In fact, I've had troubles building it until recently, so 
I've never really gotten to play with it too much.

> P.S. There is a stack unwinding feature in GCC, used from GCJ but 
> available for tapping from usual C++ code. Is it applicapble to Felix?

Unlike skaller, I like debuggers, so I would like this done as well. 
llvm has some nice hooks already built in for hooking into gdb and the like.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to