MetaCosm

I agree with you on one part, writing static language INITIAL code, does generally take more time. Depending on the language, it can vary from slightly more in something like Go (where composition is valued over type hierarchies) to a great deal longer in languages that encourage lots of castle building and type relationships.

That said, I have been in industry for over a decade in a half, and the most miserable, hellish experience I ever had was dealing with a large (100k+) non-trivial consumer facing Python application. It was a special type of pain, with novel errors happening in production on a regular basis 4+ years into the project. Refactoring was horrifically risky, and the analysis tooling stack is AWFUL... to the point that when used, it was often outright wrong.

I will gladly give up those cost savings on the leading edge, to have a product I can actually maintain in the long term. I suspect this inability to maintain apps writing in certain dynamic languages is why they have culture bias towards starting over (and being proud of it, "version 2.0, rewritten from scratch!")... which I found a bit shocking at first versus C, which would trend far more toward refactoring.

Built in. "Clip This Page" or "Clip This Selection". It is a single keypress in FireFox for me.

It works for trivial examples, but on anything complex... as you go 3/4 layers down and on longer / more complex functions, I suspect it quickly makes less sense... what about when that function references other stuff in its local context, etc?

That is an amazing demo feature -- but maybe not as useful day to day versus just hoping around functions.

This is exactly what I thought. I set vim to always open in new splits, I often have the same file open in 3 splits for 3 functions. It press 2 keys to open a reference to a function in a new split with me looking at the function.

It seems like the author might not have ever learned how to properly use the existing editors.

> Clearly I'm a biased observer, but I really think people should take steps to archive stuff that is important to them.

I recently converted all my bookmarks to saved copies of the pages in Evernote. This means I have full text search over everything I "bookmark" -- still have the links -- and never lose it regardless of what happens.

In this process, I was shocked at the number of 404s I encountered from relatively recent (last 18 months) bookmarks.

Evernote is a bit of a wreck, but so far the combination of decent copy of page, browser plugins, tags, search, accessibility (phone clients, web client, some native clients) have made it my best option.

Forever on Firefox because of tree-style tabs.

Couldn't anyone choose to create a mirror on Github and do the busy work of shuttling patches back and forth? If the accessibility is important to them, can't they independently solve this issue?

Furthermore, if this is as important as implied, wouldn't that Github repo become an important source of progress for the project, without infringing in any way on Eric's desire to NOT use (or depend on) Github?

What astounds me -- I think -- is his honesty. He overstates and overestimates his value... but... he wrote it as it is.

I read his account and think he is a goddamn idiot... basically a self-indulgent, petulant child. I think it shows a profound disconnect with reality, he legitimately thought that if he told the story... people would be on his side.

I am deeply curious about his mental state... he considers himself victimize, he considers disclaimers meaningful, he really can't understand why people would take offense at his shallow, low value wrapper trading off the names and content of other people.

Yeah... getting caught out of evil mode can be scary... WHAT DO I PRESS TO LEAVE... CTRL-F... dafuq?

Vim has great plugins -- but expanding it is often best left to experts. I have a pet theory that part of the reason for the high quality of many vim plugins is the horrors of writing them (and of course, tpope). Most Vim users are simple, "off the shelf" users -- they use plugins, but they don't WRITE plugins and they often don't radically change the environment (it still feels like vim, as expected). Vim is a good editor that works great with other tools.

Emacs is more -- of its own things -- lots of people write little bits of elisp to do their bidding, and the "plugins" can completely reshape the editor into an IRC client... a mail client... a media player ... a connection to spotify ... etc. It is a wild crazy world powered by elisp.

That is a handful of firms offering that, and some are tiny. W&C is legendary and like 200 people out of a single office... they grew to 200 people in 45 years -- do the math. These firms are hiring the absolute best... heck, if we keep an exclusive list like that, I bet with stock options software developers crush lawyers -- if we only care about the top sub 1% .. with some of the crazy stock adjusted packages at Google, MS, Amazon ... excluding the crazy start-ups.

Actually, I think I have used a clone of Lusty on the Vim side and it worked nicely. Getting tags support working would be nice as well -- I really like the global tags option in CtrlP (I got this function name somewhere in an open file, take me there).

