| Newsgroups |
gmane.comp.lang.ocaml.beginners |
| Message-ID |
<[email protected]> |
On Fri, Jun 26, 2015 at 07:12:40PM +0000, Kenneth Miller [email protected] [ocaml_beginners] wrote:
> Well, here's my take on some of those approaches:
> OcamlJava and js_of_ocaml sound like really good options.
> For one, using a browser is very modern. You can reach all os's and
> you don't really have to fanagle in terms of limitations that the
> route for drawing to the screen put on you.
I have thought of generating and dynamically modifying the html, or
some tree-structured data structure encoding the html (such as the
stuff inside browsers that the javascript modifies.)
> The js_of_ocaml sounds
> like a really good route, because all your software will be a
> service, and additionally, everything can be a callback. You'll need
> to learn a lot, but I think this is really the very best option.
> Ocamljava does put some restrictions on you because you can't use any
> library that has C code as a dependency.
Both are interpreted, which will cost performance, though it might be
convenient to be able to use them on my tablet. Not the current
proect, but another I have in mind, will proably be compute-bound, so
I'd rather have something statically typed that I can compile to
machine code rather than something with dynamic typing and interpreted
or even JIT-compiled. Other language in the running here is Modula 3,
which has a pretty severe problem with modern user-interfacing, too.
But it can handle multicore shared-memory execution within one program,
whch might just be helpful (won't know for sure until I try it, of
course).
If OCaml wasn't compilable to machine code, I wouldn't even be
considering it.
Now that I've mentioned Modula 3, it should be clear that 'modern'
isn't a criterion.
> Going from OCaml to just native C is easy with ctypes. The other way
> around is a nightmare because OCaml has a runtime and virtual
> machine; you have to interface with that in order for things to work,
> and that means taking some significantly complicated considerations.
I know. There's a whole section in Chapter 19 about callbacks.
> I really wouldn't worry so much about the minor version of a library
> as the big version unless you need something that's critical. The
> caml manual specific description of using labltk sounds acceptable,
> and you can bet that if it's in the manual that lots of people have
> taken that approach.
Same may work with Gtk2. I'll have to look at both.
> Printing pdfs from OCaml sounds slow as all getout,
> and pdfs are really bloated.
Of course. pdf's are bloated. They are low-level printer-control
scripts. Almost no one uses the significant programmability built
into postscript.
I printed pdf's from OCaml when I needed to control a printer.
For current use, I don't even dream of using pdf's.
Cairo has several output options, including displaying to a regular
computer screen. Some browsers actually use cairo to display web
pages, so it should work for me, too.
-- hendrik