skysight-inc/HackerNews huggingface dataset:
>The primary virtue of these commands is that they use the Perl regular expression engine.

You mean the engine that lets you write pathological regular expressions[1] and accidentally ReDoS[2] yourself? To be fair, it's fine if you understand how the engine works well enough to avoid these cases. But how many people can actually say this?

1. http://swtch.com/~rsc/regexp/regexp1.html

2. http://en.wikipedia.org/wiki/ReDoS
Stanford creates flexible, high-efficiency peel-and-stick solar cells
In Montana (mid 40°s North), people rarely have large, permanent air conditioners in their homes.
Actually,

boo :: Map a b -> b -> Maybe a

since Haskell doesn't have null inhabiting every non-primitive type.
Architecture patterns for scalability in the cloud
While ack is a great tool, I don't think the author pointed out its strengths in this article. From my perspective, the strengths are using it recursively and its ability to 'recognise' files containing source code (and yes, I know that grep has a recursive option - it's more innate, though, in ack).
Seattle is a good example because its weather is similar to London. For what it's worth, A/C is also pretty rare in Seattle homes.
Nothing new under the sun, kids. Hormesis. Look it up.

http://gettingstronger.org/stoicism/
While I too hate PDF, let me say that a developer could take a PDF parser and since the PDF report is going to be static, it should be easy to extract the information.

Not that it's right, but it's possible.
I was looking into breaking a Perl IRC bot the other day and couldn't get any of the examples to work (that is, take more than a split second to execute). Does perl now detect these pathological cases and work around them or was I just not trying the examples correctly?
AllTheStars: A magical arduino-based christmas computer
Nope, no word missing there. "Would that there were" is a slightly archaic phrasing, but perfectly acceptable English.
I'm ok[1] with them for "I accidentally deleted a file" type stuff, I would not suggest it for a full system backup. I'd suggest SuperDuper! for that if you're on a Mac; I don't have any useful suggestions for Windows or Linux users (sorry!). Of course, I use a full system disk image for "I need to be up and running at 95% capacity within an hour", and these offsite file services as, basically, long-distance undo, or for files I'd be unable to get back in some other form. Think tape storage: it doesn't need to available ultra-fast, but I need to have as many nines of certainty possible that there will be some way to get at those files again.

[1] though I'm switching off of them, not sure where to yet. There's some sort of issue in their client software that murders my home network, rendering the entire thing unusable while a backup is running. Their support was... less than helpful in trying to remedy the situation. For $5 a month and with the amount of stuff I was backing up, I can't blame them.
I don't personally use Instagram, but I do use other services that share a similar monetization structure. (Google, et al.)

Although the entitlement mentality shown by users is certainly an overreaction, primarily by users who don't understand the corporate structure that they've bought into by their use of the services, I can't say that xkcd comic you quoted in support of your position is valid.

These companies turn the data we the users produce from our individual actions and queries into a marketable asset that they can (if everything goes according to plan) profit from. This means that their service is not offered altruistically or even unwillingly; their persistant existence relies on our using their services.

I don't want to come off like a privacy nut, because first of all it would be hypocritical given that I am a user of Google and Gmail, but something just doesn't smell right to me about this situation we have all gotten ourselves into by using these products.
it is accurate because it is internally consistent

Internal consistency is necessary for accuracy but not sufficient.
Dropbox does one thing and does one thing well. They've worked really hard to keep feature creep to a minimum. Dropbox for teams is a feature that adds so much over and beyond the initial KISS offering that the cracks in the 'just one folder' model are beginning to show. Ideally you'd have two or more folders marked as dropbox folders where you could associate each individual folder with the team or not at will.

Now your only real solution from what I can see is to create multiple accounts, if you don't want to give the team administrator the chance to nuke your account if he/she feels like it. Warnings about the possible consequences do not really solve the underlying issue and having the original team leader have a say in the unblocking of your account doesn't help at all.

This is a feature that will need some serious work and breaks the simple dropbox model that has gotten dropbox to where it is today.
if all you need is Perl regexp you can use grep -P, no need to stop using grep
Well, with a simple haystack like the one used in the example, there really would be no reason not to grep for "silver needle" in the first place. So it's really not the best or most realistic example of the usefulness of the double grep method.

When I use double grep in real life, I often tend to do so on a relatively large haystack, where I don't necessarily know what the second search term will be. In that situation, I'll usually do the first grep, look through its output, and add on the second grep once I see something in the first grep's output that I want to narrow the results down to.

Of course, instead of adding on a second grep, I could modify the original regex (and sometimes I do); but if the original regex is complicated, then modifying it is error prone. And, anyway, using a shell abbreviation, it's very easy to type " G " and have that expand to " | grep " to simply add on another grep, without touching the first regex.

