skysight-inc/HackerNews huggingface dataset:
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.
"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 :)
So, you basically ended up being better coming up with new algorithms?
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 ;)
I love LyX!

The end-result of good looking LaTeX documents, without (most of [1]) the pain.

I recently adapted a colleague's document from LaTeX and it was simply easier to redraw a slightly complex table in LyX than to understand the table markup. I think he'd be disheartened to learn how fast it was to produce the table.

Writing math is also a no-brainer compared to LaTeX. Whenever my LaTeX-using colleagues see me writing stuff in LyX, and the screen is filled with semantics rules that basically look just like they'll look in the final PDF, they go "yeah, I really have to check out LyX some time..."

Mostly they end up never checking out LyX and sticking with LaTeX, to their loss, but I've managed to convert a few people over!

([1] the remaining pain is related to dealing with conference and journal style files, which often have quirks in LaTeX, and adding LyX on top sometimes demands an extra layer of adaptation.)
Which acme user are you, Russ or Rob?
This is what happens to most programmers as well, when they try to read code that they wrote a while ago.
Right, scanning large heaps means someone has to pay along the way. The Go GC pays with lowered throughput much like the adapted HotSpot VM is showing. The 10ms pause times for go were reported for a 250 gigabyte heap, however, and that is pretty amazing.

But the lowered throughput has to be present as you are scanning the heap and you have enabled the write barrier to make the concurrent scanning work its invariants. In fact, the newest versions will make aggresively allocating goroutines run slower by using some of their timeslot when they request data do run the mark phase.
TeXmacs and LyX take different approaches to document generation. You cannot say one is better than the other without considering how their respective differences will impact your needs from the program.
Point of this article is not the point of this article. The clever bit was:

> ...the IPv4 address will convert into a number...

Many fancy, post-modern app developers might insist, "You won't do math with an address; it's not a number." But some things are numbers, with a scheme and pattern you can exploit.
Math seems to have a very ephemeral lifetime in the brain. I skipped a year of college once, and when I returned I realized I had to basically abandon any major with a math requirement, because I had seemingly forgotten everything.

I'm currently struggling with an online Machine Learning class (the Coursera one... at the tender age of 43), and I can only take it (so far, at least... just failed my first quiz... fortunately I can review and re-take) because I was rather obsessed with matrices, oh, about 28 years ago. "You mean I can rotate things in an n-dimensional space without using trig?"
A PhD isn't so much a test of intelligence as it is of perseverance.
First, I am not sure Functional Analysis is as obscure as some other areas. But, second, this just shows, once again, that one ought never to use "clearly," "obviously" etc in proofs.

It is the same principle as writing programs so they are easier for the next programmer to read. That person may be you.
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.
The Future of Information and Privacy: The Good, Bad and Ugly of It
A memory chip has a capacity that is an exact power of two. Hard drives - not so much. Check out this reference:

http://www.pcguide.com/ref/hdd/geom/geomLogical-c.html

The drive they discuss has 6 read/write heads, 6,810 cylinders, and 122 to 232 sectors per track (presumably more on the outer tracks).

None of these numbers are the slightest bit base-2-ish, which is why capacities are rarely near powers of 2. So, there is no valid technical reason for storage sizes to be expressed in powers of 2.
> Mathematics is an excellent proxy for problem-solving

I went to a special, maths focused high school class and this rings true on that lower level too. I am a reasonably successful programmer/architect today and I have -- repeatedly -- attributed my successful attitude toward solving my problems to the 1200 or so problems we solved during those four years. Our maths education was literally nothing else but solving one problem after the other.
As a "kid" - you are right !
Given that the modern app developer did a de-dupe operation for his solution, and that the most plain reading of the English text is "in any of the scans", I think the OR is correct.
This does not surprise me in the least.

Math was always extremely easy for me growing up. Up through my first differential equations class I found almost everything trivial to learn (the one exception is that I always found proving things difficult).

I made the mistake of minoring in math and that slowly killed my enjoyment of it. Once I got to differential geometry and advanced matrix theory it all just became too abstract and I just wanted to get away from it.

For several years after college I would routinely pull my advanced calculus text out and do problems "for fun". After a while I stopped doing that. Within a few years of no longer being exposed to math, I found it all incredibly foreign and challenging, to the point where I would say I have a bit of an aversion/phobia to it.

