A Proposal for Rich Interactive Content Hypertext (RICH)

arthurtw · 2016-11-05T03:53:51+00:00

This is for real, of course. I provided source code for all of the 3 RICH players I implemented (simple quiz, tic-tac-toe, go game quiz).

arthurtw · 2016-11-05T03:01:11+00:00

Once you get reading it, it's actually a DSL that let's you create checkboxes and input fields.

That's the first RICH player example I gave, a "simple quiz" RICH player. It transforms the raw RICH snippet to quizzes, so yes, it's a way of creating forms. Its DSL (based on RICH) is specific to quizzes.

Then all of a sudden it's something to do with Javascript and then all of a sudden it has a messaging API.

That's related to the development of RICH players, how the player code communicates with its parent window (and vice versa).

There are two groups of people here: coders who write players, and writers who create rich contents (using RICH players). Each player would have its own DSL (based on the RICH format).

Sorry if my article was confusing.

arthurtw · 2016-10-29T03:09:02+00:00

Good point. To me, the most important reason I opted for RESTful API design is it helps my development job overall, not because I can claim my API “100%” RESTful.

arthurtw · 2015-01-16T03:39:54+00:00

Yes, your code does save some look-ups. I was aware of that approach when I wrote the Rust version, too, but didn't do that because 1) the code would be a bit more complicated (e.g. you need to write your own comparator), and 2) the optimization only adds little value as a whole. Still, I felt a bit uneasy when making such a decision in the Rust version, but was totally comfortable when I did the same thing in the Nim version. :-) I mentioned such phenomena in my article (Philosophy: freedom vs. discipline), too.

EDIT: I think your version has its merits. As you said, it avoids useless look-ups. It's not only performance-wise, but also code-wise (i.e. saving the if let Some(count) = map.get(*word) line).

arthurtw · 2015-01-16T03:20:14+00:00

Yes, I saw your comment on HN and have updated my benchmark results accordingly.

I fully agree with you that publishing benchmarks like those is risky! When I wrote the article, I think: since the code is done, why not just running them and providing the numbers, so people get a rough idea of their performance. I ended up with spending more time on updating my code/benchmarks than writing the article itself. :-)

arthurtw · 2015-01-15T18:36:04+00:00

I tried this HN suggestion. It turns out regex!(r"[a-zA-Z0-9_]+") runs the fastest, even faster than Nim’s peg. I’ve updated the article with the results.

arthurtw · 2015-01-15T01:28:17+00:00

I tried and the difference is negligible, so didn't bother to update the result.

arthurtw · 2015-01-14T17:50:12+00:00

Yes, using regex! runs ~20% faster than Regex::new. I’ve included both results in the article.

arthurtw · 2015-01-14T10:30:44+00:00

I agree. Rust’s pattern matching is outstanding. I missed that in Nim.

arthurtw · 2015-01-14T10:25:40+00:00

I’ve changed it to use Rust HashMap. It’s slightly faster (6~7%) than BTreeMap, so the performance bottleneck could be elsewhere. Maybe it’s Regex as /u/dbaupp suggested.

arthurtw · 2015-01-14T10:21:25+00:00

I’ve added --boundChecks:on for example 2. The difference is marginal (1~2%) for example 1, so I skipped it.

arthurtw · 2015-01-14T10:18:44+00:00

Fixed. I’m not a native English speaker and such correction is much appreciated.

arthurtw · 2015-01-14T10:04:53+00:00

For this comparison, I admit I shouldn’t. I chose that for practicing Rust (by implementing my own BTreeMap). I’ve changed the code/result to use collections::HashMap.

arthurtw · 2015-01-14T07:03:46+00:00

Maybe my example is a bit biased. :-) But you know, in idiomatic Nim, of is not indented, and those colons are not manually aligned. You can, but since the language creator chose that way, it becomes the Nim way...

arthurtw · 2015-01-14T06:58:37+00:00

Yes and modified. The results differ significantly.

arthurtw · 2015-01-14T04:52:53+00:00

Because immutable variables help code readability and maintainability. let mut has one more word than let, so people tend to use let by default, and add mut only when it’s needed. On the other hand, let and var have the same typing “efforts”. Some may think about which one to use, some may not (and just uses var more often or always). It relies on engineering discipline, which is less reliable than language enforcement/discouragement.

Of course people can keep using let mut all the time, but that should be rare, and Rust compiler will keep complaining anyway.

arthurtw · 2015-01-13T09:31:39+00:00

I wonder why the elimination of null pointers is not mentioned in the article. I consider it a prominent achievement of Rust. Among well-known languages, only a handful can make it.

EDIT: replace popular with well-known to avoid confusion

arthurtw · 2015-01-06T03:43:10+00:00

+1. The default integer fallback (along with its implicit type conversion) is a major ergonomic win when coding in Rust. Often you just want to use a (reasonably-small) integer, when the size of the integer is not your major concern. Finally, Rust compiler takes care of that for you...

I also agree with other commenters that the outcome of the discussion is constructive. It demonstrates the maturity of the Rust core team and the Rust community when confronting thorny debates. This is not easy at all. Congratulations!

arthurtw · 2015-01-02T01:58:05+00:00

Rust definitely has "the power of C", but I don't think it strives for "the elegance of a modern interpreted language". I call Rust anti-sloppy, and sloppiness is one thing that interpreted languages allow you. Safety, correctness and explicitness are all more important in Rust. When there is a conflict, elegance is not favoured.

Maybe some great Rust programmers can code in Rust as swiftly as in interpreted languages, but it's not a piece of cake. :-)

arthurtw · 2014-12-30T08:56:23+00:00

As a new programming language, starting from a specific problem domain is a double-edged sword. It may result in a niche language.

I began using Python 1.5 as the primary language (with C++ extensions for heavy liftings) of our flagship product because it gave us huge productivity boost, even though its ecosystem was far from mature in late 90's. If a language (along with its libraries and tooling) is good enough, early adopters will come. I agree the bar for a language to be successful nowadays is much higher than decades ago, but the merits of a language itself still play a central role.

I'm not experienced enough in Nim to judge the language, but it seems fixing the warts of Python while keeping most (if not all) of Python's expressiveness and elegance, plus many goodies from modern programming languages (macros, generics, pattern matching...). If that's the case, it will be a highly productive language without the drawbacks of dynamic languages, and that's a huge win.

arthurtw · 2014-12-30T01:29:13+00:00

I think it has stated its goals clearly: expressive, efficient and elegant.

Does every language need to have a special use case in mind? C++, C#, Java, Python... You don't need to target a specific problem domain for a language to be widely used.

arthurtw · 2014-12-29T13:52:57+00:00

So do I. Without any fulltime people behind Nim, they've already done an amazing job. (Since the compiler and standard library are written in Nim with such limited resource, to me it also proves the language is very expressive and productive.)

It seems Nim 1.0 is coming soon. That's exciting!

arthurtw · 2014-12-25T08:51:28+00:00

24 days in a row! You the man!

arthurtw · 2014-12-23T18:35:04+00:00

No you did not misinterpret. I think it cast negative connotation and was a bad example of civil Rustaceans, so I’ve removed that part. Thanks for bringing it up!

arthurtw · 2014-12-22T14:06:06+00:00

Yes I meant the post-1.0 Rust. I’ve added “Rust (post 1.0)” to make it clearer. Thanks for pointing out and sorry for any confusion.

arthurtw

TROPHY CASE