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.

Yup that's the point of my submission, too bad HN edited my title so it looks like a boring trick. It allows you to transform your code without significant speed loss.

Think of possibilities like

# coding: JIT

or

# coding: inline-C

etc.

The typical way to do that is to reuse the interpreter infrastructure. This hack could be done with the ast:

https://docs.python.org/3.5/library/ast.html#ast.NodeTransfo...

AST is cool, but you have to comply with Python's syntax.

the coding way you can invent any wild syntax.

I guess my first approach to that would not involve overloading the import statement.

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...

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.

I still think that a declarative language is more suitable to describe the UI layout than a DSL built by non-declarative languages.

This no longer works in React 0.12 because they changed the element creation syntax. :\

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/

Wouldn't this be possible with some preprocessing pipeline?

The above is not possible with Riot.

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

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.

No the difference is that GNOME is moving towards a 'product'. Everything is designed to work together, to be consistent everywhere. When you mix and match, you just get medicority because none of them were designed to work together at all. I would not call that even a Unix philosophy, it's just something that happened organically.

Doing what GNOME is doing is hard. Making hard choices on what to keep and what not. Fixing the things in the other parts of the stack instead of band aiding it in their own.

everything is breaking *nix philosophy. systemd is the new hotness and it does everything. That philosophy is nearly dead, insofar as it ever lived.

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

FWIW there is no Go 'dependency' unless you want to build from source.

Admittedly if there's no binary available for your platform then you need to build from source.

Indeed it looks like it's doing something very similar, I didn't know about it. I guess one advantage of massren is that it can work with any text editor. The demo is with vim but, for example, on my machine I've set it up to use Sublime Text.