I'm trying to reverse that now by tackling a topic I'm interested in but have previously avoided due to the math-heavy nature of it - type theory.

Hopefully I can find the joy in math again through this.

I think my point is that you can lose competence in math very very quickly through lack of constant exposure.

The same is probably true of programming but I hope to never end up in that position.
The Financial Cloud
There is no reason why anyone should use LyX over TeXmacs in high school or undergraduate classes.

TeXmacs is also better for academia but most universities, conferences, and journals are behind the times... so graduate students and professors are still stuck with LaTeX.
Another mis-analysis of Yahoo. The situation is and had been very clear- Yahoo has never accepted what it is: A conglomeration of useful web services and utilities. Not sexy, but used by millions and potentially very profitable with properly tiered service levels. Instead it has always called itself a "media company" and chased after the success of its competitors. When I worked there a decade ago it wanted to be Google. Now it wants to be Facebook, YouTube or god knows what. This, combined with the inexperience, ego and vanity of Mayer assured Yahoo would continue its slide to irrelevance. Very sad.
You may be interested in checking out Ivy; it has a similar workflow to Helm but is much more lightweight. As a fan of Ido, Ivy has replaced Ido everywhere for me except for opening files.
Sounds like your browser is trying to do you a favor. Does it keep you from loading Slate or Gawker too?
What? The kids? I see young people using python more than any other language by FAR. What region are you? I've seen this through the northeast and midwest United States.
Hackers Demand $3.6M from Hollywood Hospital Following Cyber-Attack
Because money. I doubt there's any really good reason besides the fact that they don't want you to just be able to copy books directly from your Kindle and read it elsewhere.
> it's worth pointing out that ST3 is a binary that you download and have complete access to, so of course it will be there next year

This is not "being there." Popular architectures change, as do operating systems. Unless you intend to freeze your current computing environment for posterity, a working executable means nothing.
Oh, didn't realize you meant only certified Unices. I'll be on my way...
Not at all. I can appreciate an elegant, problem-specific solution as much as anyone else. The point is that there are always tradeoffs.

What's the query interface like for the bit array? Does it even have one? Seems like you'd have to sit down and add more code whenever you wanted to know something new about the data. Would you write your own query layer? Would you eventually need a dedicated team to maintain it? You may say that is an extreme conclusion, but I've seen this very story play out multiple times in large dev organizations.

As amorphic pointed out, indexing the data with ES makes it easy to access even for non-technical users. Each layer of abstraction comes with its own costs – of course – but also its own benefits. Tradeoffs.
All of these arguments are arguments for replacing the mathematics curriculum with video gaming. Games require generalized problem solving (arguably better-generalized than math, and arguably better-transferrable to other domains). Games build character: grit and tenacity, cautious optimism, etc blah blah etc. And games are fun (for many more people than find math fun).

Guess math teachers should start learning to play League of Legends and Pokemon.

Alternatively, I guess we need better reasons than those to teach a subject.
Google started with less, and so almost every project on the internet.
Would you agree though that Yahoo has not kept up with users moving their attention to smartphones, and there will be a corresponding loss in users and profit in the long run? If so, I believe Mayer was trying to correct this through her efforts.
Running emacs like "$ emacs <text-file>" is like booting a computer, editing a single text file, and then "$ shutdown -h now".
then you have to maintain/monitor that daemon, seems like too much work.
Just tune the VM:
https://github.com/atemerev/skynet/issues/33

and speed doubles :)
How Python helped create the VFX for an Emmy nominated TV show
Which feels like a 'life is suffering' weirdness. I did it and never needed my diplomas for anything. Maybe I benefited somehow but I was a coder and entrepreneur before that; I had a software company before uni. It was over 20 years ago and in hindsight I find it pretty pointless and a waste of time. Maybe I became a better problem solver on some level but unless you are going into research or are not a self starter I would not recommend it.
In Spack this would look like:

spack install guis ^guile@<new version>

How do you handle optional dependencies in this model? Or, a more complex case, dependencies that are only present for certain versions of the package? Look at the gcc package in Spack:

