Hi John,
What made Felix stand out for me, as an aspiring game developer, was:
1. Static type checking (compared to Lua/Python)
2. Garbage collection (compared to C++)
3. Easy binding to C++ (compared to anything except C++)
4. "High level language" features like closures, data types
5. Punctuation and braces ("{ ... }" rather than "do .. end", f(x) is
normal rather than f x)
Until you've made a determination that the target audience of your
marketing will be "game developers", you should probably file my opinion
under "interesting but probably useless."
If you're ready to begin the study of marketing, take a look at "Crossing
the Chasm" by Geoffrey Moore - it has some great guidance in terms of
picking a target group to market to. "The Innovator's Dilemma" helps one
understand how markets are disrupted and new languages (like, say, Ruby)
manage to rise to prominence. And "The Three Laws of Performance" can help
you to achieve breakthrough performance in your own life so you can apply
what you learned from the other books without drilling holes in your own
boat. I suspect Seth Godin's book "Tribes" is very useful for someone who
wants to build a community around a new programming language.
Knowledge is power, so they say.
Cheers,
Dobes
On Mon, Feb 18, 2013 at 2:36 PM, john skaller <skal...@users.sourceforge.net
> wrote:
> What's so good about Felix? I need to know because its hard
> to market something without a coherent explanation of why it's better.
>
> 1. Easy compilation.
>
> Just saying "flx filename" is really cool. No makefiles or crap.
> I plan to extend this capability to C/C++. At the moment, Felix + C++
> compiler is supported on the command line but doesn't work.
> It needs to be fixed, and some way to just make C++ code added.
> It's pretty easy to add
>
> //$$ Depend: packagename
>
> to C++ files so you can auto compile and link the same was as Felix does
> it.
>
> My target here: the whole Run Time Library is going to be installed
> AS SOURCE and the actual binaries cached just like for
> Felix code. In other words put Felix and C++ code in the same
> basket. Unlike Ocaml, C/C++ translation units can be built
> in any order. There are no dependencies.
>
> 2. Easy refactoring. You can just move stuff around. It's more or less
> that simple. Try doing that in any other language. Split out a file?
> Just respect scope, put include "./filename", and you're done.
> Reorder code? Again, just respect scopes and you can reorder
> any definitions (NOT variable initialisations or executable statements!)
> Thanks to "setwise lookup", and the lack of "interfaces". Executable stuff
> can be packed and interleaved as desired with definitions but not
> reordered.
>
> 3. Simple shellish script.
>
> We're NOT there yet. It's still easier to write simple stuff in bash.
> On unix, however the shell and tools are severely compromised
> by a completely broken file system model, and a total lack
> of coherent interfaces for the tools. Some progress here is
> available with flx_cp, etc. These tools have a simple common
> interface (being improved all the time) and a coherent view
> of the filesystem via Perl regexps. There's great potential here
> to improve the tool set, particularly leveraging the relatively
> new stream iterator constructs.
>
> 4. A great balance between simple script and high performance.
> Typical Felix code, even using high level (read SLOW) constructions
> like stream iterators, closures, plugin objects, etc, has pretty good
> performance compared with similar constructions in any other
> scripting language. And you can rely on core calculations being
> thousands of times faster, on par with C.
>
> The result is you can do things like high level matrix maths,
> and you don't have to split your code into Python for the
> top stuff and NumPy or whatever for the core. One language
> can do both. So it's extensible, whilst Python/NumPy is not.
>
> No, it's not really suitable for kernel development and on the
> other end there's no REPL. but it covers the territory in
> between better than anything else.
>
> 5. Self documenting Code
>
> This is in a very primitive form at the moment. It's possible to
> write library modules with web-servable documentation.
> It's possible to write unit tests with documentation and
> expected results. That's about it. I hope this will extend to
> something roughly like a Wiki based language, in particular
> eliminating the need to install stuff (that's what "the web"
> is for isn't it?) It's been done before (Perl/CPAN, TeX/CTAN)
> and of course C++/Boost).
>
> --
> john skaller
> skal...@users.sourceforge.net
> http://felix-lang.org
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to felix-language+unsubscr...@googlegroups.com.
> To post to this group, send email to felix-langu...@googlegroups.com.
> Visit this group at http://groups.google.com/group/felix-language?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