A second, quite common use case for a double grep is when I want the second search term to match whether it's before or after the first term. There's probably some convoluted way to get the same effect using a single regex, but it probably won't be nearly as easy or intuitive as a double grep.
Minimum Wage January - Click here to get beach-ready abs for $3 a day
> And Dropbox isn't specifically marketed towards developers.

Dropbox for teams is specifically marketed towards businesses.
You did not get the point. Currently we are close to 400ppm/+0.8°C without geo-engineering. If we use geo-engineering, keep temperature at current level and continue emitting CO2 to let's say 1000ppm, we can't stop because the greenhouse effect of these extra 600ppm will kick in as fast as the reducing effect of the engineering slows down.

But you are right: This is not comparable to today's situation where concentration rises by 1-2 ppm y⁻¹, but it is comparable to injecting instantly the equivalent of 600ppm into the atmosphere. It's like the opposite of a huge volcano eruption.

So to make a long story short, any geo-engineering solution which does not remove greenhouse gases from the atmosphere and turn them into a stable chemical compound is nothing but a time bomb - exploding at failure.
Having come from a country where the postal service was privitized, I'm going to let you in on a little secret: it sucks. But hey, they're profitable...

One of the (very few) things the US does better than most countries is the USPS. It should be a point of pride, not some problem that needs to be left up to the 'free market' to ruin.
Is it worth learning grep or ack or a similar tool?

When I need to do these sort of tasks, I do them in a scripting language with some combination of split() and regex instead of using command line tools. But, I'm just doing that because it's what I know.