https://github.com/LLNL/spack/blob/develop/var/spack/repos/builtin/packages/gcc/package.py#L54

This builds gcc 4.x and 5.x versions, and it's pretty concise. The `mpc` and `isl` dependencies are only present when the version of gcc is 4.5 or higher, or 5.0 or higher, respectively.

There's an iterative DAG-building step called concretization that looks at these types of constraints and tries to solve for a satisfactory DAG, which is then built in a functional style. I don't see how I would model that in Guix, and but in Spack it's a few lines, and there's command-line syntax to customize versions on the command line, not just programmatically. e.g.:

spack install gcc@5.0 ^isl@0.11.1 ^mpc@1.0.2
TLDR: The author independently re-discovered what you may know as Old Code Syndrome.

I think that's because mathematical papers place too much value on terseness and abstraction over exposition and intuition.

This guy's basically in the position of a fairly new developer who's just been asked to do non-trivial update of his own code for the first time. All those clever one-liners he put into his code made him feel smart and got the job done at the time. But he's now beginning to realize that if he keeps doing that, he's going to be cursed by his future self when he pulls up the code a few months later (never mind five years!) and has zero memory of how it actually works.

I'm not intending to disparage the author; I've been there, and if you've been a software developer for a while you've likely been there too.

Any decent programmer with enough experience will tell you the fix is to add some comments (more expository text than "it is obvious that..." or "the reader will quickly see..."), unit tests (concrete examples of abstract concepts), give variables and procedures descriptive names (The Wave Decomposition Lemma instead of Lemma 4.16), etc.
No. Python is extremely useful and will remain so. However Python has fundamental design problems regarding unicode handling and 2/3 discrepancies that make it challenging to work with in a number of contexts.
Python occupies a niche that isn't going away any time soon: making it easy and natural to write readable, straightforward, more-or-less imperative, slightly boring code of the type you learned in CS 101.

This is still a very practical way to solve many problems and I'd wager for most programmers it's still the easiest way to do things. Maybe it will always be. It's hard to imagine there'll be a generation of programmers some day that finds it easier to compose dozens of tiny modules, chain callbacks with a variety of async abstractions, and implement as much as possible in tiny idempotent functions.

I feel like the worst case scenario for Python is that it will fade into the wallpaper of mature and unsexy languages like Java and C++ that nonetheless run the world and will probably be around for another 100 years at least. I'm guessing Guido would be cool with that.
Python is fine. I just came off a job in it and interviewing around saw a couple other jobs in it. I see it competing with Ruby and server-side-js. Python is more mature than either, and has a different flavor that will appeal to some people. Choose your environment to taste.
OTOH, job[-2] was switching away from Python due to run speed concerns, towards Go. But while the application would be less Python, the 'devops' system glue would still be all Python.
Why can't Julia fill that role?
It is so big because it is based on Latex and its ecosystem, which is on most distributions by default quite large. It will install a lot of Latex packages which you probably won't need right away, but if size isn't a big problem I wouldn't bother with trimming it down.

One of the advantages of Lyx is that it builds on Latex and its extensions, which thanks to tens of years of development is very mature and feature rich. If something that you want to do with Lyx isn't supported you can just use raw (La)tex script. For example I used it for autonumbering of chemical compounds.
> type theory

Not sure if related to your username, but I have a book on it (that was recommended to me here, in fact) on this topic, which I was curious about due to its implications in the programming field
It's fascinating how many people here are defending the "modern app developer" approach, mostly with arguments about flexibility, maintainability, ability to pass on the code to junior developers, and the like. If you think about what the "old-timer's" code here would actually be, these kinds of objections make no sense at all.

Assuming the code to run nmap itself would be equivalent either way and we're interested in the data storage and analysis functions here, the old-timer would write that entire part of the program in about one screen of any decent programming language in perhaps 10 minutes. The functions would be short and simple, needing only basic iteration and bitwise arithmetic. Any junior programmer who's going to get anywhere in this industry would be able to understand that code in moments with no specialist knowledge or additional training. Nothing about the code would get in the way of any reasonable commenting or testing policy either.

If in the future someone didn't find the compact data structure appropriate for some new application, they could easily convert the data to a more suitable alternative format, because the current format would be well-specified, simple, efficient, and without external dependencies.

