On Sat, Feb 14, 2009 at 11:56 PM, Matt Gushee <[email protected]> wrote: > OK, I'm hooked. I was trying to avoid learning another new language-- > especially since I was in the middle of trying to systematize my > haphazard knowledge of C. But I find Factor ... strangely compelling.
Thanks for the feedback! > Anyway, my first thoughts when I encountered factorcode.org were, "Hmm, > this is weird," and "'Practical'? Yeah, right!" And having tried in the > past to understand bits of PostScript (gulp!) and having read part of an > introduction to Joy, which I found utterly incomprehensible, I really > had doubts about a stack-based language. But I could see that Factor at > least had an extensive library and lots of documentation, so I guess > that was enough that I decided to come back and try it. I've been > learning Factor for 3 or 4 days, and it is gradually starting to make sense. > One of my goals with Factor was to discover how far stack programming can go, and all the contributors have also at least partially shared this goal. By applying Factor to various domains: compilers, UI toolkits, web server, graphics, XML processing, etc -- I think the Factor community has come up with a pretty good set of idioms and abstractions. A big part of making a language usable is API design, and as you design APIs you notice deficencies and problems in the language, this creates a good feedback cycle. We've been trying to come up with good libraries as well as good language features, and to share as much code as possible between the libraries, in turn adding language features that make this possible. I think the Joy papers are pretty great, and once you're more comfortable with stack programming I highly recommend reading over them again. > The only thing I can see that's really lacking (or > maybe I just haven't discovered it yet) is an interface to version > control systems. Does anybody do serious development without some > form of version control? Since Factor's development is done in a GIT repository, that's the version control tool that I've been using the most lately. I agree that having GIT support built-in to the workspace UI would be great, and Ed Cavazos posted a prototype Factor GIT tool recently. Until a complete tool is implemented, the approach is the same as with editors; you have to leave the Factor environment to interact with version control. > * While the easy access to documentation is great, and the reference > material appears to be very good, I think there is room for a lot of > improvement in the tutorial content. Yup, definitely. Just writing the reference docs is a lot of work, and when they're in a better shape I'll shift my emphasis to more introductory material. > > - Consider renaming and restructuring the Cookbook. Every other > programming "Cookbook" I have seen is a collection of realistic > examples intended for programmers with some experience--what you > might call "journeymen"--trying to solve real-world problems; > usually each "recipe" stands on its own. Beginners, IMHO, tend to > do better with a sequence of chapters, each building on the > previous ones. Not that there is any single correct sequence for > learning a programming language or anything else. But any structure > provided by a knowledgeable writer is likely to be better than no > structure at all. > > - Try to provide series of related examples, gradually increasing in > complexity/difficulty. I think the book _Practical Common Lisp_ > does this very well. > > - Although stack manipulation is a fairly simple concept (compared > to, say, monads in Haskell or call/cc in Scheme), real programs > are composed of many stack operations, and it can be hard to > follow. In the early stages of learning, step-by-step explanations > and/or diagrams would be very helpful. These are good suggestions; the cookbook really needs to be updated at some point. It also misses out on some more recent language features (fry, locals, cleave combinators, ...). > - I think experts in any given language tend to underestimate the > difficulty of syntactic details. For example, what are the rules > for using semicolons? It is confusing that a USES: declaration > ends with a semicolon, but not an IN: declaration. In this specific example, USING: takes several vocabs, so it has to be terminated with some type of token to demarcate the end of the USING: form. IN: only takes one vocabulary. Another example of this is GENERIC: -vs- :. GENERIC: just reads a single word name, whereas : reads a definition. There's a general philosophy where parsing words avoid unnecessary tokens; this is a good rule of thumb, but isn't followed religiously, for example the qualified word syntax uses some sugar: FROM: vocab => words ... ; > If I stick with Factor--and I think at this point I probably will-- > when I gain enough understanding of the language I might be able to > help improve the beginners' documentation. I have done some technical > (and other) writing in the past. Great. Documentation will become a priority for me too, once I finish a big UI overhaul I'm working on now. > * The optimizing compiler (v. 0.92) is *horrendously* slow on my > machine. I didn't time it, but I think it took about 15 minutes to > compile the Tetris demo. A comparable program in OCaml would compile > in less than 30 seconds. That's probably an unfair comparison, but > still ... So, are there any plans to speed up the compiler? Or are > there ways to compile faster with the current compiler? What are the specs of the computer you're running Factor on, and how recent is your build? "tetris" run completes pretty quickly for me, less than 30 seconds. As for "tetris" deploy, the deploy tool takes something like 3 or 4 minutes the first time you run it as it creates a staging images for deployment, but after these exist it deploys very quickly. If you find yourself frequently playing Tetris at work during the day ;-) you can save the image after loading it with "tetris" require. You can put "tetris" require in your ~/.factor-boot-rc so that its loaded every time you bootstrap; I do this with vocabularies I use frequently, like editors.emacs, compiler.tree.debugger, and a few others. Slava ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
