On Wed, 2006-08-30 at 12:56 -0400, Peter Tanski wrote: > On Aug 30, 2006, at 1:48 AM, skaller wrote: > > > Felix is designed to take on Java: Java is its main > > competitor. > > Hmmm... I never thought of Felix that way.
Felix is aimed at C++ programmers, and intended to provide an upgrade to a much better system, but with compatibility along the lines of C -> C++ upgrade, without sacrificing performance, but with much better portability than Java. It's also supposed to provide a much simplified compilation model, along the lines of running Perl or Python scripts. > Java is a user-space > language designed for building applications--including server-apps > which is all the Apache stuff really is; at least to me, Felix is an > easy functional handler for C++ (although Felix does not have any low > level operators--you have to know C or C++ to do that). Well things like closures, variants, and pattern matching smack of an FPL .. but really they have very little to do with functional programming. Advanced languages like ML and Haskell provides these features not because they're functional .. but because people who knew some basic theory knew these features were essential in *any* language. ML isn't a functional language: it has mutable store. So does Ocaml. These days even Haskell does :) Yes, Ocaml, SML, and Felix provide much stronger functional programming facilities than C++. That wouldn't be hard! Any procedural, imperative, or other language should have all these things: imperative languages still have expressions: they still have a functional component. If there's anything 'novel' in Felix, it is actually the user space high performance 'microthreading' or fibration .. and that's entirely a procedural/imperative construction: Felix fthread can only be procedures and they can only be spawned by procedures not contained in functions. [The machine stack .. it gets in the way, the fthreads are continuations, which won't work unless the machine stack is empty] > In other > words, on top of C++, Felix is a real programming language, capable > of being used in real-time embedded systems. Indeed .. it was designed originally for a telco application. But then again, parallelism and real time behaviour are no longer special requirements. Almost all modern applications require these facilities because most of them play with networking. > Felix is meant to be > cross-platform (ISO C++) but it is far more succinct than Java and > does not run on bytecodes. That is a biggie: no bytecodes! Yes: it's defined as a scripting language: in terms of source code. The unit of 'portability' is text files of source codes .. seems right for an Open Source programming language :) > Small, > fast, stand-alone executables and dynamic libraries are much easier > to distribute and use. What commercial developer wants to force > users to install a bytecode interpreter, just so they can run the > program? You can do that too: Felix can either static or dynamic link. > The (relatively) new Felix wiki you put up seems to target library > designers. Of course. Everything is a library. Even C programs are just libraries, with one distinguished functions, main(). > I would be very happy if something displaced Java-- > Microsoft basically answered that with C#, another despicable > language-- C# version 1 was just a Java clone. However the latest C# is getting much better. It is worth looking at. Remember MS actually has real academics and researchers working for them. Recall the lead developer of Haskell .. Simon Peyton Jones .. actually works for Microsoft :) C# has true generics (unlike Java) and version 3 actually has advanced features like type inference -- as well as overloading, which is some mean feat! The algorithms are quite advanced. > The big downside to Haskell is how extremely > difficult it is for a programmer to debug memory leaks and make code > efficient (complaints #2 and #1, respectively). This is a temporary state of affairs. Haskell is very slow at some things. But it is getting better. I'd say the main problem with Haskell is really portability. Haskell code is portable .. what I mean is the availability of the compiler. It's a real pain to get running. This too will change, IMHO, but the world just isn't ready for Haskell yet, and Haskell isn't ready for it. > The key is programmer productivity. Program performance matters too. C/C++ proves that. > Java has taken off because it > has a gigantic base of easy, cross-platform libraries and it was one > of the first languages with good library support to be garbage > collected: without those, no one would use it. I agree. The key library was Swing, the GUI. > Felix could go head- > to-head with functional languages on one singular basis, the same > reason programmers new to functional programming migrate to OCaml > (besides the speed): Felix can be both procedural and functional. > Going pure functional is a big hurdle. I don't believe in it. Neither do Haskell people: STM monad, I/O etc. The fact is, people think in terms of both environment (declarations) and action (procedures). Any real programming language needs both. The big problem has always been how to integrate them. The way ML does it is just wrong. Haskell has shown another way, using monads. Of course that is wrong too, but it is better, because it localises the action oriented code in a way that can be tracked by the type system. The 'right' way to do this is with coalgebras, but the theoreticians haven't provided enough stuff yet :) > Felix can also go head-to-head with OCaml and any other functional > language I can think of because--better than Python--Felix has a dead > simple interface to C++. Not even DigitalMars's "D" has an interface > to C++; Unfortunately, D is basically a souped up object oriented language. In my view it misses the boat: the future is in functional programming and parallelism along with plain old procedures: there's a place for OO in there, but it should be a 'feature' not a fundamental. > if there were any competition for Felix, it would be from the > D world. Have you ever attempted to use SWIG to interface OCaml to C+ > +, or write your own C++ wrapper to OCaml? Nope: I once worked on MLGtk, an Ocaml binding to Gtk. Ocaml's FFI is not that hard to understand, but it is very laborious to construct the bindings, and doesn't seem amenble to automation. > From what I have observed, languages that have easy and fast GUI, > Web and Network library support quickly become widespread. It helps. We have async I/O support now, which is basically sockets and timers, and we have two kinds of threads so far (fthreads/fibres and pthreads). The socket support is state of the art for a non-syscall/kernel module/assmebler binding --we use epoll, poll, kqueue, select, Solaris iocompletion ports and Windows iocompletion ports. > A great > project, when I can find the time, would be something I mentioned > before: an interface to wxWidgets or some other good cross-platform > GUI library. SDL. It's not a GUI library. That's the point :) > The difficulty with wxWidgets would be rampant macro > usage, but a wxFelix library would be easier to use than Ultimate++, > and, more to the point, would be able to use a thread-model instead > of an event model and still be as fast or faster. The problem is, most GUI are brain dead. They're all based on callbacks. Good libraries, such as Microsoft Windows, don't hide this. Windows actually isn't callback driven: you have to dispatch messages yourself. Unfortunately, wxWidgets seems to hide the event loop. Felix provides its own scheduler/event loop: I don't see any way to merge the event loops. Of course, it is easy in theory to solve this problem with a client/server interface .. the problem is GUI's are typically HUGE and we'd have to wrap a lot of functions. > If you want a good > basic GUI to work with, you might try FLTK, at http://www.fltk.org/ . Unfortunately .. doesn't seem to be re-entrant: from a tutorial, these lines condemn it: ------------------------- Window *window = new Window(300,180); It then calls "begin" on it, which indicates that all widgets constructed after this should be "children" of this window: window->begin(); It then creates a box with the "Hello, World!" string in it, this new widget is made a "child" of the window we just created: Widget *box = new Widget(20,40,260,100,"Hello, World!"); For most widgets the arguments to the constructor are: ------------------------ So how can calling 'begin' ensure the 'next' widget created is a child? By maintaining hidden state in a static variable. Gak. First rule of programming: everything should be re-entrant unless it cannot be (eg signal handlers must access static variables). -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