Hypothetical arguments about scalability are silly. The problem is fundamentally built around IPv4 addresses, which have been 32 bits wide since they were devised and will still be 32 bits wide tomorrow and next year. Designing for something more scalable is some horrible combination of scope creep, YAGNI violation, and worst of all, not giving even cursory thought to what the requirements actually mean. (I await the seemingly inevitable unintentionally amusing response about IPv6...)

The only thing I really quibble with here is the characterisation of the two types of developer. I don't think this is really about modern vs. old-timer. It's just about a good programmer -- who looks at each problem on its merits, chooses suitable tools for the job, and leaves their options open -- and the bad programmer, who does not.

Well, that and the fact that no self-respecting old-timer would misuse the word "performant" so heinously, but I digress. :-)
Some say arrival time, not drive time. Arrival time misleading if it's sending you on. A 26-hour journey, and you have to choose to view the full route, often through a tedious UI.

IMHO, this is a place where blaming the user is inappropriate. GPS trips exceeding 3 hours are rare enough that it would be perfectly reasonable for it to make you click through a few extra bits of information in those cases.
You realize racial profiling is on literally every single social network out there? It's a problem ingrained deep in society. You can't blame a communications platform for people's behavior.

Do you get mad at your racist uncle's racist rants on Facebook? You might. But do you blame Facebook for it?
Java has gotten significantly better in recent years across the board. Python it's a mixed bag due to the 2 to 3 incompatibility transition, one step forward, one step back and some step are changes but not improvements.
It's the TeX distribution, it has loads and loads of packages. It's better than having to download single packages on demand.
This is an implementation of "simple" directional payment channels between two parties, without the concept of hubs (as in the original LN) or p2p routing (as we have in LN today), and which expire at at a pre-determined timestamp (forcing you to close & re-open the channel every once in awhile).

This is useful for cases where one party wants to send payments in small increments to another party (e.g. pay-per-kilobyte for internet access). Funds locked up in the channel are only usable for transacting between the two parties, and funds can only be sent in one direction.

BitcoinJ implemented this nearly two years ago: https://bitcointalk.org/index.php?topic=945401.0

And BitPay released this as part of BitCore around 1.5 years ago: https://github.com/bitpay/bitcore-channel

The innovation in payments channels being discussed nowadays is something completely different: bi-directional payment channels that can be kept open indefinitely, with a peer-to-peer routing layer that makes it possible to send off-chain payments to anyone in the network and not just to one specific party.
I have been working on integrating some ideas. http://tinyvillages.org.

Note that the files are on Github and it really isn't about one person or group doing a complete design. One of the things that I have started thinking about that needs to be fleshed out more on that page is Open Source Engineering and ways to make zoning and all aspects of urban systems more component-based as well as moving beyond code/standard and form-based to common information systems platforms that will facilitate automation of planning/approval and smart/sensor network data integration.
Not only is Python not dying, but it's stronger than it's ever been. The majority of top colleges are now teaching CS using Python. It's completely dominant in academia, finance, and startups. It has the best libraries and documentation of any language. And Django has arguably the strongest community of any open source project period.

That's not to say there are zero problems, but Python is so much better than all the other alternatives that this just seems like a ridiculous question.
The major problem, without any measurement and just guesswork, is that you have a larger allocation overhead in Erlang. Not only do you need the process control block for the process, you also need to go to the memory subsystem and grab a heap for the process. In the Go variant, you are allocating out of the same heap and you can usually avoid some allocation there because everything you allocate is used. Not so in the Erlang system.

Were these processes/goroutines to do anything more complex, then the difference goes toward zero. But the constant overhead at the lowest level is probably higher.
If only someone made something that could monitor daemons and make sure they stay running...
My response is that for every 100 of these types of papers, one of them may prove to be pivotal or inspirational in something truly groundbreaking and functionally useful. For this reason, I am all for 100 different people spending their time doing things like this, because eventually one of them will make an impact that is greater than 100x the efforts of 100 normal men.

It's just a different kind of "brick in the wall" - only the diamonds in the rough can turn out to be hugely important for something else in the future.
Could this possibly have been just a temporary hangover/withdrawal period after which productivity would later increase?
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.