LWN: Comments on "FontForge and moving forward"

FontForge and moving forward

ssokolow — Fri, 15 May 2015 05:26:36 +0000

I don't personally use scientific computing stuff with heavy enough data loads to need anything more performant than ipython-notebook and it's not the kind of glamourous stuff that get trumpeted from the rooftops, so I don't have a ready answer.

However, crates.io does appear to already have a couple of different BLAS bindings, so there are obviously some people interested in that use.

FontForge and moving forward

dashesy — Thu, 14 May 2015 16:50:32 +0000

I have only read praise about Rust, and am very eager to try it in what seems to be a good fit. What is the state of scientific computing in Rust? is there any equivalent of SciPy, NumPy, Scikits, Pandas, IPython and the most important one for me matplotlib in Rust?

FontForge and moving forward

ssokolow — Thu, 14 May 2015 10:01:57 +0000

Given how much onus JavaScript puts on the developer to ensure the codebase remains maintainable (duck-typed dynamism doesn't help there), my hopes are for Emscripten being updated to a new enough version of LLVM for such apps to be written in Rust.

(If you haven't tried the Rust 1.0 beta, I highly recommend trying the 1.0 final release that's coming out tomorrow. It's got string handling, package management, segfault-immunity, and GTK bindings that place it in competition with languages like Python and JavaScript but it compiles to GC-less native code with performance comparable to C or C++ and not only does it have a great FFI for calling C code, it makes it really easy to generate libraries that C code can call.)

http://rust-lang.org/ (Downloads)
https://play.rust-lang.org/ (In-browser compile+run playpen)
https://github.com/ctjhoa/rust-learning (Curated list of learning materials)
https://github.com/kud1ing/awesome-rust (Curated list of libraries)
https://crates.io/ (NPM/PyPI equivalent)
https://www.reddit.com/r/rust/comments/35ue7y/rust_with_e... (Source for my Emscripten comment)
https://www.youtube.com/watch?v=LazvK39Oc4U (Ghe concepts behind Rust and calling Rust from Ruby)
https://www.youtube.com/watch?v=3CwJ0MH-4MA (Calling Rust from Python)

Noteworthy tutorials:
http://doc.rust-lang.org/1.0.0/book/
http://www.rustforrubyists.com/

Noteworthy Libraries:
https://github.com/rust-gnome (PyGTK/PyGI equivalent)
http://www.piston.rs/ (PyGame equivalent)
https://github.com/kbknapp/clap-rs/ (Very nice command-line argument parser)
http://arewewebyet.com/ (Overview of server-side web frameworks)

...and the subreddit and IRC channel are very helpful.

FontForge and moving forward

rsidd — Fri, 08 May 2015 15:00:15 +0000

Replying to myself: I continue to use (La)TeX for serious stuff, which originally depended on Metafont, but modern versions (pdftex, xetex etc) use Type1 postscript or OpenType fonts instead.

FontForge and moving forward

rsidd — Fri, 08 May 2015 14:58:28 +0000

Interesting to learn about Metapolator. So Metafont is still alive, if in a different form. One of the more interesting chapters in Douglas Hofstadter's "Metamagical Themas" (originally columns in Scientific American in the early 1980s) is a discussion of Metafont, including a version of "The Lord's Prayer" typeset by Knuth slowly tweaking parameters such that the first few words look like some 19th-century florid heavily-serifed font, while the last few look like a modern sans-serif typeface not too different from Verdana (which was well in the future at that time), but the changes from word to word are hardly perceptible. I wonder if Metapolator can pull off things like that (not that I'm sure there is a point, and much of Hofstadter's article was devoted to attacking Knuth's view that there is a "universality" to fonts such that a sufficient number of twiddlable knobs could cover all the font families around.)

FontForge and moving forward

massimiliano — Fri, 08 May 2015 06:37:12 +0000

If, with the current state of web technology, it can be done at all.

The "current state of web technology" is a very fast moving target, and incredibly diversified.

Given the variety of different frameworks that one can call "web technologies", I am convinced that the complexity of a large "web based" software product can vary a lot depending on design decisions and frameworks adopted (which is of course true also in the C and C++ world).

However, the "web" ecosystem is becoming truly amazing, and in particular it is providing tools that support very clean software design and implementation. I would contend that making the right choices one can not only implement projects "as complex as the C and C++ ones", but also do them "better" and in a fraction of the time.

Just look at how many desktop projects are choosing something like node-webkit, or the new "electron" by Github, as a base framework. Heck, you can laugh at it, even Microsoft used electron for their new free (as in beer) cross platform development environment!

We should stop assuming (by preconception) that "web development" equals necessarily "an entangled unmaintainable mess of PHP and spaghetti Javascript". The world is moving on :-)

FontForge and moving forward

alankila — Thu, 07 May 2015 19:39:29 +0000

Yeah, I think that I indeed missed it. Still, I do think that JavaScript has solved at least some of the "problems" such as how to handle strings (especially if I can compare to C), so it is probable that most programs are simpler, shorter, and less prone to security vulnerabilities and segfaults when written in JS. So I think it's at least plausible to argue that some applications would indeed be better when written in JS.

On the other hand, I have no expectation that every kind of application can be ran from the browser sandbox. indeed, application such as Blender or some video or sound editor would probably prove to be either impossible or perform very poorly. However, this is more a question about the APIs available to developer than about the fundamental implausibility of the task.

FontForge and moving forward

halla — Thu, 07 May 2015 15:32:22 +0000

You missed the point of the discussion, not that I was there, but it was, obviously, not about whether to write web applications in c/c++ or javascript, but whether web applications using javascript can be used to write applications approaching desktop applications in functionality without their codebase becoming just as unwieldingly complex as c/c++ based desktop applications.

I'm pretty sure that if you write a fontforge, a krita, a scribus, a blender, a gimp in javascript/webgl, that you'd end up with something at least as complex and impenetrable, and probably something much worse. If, with the current state of web technology, it can be done at all.

FontForge and moving forward

alankila — Thu, 07 May 2015 14:16:17 +0000

> Øyvind "Pippin" Kolås from GIMP then disagreed strongly with the notion that web-development languages could compete with C and C++. CSS and JavaScript user interfaces rely on levels of abstraction to keep things simple, he said; the core development underneath is just as complex in a "web stack" as it is in native code.

This statement sounds pretty stupid. I hope it had better context, because it's so clearly not true in practice. Firstly, there are very few to none who write web backends in either C or C++. Java and the scripting languages of various kind basically own this space. For web application server side, C and C++ are basically nonstarters.

Secondly, neither C nor C++ can be comfortably used as a development language. JavaScript won over these despite its (subjective) ugliness and steep performance and memory penalty. But these days, it's not that bad. If anything, there is less point today than ever to even consider choosing C or C++ for writing web application frontends.

The quote contains a measure of truth in that the algorithms and datastructures have to be more or less the same in order to solve a similar problem, so writing in JavaScript does not equate to magically waving a wand that eliminates the core of the problem. However, it does eliminate a giant portion of the other kind of complexity which definitely matters.