cmpitg

This is the exact reason why I keep telling myself to slow down all the time, using pen and paper, drafting the problems and solutions before getting my hands dirty, writing them down and writing them bold. One tip I learn from my current CEO is that whenever you feel you're in a heating situation, get yourself a glass of water or coffee, drink it slowly, enjoy and the moment and do nothing. That quiet moment would help you slow things down, recharge your mental energy to do better.

And what does it have anything to do with C++ compared to any other language X? The bare-metal characteristics could be created as a subset of any non-safe non-garbage-collected language.

I agree on the overhead. There are information available only at run-time that could be (and actually has been, in case of interpreter like PicoLisp) used to have better optimization compared to compiled code. It isn't technically faster or slower.

Edited: Correct my bad grammar.

That said, it's a about the implementation not the language itself. The phrase is technically incorrect, right? One could write a compiler that compiles Python or Ruby down to machine language without the interpretation overhead, and not necessarily faster or slower than their original interpreters, or other C/C++ compilers.

I don't think it has anything to do the relationship between the language and its (compiler/interpreter) performance. Besides, the subset of a large number or programming language could be considered bare metal, right? If so, why mentioning bare metal at all?

I don't think it's fair to separate the code and the software itself. I personally don't feel proud of the result of a piece of software if the code is crappy, i.e. spaghetti code, (almost) unreadable, unmaintainable, ...

I think what the author wanted to emphasize was the importance of code clarity, as many of us developers don't actually care. Bad code builds up negative tech debts that somebody has to pay at some point in the future.

Perhaps a bit off-topic but serious question. I don't understand whenever someone says language A is next to bare metal? What does a language have anything to do with bare metal or performance? Isn't it the compiler/interpreter that performance is about?

You might want to combine Geiser with Quack[1] for best result with Scheme. Also, I think it's worth a shot to have a look at the fairly new Racket-mode[2] written by Greg[3]. Geiser + Quack are rather old and for Scheme in general, Racket-mode focuses on and is tightly integrated with Racket.

[1] http://www.neilvandyke.org/quack/ [2] https://github.com/greghendershott/racket-mode [3] http://www.greghendershott.com/

My bad, you're right. I didn't know the documentation section for macro was added recently. It looks pretty Common Lispy. Reader macro looks nice, still at its beginning stage though.

I've been following Hy for a while and it's sad that macros are still part of on-going discussions with no definite plan. It's one of the reason I prefer Scheme-inspired Lisps to Common Lisp. Hy just looks Lispy but it's no where near Lisp without all the macro system.

How do you make sure the correctness of the implementations? Shouldn't there be tests?

Perhaps it should be opt-out?

Well, I personally don't think they do imply the same thing from a user's perspective.

* Google, Facebook, Twitter, ... have become so well-known brands comparing to the new Persona. Normal users could quickly get a sense of what "Sign in with Google/Facebook/Twitter/..." means, but not "Sign in with Persona" means.

* Persona is not a social network while other mentioned brands are or provide a sense of social network. A user might perceive "signing in with <your-favourite-social-network-provider>" as an act of making the site a part of the network; while with Persona it's totally different.

So how about something like "Sign in to ABC with Persona", or "Sign in to ABC with Personal using your email" (more specific)?

Vim counterpart everyone? :-) http://vimcasts.org/

Being a fan of both, a lot of cool things from Vim to could be brought to Emacs workflow.

TRAMP & eshell would help you achieve 100% your local Emacs productivity on remote machines, and 100% smaller (you actually don't need to install anything on remote machine) :-)

Not really. Emacs Lisp is really powerful but not a beautiful language. The APIs are unnatural and sometimes inconsistent to those who come from non-Lisp background. I got to write tons of "immediate" APIs to make things prettier. No namespace-like feature and undocumented APIs (like the notorius CEDET or how to create a new mode...) are real pain.

Not really. Macro makes your washing machine a "generic" one, where you could wash your clothes and your cups (even at the same time) :-).