When I spent a few weeks learning Emacs -- I had to filter out EmacsWiki because it lied to me so many times. :(

Working on code that only makes sense against production data... our current "small" dataset is 20TB, our real one is going to land about 150TB. These datasets are a pain to get locally, and a pain to maintain. Way easier to just have an account on an attached box you can use from anywhere.

Another perk of it is using tmux and having a consistent environment you can tap into from work, home, the road, etc.

Vim defenders will also tell you to use search. Also, why would even Emacs fans recommended corded combos over single keypresses? Give my pinky a break man!

Fast proper fuzzy-find completion on files, buffers and tags that works across multiple platforms and even on files not in source control. In Vim I have it bound to <leader>f, <leader>b, <leader>t -- on my multiple trips over to Emacs land -- I have tried lots of ways to get the equivalent working and always come up short.

Craftsmen and tools. It is an age old story, you grow to trust and understand a tool. Programmers and text editors are an extreme example, because programmers often spend 30+ hours a week using a single too, their editor.

Vim and Emacs have survived because they are "fit for a purpose"... they are really good at editing text! Emacs has a niche in expandability. You can always twist Emacs to do your bidding... and it has a culture of tinkers. Vim has much more of a culture of users, people who want to edit text rather that toy with their editor.

These editors have roots in the 70s and are still kicking -- that isn't some random accident, that is because the fundamental act of editing text hasn't change too much.

1. Well -- unless I misunderstand, they use STM to emulate a GIL (while actually letting stuff be done concurrently). Which means that it will still be a bit of a hodgepodge messy disaster.

2. I can't speak for Dropbox, but I worked in a shop that bet their future on Python -- and we spent a good bit of effort looking at PyPy ... it was a nightmare if anything went wrong -- a horrific impossible to debug mess.

3. Yep, I added Python to my "won't work on" list of languages (with Cobol, Progress and MUMPS).

The fact that the money seems to be being spread around seems to be working well for the project.

Change 6 months to 6 days -- and agreed. Go has a 50 page SPEC -- the language fits in your head.

Exactly -- I worked on IMAP related nonsense for about 18 months -- it is a special, broken type of hell.

Dependently typed programming already rocks my world -- but not my job.

I enjoy Haskell.... as a hobby. Whenever I am playing with it -- I distinctly understand that "it" is the point. The focus is squarely on the language and the programmers. I absolutely think this has a place, and I am delighted it exists. I remember the ... purity of my first little chess engine I wrote in it -- how it itched the OCD spot in my brain so perfectly, it made me exceptionally happy.

That said, when I am programming "in the wild"... the language is almost never the point. The application is the point, the library is the point, the problem domain is the point, the user is the point. Cleverness matters little, often what needs to be done is obvious and tedious. The biggest problems tend to be maintenance in every sense of the word... how to you maintain this if you are successful (multiple data centers, dozens of employees). How do you avoid rewriting everything at each major growth spike.

This means I use boring dependable imperative languages for what I bet my business (start-up) and future on -- and I spend my hobby time using far sexy functional languages... but I don't confuse my love for them with thinking they are a good fit for my business.

To be fair, "babel" isn't really a unique emacs term. It had a meanings outside of emacs, and a movie... and multiple albums... and a book... and the open babel chemical project... and the python internationalization library...

Maybe it was confusing already?

Yep. Asking a developer about style/formatting is an amazing filter if you have a lot of candidates... the answers I am looking for include "the language / platform standard", "the overwhelming most popular standard". The answers I have gotten have been nothing short of insane at times. I had a guy explain to me for almost 25 minutes why HIS system is UNIVERSALLY applicable to our code base, from C and C++ (multi platform) to Python to Makefiles...

The arguments against Soylent that compare it to some perfect diet are just obnoxious and disingenuous. McDonalds feeds 68+ million human beings A DAY... just McDonalds.

If there is a solution that is convenient, simple, healthier cost-effective replacement for fast food calories, I am all for it.

You are 100% right on unparalleled flexibility. Why limit your self to one set of flow control operators when you can have two! Also, lets make one break out of another one at any point of exception! The flexibility is endless!

You are 100% right, it is terrifyingly flexible. There is a reason exceptions as flow control is considered an anti-pattern.

I wouldn't say "more reliable" -- I would say "easier to reason about". Errors are just another returned variable, nothing more, nothing less. Go doesn't encourage tracking two independent flow control sets -- one for exception flow, and one for normal program flow. I have seen all sorts of complex nastiness created via the multiple flow control sets in Java.

I write server code the runs for long periods of time, the amount of times I want to blow up and get a stack trace is exceptional low, only when continuing to run is more harmful than having the service completely down.

As for just wanting it to blow up -- just ignore the error handling, it will blow up. Instead of putting the error in a variable, just throw it away using _ ... and the next dependent thing will blow up. Not very elegant, but it will remove all the boilerplate you don't like, and it will crash hard like you do like... alternatively write a crashOnError(err error) function and call that passing in error -- and all it has to do is if (err != nil) { panic(err) }

I love (don't use, but love) editors like this -- that push at some boundaries and rather than having that push be some "side feature" or "addon" -- is the core part of the editor.

An older editor that I thought was amazing was Acme (http://en.wikipedia.org/wiki/Acme_%28text_editor%29) -- the famous plan 9 editor. http://youtu.be/dP1xVpMPn8M is a Tour of Acme, some really cool features are built into it. Any text is a command.

http://labix.org/gopkg.in is a rather good solution for distributing libraries with transitive dependencies. It requires critical mass for it to really take off, but the level of effort is extremely low for implementation (make a branch on github, don't break it... done!). I think this low level of effort is really important, as I have been able to simply poke authors of my favorite packages for support, and had it in a day or so.

As for an internal project (non-distributed) I think vendoring is the solution everyone who is sane has always been using, why would you risk you project on a random guy deciding he wants to delete his github account.

Still, IMHO, nice to split them out -- so they don't stomp on each other or do other silly things. Same reason it is nice (but not memory efficient) that Chrome does this... individual processes are safe and sane.