b6fan

Lazarus / LCL. It is cross-platform, lightweight (more lightweight than Qt since it uses native widgets), can be used for commercial purpose, and is fast to compile.

The limitation is mainly that the widgets are limited. For example, comctl32.dll hasn't got new widgets since Windows xp. So depending on your needs, it might fit perfectly, or lack some features and that's going to be painful.

The Pascal language will feel outdated. But you don't have to do everything using it. You can, for example, write the non-UI logic in other languages and then glue them using dynamic libraries.

I sometimes find LaTeX too verbose. And sometimes it's very tricky to do seemingly trivial things.

For web development, HTML, CSS, Javascript can be written directly, or generated by some other template language like haml, slim, coffeescript, sass, stylus, etc.

I believe the same applies to TeX. Although AFAIK there aren't template languages targeting TeX, treating TeX as "dynamic HTML" or just use your favorite language to generate TeX sometimes turns out to be much cleaner and more maintainable code. The generated TeX is not human-read friendly, but just works.

The `codecs.register` approach is interesting. I hope Ruby has something similar. Unfortunately I could not find such thing in Ruby.

I think both the old and new diff worth a look. Maybe showing them using different colors is a good idea.

Phabricator uses light colors to show changes not introduced in this patch but a rebase against master [1]. The experience is pretty good if the workflow is to always fast-forward and the patch author does rebase. Changes introduced by other people are in light green and red. Duplicated-line issue can be obviously seen.

[1]: https://secure.phabricator.com/book/phabricator/article/diff...

Actually I am using this syntax with React 0.12.1. React.DOM just work as expected. For custom components, prepend "React.createClass" with "React.createFactory". See http://jsfiddle.net/saxr8gLd/

One thing I like React is it is plain javascript.

Therefore I can use coffeescript to describe the component:

    {div, p, ul, li} = React.DOM
    ...
    render: ->
      div className: 'foo',
        p className: 'bar', 'blabla'
        p className: 'bar', 'blabla'
        ul className: 'somelist',
          @state.items.map (x) -> li key: x.id, x.content
            

If Riot.js uses a custom parser, it may not be able to do this.

This may be why concerning of testing in ruby, dhh supports native Test::Unit instead of Cucumber [1].

1. http://cukes.info

Yeah. pacman is a killer feature. I always install pacapt [1] before dealing packages elsewhere.

[1] https://github.com/icy/pacapt

Does this mean people live in Autarctica could live longer but think slower?

I think GNOME3 is breaking *nix philosophy: do one thing and do it well; to be highly configurable. You have freedom to use compiz in GNOME2, but not in 3. There are a lot of good GTK2 themes but gitg and d-feet have hard-coded styles so only default GNOME3 theme will look sane. Super+p is somewhat hard-coded and you cannot customize it ... and there are more annoying issues. I am happy that mate-desktop is still alive.

There is a vim plugin: rename.vim [1] which basically do the same job but without go dependency.

[1] http://www.vim.org/scripts/script.php?script_id=1721

Or use dlopen, dlsym to get the real function.

Maybe Facebook could try something like Flattr: one user has, say, 30 likes per months for pages. If he or she likes 3000 pages in one month, then each like counts as only 0.01 normal like.

I have used ptrace and cgroup (in an online judge system). The cgroup way feels more correct and stable while ptrace feels a hack. The usage of ptrace and SIGSTOP in upstart looks pretty ugly to me.

The Ruby way is:

  1. common (not all) things are simple / elegant.
  2. Advanced things are doable, usually require a slightly more complex syntax.

For example, Ruby allows one "block" (anonymous function) per method. Why not 2 or more blocks? Because Matz has studied common lisp (likely, maybe something else) standard library and noticed that in ~97% (maybe not exact number) cases, one anonymous function is enough. But you can use more anonymous functions using a different syntax.

And here is the same case. People call methods much more often than to get the method. Therefore Ruby makes it default to call the method, but not stop you from getting the method object. It's just unfair to say Ruby cannot do these things.

The Ruby examples are unfair.

Ruby intentionally makes parenthesis optional. So `do_something` is `do_something()`.

For the first example,

  - method_as_fun = o.my-method
  - method_as_fun(5) # not reached
  + method_as_fun = o.method(:my_method)
  + method_as_fun.call(5) # or method_as_fun[5]

And for the lexical scope thing,

  def f(x)
    g = ->y {x + y}
    g[2]
  end
  f(2)

Or, explicitly use class variables,

  def f(x)
    @x = x
    def g(y); @x + y; end
    g(2)
  end
  f(2)

I write another one for ruby, check out samples here: https://github.com/quark-zju/easysh

Although its functions are a subset of sh for python. It has many synatactic sugars, makes full use of ruby Enumerable, and does lazy-execute.

Seems not working with cruby 1.9.3 ? SyntaxError: .../rubysh-0.0.2/lib/rubysh/subprocess/parallel_io.rb:77: Invalid next

I noticed that hamlet.rb is based on slim. Why not use slim directly?