LVC – Linear Verified Compiler - <AUTHOR> https://www.ps.uni-saarland.de/~sdschn/LVC.html <comment><USER2> Saarland University seems to be putting out great research in the last few years. The author is advised by S. Hack ([http://compilers.cs.uni- saarland.de/people/hack/publications...](http://compilers.cs.uni- saarland.de/people/hack/publications.pp)). Saarland also has Andreas Zeller ( [https://www.st.cs.uni-saarland.de/zeller/](https://www.st.cs.uni- saarland.de/zeller/)) who wrote 'Why Programs Fail' which I gift to junior developers. There's also the great Fuzzing Book ([https://www.fuzzingbook.org](https://www.fuzzingbook.org)) in progress. Probably a great place to do CS research right now.

<comment><USER3> I was just reading the editorial reviews for the "Why Programs Fail" [0] that you recommended and couldn't agree more with this statement:

"Today every computer program written is also debugged, but debugging is not a widely studied or taught skill. Few books beyond this one present a systematic approach to finding and fixing programming errors." \--James Larus, Microsoft Research

This was something my school's CS program severely lacked.

[0] [https://www.amazon.com/Why-Programs-Fail-Systematic- Debuggin...](https://www.amazon.com/Why-Programs-Fail-Systematic-Debugging- ebook-dp-B0092L8LCW/dp/B0092L8LCW/)

</comment></comment><comment><USER4> Yes, single assignment is functional programming.[1] But without all the cool notational problems.

[1] [https://www.cs.princeton.edu/~appel/papers/ssafun.pdf](https://www.cs.princeton.edu/~appel/papers/ssafun.pdf)

<comment><USER5> There've been some follow-up papers to Appel's _Compiling with Continuations_ over the years. The most recent one, _Compiling with Contiuations, or Without? Whatever._ [1] is pretty interesting — they show a direct-style functional IR with 2nd-class continuations, and describe how it can be used for both traditional SSA-style optimizations, as well as some optimizations that more naturally operate on CPS-style IR.

[1]: [https://www.cs.purdue.edu/homes/rompf/papers/cong- preprint20...](https://www.cs.purdue.edu/homes/rompf/papers/cong- preprint201811.pdf)</comment></comment>


Family swamped by avalanche of bills after son's death: 'It's continuous' - <AUTHOR> https://www.theguardian.com/us-news/2019/jun/04/us-health-insurance-healthcare-child-death-charged-thousands <comment><USER2> This may seem macabre, but the services rendered did not in fact save the child's life, then why should they pay for said services that ultimately failed to deliver?</comment>


LocalForage: Offline Storage, Improved - <AUTHOR> https://hacks.mozilla.org/2014/02/localforage-offline-storage-improved/ <comment><USER2> Not sure how this compares to the myriad other similar libraries that have been around for a while, like Lawnchair? That would have made a good section in this blog post.

But the real problem with offline storage is that Apple refuses to support IndexedDB, when every other browser vendor implemented it years ago (even IE!). My question is, why? I can think of three potential answers:

1\. They just don't care about the web. (But in that case, why raise such a stink about not letting other web browsers run on iOS?)

2\. They are incompetent. (But in that case, how have they made so much other great software? And IndexedDB isn't even very complicated. Even if it was, they could just copy Mozilla's or Google's open source implementation.)

3\. It's a conspiracy to cripple HTML5 apps and encourage people to write native apps. (I don't like conspiracy theories, but it's hard to come up with a better explanation than this...)

<comment><USER3> Or: it's low on the roadmap and it's not something that markets well, since the non-dev user doesn't care about IndexedDB support.

Occam's Razor applies here.

<comment><USER2> I guess that's possible, but then why did Google, Microsoft, and Mozilla all decide it was important enough to implement years ago? It's not like this is some controversial political thing like DRM, or some huge technical challenge that would require a lot of resources - it's just a simple database API. Even if they ignored the multiple existing open source implementations, they could build their own very easily. And they've had years to do it.

Incidentally, I've been trying to make non-dev users care. I wrote a semi- popular HTML5 game that runs everywhere except iOS because it uses IndexedDB. When people complain that it doesn't run on iOS, I implore them to direct their complaints at Apple for not supporting IndexedDB. AFAIK nobody has even gotten a response.

<comment><USER4> I agree that the absence of IndexedDB is a little weird, but I don't know if it's "crippling," just annoying. Safari has supported Web SQL for a long time. While it was (rightly) abandoned by W3C because it was attempting to standardize SQLite as an implementation, there is a polyfill ([https://github.com/axemclion/IndexedDBShim](https://github.com/axemclion/IndexedDBShim)) that implements IndexedDB semantics on top of Web SQL. It looks like localForage also supports Safari using Web SQL.

<comment><USER2> The polyfills (there is another by Facebook in addition to the one you linked) are slow and buggy (look at all the open issues, or try using it in a non- trivial project yourself). Web SQL in Safari is also slow (check any performance benchmark) and buggy (see the huge bugs introduced in the most recent version of Safari). So the truth is probably closer to "crippling" than just "annoying". Who is going to go through the trouble of working around all the polyfill and browser bugs, only to be rewarded with horrible performance? Not many people except those with simple needs. Making something complex? Better put it in the App Store.

Libraries like localForage are great if you're doing very simple stuff. But if you need to use slightly more advanced DB features (indexes, transactions, etc), they don't work. IndexedDB, while not a panacea, does generally work for that stuff... except for Safari :)

</comment></comment></comment></comment></comment><comment><USER5> Mozilla was involved with the standardization of the LocalStorage and IndexedDB APIs. If this is the API that users really want — and I'd argue that it is — I wish they would've realized it sooner and lobbied to standardize a simple, asynchronous, variable type key value store.

<comment><USER2> One major goal for IndexedDB was to be low-level enough that people could build the APIs they want on top of it. This type of design is popular these days due to some older standards like appcache and localstorage which have nice, simple, usable APIs but are not flexible enough to handle many real world situations.

(Now, one could argue that IndexedDB is still not low-level enough... but that's a separate problem.)

<comment><USER6> > One major goal for IndexedDB was to be low-level enough that people could > build the APIs they want on top of it.

IndexedDB is neither low or high level, it's just worthless. I'd like to be able to use HTML APIs WITHOUT a framework. At least WebSQL was usefull. One could build an IndexedDB on the top of it if one wanted,or use it directly, but you cant build WebSQL on top of IndexedDB.

Thank you Mozilla.

<comment><USER2> It's a bit much to call IndexedDB "worthless". You can asynchronously store/access large amounts of indexed JS objects. That's a huge win, despite the fact that I agree the IndexedDB API is not ideal.

 _you cant build WebSQL on top of IndexedDB._

I don't see why you couldn't build Web SQL on top of IndexedDB. Nobody's done it and it would be a ton of work, but it should be possible.

 _I 'd like to be able to use HTML APIs WITHOUT a framework._

You can use the IndexedDB API directly. It's not that hard. It's just overkill for something like localForage that is only doing very simple data storage and retrieval.

 _Thank you Mozilla._

It wasn't just Mozilla. Microsoft deserves much of the credit/blame, since they were also in the anti-Web SQL and pro-IndexedDB camp. And Google quickly came to agree with them, even though they had implemented Web SQL previously.

</comment></comment></comment></comment><comment><USER7> Nice! Good to see others tackling this sort of problem.

I'm actually working on a similar project, but it instead uses the file system abstraction for storing and retrieving data. It's called BrowserFS [0], and it emulates the Node file system API.

I haven't written an IndexedDB or WebSQL backend yet, because I've been focusing on the architecture and other problems recently. But I'd appreciate any comments people have on it. :)

[0] [https://github.com/jvilk/BrowserFS](https://github.com/jvilk/BrowserFS)

</comment><comment><USER8> Interesting, this could even help to integrate same codebase using the chrome.storage API on Chrome Apps:

[http://developer.chrome.com/extensions/storage.html](http://developer.chrome.com/extensions/storage.html)

Still, it carries the normal limitation of key-value only storage in the sense that you have to keep track of your keys yourself. No queries are possible.

</comment><comment><USER9> It would be great to have a low-level binding to LevelDB in the browser for developers who want to implement their own indexing and transactions. I have been working with WebSQL and IndexedDB ever since they launched and performance is often an order of magnitude slower due to design decisions taken by browser vendors.

<comment><USER10> Very true. I have been doing some wacky custom DB stuff using Python and LevelDB (for very strange indexing requirements, and using the Basho variant of LevelDB) and it's superbly fast, predictable and easy to use, at least until you get to about 100m k/v pairs!

The horrible binary manipulation capabilities in JavaScript is a serious headache for any kind of serious networking or storage interfacing.

</comment></comment><comment><USER11> While localStorage is blocking it offers A LOT better performance than IndexedDB, at least based on my experience.

There's also some benchmarks here: [http://jsperf.com/indexeddb-vs- localstorage/6](http://jsperf.com/indexeddb-vs-localstorage/6)

<comment><USER12> That's because most localStorage implementations are in-memory. Chrome and FF (as far as I know) have to synchronously load all your localStorage data from disk at page load and then flush changes to disk later. This increases your page load times dramatically if the user has a spinning rust hard drive. (This is part of why localStorage has a ~2.5mb cap in Chrome and a ~5mb cap in Firefox.)

So, in practice you're benchmarking actual I/O vs in-memory data structure updates.</comment></comment>


Having Uncomfortable Conversations About Money - <AUTHOR> http://blog.quoteroller.com/2013/09/19/uncomfortable-conversations-about-money/

<comment><USER2> A lot of good points, but this one I'm not sure I can agree with:

 _" Back yourself into a coner - Nothing makes asking for more money easier than not having an alternative."_

Maybe that makes the conversation more urgent and steels your nerves. I could see how there'd be a psychological benefit there. But the best way to build leverage in a negotiation is to have a strong hand before starting the negotiation. This concept is known in behavioral sciences and business theory as BATNA ("best alternative to a negotiated agreement"). In layman's terms, it's your Plans B, C, D, etc. The stronger your backup options, the better your position in the discussion.

This correlates with the market-based theory discussed in the article ("If you can find someone to pay you X, you're worth X"). You increase your chances of getting X if you can get Backup Y as close to X as possible.

Glassdoor is extremely helpful for leveling a lot of the information asymmetries that push a money discussion in the employer's or client's favor. But Glassdoor isn't the same as leverage. Just because a typical Role X makes $Y doesn't mean _you_ are entitled to that...unless you convince the market that you should be, i.e., by getting someone to give you that much (or more).

<comment><USER3> If one of your biggest obstacles to financial success is personal discomfort with the social/emotional piece, being cornered is an excellent experience for getting over it. I am going through that currently. It really is helping me change things about myself I have long been frustrated with but could not figure out how to change. So it kind of depends, I guess.

<comment><USER2> I totally get that, and I respect that line of thinking. It's a psychological/motivational thing. But if you've got no other options, keep that in mind. You are playing at the table with a weaker hand, and you run the risk that the other side will call your bluff.

At the end of the day, whatever works best for someone works best for him. I would just caution against _intentionally_ backing oneself into a corner. Sometimes we do our best with our backs against the wall, but that doesn't mean we should seek to put ourselves in that position.

<comment><USER3> There are always other options. I suggest you watch "Kingdom of Heaven" if you have not yet seen it. Painfully bad movie, totally worth watching all the way through one time in order to see the negotiation scene in context.

I have negotiation skills in spades. But I tend to be a doormat. Being under the gun has been extremely uncomfortable but is getting results in ways that simply studying the subject intellectually was not. Getting over some things has been terribly difficult for me.

My situation is complicated and a comment or two on HN won't convey it. If we had more time to talk, we might find we agree more than it seems.

Peace.

</comment></comment></comment></comment><comment><USER4>
        > I've done plenty of business with friends. In fact, the
        > majority of my business has been with friends or
        > acquaintances. Some of those friends even stopped using
        > me when I raised rates over the years and they're still
        > my friends. I'm having drinks with one of them tonight,
        > in fact.

I'm happy that doing business with your friends worked out in this case, but in general I'd tend to stay away from it. Nothing can ruin a great friendship like money.

<comment><USER5> It is hard to build sales and marketing channels when you're just starting up. That is why majority of us start with closest circles - friends, family, friends of friends and friends of family... In many cases doing business with friends is inevitably.

</comment></comment><comment><USER6> Why should conversations about compensation be uncomfortable at all? You are not begging for a handout, and are likely not imposing any undue hardship on the other side. It might be personal for you; for them, it might be just a line item.

<comment><USER7> Because many employers, from the moment they hire you, endeavour to create the illusion they are giving you a hand-out, that they are oh-so-generous and that you're lucky to have a job. When I tell colleagues that it's a fair and equal exchange of their compensation and your labour, I get blank stares.

</comment></comment><comment><USER8> Some really good reminders in here - thanks for posting</comment>


A Call for Browser Supported 3d Image Formats - <AUTHOR> http://linearlyindependent.com/post/472949731/a-call-for-a-browser-supported-3d-image-format

<comment><AUTHOR> Are MPO and JPS mature formats? I'm not sure they are the best choice, but given 3d is getting ready for the mobile space, it seems clear we will want some sort of standard for 3d images, and eventually videos, soon.</comment>


Founder Stories - <AUTHOR> http://www.danecjensen.com/2012/10/19/founder-stories.html

<comment><AUTHOR> Like I said in the article any feedback is appreciated please post feedback in these comments.</comment>


Scientists create 'designer yeast' in major step toward synthetic life - <AUTHOR> https://www.washingtonpost.com/news/speaking-of-science/wp/2017/03/09/scientists-create-designer-yeast-in-major-step-toward-synthetic-life/ <comment><USER2> Here's the paper cited by the article ...

[http://science.sciencemag.org/content/355/6329/1040](http://science.sciencemag.org/content/355/6329/1040)

Abstract:

We describe complete design of a synthetic eukaryotic genome, Sc2.0, a highly modified Saccharomyces cerevisiae genome reduced in size by nearly 8%, with 1.1 megabases of the synthetic genome deleted, inserted, or altered. Sc2.0 chromosome design was implemented with BioStudio, an open-source framework developed for eukaryotic genome design, which coordinates design modifications from nucleotide to genome scales and enforces version control to systematically track edits. To achieve complete Sc2.0 genome synthesis, individual synthetic chromosomes built by Sc2.0 Consortium teams around the world will be consolidated into a single strain by "endoreduplication intercross." Chemically synthesized genomes like Sc2.0 are fully customizable and allow experimentalists to ask otherwise intractable questions about chromosome structure, function, and evolution with a bottom-up design strategy.

<comment><USER3> Actually, it's 7 papers co-published in Science simultaneously.

The others are:

Synthesis, debugging, and effects of synthetic chromosome consolidation: synVI and beyond: [http://science.sciencemag.org/content/355/6329/eaaf4831](http://science.sciencemag.org/content/355/6329/eaaf4831)

"Perfect" designer chromosome V and behavior of a ring derivative: [http://science.sciencemag.org/content/355/6329/eaaf4704](http://science.sciencemag.org/content/355/6329/eaaf4704)

Deep functional analysis of synII, a 770-kilobase synthetic yeast chromosome: [http://science.sciencemag.org/content/355/6329/eaaf4791](http://science.sciencemag.org/content/355/6329/eaaf4791)

Bug mapping and fitness testing of chemically synthesized chromosome X: [http://science.sciencemag.org/content/355/6329/eaaf4706](http://science.sciencemag.org/content/355/6329/eaaf4706)

Engineering the ribosomal DNA in a megabase synthetic chromosome: [http://science.sciencemag.org/content/355/6329/eaaf3981](http://science.sciencemag.org/content/355/6329/eaaf3981)

3D organization of synthetic and scrambled chromosomes: [http://science.sciencemag.org/content/355/6329/eaaf4597](http://science.sciencemag.org/content/355/6329/eaaf4597)

Along with an introduction: [http://science.sciencemag.org/content/355/6329/1038](http://science.sciencemag.org/content/355/6329/1038)

and perspective: [http://science.sciencemag.org/content/355/6329/1024](http://science.sciencemag.org/content/355/6329/1024)

<comment><USER4> Are there any good resources to start in this field for non-biology majors? It seems they have now full end-to-end simulation so one can program yeast and even test it out at some extent with nothing but just a computer.

<comment><USER3> They don't have that at all. This was a Herculean effort over 5 years with very few actual changes to the natural genome. I don't mean to make it seem not impressive (it is ambitious and impressive); it's that we are so far away from an end to end simulation of anything even orders of magnitude simpler than yeast.

</comment></comment></comment></comment><comment><USER5> With the pace of advancements in gene editing and the availability of biology maker-spaces, I expect that we're soon going to find out that the "3D printed guns" issue of hobbyist biology will be simple cells like yeast modified to synthesize illegal drugs. It may not be as efficient as industrial chemistry could be, but it only takes one entity producing such a cell before it will become a mainstay of illicit bathtubs everywhere. Every time I see an article like this I wonder why it hasn't already happened. We already have yeast that produce the active ingredients in cannabis, and I suspect the only reason nobody cares is because many people just grow plants anyway. How will this be handled once we can go a step further and make completely new genes that can make artificial drugs like LSD?

<comment><USER6> Relevant: [http://www.npr.org/sections/thesalt/2013/09/17/223345977/aut...](http://www.npr.org/sections/thesalt/2013/09/17/223345977/auto- brewery-syndrome-apparently-you-can-make-beer-in-your-gut)

> The patient had an infection with Saccharomyces cerevisiae, Cordell says. So > when he ate or drank a bunch of starch — a bagel, pasta or even a soda — the > yeast fermented the sugars into ethanol, and he would get drunk. > Essentially, he was brewing beer in his own gut. Cordell and McCarthy > reported the case of "auto-brewery syndrome" a few months ago in the > International Journal of Clinical Medicine.

<comment><USER7> Getting infected with an illicit-chemical producing variant of that might be quite inconvenient!

<comment><USER8> Just being infected with that, and being pulled over with a high BAC would be too. Clever way to get someone out of the way too, without killing them. Who would believe a drunk driver vs. their blood test results and a video of them obviously intoxicated?

</comment></comment></comment></comment><comment><USER9> But what does the beer it makes taste like?

<comment><USER10> Sadly they have started with bakers yeast so any beer will probably taste bad.

<comment><USER11> "In the past, there were two types of beer yeast: ale yeast (the "top- fermenting" type, Saccharomyces cerevisiae) and lager yeast (the "bottom- fermenting" type, Saccharomyces uvarum, formerly known as Saccharomyces carlsbergensis). Today, as a result of recent reclassification of Saccharomyces species, both ale and lager yeast strains are considered to be members of S. cerevisiae. "

[https://www.beeradvocate.com/beer/101/yeast/](https://www.beeradvocate.com/beer/101/yeast/)

</comment></comment></comment><comment><USER12> Does the new genome contain overlapping genes? Natural Yeast have a number of overlapping genes. It would be really neat, since you can make synthetic chromosomes, to compare the effects of making genes overlap. This has implications (various RNA surveillance mechanisms can interfact with pairs of mRNAs that hybridize).

</comment><comment><USER13> Do you want zombies? Because this is how you get zombies. ;-)

<comment><USER13> Really with the downvotes??? Here let me try again in a more proper HN way:

[collegiate voice]

This is an exciting development and a massive step forward for the scientific community. However one must be careful to examine the ethical implications of such research as it can have unintended consequences. Creating new lifeforms without taking the time to fully understand the impact it would have on our fragile ecosystem could potentially be disastrous.

[/end collegiate voice]

In other words, we might make zombies. Geez downvoters, lighten up.</comment></comment>


Ask HN: As a DIY investor, what tools do you use to manage your portfolio? - <AUTHOR> If you're managing your own investments (taxable, 401k, IRA, etc), what tools do you use to stay on top of your investments?<p>A "tool" can be as simple as a periodic calendar reminder to "rebalance portfolio". <comment><USER2> Portfolio Visualizer [https://www.portfoliovisualizer.com/](https://www.portfoliovisualizer.com/) is good for backtesting investment strategies.

<comment><AUTHOR> What do you like the most about it? What's missing?</comment></comment>


Programming Languages: History and Future (1972) [pdf] - <AUTHOR> http://www.csee.umbc.edu/courses/undergraduate/CMSC331/resources/papers/sammet1972.pdf <comment><USER2> Most important quote.

Programming languages---using any definition-- are the primary means by which a person communicates with a computer. Viewed from that perspective, all future developments should be aimed at making this communication easier and more cost effective. Each person doing research and development feels he has the answer. The real truth seems to be that there is no single best way for people to communicate with a computer, and hence no single solution. Thus there will be no single language useful to everyone.

Sad that this likely will not see the front page, a lot of interesting things in this pdf, thank you.</comment>


We published a book in "Pay as you want" model. Here are the results. - <AUTHOR> http://blog.sitarska.com/post/87602057063/experiment-results-book-in-a-pay-as-you-want-model

<comment><USER2> What do you think about crowd-funding further development of existing open source project? Did something like this happen?

Pay as you want for books is good idea, as long as you know what to expect. Good job on summarizing the outcome :)

<comment><USER3> The problem is, you never know how much people will pay in this model. I wonder what are the factors that would increase average price.

<comment><AUTHOR> there should be some additional mechanism, if you pay more than average than you get X

<comment><USER4> So it's Humble Bundle style, right? It could work if you have more than 1 item. [https://www.humblebundle.com/](https://www.humblebundle.com/)

</comment></comment></comment></comment><comment><USER5> > _Note that Hacker News traffic is included in "(direct) / (none)", they hide > it somehow._

Why does HN hide the referer url? (How?)

<comment><USER6> If a website using https (HN) points to a website not using https (the blog), then the referer is hidden. So it's not something HN is doing specifically, it's just because one is https and the other is not.

More info here: [http://en.wikipedia.org/wiki/HTTP_referer](http://en.wikipedia.org/wiki/HTTP_referer)</comment></comment>


New Electronic Scrabble Game - <AUTHOR> http://www.wired.com/geekdad/2010/09/scrabble-flash-is-a-b-l-a-s-t/

<comment><AUTHOR> I just saw a commercial for this game, and I got interested when I started thinking about how the architecture might work. How might the tiles communicate between each other? They all have to tell each other what letter is on the other tiles, then one of them (or all of them?) decides if its a valid word.</comment>


Essential Cheat Sheets for Machine Learning and Deep Learning Engineers - <AUTHOR> https://medium.com/@kailashahirwar/essential-cheat-sheets-for-machine-learning-and-deep-learning-researchers-efb6a8ebd2e5 <comment><USER2> Where are the perl based cheat sheets...

I kid.</comment>


Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping - <AUTHOR> https://www.npmjs.com/package/aws-cost-saver <comment><AUTHOR> Just published a tiny CLI utility to save some bucks on AWS development environment while I'm not really working.

[https://github.com/aramalipoor/aws-cost- saver](https://github.com/aramalipoor/aws-cost-saver)

The idea is to stop/shutdown any resources (such as EC2 instances, RDS databases, ECS tasks, etc.) when you're done for the day and restore them back up next time you continue.

Currently it's in a very early stage, a hobby side-project :)

Ideally I'm thinking to provide a CloudFormation template or terraform config for example, to provision a scheduled Lambda with predefined "start of work" and "end of work" times and have it automatically do that for you.

I'd like to know if something like this would be useful for you too and what do you think about it?

<comment><USER2> Im very interested in learning about your work flows, like how does a typical day look like? I do all my work on a local pc and only use servers for production. So im interesting in how/why you use the cloud stack

<comment><USER3> How do you test or develop against cloud resources like ECS using a local PC?

<comment><USER2> I would like to know how and why you use resources like ECS. et.al. There reason why I do not like to use cloud/serverless is because I find debugging is much easier on a local computer or a server I have root/metal/hardware access to. And that serverless have a very slow iteration rate, it can take minutes just to run a simple test that would be instant locally.

The reason I'm asking is because on my free time I'm developing a cloud IDE but I'm having trouble understanding the market. I beleave cloud dev services will be a huge market. But I don't understand how people use it practically in their dev setup.

<comment><USER4> I use it (and similar tech) because I don't want to think about individual boxes at scale, rather instances of an application. Containers + orchestration allow me to develop and test in the exact same environment my apps will be in in prod, which allows me to mostly remove the hardware and OS as a variable that could affect its runtime behavior. They also make it easier to spin up a local copy of my services' runtime environments for testing, as I need only describe it in a simple yaml file and spin it up w/ docker-compose in a single command.

I found at first testing was arduous, but you learn to adapt. In my case, I increased the amount of debug logs my application throws (can also be useful to enable in prod when trying to hunt down an issue) and invested time in creating unit/integration tests that run outside of the container/lambda to validate specific paths/features. Worst case there's always docker exec and language-specific debugging when I want to dig in manually.

I'm still pretty skeptical about serverless (I mostly use it for cloud- specific automation), but as much as people like to shit on Docker it's been pretty great to use from an ops perspective. I interpret most negativity about it as curmudgeonly reactions to the admittedly excessive hype in the technologies, with some fairly pedantic complaints about the (imo minimal) overhead such technologies incur thrown in as an uninteresting justification.

</comment></comment></comment></comment></comment><comment><USER5> aws has a instance scheduler as a solution that achieves some of this objectives

[https://aws.amazon.com/solutions/implementations/instance- sc...](https://aws.amazon.com/solutions/implementations/instance-scheduler/)

<comment><AUTHOR> That's a good alternative for EC2 / RDS instances but when it comes to other cases like DynamoDB provisioned throughput or Kinesis shards or ElastiCache it wouldn't help much

</comment></comment><comment><USER6> Is it common to have a dev environment on AWS? I just use it for production and maybe staging. Staging is scheduled to run during office hours.

<comment><USER7> I guess depends on the size of the company. How else would you constantly test integrations between different services? Especially if some services can't be easily ran on the laptop.

Also if you add terraform/ansible and all that jazz to the table. Where else? Infra team needs dev/stage as well.

<comment><USER8> Localstack can get you pretty far.

</comment></comment></comment><comment><USER9> It looks like a nice tool doing it's job well :-) I'd also consider services like provisioned DynamoDB tables or Kinesis streams in this context because there you can also waste lots of money depending on your setup. For example, you could decrease the provisioned read/write capacity for a DynamoDB table or decrease the shards of a Kinesis stream over night. I've discussed these topics in a blog post, in the context of a CloudFormation stack, if anyone's interested: [https://www.sebastianhesse.de/2018/04/22/shut-down- cloudform...](https://www.sebastianhesse.de/2018/04/22/shut-down- cloudformation-stack-resources-over-night-using-aws-lambda/)

<comment><AUTHOR> Thanks for sharing your experience. Both of them sounds like great ideas, will add them to ToDo right away :)

</comment></comment><comment><USER10> Great addition to pile of scripts to take with you on problem solving missions. I have something similar, but written in terraform. WRT AWS cost visibility, I find it is usually faster to spin up and grab most of the relevant information using mlabouardy's [komiser]([https://github.com/mlabouardy/komiser](https://github.com/mlabouardy/komiser)) than to try and standardize yourself. Not shilling, just a tool I like.

</comment><comment><USER11> If you're using IaC and have it set up in a CI/CD pipeline, you could also achieve the same by having a cronjob set a flag outside of work hours, and use conditionals in your IaC based on the value of that flag (e.g., for Terraform `count = var.scale_down ? 0 : 1`)

<comment><AUTHOR> There were a few reasons why I couldn't use IaC:

1) Using conditionals to achieve this usually makes terraform unmanageable specially if your terraform is complex.

2) Sometimes you'd need to do more complex steps to save some money, for example in case of ElastiCache you'd need to snapshot/delete/create.

3) Using terraform in a Lambda to schedule this was not straightforward (in my current company) so I gave up making it work :D

</comment></comment><comment><USER12> While this only works with instances, I usually just cron the shutdown command with a future time. Nice thing is, if working late I give myself a couple hour window to cancel shutdown on any nodes I'm still using.

echo "0 22,0,2,4,6,8,10 * * * /sbin/shutdown +115" > /etc/cron.d/autoshutdown

I'm all for a better tool, just wanted to point out a builtin alternative.

</comment><comment><USER13> Any similar for other cloud services like azure, gcp and especially digital ocean

</comment><comment><USER14> looks cool. If anyone is interested, I made something similar a while back (web app instead of cli): [https://github.com/gbolo/aws-power- toggle](https://github.com/gbolo/aws-power-toggle)

</comment><comment><USER15> This is awesome - Does it work cross-region?

+1 to add in:

\- Elasticache instances \- Load balancers associated with ECS clusters

</comment><comment><USER16> That is what Kind is for.

</comment><comment><USER17> Because my favorite place for AWS credentials is some random NPM module?

<comment><USER18> This works like every other AWS CLI tool - it uses your shells AWS credentials dir or ENV vars

</comment></comment><comment><USER19> I find it price gouging that AWS doesn't already implement this on their own within their pricing structure and that you need a 3rd party tooling to do this.

<comment><USER20> They earn more money by not doing this.

<comment><USER21> The downside of shutting down the resources is that there may be none available anymore in that sizing or pricing when you want to start them up again. I suppose they also don't want to risk being liable for that.</comment></comment></comment>


Intel Rolls 14nm Broadwell in Vegas - <AUTHOR> http://www.eetimes.com/document.asp?doc_id=1325057 <comment><USER3> Jesus. When I worked at Intel, .18 to ~.14 MICRON chips were a big deal. (I think that was the jump then... I am a bit foggy, this was in 1998).

I also recall when I was there having conversations and hearing the questions of "Why don't we just stack multiple processors on a single die?" \-- and how some people thought that was going to be impossible.

<comment><USER4> When I started building computers in '04, I remember the old Newcastle AMDs were 130nm, and the new Hotness was Venice/San Diego 90nm. Now we have 32nm in Haswell, 14nm in Broadwell.

<comment><USER5> This is interesting:

[http://www.bit-tech.net/news/hardware/2012/05/14/intel- proce...](http://www.bit-tech.net/news/hardware/2012/05/14/intel-process- roadmap/1)

</comment></comment></comment><comment><USER6> Notable: these are all just low-power ultrabook range CPUs.

If you want high-power Broadwell CPUs that go into regular faster notebooks (e.g. Macbook Pro, workstation Thinkpads, all gaming notebooks like MSI, Gigabyte, Asus, Clevo, Alienware, etc), you will need to wait at least till mid 2015.

Basically if you do anything non-trivial with CPU (gaming, rendering, compiling), Broadwell CPUs launched so far are not interesting for you, you will need to resort to old Haswell CPUs.

Intel's marketing managed to downplay this pretty well, most of news didn't really notice this.

\</comment><comment>

Source: Intel Broadwell presentation slides

[http://www.notebookcheck.net/fileadmin/Notebooks/Sonstiges/P...](http://www.notebookcheck.net/fileadmin/Notebooks/Sonstiges/Prozessoren/Broadwell_ULV/5th_Gen_Core_LLPT_Final_16Dec2014_PDF- page-004.jpg)

<comment><USER7> My Macbook Pro Retina 13" comes with a 28 W TDP processor which the slides you cite promise at end of Jan.

[http://ark.intel.com/products/75990/Intel- Core-i5-4258U-Proc...](http://ark.intel.com/products/75990/Intel- Core-i5-4258U-Processor-3M-Cache-up-to-2_90-GHz)

Hopeful to see rMBR 13" soon thereafter.

</comment></comment><comment><USER8> > "2/3 of the processor are dedicated for graphics"

That makes me sad. I would like to see a desktop version that instead puts in more cores or whatever as when combined with any video card (GTX XXX or AMD XXX) 2/3 of the processor are simply not used!

<comment><USER9> Not me; I want a thin retina laptop with long battery life...

<comment><USER10> As long as "retina" means "high pixel density" and not necessarily an Apple product, how about the new Lenovo Thinkpad X1 Carbon? [http://arstechnica.com/gadgets/2015/01/hands-on-new- lenovo-t...](http://arstechnica.com/gadgets/2015/01/hands-on-new-lenovo- thinkpad-x1-carbon-reignites-my-love-thinkpad-love-affair/)

<comment><USER11> Oh wow, Lenovo finally got out of its own way. At least from a quick surface glance. I spent a few days looking for something for me to just type on. I gave up and got a new SSD for my X201 last night. But the heat is unmanageable (under warranty I had the fan replaced thrice, to no real avail).

Still, one can hope this is a good sign and I'll be able to get a non-suck, non-Apple, 12 inch machine this year.

Edit: Apparently it's a max of 8GB RAM which would be a huge sacrifice. FFS, Lenovo.

<comment><USER10> I'm still rocking my T410. With 8 GB of RAM and an SSD, it does quite well. However, I really want to get a lighter laptop with a high-DPI screen. Before Lenovo's recent announcements (the T-450 also looks quite good) I wasn't sure where to turn when my T410 no longer sufficed.

<comment><USER11> Yeah the older ThinkPads are perfect if they just had a tech refresh. The screens are useless, and the limit on CPU and RAM in them hurts, too.

I'm really annoyed. I went on to Lenovo right now to buy the new X1 - <USER2> news I've had all year. I go to select RAM, and it's capped at 8GB. Just to run my two dev machines I need at least 12GB (full Linux GUI + full Windows, dev setup in both). Pretty lame. (The new X250 is also capped at 8GB, doesn't offer a high-def screen. The new T450 fixes RAM, but apparently has only 1600x900 pixel screen, much less a proper 3K display. The T550 offers high-def screens, but has an _offset keyboard_. It's like Lenovo is just flailing around because there's no competition. ffs.)

I might get it anyways as my secondary in-bed laptop just to jot notes and code on, but at $3000 ($3388 with 3yr warranty) properly kitted, I expect more.

<comment><USER10> I've found 8GB to be acceptable for me, but it does seem strange that they would cap it at 8GB. And at this point, they should be offering high-DPI screens as an option on _every_ ThinkPad model (or at least the T, X, and W series). My $400 phone should not have a better-looking screen than my $2000 laptop.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> While on average CPU's do not represent significant power draw anymore, it is worthwhile to remember the "on average" part. As soon as you load your system battery life drops down by at least half, so any kind of efficiency gains are awesome.

</comment><comment><USER13> If you're already on Haswell, or even IVB, Broadwell isn't worth it. I'd wait for Skylake.

<comment><USER14> Why?

<comment><USER15> Skylake will be able to run external 5K displays, more (smaller) CPUs will be quad cores and it has support for DDR4. By then you'll also get a lot more machines with the new USB Type C connector.

</comment></comment></comment><comment><USER16> So is this a breakthrough in transistor size? Why or why not? How did they overcome all the challenges they were saying in the 2000's that they would have to reach this size?

<comment><USER17> Billions of dollars and thousands of PhDs. Considering that 14 nm is about a year late, clearly there are some challenges left to fix.

</comment></comment><comment><USER18> Will Intel build any NUCs with these chips? I was thinking of buying one with the current generation and would rather wait if they have any plans.

<comment><USER13> > While the new Core line has modest improvements in productivity, Intel hopes > battery life gains will encourage users to buy new devices, said Karen > Regis, director of notebook roadmap and strategy for Intel's PC Client > Group.

It says right in the article that it doesn't have major improvements in performance (like all of its chips since SNB), so why would it matter that you have Broadwell in a NUC?

Intel is focusing on reducing power with all of its new generations for the most part, and is only slightly increasing GPU performance with each new generation (20 percent or so, for the same class of chips).

<comment><USER18> Lower power would be nice for the energy savings and reduced fan noise. I'd like to get one of these as a Linux home server.

</comment></comment></comment><comment><USER19> I was hoping for deeper tech dirt and architecture commentary from eetimes. This article didn't say anything I didn't read in Ars Technica yesterday. :-/

</comment><comment><USER20> No HEVC decoding?

<comment><USER21> From AnandTech's coverage ([http://anandtech.com/show/8814/intel-releases- broadwell-u-ne...](http://anandtech.com/show/8814/intel-releases-broadwell-u- new-skus-up-to-48-eus-and-iris-6100/2)):

Support for HEVC is also present in terms of a combined (hybrid) hardware and software solution, just as it was on Core-M. Intel stated that as parts of the H.264 algorithm are near if not identical to those of the H.265, with a small tweak to the hardware it can be used for both. This is still not an all- encompassing hardware acceleration, but it does aim at some parts of the codec. I would speculate that if a full section of the silicon could be made for complete hardware acceleration, it might eat into certain power budgets.

<comment><USER20> Thanks. I'm not qualified to discuss this, but Apple did include hardware decoding for HEVC on the iPhone 6, and they're extremely power-conscious.

</comment></comment></comment><comment><USER22> Everything is coming together for a new Macbook Air. I'm expecting a super thin Macbook Air with a radical new design. They are removing the Fn keys from keyboard to make it simpler. This is what I heard from someone inside.

<comment><USER23> > They are removing the Fn keys

Well that's going to be fun.

<comment><USER24> Maybe pressing fn+1 would produce a F1?

<comment><USER25> They would be removing the Fn key, which would mean the F-keys would go as well. So just brightness, volume, etc., along the top.

You could probably still switch to the old F-keys in Keyboard Settings though.

<comment><USER26> So then, there will be software you can't run without attaching an external keyboard?

<comment><USER23> Yeah. Well technically you'll be able to run it, and probably use it via menus and buttons, but some keyboard shortcuts won't be accessible.

Mostly cross-platform stuff I'd expect, can't think of any OSX software using function keys, but some of Firefox's developer tools are bound on F-keys for instance.</comment></comment></comment></comment></comment></comment>


Why GNU Emacs? - <AUTHOR> http://elephly.net/posts/2016-02-14-ilovefs-emacs.html <comment><USER2> Many Emacs advocates fall for the trap of apologizing for why Emacs is not Unixy, as though it were some sort of defect. They should celebrate the fact that Emacs doesn't come from the Unix tradition of small, composable tools and "doing only one thing and doing it well". It is rooted in the ambitious work of the MIT Artificial Intelligence lab, the LISP programming language, and the single user MIT Lisp Machine that essentially booted up to a LISP REPL.

<comment><USER3> Unix has a big flaw: through the pipes pass random data. It's up to the receivers to interpret it. Lisp gives you the possibility to easily structure your data and pass it around, plus the ability to pass programs around. Other than this, the unix way and the lisp way are nearly parallel, though in lisp "command line utility" is called a "procedure".

<comment><USER4> So, JSON passed between a bunch of Javascript things from Github means that the browser is the new EMACS ?

<comment><USER5> The article more or less makes this precise comparison.

"Do everything in Emacs" isn't really so different from "Do everything in the browser."

Arguably, modern browsers are more heavyweight and complex at that. They certainly eat a hell of a lot more RAM than my Emacs ever does.

<comment><USER6> True, But they also do much more things than Emacs does.

<comment><USER7> If you really believe that you haven't understood emacs at all.

<comment><USER5> Ironically, the only thing Emacs can't seem to do these days is be a browser. ;)

<comment><USER8> The xwidget_mvp branch has been merged into the emacs master branch about a month ago.

It allows you to embed GTK widgets INSIDE an emacs buffer, effectively allowing one to create actual GUIs inside of emacs.

This also allows you to embed a full webkit-based browser (with javascript support!) right into emacs, and use it like a regular browser.

Just clone the emacs repo, build it with gtk3 and xwidget support, and run 'M-x xwidget-webkit-browse-url' to get a full-fledged browser with proper rendering right inside emacs.

[https://www.emacswiki.org/pics/static/EmacsXembedScreenshot....](https://www.emacswiki.org/pics/static/EmacsXembedScreenshot.png)

<comment><USER9> There's only one question that remains to be answered. Why?

<comment><USER3> Browsing through an environment that's integrated nicely, deeply configurable, and completely programmable. What else would you want as a programmer and an pc user?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I enjoyed this; I moved from Vim to Emacs a couple of years ago and indeed the most important thing to recognise is this:

Emacs _does_ have a great text editor, and it's Vim!

With evil-mode you can use all the Vim bindings you're used to (including sed commands with ':'), but with the added benefits (and drawbacks) of Emacs!

I've also found that fiddling with my .emacs is really fun, fiddling with .vimrc was usually quite frustrating.

<comment><USER11> I tried this, but found that the issue is that most major modes use a "grammar" that make sense to native-emacs user, and ended up fighting with them.

<comment><USER12> After a day of editing on Emacs on a MacBook Pro, my hands felt like they were going to shrink and stick into a contorted state.

So I tried Evil which does work fairly well for editing text. In some ways it's better than Vim--the :substitute is really nice as it shows all pending substitutions in the buffer. But as you said, some major modes work with Evil and others don't, so I'm never sure what I'm going to get.

Ironically a modern laptop is well-suited for Vim, as vi worked on primitive terminals--laptop keyboards don't have a lot of keys and they are poorly positioned. The MIT lab for Emacs probably had nice keyboards.

So these days I am back to Vim and have been finding plugins to make up for the things that Emacs has that Vim doesn't. vim-dispatch is a decent replacement for M-x compile.

<comment><USER13> >The MIT lab for Emacs probably had nice keyboards.

Oh you have no idea...

[https://en.wikipedia.org/wiki/Space_cadet_keyboard](https://en.wikipedia.org/wiki/Space_cadet_keyboard)

<comment><USER14> It was so ahead of its time, it even had Like and Dislike keys on the RHS!

<comment><USER15> The LIKE key... priceless :)

</comment></comment></comment></comment></comment></comment><comment> jake-low Once, I used Emacs. All I did with it was play in the land of elisp. I never got any real work done.

Then, a passionate friend converted me to Vim. I only ever used it to do battle with my .vimrc. I never got any real work done.

Now, I use Atom. Click a button, install a feature. No more distractions.

I wish it were faster though; I can never get any real work done.

<comment><USER16> This doesn't make sense. You used to be someone easily distracted by yak shaving, is what it reads like.

Installing features in Emacs is not exactly tough, either. I do think you can get distracted by the sea of things you can install. Probably no different from the new toys in the realm.

<comment><USER17> Makes sense to me. I love both emacs and vim, but I agree there are too many yaks to be shaved to get them in a usable state.

<comment><USER16> I question the lack of shaving in the next application. Seems there is always something that could have been done a different way.

</comment></comment></comment></comment><comment><USER18> > _Sometimes people who use computers ask me why I would use something as > "bloated" as Emacs for text editing. Usually they remark that Emacs is a > hold-over from a by-gone era, much too large compared to editors like "vi", > and that they are quite content using a variant of vi or some Notepad-like > editor._

This feels like a very out of date sentiment to me. I know a decade ago this was the perception, and well know the "good operating system, bad text editor" joke you'd see on Slashdot or whatever.

But nowadays while Emacs clocks in at a dozen MB, it's still smaller than what I'd consider "light weight" editors like ST3 and Atom, and minuscule compared to the likes of IntelliJ, Eclipse, or XCode.

<comment><USER19> I guess bloated means compared to 'instant startup'. Vi starts always instantaneously, whereas Emacs can have a noticeable delay, even if it's only a fraction of a second. Hence the perception that is bloated. Of course compared to the others you mention is quite fast.

<comment><USER3> Running emacs like "$ emacs <text-file>" is like booting a computer, editing a single text file, and then "$ shutdown -h now".

<comment><USER20> Not really. GNU Emacs is no operating system. It has no network stack, no framebuffer interface, no file system implementation, etc. It provides interfaces to those. As such it does not initialize hardware and it starts no OS during startup.

GNU Emacs starts a Lisp environment, loads a memory dump, runs various initialization code, etc.

<comment><USER3> Oh, thankfully someone told me that emacs does not have framebuffers and filesystems. It doesn't have wireless drivers too!

My grandparent comment was an analogy, for illustrating how it's not the optimal way to use emacs, as a command line program invoked to operate on one file and then closed and reopened.

<comment><USER20> The analogy wasn't that great. Booting a machine has nothing to do with typical uses of Emacs. There are many applications which are long running and are working on multiple documents - it's just another mode of working with an application.

One can use GNU Emacs just fine as an editor which starts and quits on a single file. 'emacs -q' starts in a few milliseconds on my Mac. I use single file edits with Emacs on the terminal all the time. Though I usually also have a long running instance of Emacs - but then it is used as a Common Lisp IDE, not just as an editor.

Then one can setup an Emacs editor server.

Or start the Editor and leave it running. This is no different from, say, a CAD program or any typical application on the Mac, where usually a single instance of an application keeps running, editing multiple documents.

</comment></comment></comment></comment></comment></comment><comment><USER21> If you are a newcomer and look at Emacs what you see at first glance on the outside is basically total crap. The default behavior of Emacs distinguishes itself by the complete lack of sanity. Emacs key-bindings are neither ergonomic nor do they make any sense in any way. They are barely consistent across modes, only if you are lucky. They are the way they are because they are old. And old people don't like change. However my experience was, the more I learned the more crap appeared. One layer of crap after the other. At first everything could somehow be fixed with a lot of configuration and scripts. I needed several hundred lines of Lisp code in my init.el just to be able to work normally.

But then the lowest emacs layer of crap appears which can not be fixed. It includes issues like lack of multithreading, elisp being the least capable and at the same time by far slowest lisp dialect. Stuff like the lack of ability to move the cursor off screen. Inherent jumpiness while scrolling which can not be fixed and really strains my eyes. And don't even try to look at the C source, it is the worst historically grown ifdef hell you will ever experience.

And finally there is the community which lacks disposition to unify or work together. It is more like a community of loners where each of his own produces personal "modes" which are inconsistent to use and most of the time conflict which each other. The most important reason for this might be lisp itself. It is inherently hard to read other peoples lisp code. So everybody writes his own.

</comment><comment><USER22> Calling Vim my "editor" is really doing the rest of the programs that actually make up my development environment a huge disservice. Vim might be what I use to edit text, but the rest of "Unix" is my IDE of choice. Being able to tab between an IRC/chat client, my email client, a shell, and an open instance of Vim is a huge advantage for me. So up until recently, I never had a need for Emacs...looking at it as too much of an investment into re-building all the features that are in my shell configuration. That's when I discovered Org Mode.

I love Org Mode. It's become my primary note-taker, todo list, and general idea dump. I've used it to plan out projects for work, tours for my band, and to write down essential things I need to get done each week. Syncing to MobileOrg over Dropbox, and keeping my Org files in a synced documents folder, means that all of my computers have access to the same information at all times. I tried using vim-orgmode for a long time but most of the features that seemed the most useful to me just weren't supported. Why screw around with VimL when I could just download Spacemacs, configure Solarized and Monaco to at least get it looking like Vim, and then use that _just_ for Org Mode? That's what I've been doing, and I have to say I've fallen in love with how fast I could get packages up and running and with how many great features seemed just "built in".

</comment><comment><USER23> ...Click a button, or invoke a command and an empty, unremarkable rectangle appears. Little you know that it is a relic from an age long past...

Emacs to me, first and foremost, is a doorway to another dimension, a place you can escape to from the absolute drudgery of the contemporary software development.

...A relic, yes, but it seems as alive as ever, a dark block inside it, blinking, like a pulse on a medical instrument...

It is also a glimpse into what professional tools might be like, if they were not so obsessed about beginner users. [1]

...You wonder what the hell you should do with it...

[1] I think Erik Naggum kind of nailed it in [http://www.xach.com/naggum/articles/3065048088243385@naggum....](http://email@example.com)

</comment><comment><USER24> What I think is funny is people making fun of me for reading email in Emacs. I use my own filtering system built on top of MH-E, which is layered on top of nmh command line tools. MH-E uses GNUS for MIME handling and I'm able to view HTML messages just fine.

Why I think it's funny: people laugh that I'm using 20-30 year old technology and new tech would serve me better. To each of them I say: I challenge you to an efficiency dual/bet. Pit your system against mine. When I show them actually what I use, they don't take the bet.

Yes, what I'm using was first written almost 30 years ago, but I've tuned the crap out of it (with my own tweaks) and so have others, improving the tools themselves.

The only thing that would make my life easier would be if nmh could use IMAP. There have been many discussions of this, but it's just not a natural fit. I don't know if it will ever be done.

EDIT: typos

<comment><USER25> People often tend to confuse the newer with the better.

</comment></comment><comment><USER26> Apparently, I'm feeling ranty today...

<rant>I've used Vi and Emacs as my primary editor. Now I've moved on to Sublime Text 3. Despite being powerful tools Vi and Emacs have probably harmed the state of Unix text editing. They've kept antiquated UIs from before keyboards were an text editing UIs were standardized. It's kinda sad that MS Dos, Windows and MacOS have all had a plethora of powerful editors with convenient standard user interface meanwhile the Unix world is anchored to Vi and Emacs. It seems like they've managed to starve out a good chunk of innovation on this front.

<comment><USER27> I went from Emacs to Sublime and back to Emacs. The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there.

But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivalents. Things like linters work as expected and there are lot more packages available for niche things. Emacs is subjectively _better_ , even if the UI doesn't feel as platform-native as other editors.

I don't use Emacs because I'm a graybeard afraid to learn something new. I use it because I've tried every new hotness to come along and I've yet to find something as powerful, well-supported, and ubiquitous.

<comment><USER28> The thing is, in this day and age most people don't need their editor to last 100 years. Because of [https://en.wikipedia.org/wiki/IBM_Common_User_Access](https://en.wikipedia.org/wiki/IBM_Common_User_Access) & friends, you can just switch to another editor.

Meanwhile, if you're used to Vi's modal editing or Emacs's elisp, you're basically going to hate the other tools forever if for whatever reason. For example if you need IDE features for your project or the Vim/Emacs extensions for language X are no stable/flexible enough.

<comment><USER29> Once you're past the basic navigation cluster + cut/copy/paste/undo/save (which tend to be more Windows-style, I'd say, than CUA!) every editor is different.

Ctrl+F for Find is a common standard, for example, but it's hit or miss whether this is Ctrl+F for Find (and that's your lot! Find & Replace is something entirely different), Ctrl+F for Find (and you have a checkbox for Replace), Ctrl+F for Find (and you have a checkbox for Replace... and this is how you search across multiple files as well). And there are multiple standards for all of these additional options. Your muscle memory will be useless no matter what you're used to. You're welcome to describe emacs as unusual... but don't assume everything else is a nirvana of UI consistency. The process of "just" switching can be a bit more inconvenient than you might think ;)

<comment><USER30> Do you really use one editor for everything?

When I'm working on Python code, I'm in PyCharm. My C++ work on Windows is in Visual Studio. When I ssh into the Linux machine that serves our in-house documentation to make changes, I'm using vim. On OSX, I use BBEDit most of the time. When I'm writing a letter, I'm usually in Word or Google Docs.

I think if I spent all day every day in one environment, I would get bored.

<comment><USER31> > Do you really use one editor for everything?

Yes, at least whenever possible.

> I think if I spent all day every day in one environment, I would get bored.

The opposite perspective: It's extremely frustrating constantly switching between significantly different environments with different UIs, different hotkeys, subtly different jargon, etc.

<comment><USER30> > It's extremely frustrating constantly switching

Maybe that's the difference. I'm not a productive multitasker. When I have some Python to work on, that's all I'm doing for the next day or two. I'm not jumping from Word to PyCharm to Vim all day.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> Does anyone have an opinion on _Spacemacs_ [0]?

I haven't used it, nor Vim/Emacs. Just came across it during researching the two. _Spacemacs_ appears to have excellent documentation though.

[0] [http://spacemacs.org/](http://spacemacs.org/)

<comment><USER33> I switched from vim to spacemacs a few weeks ago and I don't regret it. The fact that you can run a shell in a buffer, have on the fly syntax checking and so on makes coding much more comfortable and you feel like you're using a full blown ide instead of just a text editor. Would recommend

<comment><USER34> Funny that, I also did the same exact thing this month for org-mode. I never missed Vim.

</comment></comment></comment><comment><USER35> Nowadays the only thing I use outside of Emacs is GNOME Terminal / Google Chrome / bash / screen / ssh. All the rest (including E-Mail) is inside Emacs.

The Emacs/Vim war is a bit silly, because historically they're really not comparable in that way (although vim has gotten larger). Emacs is more of an alternative to GNOME/KDE/Windows/OSX than it is an alternative text editor.

<comment><USER3> "Nowadays the only thing I use outside of Emacs is GNOME Terminal / Google Chrome / bash / screen / ssh. All the rest (including E-Mail) is inside Emacs."

There are ansi-term, shell, and eshell. The first is an actual ansi-term within your emacs, the second is a comint shell, and the third is a shell implemented in elisp. Emacs has frames, and with C-u M-x shell you can open as many new shells as you want. proced is like top/ps aux. So it's time to get rid of gnome terminal and screen :)

<comment><USER36> All of emacs' terminal emulators have been resoundly awful for me. This was probably my biggest disappointment with emacs. I was so looking forward to having the shell be useable from inside emacs, but it's really not.

Now I just use a regular terminal with tmux inside it and emacsclient inside that.

<comment><USER3> Emacs doesn't really have a terminal emulator, and terminal graphics are mostly unusable in emacs. Shell and ansi-term are there for when you cannot avoid some shell-fu. I use it mostly for VCS operations that cannot be done with VC _, and nowadays building Emacs 25 pretests. I use dired instead of ls, proced instead of h?top|ps, but for a sysadmin these are not viable, I understand.

_ I do not use magit because I do not only use git, and VC allows me to use Git, RCS and CVS easily without learning different emacs interfaces for each.

</comment></comment></comment></comment><comment><USER37> Emacs is in one sense the canonical computer program. A "historical landmark" of computing, the internet, and our industry.

It's grown, it's still viable and used heavily. Even if you don't use it, it's sort of the Aristotle of computer programs - we owe it a lot.

</comment><comment><USER38> I'm a Emacs user and use it everyday. I've seen a post like this from time to time. Most of them make sense, and I indeed agree on it. But from my personal experience, I prefer Clion to write C/C++, prefer IntelliJ to write Java. I will not recommend Emacs for these coding job. A modern IDE is doing a much better job. I still love the org-mode of Emacs though.

</comment><comment><USER39> I've been an emacs user for the last year or so. Previously, I'd used Sublime Text, which I think is a fantastic editor. I loved its speed and especially its simplicity -- pretty much everything just works right out of the box, configuration is managed through JSON instead of some obscure imperative language, etc. But ultimately I really needed two things: the ability to use it over SSH, and the ability to run a terminal inside of it. (ST has a third party shell plugin but it's frankly terrible). So much of my work involves either SSHing into a machine to do work, or rapidly alternating between a shell and an editor. The frustration of having to fumble my way through emacs or vim every time I SSH'd into a remote machine, or having to hackily arrange windows side-by-side so that I could get ST next to a terminal, ultimately became too much and I decided to just start using Emacs.

At this point, I'm reasonably proficient at emacs. From the sound of it, I'm nowhere at the level of the author of this article. But at least I'm comfortable with the essentials -- copy/paste, find/replace, nagivation, etc, and I can easily accomplish the two things I missed from ST (though I'm getting increasingly fed up with the shortcomings of ansi-term, and I might just switch to using tmux).

Unfortunately, what I've lost is the simplicity. I find emacs lisp to be a horrible language. I find it ironic that a platform built on a functional language like lisp manages to produce some of the most complex and incomprehensible compositions of state, as different packages interact with each other in a non-deterministic way, or one package will simply hijack the editor and freeze/crash it, or refuse to let you enter input because a plugin can't parse your buffer, etc. Have some weird behavior in your editor? How can you tell which plugin is causing it? No one knows. It's really quite unpleasant at times. Maybe vim would be better, or maybe not, but learning vim would mean a period of being woefully unproductive or frustrated.

It's irritating that the only choices for terminal-based editors are either embarrassingly under-featured (nano, pico, etc) or require a ton of learning to become proficient in (emacs, vim). On the other hand, there are several GUI-based editors which are powerful and easy, but none of them work in a terminal, nor do they provide a terminal emulator of their own. :(

<comment><USER40> I found [http://vim-adventures.com/](http://vim-adventures.com/) (no affiliation) to be the best way to finally learn vim in the sense of actually developing automatic muscle memory. It teaches you how to use vim using a 2d game. It's worlds better than the built in vim tutorial, to say the least. :)

For a really different take on editors+shells, check out acme: [https://www.youtube.com/watch?v=dP1xVpMPn8M](https://www.youtube.com/watch?v=dP1xVpMPn8M)

</comment></comment><comment><USER41> lisp is beautiful. The crown jewels of computer science. getting to spend time with it reminds you that programming can be fun (and profound) while you are being paid to work with some awful drudgery language solving some stupid problem. Being close to lisp, in this way, is like being at the same party as Audrey Hepburn. It reminds you of grace.

<comment><USER25> Joel Moses has been credited with coining the phrase in the 1970s

APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud - it still looks like Lisp.

<comment><USER42> > Lisp is like a ball of mud. Add more and it's still a ball of mud - it still > looks like Lisp.

Such claims are usually made by people who haven't discovered the power of Lisp yet.

[http://www.defmacro.org/ramblings/lisp.html](http://www.defmacro.org/ramblings/lisp.html)

<comment><USER25> Such claims are usually made by people who haven't discovered the beauty of APL yet.

<comment><USER42> APL is actually beautiful. Watch the development of Conways game of life in APL:

[https://www.youtube.com/watch?v=a9xAKttWgP4](https://www.youtube.com/watch?v=a9xAKttWgP4)

</comment></comment></comment></comment></comment><comment><USER43> I find it interesting that we as programmers love to base a lot of our technical decisions on hard data, but somehow the choice of editors seems immune to this. Has anyone ever done an analysis of the actual objective benefits of these editors? I got suckered into the 'religion' of vi and have spent countless hours learning it to a fairly high level of proficiency over the years. I don't think I've ever recovered all the time I spent. Maybe it requires a special use case. Most of my time is spent outside of the editor - reading specs/docs/code, debugging/tracing/analyzing existing code, or just thinking about code.

<comment><AUTHOR> > _Most of my time is spent outside of the editor - reading specs /docs/code, > debugging/tracing/analyzing existing code, or just thinking about code._

Most of my time is spent _inside_ the "editor" (Emacs). Reading docs is in Emacs, debugging is in Emacs, too. Thinking about code is assisted by `M-x zone`... :)

To be able to stay in the same application in which I can use my home-grown features on _everything_ that can be mapped to text buffers is an advantage; a subjective advantage, maybe. I don't need to switch contexts as often any more, and my brain thanks me for that.

I grew up on vim and got very comfortable with it, but elisp, interacting with inferior processes, and the overflowing kitchen sink in general slowly replaced my combination of vim+xmonad+tmux+terminal.

<comment><USER43> Ah, well I guess you're the lucky one :)

For me, most of the material that I need to reference is PDFs/Slides from talks/Books/Web pages/My own hand written notes/etc - basically stuff that is not plain-text. Luckily I have a multi-monitor setup, so I don't really pay any penalty to switch contexts.

But keeping all that aside. As far as just the editing is concerned, all the advanced features in vi and such do help if you're typing out reams of code - something which I never find my self doing.

I suppose the obvious unstated thing here is that people have been productive in all sorts of environments, from notepad to pico to visualstudio to vi. From personal experience I find my self agreeing a lot more with people who say it doesn't matter _that_ much.

<comment><AUTHOR> I'm not one to argue about productivity. It's a term I never found very meaningful, so I cannot be sure other people mean the same that I understand when I hear the term.

For me it's not about lines of code per unit of time, but about what feels right, and that's very subjective. Dependent on the task I can probably make a decent amount of progress without Emacs, too, so I wouldn't argue that my productivity depends on it. But this Emacs environment is molded after my habits, so it's a really comfortable place, an extension of my body, much like a good tool for wood working that fits your hand just right and lets you work directly on an object without having to think of the tool as a mediator between your body and the work piece.

I wouldn't work with computers if I didn't feel comfortable. Thanks to the flexibility and hackability of Emacs I'm a lot more comfortable doing computer work than I would be without it, meaning that I'll become a gardener a couple of decades later than I would without it.

<comment><USER43> I agree with your view.

</comment></comment></comment></comment></comment><comment><USER34> I just recently moved from Vim to Spacemacs.

I was looking for a TODO list application that would work on plain text. This led me to org-mode. Fortunately, I discovered Spacemacs when trying to find a plugin that would emulate Vim keybindings in Emacs.

All I can say is WOW!.

I get to keep all the modal editing goodness of Vim while getting the excellent, well documented functions of Emacs. I also like it that the commands are Vim-like(doing a sequence of keys using a leader key instead of key chords).

</comment><comment><USER44> Emacs grabbed my attention soon [1], I used to spend a huge amount of time on almost all aspects of it. Now, I don't care[2]. Turns out editors are a waste of time, at least if you consider them so[3]. Brilliant algorithms are short in characters.

That said, Emacs is a full fledged system giving you a lot[4], if you're willing and able to use that lever you'll be happy. Lastly, Emacs survived for decades, it can swallow most interesting ideas that comes (ligthtable ? checked [https://github.com/Fuco1/litable](https://github.com/Fuco1/litable) [https://www.youtube.com/watch?v=mNO- vgq3Avg](https://www.youtube.com/watch?v=mNO-vgq3Avg)).

\----

[1] It's syntactic system is powerful enough to feel different and more solid (important) than other editors at the time (before Eclipse and IDEA). It was repl-friendly, another factor that talked to my mind.

[2] It's still the 2nd most used program on my machine after chromium .. maybe even a tie.

[3] Learn hard things, fundamentals (parsing, compilation, optimization, paradigms), learn how to help yourself (see G.Bernhardt talk about unix chainsaw[3]) in all possible ways.

[4] its open keybinding trie is still something that I miss in most programs and I try to port a subset of it everytime I design a UI. It's also based on a lisp, so enjoy using alien tools from the future. Btw, its git interface (magit) blows Eclipse one out of the water for instance, most people wouldn't suspect how efficient it is compared to heavy 'pro' tools.

</comment><comment><USER45> I'd love to get started using emacs, but it's extremely difficult.

I want to use it to write c++ on Windows. I'd like to have autocompletion support, and navigation support on a large project (>1million lines).

I have yet to manage to get it set up. If it were more straightforward to set up and use, more people would use it I'm sure.

<comment><USER46> Maybe this could help: [http://tuhdo.github.io/c-ide.html](http://tuhdo.github.io/c-ide.html)

<comment><USER45> That's great looking. I'll give it a go today!

</comment></comment></comment><comment><USER47> Emacs have been my main editor for 15 years soon and while it definitely got some rough edges, once you learn all basic key-combinations for editing and buffer management (which often is even more uncomfortable with a non us keyboard layout) I feel that nothing else really compare. Text editing is great but as many have pointed out the extensibility and all the high quality community projects/modes out there make emacs something unique. I don't think it's wrong to regard emacs more as an elisp environment than an editor.

The biggest problem with emacs right now as I see it is the lack of multi- threading.

</comment><comment><USER48> Emacs and vim allow extreme customization for precision editing and navigation:

[http://howivim.com/2016/damian-conway/](http://howivim.com/2016/damian- conway/)

[https://www.emacswiki.org/emacs/AceJump](https://www.emacswiki.org/emacs/AceJump)

Worrying about startup time is the wrong problem. You want to optimize for keystrokes, for example. More work, less typing.

</comment><comment><USER49> I'm a recent ST3 to Atom convert.

I've used all sorts of text editors with a shell inside them, and I can't quite fathom why you'd want to do that. What's wrong with bash running in iTerm? Then it's a first-class citizen of your desktop instead of a subprocess of a subprocess of a thing running inside another thing running in the one terminal window you're using for everything.

I've tried using vim and emacs a few times, but I can't quite get to grips with the whole modal editor thing. Feels like a whole huge learning curve just for the sake of it, getting in the way of actually getting things done.

My _operating system_ is a perfectly good operating system, I don't need emacs for that.

On the odd occasion when I need to edit something on a remote server (this is _very_ rare, cos ansible/puppet) I'm quite happy using nano. It has zero learning curve (no modes) and the few shortcuts you do need are marked on the bottom of the screen. Yes it's kind of featureless, but you shouldn't be editing things on your servers anyway.

</comment><comment><USER50> Emacs+Org-Mode can be an incredible platform for personal information/knowledge management and quantified self.

</comment><comment><USER51> The boilerplate argument against emacs is getting kinda old, isn't it? I used vim exclusively for ~5 years up until last summer when I switched to emacs which I use in more or less the same way, edit something, ctrl-z out to the shell, fix something, fg back to emacs etc... I find the ~2 second startup time for the times when I don't run it as a daemon negligible, and imho it's easily worth it at least if you make use of some of the more powerful editing modes.

Also the lacking a decent text-editor joke is just that, a joke :S

<comment><USER52> > Also the lacking a decent text-editor joke is just that, a joke

well, noone's saying that viper-mode couldn't be improved

<comment><AUTHOR> Or `evil-mode`. (I prefer `god-mode` as I have Emacs keybindings in muscle memory and the vim bindings slowly fade from memory.)

</comment></comment></comment><comment><USER53> I switched to emacs a year ago and I love it. I feel a lot more productive when everything I need is in single window. However, just recently, I started feeling what used to be minor RSI to be a major discomfort. There are days where I can't type at all. I don't know if emacs' key bindings is mainly to blame here, but it seems like it. evil-mode have been recommended to me but I'm hesitant because I never liked vim's key bindings.

<comment><AUTHOR> I recommend God mode. On my Thinkpad X200S I bind the mode switcher key to the right mouse button, which is easily reached by the right thumb. With God mode you don't have to relearn key bindings, you just no longer need to hit Control and Alt.

[https://github.com/chrisdone/god-mode](https://github.com/chrisdone/god-mode)

<comment><USER53> This looks amazing, thank you!

</comment></comment></comment><comment><USER54> Why should people use emacs to run applications when the shell already does that just fine? Just use the shell and you can run applications in any language you want rather than having to stick with elisp. If you want to constantly switch between applications, you can use tmux or simply your terminal emulator's tabbing functionality. You can even switch between GUI applications instaneously if you use a tiling window manager like XMonad.

<comment><AUTHOR> Emacs _is_ my shell. You don't have to stick to elisp either, you just need a little elisp glue. (The Emacs interface for the GNU Guix package manager, for example, is written in Guile Scheme for the most part.)

Emacs is trivially extensible and whatever I make it do can be used in other sub-applications. I can evaluate code wherever I want and change the system at runtime. It's quite a different feel compared to having "unglued", ununified applications.

</comment></comment><comment><USER55> Emacs is a fine editor to use until you write your own. It's the only way to make your primary interactive tool work exactly the way that you think it should.

<comment><USER56> That's a hefty endeavor. Care to share more about your experience writing your own?

<comment><USER57> I think pklausler means that, out of the box, emacs is decent but, over time, you slowly mold it into something that is more truly yours.

That's been my nearly twenty year experience with emacs.

<comment><USER55> I am glad that you have enjoyed your use of emacs, but no, I was being literal. A text editor is not a complicated piece of software to write from scratch.

<comment><USER39> I guess 7100 lines of C might sound simple to some, but that sounds pretty complicated to me! :)

</comment></comment></comment></comment></comment><comment><USER58> I use both Emacs and Vim and Emacs is slow. Often I would issue commands too fast for Helm to pick it up. It has rich environment and a lot going for it, but it is slow. Excuse to have "full featured" environment does not stand because Sublime Text is very much full featured and very fast.

Anyhow, while Vim is still my goto editor, Emacs has a lot going for it and I fire it up when I work on Elixir because of superior support. Org mode is nice.

<comment><USER59> This entirely depends on the set of packages you configure. I was able to make vim plenty slow by running too many plugins over too many files. I made vim lightning-fast by keeping things simpler. I did both of the same to emacs.

Actually, advanced IDEs like Idea only feel fast because they do most of the stuff asynchronously. Afaict neither vim nor emacs are excessively good at it.

</comment></comment><comment><USER60> I also love Emacs. I bought an original Emacs Manual for Richard Stallmam (late 1970s?) and still spend a ton of time inside Emacs every day.

I do,use other editors like TextMate and GEdit and the JetBrains IDEs sometimes. Right tool for the job. Emacs really excels for Lisp languages, for me that is Haskell, Common Lisp, Clojure, and Scheme.

</comment><comment><USER61> Given the whopping size of Atom, I really wonder why anybody would call Emacs big. Emacs was just ahead it's time.

</comment><comment><USER62> [http://www.sachachua.com](http://www.sachachua.com) is the blog of an avid Emacs user who promotes its use, and the plus is that there's a lot more interesting information there too as she documents her journey.

</comment><comment><USER63> I try Emacs around once per year. The problem is it's so slow under OSX. It's much faster on my 2007 iMac running Linux than 2013 mbp. I even tried to run it under X-Quartz but still performed poorly. What can I do?

<comment><USER64> Turn up the limit on garbage collection made a big difference for me. I'll post my .emacs.d on github and reply here.

I'd only make a personal recommendation for emacs if you were doing Clojure development. Emacs+Cider+clj-refactor puts everything else to shame.

Otherwise I'd just say use atom or sublime or whatever ide.

<comment><USER36> Just fyi, I also have huge issues with helm performance on my system. I tried the (setq gc-cons-threshold 100000000) from your init.el, and it didn't help at all.

I'm running emacs 24.5.1 with a recent helm on a 2-core 64-bit Linux system with 8 gigs of RAM. Bringing up helm-mini takes about 7 seconds for me, as does getting a response from helm-apropos when I type a single character or even type control-g to close it.

The rest of emacs runs fine. It's only helm that has anything remotely like this severe performance problem.

<comment><USER64> I've never used helm, so I don't have any experience there. I can't say that I've felt like I'm missing anything by not using it though.

I'll give it a try on my system, maybe that will give some insight.

\-- update \-- I installed a bunch of helm stuff, it didn't slow anything down for me. try doing a clean pull from my repo and then adding your helm packages and see if that helps.

emacs starts up in about 1.2 seconds for me.

</comment></comment></comment></comment><comment><USER65> Do you really think choosing between vim, emacs, textmate, sublime, etc is going to make such a big difference in the end result?

<comment><AUTHOR> To me the answer is "Yes".

What is the "end result"? Is it just a text file containing characters in the desired order? Is the journey at all important or is all that matters reaching the goal?

I have a feeling that most people commenting here have not actually read my blog post; or maybe I failed to get my point across. Comparing Emacs with other text editors is a different topic. I hardly even mention text editing in the blog post.

Using Emacs for text editing is what I do because I'm already using Emacs for everything else (or was it the other way around?). It makes a difference for me because I can use the same malleable system for everything that can be mapped to some text representation. Emacs modes enhance that text representation, make it alive (e.g. hyperlinking in man pages, shells in Emacs, REPL interactions, M-x compile, etc).

</comment></comment><comment><USER66> Out of curiosity, I have tried Vi and Emacs, but the CLI text editor I have gone back to is GNU nano.

Am I missing something?

<comment><AUTHOR> It depends on what you want to do and what you expect. As I wrote in my blog post, Emacs is more to me than just a text editor, just like a browser is more to many people than just an HTML viewer.

I don't use Emacs on the command line; I use a graphical instance. I usually only have two programmes open: Emacs and a graphical browser (eww still needs some work).

Being able to use my very own Emacs that has been molded according to my habits for pretty much _every_ task is a great feature, but it only becomes obvious after some time of continued usage.

</comment></comment><comment><USER67> It just amazes me that programmers would use anything else.

</comment><comment><USER68> Long live Emacs! It just C-w 's all competition.

</comment><comment><USER69> Because it's awesome.

</comment><comment><USER70> Any Acme users here?

<comment><USER71> Which acme user are you, Russ or Rob?

<comment><USER70> Neither, actually. In fact, I don't even consider myself to be a programmer (Although I routinely write scripts of sorts)

</comment></comment></comment><comment><USER72> This article seems to assume that people who criticize Emacs don't understand that Emacs isn't a monolith, and that the various features are modules. I'd guess the majority of people who say "Emacs is bloated" do get this. The author fails to understand what people really mean by this criticism.

I'll just speak for myself here, because that will make phrasing easier; the point is that for me a text editor doing most of the things the author describes (running shells, handling email, todo lists, etc.) makes no sense. For me, a text editor should first and foremost be a great text editor. Secondarily it can be nice to have integration with Git or other tasks that are intimately related to the files I'm going to be editing with the editor. But why would I ever want my editor to do all those other things? I have a window manager for that. Or at least a shell.

The comparison of Emacs to a shell kind of illustrates my point; a shell only exists to facilitate managing of files and processes. It being able to run any command you want is its whole purpose. Emacs was originally an editor, and the community grew its capabilities from there. (I'd argue that it grew during an era where it having so many modules with so many capabilities made more sense than today, but that's another conversation.)

The comparison of Emacs to a web browser is better than the comparison to the shell. But this comparison still misses the mark, because browser based apps have several advantages (and disadvantages) over native apps, they are fundamentally different because of the technologies involved.

Using Emacs to do things like email, manage your shell sessions, etc. is a bit different from running another mail client, or running separate shell processes, etc. but they are not fundamentally different from each other in the same way. Whether you're running Emacs locally or remotely, you can run separate mail clients, etc. the same way.

Anyway, my point is not that Emacs has no reason to exist, but it comes down to this; personal preference. The only reason to use Emacs the way the author does is because you like it.

</comment><comment><USER73> "Doing just one thing and doing it well" \-- which is better at this, Unix programs or Emacs functions?

<comment><USER74> At least Unix programs don't suffer from dynamic scope. (Unless you use bash to glue them, of course.)

<comment><AUTHOR> There are some instances where dynamic scope actually is not as insane as it may seem. Although the paper is probably dated and opinions have changed since then I can still understand that there are practical reasons to dynamic scope in some instances:

[https://www.gnu.org/software/emacs/emacs- paper.html#SEC18](https://www.gnu.org/software/emacs/emacs-paper.html#SEC18)

All my own Elisp code uses lexical scoping by default and I don't trust myself enough to use dynamic parameters liberally in my code. But I don't think it's entirely unreasonable to have the ability to dynamically override internals.

<comment><USER74> Oh, definitely. Even extremely statically minded Haskell offers a dynamic scoping construct: the reader monad. (As Haskell is wont to do, this monad infects every user of it with a `tag', just like IO does. No silent surprises from dynamic scoping here.)

<comment><USER75> Implicit parameters, too.

</comment></comment></comment></comment></comment><comment><USER76> I love EMACS, partially because of those zippy the pinhead quotes that can be evoked with the 'M-x yow' command

</comment><comment><USER77> Different people like different things, OK? A 40 year old flamewar is boring and old. Just let it die.

[1] [http://unix.stackexchange.com/questions/986/what-are-the- pro...](http://unix.stackexchange.com/questions/986/what-are-the-pros-and- cons-of-vim-and-emacs)

<comment><USER29> I think this is a misreading of the article!

<comment><AUTHOR> Indeed! I was actually raised by a pack of vims, and I like both editors. I used to use evil-mode in Emacs for a while until I reset my muscle memory by switching to dvorak.

I have no interest in old flame wars. Our generation has its own set of flame wars to fight ;)</comment></comment></comment>


Solved: A Decades-Old Ansel Adams Mystery - <AUTHOR> https://www.atlasobscura.com/articles/ansel-adams-mystery-astronomy <comment><USER2> >...the potential location—a spot on the road about eight miles from the nearest ranger station...

Lols to "a spot on the road" \-- large format gear is not pleasant to carry around.

<comment><USER3> When younger, Adams did hike with large format cameras.

But later he built a platform on the top of his station wagon and used that.

</comment></comment><comment><USER4> If you enjoyed this bit of photo sleuthing then I highly recommend film director Errol Morris' incredible tale of sleuthing regarding a photo from the 1850's (!) taken during the Crimean War:

[https://opinionator.blogs.nytimes.com/2007/09/25/which- came-...](https://opinionator.blogs.nytimes.com/2007/09/25/which-came-first- the-chicken-or-the-egg-part-one/)

</comment><comment><USER5> Never forget: how to steal a flag ([https://www.vice.com/en_au/article/d7eddj/4chan-does- first-g...](https://www.vice.com/en_au/article/d7eddj/4chan-does-first-good- thing-pulls-off-the-heist-of-the-century1)).</comment>


"Secret Writer's Society", the best way to swear at children in 1998 - <AUTHOR> https://obscuritory.com/educational/secret-writers-society/ <comment><USER2> Tangential anecdote: I supported a product recently that had a password generator feature that admins could use to create a "random" password for a new user account. The password would be emailed to the user (the admin never saw it). The generator used a wordlist file that the developers must have grabbed from an online dictionary. It was about 10k words and contained MANY offensive ones. Pretty much any obscenity you could imagine and more. It was obvious no one had sanitized it.

I filed a bug a couple years ago but it still isn't fixed. Luckily it's a seldom used feature, and I haven't seen anyone affected yet.

</comment><comment><USER3> Digging through the links on rtmark's history nets a link to this talk about the Yes Men, who tried to climb into corporations to reveal secrets or sabotage products.

[https://m.youtube.com/watch?t=344&v=nkOCUdvK8-U](https://m.youtube.com/watch?t=344&v=nkOCUdvK8-U)

[https://en.m.wikipedia.org/wiki/The_Yes_Men](https://en.m.wikipedia.org/wiki/The_Yes_Men)

A bit OT, but just saying it's good research on a blog if it's worth spiraling down some random links.</comment>


White House Source Code Policy a Big Win for Open Government - <AUTHOR> https://www.eff.org/deeplinks/2016/04/white-house-source-code-policy-big-win-open-government <comment><USER3> I'd encourage you all to read the draft source code policy ([https://sourcecode.cio.gov/](https://sourcecode.cio.gov/)) and consider commenting on it or responding to existing comments yourself (due by Monday night at midnight Eastern U.S. time): [https://github.com/WhiteHouse/source- code-policy/issues](https://github.com/WhiteHouse/source-code-policy/issues)

This is an unusually direct opportunity to share your expertise to help the entire U.S. federal government do a better job of building software.

</comment><comment><USER4> This is a great step in the right direction!

I did a request for Chicago's $100M ticketing system's code - written by IBM - and they're acting very, very slowly to further respond. More so than usual. Hopefully this sort of work helps out :). I feel like I should probably contact EFF after seeing this..

<comment><USER5> What particular project are you referring to? That's an awfully large contract. I'd like to know what the outcome is of your work.

<comment><USER4> It's called CANVAS. I saw some very interesting things in that contract - <USER2> example, 20M of that included a subcontract for paper. It's relatively understandable, but it's pretty clear that someone at an obscure, difficult to research company got a very pretty penny for it.

And gladly - I'll try to keep you updated.

</comment></comment></comment><comment><USER6> I wonder if it is going to wind up applying to voting machines or if they're somehow going to be "loopholed"

I'd prefer that those machines could have their code audited.

<comment><USER7> Likely not. In this country the states run the elections, not the federal government.

If you want this in your state, push them (that is, your state senators and state legislature) to adopt a similar policy at the state level.

</comment></comment><comment><USER8> This is a proposed policy. The original title is a little misleading.

Good to see the government considering steps like this. Still, the system needs a major upgrade of tech understanding if we're to really introduce better tech within government. We can begin by electing people who understand technology.

</comment><comment> V-2 Coding convention for WhiteHouse Android app is abysmal ;)

[https://github.com/WhiteHouse/wh-app- android/blob/master/app...](https://github.com/WhiteHouse/wh-app- android/blob/master/app/src/main/java/gov/whitehouse/app/BaseActivity.java)

        public
        boolean checkNetworkElseFail()
        {

        public
        Tracker getTracker()
        {

etc. Who does that?? And that's despite the fact that

" _Contributers_ [sic] _are expected to adhere to the official Android Code Style Guidelines._ " ;)

<comment><USER9> >>Who does that?

You mean the indentation style? The K&R vs ANSI/Allman thing?

That argument started well before java, and continues. I would guess you're seeing it there because whoever wrote it had previously been a C++ developer. Inertia. GNU's classpath, for example, is indented this way...same thing, inertia. Easy enough to batch reformat though.

<comment> V-2 I was referring to putting visibility modifier in its own line.

<comment><USER10> It's handy if you're looking for the methods definition using a regex. Instead of doing something like (in pseudo-regex):

        $[public|private|whatever-else-can-behere](FUNCTION_YOURE_LOOKING_FOR)

you can do a slightly simpler

        $(FUNCTION_YOURE_LOOKING_FOR)

Obviously your code editor/IDE should handle that, but maybe if you wanted to whip up a quick script to something a little odd, it'd be quite handy to have the function name on a separate line.

<comment> V-2 Well, that's the first time I see such convention. And your argument doesn't quite hold water to me. They put the visibility modifier in its own line, not the function name. It's still next to the return type (or void). So it would still beat your regex. Plus, I'm not exactly sure if any Android devs snap out little regex-based scripts for refactoring or whatnot :) I'm sure it's far from unusual in dynamic languages, but looks like a great YAGNI in this case. I'm not hating it, all I'm saying is it's odd :)

<comment><USER10> You're completely right, it's odd. Also I didn't realise that the return type was also on the same line as the function name, in which case, even more odd.

I think the idea dates back to early C. I've definitely seen C code with the return type on a separate line.</comment></comment></comment></comment></comment></comment>


The new guy wants to hack the city's data - <AUTHOR> http://radar.oreilly.com/2011/09/hack-tyler-texas-open-data.html <comment><USER2> > While there are things to like about Tyler — a cheaper cost of living than > Chicago, for example, and no lengthy commute

This city is in the armpit of nowhere. Unless he's working at the university or from home, he'll have a commute.</comment>


The cost of cross-border payments needs to drop - <AUTHOR> https://www.economist.com/leaders/2019/04/13/the-cost-of-cross-border-payments-needs-to-drop <comment><USER2> There's a paywall on the article but, does it mention the immense legal barriers on remittances?</comment>


U.S. Navy Will Attempt To Land Jet-Sized Drone On Aircraft Carrier - <AUTHOR> http://talkingpointsmemo.com/news/us-navy-will-attemp-to-land-jet-sized-drone-on-aircraft-carrier.php

<comment><USER2> Spoiler Alert: [http://gizmodo.com/first-video-of-the-navys-x-47b-drone- land...](http://gizmodo.com/first-video-of-the-navys-x-47b-drone-landing-on- an-air-735334127)</comment>


Tracker 2.0 vs. Redux – Meteor Autoruns and Solutions to Its Core Problems - <AUTHOR> https://medium.com/@faceyspacey/the-evolution-of-tracker-solutions-to-its-core-problems-4b9cb90d479a <comment><AUTHOR> This is a must-read for Meteor or would-be Meteor developers. Meteor's reactive Autorun library, Tracker, at the core of all client side Meteor reactivity is broken. We can fix it.

Only once we do that can Tracker have a fair fight with Redux.</comment>