bubblesocks

I love the way in which this lady broke down the complexity of graph theory into something that anybody can understand. I mean, I understood it.

I didn't go to journalism school but I did take a couple of journalism classes as part of my writing degree. We were taught to be objective and not provocative in my classes.

It could be that since the obituary is behind a paywall, many people don't know what it contains, other than what they've heard second-hand.

I agree. "Something cool" is something that doesn't exist yet and it is really hard to find tutorials on those.

Just curious... Does spacemacs only offer Vim keybindings, or does it support Vim macros as well?

I disagree. In Python, the PEP8 standard is to use snake case for variables and function names. Classes should appear in this format: ClassName. Downey uses the class style for functions because, according to him, he feels it would be too inconvenient to do it the right way. This is a lazy cop-out. If you're writing a book targeting the Python community you should adhere to the Python PEP8 standards out of respect for your readers, if nothing else. The parent poster poses a valid question and it most definitely adds to the conversation because it calls into question the author's respect for his audience.

How is what Downey did any different from me writing a book and stating that correct spelling, grammar, and editing would be too inconvenient for me, so I'm just going to type whatever I feel like and that should be OK, because I addressed my lack of quality and attention to detail during my introduction?

By the way. Thanks for commenting.

You bring up a good point when you talk of introverts vs. extroverts. I cannot see extroverts being happy working remotely. They seem to need the human interaction offered in the office. Personally, I'm an introvert. I don't like being around other people and find their presence irritating and unwelcome when I'm trying to get something done. For me, working remotely really IS the one true way. I cannot even relate to the author of the article's sense of loneliness. That certainly isn't true for everyone though. Rather than dictating one or the other, companies should be flexible and embrace both, I think, in order to get the most out of all their employees.

I'm not sure why you were down-voted. This is a valid point and as a college professor and author, I'm sure Downey would appreciate any feedback that would make his book better.

It's nice to add Pages to the list of word processors with Latex support.

A lot of fake news is propagated on April 1st each year, particularly in the tech industry, so there is justifiable reason to view April 1st announcements with a bit of skepticism.

I'd prefer talent and scotch on a cheap Yamaha any day.

Probably. You can fix that by standing taller though.

Amusing observation. Having had 10, 15, 20, and 100-year-old scotch, I must admit, I couldn't really tell the difference, other than price. Yeah, they tasted a bit different, but so do Aberfeldy and Ardbeg. I wouldn't say one is any better than the other though; unless you really like the smokey taste of old pianos, then Ardbeg is definitely the best.

Not sure why you're getting down-voted. Development tools look pretty much the same as they did in 2000, languages all feel quite similar, and quantum computing still isn't ubiquitous. We are, indeed, still using Vim though, and quite happily, I might add.

My first distro was Slackware, and I bought it in 1995 as well. Mine came with a Unix book from O'Reilly. The only thing I remember about the book was a quote at the top of one of the chapters, "Dyslexics of the world, untie!"

I too used elvis for quite a while, until someone at the bank I worked for at the time introduced me to Vim. I've never met Bram, but I always feel a depth of appreciation when I see his name pop up in the editor window.

I just picked up this book on writing Vim plugins and scripts:

https://pragprog.com/book/bkviml/the-viml-primer

It has been good so far.

I found this book quite helpful in leveling up my Vim skills:

https://pragprog.com/book/dnvim2/practical-vim-second-editio...

I can also vouch for the Vim + tmux combination. PragProg has an excellent book on tmux too:

https://pragprog.com/book/bhtmux2/tmux-2

I recently finished a Linux course at school, part of which was focused on Vim. I got points taken away for using gg to jump to the top of a document and G to jump to the bottom. My professor said neither option would work. While I think it is reasonable to expect professors to know what they're talking about, it is fairly common that they don't.

I can vouch for Haskell Programming, but I haven't read the other book. Thanks for the recommendation.

I agree with the author that Haskell's unfamiliar syntax and functional constructs are why it hasn't taken over the world. I also think that Haskell's syntax and functional constructs are precisely why it should though. I also like the fact that Haskell isn't a mega-corp-owned technology, but rather grown by intelligent engineers to do intelligent things in intelligent ways.

I'm not the greatest Haskell programmer, but I love it. I recommend learning the basics of Haskell, if you haven't yet. Doing so improved my code in other languages quite a bit, so it was worth studying for that reason alone.

I found the information in the book The Subtle Art of Not Giving a Fuck, by Mark Manson, to be quite useful in overcoming adversity.

While the title is a bit on the nose, Manson's premise is basically that we need to identify what is important in our life, and then eliminate our worrying about all the trivial things we run into every day.

For me, this was my family and religion (yes, religion). I realized that as long as my wife and kids were there, and I had someplace to dump my personal issues (religion), my job really didn't matter much, since my skills are transferable elsewhere. I didn't quit my job, but I certainly don't rank it in the top-ten important things to worry about, like I used to.

Seeing as my job is about 90% of the adversity I face in life, just making that mental change resulted in a tremendous amount of joy and satisfaction.

Exactly! I switched careers by doing nothing more than studying in my local library, and then applying for jobs once I felt I was ready to interview.

The money myth is just something managers tell themselves to justify low wages. Money IS why we work. Yes, other factors are important, but I can't pay my mortgage or feed my family on company foosball tables and all-you-can-drink coffee.

I personally prefer to pull that type of functionality out into a private function. I think it makes the code easier to read.

Lisp is awesome, but I think you're doing it a disservice by comparing it to XML, which is a technology that was derived straight from Satan's bottom. Lisp is elegant. XML, not so much.

I've tried cutting sugar, and various other diets before, but they all got to be too time consuming and irritating for me. What did work for me was simply tracking my calories using Under Armour's My Fitness Pal website. The site is easy to use, and I quickly discovered that drinking a soda and eating a bag of chips left me starving at the end of the day, whereas eating grains and vegetables didn't. Just by counting calories, I naturally gravitated to healthier foods. I lost about 45 pounds too.

I'm not trying to diminish anything the author said. I think eating healthier foods is a worthy goal. I only share my experience in case others, like me, find adhering to prescribed diets and digging through ingredient lists too difficult, and want something a bit easier.

I agree that this is an excellent article. I also agree that the situation you spoke to happens all too often. I recently worked on the backend API for a mobile app. Because the company wanted it done in a month, they said "no tests!" Now that they've released, they want me to go back and crowbar a bunch of tests into place. I can guarantee the next push they have for a release will be under "no test" conditions again though.

Regarding solo TDD, it is slow going at first, but you quickly make up that time later on, when you add code, break your tests, and can quickly jump in and fix the issue. Saves your reputation too, I think.

My apologies for leaping to conclusions. As you said, it does happen all too often though. I'll try not to let that taint my judgements in the future.

I find it depends on the project and the localization company. I've used big ones, like Lingotek and LION (or whatever they're called now), but there are still a lot of small companies that do things manually, and for a lot less.