Would I end up saving a significant amount of time if I learned to use grep instead?
By the logic of your own post, I should downvote it... (but I didn't).
Devil's advocate: diabetics do not want data logs, they want a better/longer healthy life. I do not have diabetes, but I would rather have an insulin pump that maintains glucose levels by itself than a meter that allows me to monitor them.

And yes, that pump will be imperfect, but it probably will do a better job than you can do yourself, let alone than you will do yourself.

I know that, traditionally, patients used glucose level measurements, stared at the numbers, guessed at what caused them and then tried to correct for similar future events, but AFAIK, that has never been very effective. It did give you some sense of being in control, but that was more an illusion than reality. e.g: your blood sugar is high. Is that because you drank a beer last night, because you went to bed late, because you did not sleep well, because you are stressed about something, because you had a fever two days before, because you took the bus to the train station?

However, except from the truly bloody obvious, that didn't help much maintaining blood sugar levels, unless you lived like a robot. Normal daily schedules simply vary too much to allow you to determine the true cause of atypical blood sugar level variations.

IMO, the time of stand-alone glucose meters has passed, and I do not see how having users process logs will help improve their lives. Reading individual measurements definitely will, but that is so that you can react at short notice, and adjust insulin intake.
Termites act as tiny miners, lead humans to gold
"Look at that one character shorter than grep and just as easy."

Well, let's apply that same criteria to searching for two terms:

> grep needle haystack|grep silver

> ack '(?=silver).*needle' haystack

Look at that one character shorter than ack and just 10 times easier.

grep wins, by a knockout.
You can do a lot of things with `grep -E`, fwiw - there's not much here to really sell ack.

Things that do sell ack, for me:

ack css_class --sass # search .sass and .scss
ack some_method --no-flash # ignore .as and .mxml
# ignore compiled css in every Rails project on
# my system (as long as I `ack` from the root)
--ignore-dir=public/stylesheets/compiled

And the fact that it prints out like this:

path/to/file.ext
123: some text matching
234: more text matching

path/to/other/file.ext
480: a match

instead of like this (with `-n`):

path/to/file.ext:123: a match
path/to/other/file.ext:567: another match
path/to/that/file/you/didnt/know/you_had.ext:32: yet another match

makes it massively more useful for human-viewing of the results than the normal behavior of grep. And it reverts to grep-like output when you pipe it into something, so you can go from exploration to composition with no effort.
Not really - it is more that the various wrappers from tex to html are written in the spirit of the ancient web, rather than a transform to (another) simple, structured markup language. Somewhat odd considering docbook sgml should be a good match for modern html+CSS. I've considered writing something better, but have come to the conclusion that treating tex as output is just more reasonable (ie write in something like rst/markdown etc).
You might be able to change your grade, but you won't be able to move the professor. The professor has at least one of the following:

1. Tenure.

2. Credentials not easily replaced.

3. A lawsuit against the school with threat of more (this was the case with my worst professor in college.)

You will want to talk to the department chair, and then the student dean or ombudsman, then the provost or president. They will all have heard it before, and they may be able to guide you through a specific dispute, but none of them will bad-mouth the professor in front of you, a student.
Wealth. Per capita GDP in the US increased by 180% in the time period mentioned (in inflation constant dollars). Which means that in the regions of the country where it is hot for a considerable period of time almost everyone will have air conditioning, and in areas where it's hot only a few weeks out of the year a lot of people will have in-window air conditioning units, since they are so inexpensive.

The UK's per capita GDP is only 3/4 that of the US so they don't have as much disposable income and the weather tends to be much colder there than the average in the US so there's not as much demand for AC.
I would highly recommend a subscription to Lapham's Quarterly if you want to get a wide taste of the "classic" cannon. Essentially, it is a collection of writings and art revolving around an overarching theme (The last two issues, for example, were "Politics" and "Intoxication"). The content includes fiction, poetry, letters, journal entries, biographies et al. It is all very high-quality stuff and I've been using it as a proxy for what to read next i.e. I'll read a really great excerpt and then I'll order the whole book on Amazon.
Agreed. The article says:

$ grep needle haystack|grep silver

This sucks.

It would be nice if the argument against this had some sort of substance.

In most cases grep is going to be faster that ack. If you are searching large files this can make quite a difference.
As the famous saying goes: All models are wrong, but some are useful.

I agree that MBTI is largely unscientific, but I would point out that a model doesn't necessarily have to be scientific to be useful. To me, the value of a model is in the conceptual framework it provides you to work with, and the common language it gives you for discussing ideas with others.

One doesn't have to believe that anyone is absolutely an "introvert" or an "extrovert" for the idea of an introvert or an extrovert to be useful, for instance.
The trend setters are at it again, the New Social Internet
Actually, the "entitlement" our generation is accused of is different than the entitlement that refers to programs like social security. The difference is one of connotation. The former implies that us "kids" have feelings of entitlement in the sense that we think we deserve everything (but actually don't). Whereas the latter is the literal meaning of entitlement, i.e. people pay a certain amount of money out of every paycheck for decades, and as a result are entitled to the returns in the form of social security when they retire.
"HN questions should leverage the group intelligence rather than searching for the veritable answer in a haystack."

Assuming intelligence is "an adaptation… To say that intelligence is a particular instance of biological adaptation is thus to suppose that it is essentially an organization and that its function is to structure the universe just as the organism structures its immediate environment" I do not see a best way to "leverage the group intelligence" than helping community members to adapt.

I did not ask for "the veritable answer in a haystack", but for some experiences and suggestions regarding how to proceed.

"no one the community knows the answer"

I also find it difficult to believe a community of entrepreneurs, like HN is, does not possess the right knowledge to give its 2cents on this.
Slow Merging in R
Indeed, it really sounds like a very similar experience, up to and including the code generation.

One more thing I ended up adding (that isn't on your list above) is a true string type to the 'C' language (backwards compatible, works with pre-defined strings as well), including garbage collection. I found that in order to get the right level of abstraction the C string type was simply inadequate, it kept forcing things into the foreground that should not even be visible at that level.

The one thing still missing is copy-on-write for string duplication, but that's a pretty tricky thing to implement in a thread safe and portable way. This would give a huge performance boost, but at the moment that would be just another case of premature optimization.
I do wish the author described which 'ack' is being lauded. When I attempt to use 'ack' on my linux workstation the results are confusing.

moses@deunan:~$ </etc/mime.types grep application |grep x-ruby
application/x-ruby	rb

moses@deunan:~$ </etc/mime.types ack application x-ruby
application: No such file or directory
x-ruby: No such file or directory

moses@deunan:~$ ack -h
ack v1.39 Copyright 1993,94 Ogasawara Hiroyuki (COR.)
usage: ack [-{e|s|j|c[c]}] [-{a|A|o<file>}] [-zCntud] [-{E|S}] [<file>..]
Ask HN: Hone your AI skills by solving challenges. Interested to participate?
I'm one of the founders of HackerRank and we're building a platform to<p>Currently, I'm going through various courses in Udacity/Coursera/edx, etc. and putting up challenges based on that (Tic-tac-toe to code min-max algorithm, etc.)<p>However, it's very unstructured and we're randomly adding games/challenges. If this is done in a structured way, it could very well build an engaged community of problem solvers interested in AI.<p>If any of you would be interested in helping me with the structure of the content or contributing/creating challenges, would love to chat.
>Personal responsibility and the acceptance thereof is a major item on the checklist

There are two separate things going on in this discussion.

You have a personal responsibility to keep your data safe. I don't think anyone is disputing that.

Independently, softwares and services which handle user-created files should never, ever delete them without a direct instruction from the user. Regardless of your backup procedures, it is completely unacceptable for this to happen. Even if I had a copy of my data in a fire-proof safe on every continent, I would be appalled if I found that a file syncing and backup service like Dropbox had deleted some of my files and was unable to restore them, because i) it's an unacceptable thing for any software to do, and ii) it completely contradicts all of their company messaging.
Assuming Atwood's law holds true, we'll all be writing JavaScript by 2020.
These are all nice words, but when MBTI is tested it fails (citation from the article). So this model is wrong AND it's not useful.
My comment was an example of a pithy statment that did not have any deep thought or research. I was making a counter example.
Turing machines have infinite storage by definition, no such machine has ever been built (we're using approximations), real world restrictions do not apply to imaginary constructs.

If a Turing machine were not defined that way then you'd have to set some upper limit to the size of the tape and that in turn would have odd implications for what would be considered 'computable'. By making the tape infinite by definition you get much more meaningful answers about what is in principle computable and what is not.
Cumulative heat stress is the danger, so it's actually hot nights that kill people, probably because of impaired sleep quality. (Aside from heatstroke, most of these excess deaths occur in people already in poor health.) 95°F / 35°C during the day is fine, but 75°F / 24°C at night (without A/C) is deadly, especially considering that most apartments are significantly warmer than the outside at night.
Strange article -- I love ack, but this article doesn't really hit any of the reasons why, but focuses only on cases where I'd use grep anyway.
It's a valid sentence that means the same as, "I would like the world to have in it more people like McAfee." Would is the verb and the clause following "that" is its object, and the (validly) missing "I" is the subject.
NY newspaper runs interactive map with names, addresses of gun permit holders
By that logic, all of the startups that begin only serving their local market (many start in SF and expand beyond once it's viable; true in many other locations as well) would be 1/10 or 2/10.
Other industries often have approaches to issue tracking which predate the adoption of computerization within them, e.g. redlines in design industries or proofreader's annotations for writing.
Technology is culture

Technology is an aspect of civilization, which is not the same thing as culture.
A little feedback on voice. When someone says "You should stop using them. Now.", I expect the article to be about some system killing security problem, not an argument for the elegance of one tool over another. And if the argument is going to be about elegance, it better be absolutely compelling. The benefit of piped grep expressions is that you don't have to know anything beyond the principles of Unix to intuit their usage. For many uses (most uses for me), no thought is required -- grep fades into the background and becomes part of the programmatic brain stem. Commanding the reader to no longer use it is as effective as telling them to stop breathing.
You still feel inadequate because you're not as successful as some even more successful startups.

You still feel insanely stressed because there's even more at stake now.

You still wonder if you're working on the right thing.

I dunno. Things don't really change much honestly.
Thought this had been around a while - used it to plan flights for my last 2 conferences (3+ months ago)
> Independently, softwares and services which handle user-created files should never, ever delete them without a direct instruction from the user.

We're 100% in agreement on that. But since you can never be sure that the software that you're using is bug free (and in the case of dropbox there is now at least one more datapoint that confirms that their software contained at least one bug) you have to more or less count on losing all your data.

Dropbox messaging is of course not going to highlight the fact that their software may contain bugs, it simply isn't in their best interest (and none of their competitors do so either).

Maybe they have a section to that effect in their fine print but even if they don't on hacker news we really should all know better. Unless there is someone here that only writes bug free software... In that case please send me your resume.
I confused the apps in the text but the point was that those regexes look far worse than the equivalent grep pairs.
I thought perl regex was much much slower. Atleast according to Russ Cox,
Perhaps slightly off topic, but I was reminded of this story about how the political transformation of the "new south" may be linked to air-conditioning: http://www.pri.org/stories/politics-society/new-south-made-p...
It sounds like it.

But that too seems like a demonstration of something. The more "simple" methods with obscure names that populate the Unix toolbox, the more confusing it gets. I've gone from find to locate recently, for example, but their functionalities kind of overlap and so when I do find, I'm rusty with it.
Behind the scenes of a successful eBook launch ($26k in 24 hours)
Should Facebook have a Chinese Wall between Product and Platform Data
Searching text files, not parsing.
"This gets even more painful when considering the multitude of heaps in your average browser, chrome layers written in Web technologies, and (iirc) Firefox using a non-moving, non-generational GC. Whereas a multi-process browser has a vastly cleaner solution to all of that: it simply disposes of an entire address space (including all fragments and leaks) when it's done with a rendering context."

You're overstating the impact of JS here. JS memory is allocated in large "chunks" in Firefox. This minimizes external fragmentation. When a rendering context is destroyed, all of the chunks are immediately destroyed with it; because of compartments, we know that there are no chrome JS objects interspersed with the content JS objects, so we can just destroy these large chunks. So the amount of JS-related fragmentation resulting from closing rendering contexts is minimal in practice.

Regarding chrome layers written in Web technologies, this is somewhat orthogonal, since in all browsers chrome allocations stick around for the lifetime of the browser. C++ code has no compaction story, and, unlike JS, it has no reasonable path to achieve compaction in the future.
Nice, thanks for the detailed post.
Ack is sweet. Ag is sweeter:

http://github.com/ggreer/the_silver_searcher
To be fair, xmonad has no taskbar or widgets. I use Taffybar with it and it adds about 10Mb.