skysight-inc/HackerNews huggingface dataset:
Perl started with roughly the same goal. awk, sed, grep, etc. weren't quite powerful enough, C was too low-level, Perl mixed them all up with real programming language features, while still being very usable in one-liners.

I don't think this improves on Perl. Being compiled to Bash might be interesting, if your deployment systems don't have Perl. It used to be unthinkable that any UNIX/Linux system wouldn't have Perl...but, several distros no longer install Perl by default (which is annoying as hell, to me, as Python isn't at all an acceptable substitute for one-liners and shell+ tasks). But, in that case, it would need to compile down to POSIX shell, because Ubuntu doesn't install bash by default, it uses ash (a small POSIX shell). So, bash has the exact same flaw as Perl for that use case.

Anyway, I don't generally think this adds things that I wish for when working with shell scripting, and having to compile it (even a quick compilation like this is likely to be) takes away one of the biggest benefits of scripting languages.
It's a patronage job. Most of them are.
I would be suspicious of any subroutine whose function couldn't at least be described in words. So I agree that a function might be practically impossible to use in any other context, but it's worrisome to me when I see a function that doesn't do something that can be described in words.

In most cases, after factoring out a function from a bigger function, it's usually a good opportunity to think about what this function really does, and to make it do something conceptually simpler (even if that is less tailored to its sole use case). This way, you can even write meaningful tests for the new function.
Humans are computers so it does not matter.
>If you are offering elimination of credit availability as a solution...you believe wealth of parents is a good metric...

Perhaps a better solution would be merit-based grants. If you graduate in the top 10% of your high school class, Uncle Sam will foot the bill for the equivalent of in-state tuition/room/board. As long as you keep your GPA above some threshold, we keep paying for 4 years.
Sign that you're a bad person (pronounced 'karma whore'): Relinking something that is already practically linked at the top of HN. Seriously, this is linked at the top of the article currently at the top of hn (https://news.ycombinator.com/item?id=9167008). You don't have to link us and this is a clear and dumb grab at stupid imaginary points.

The number of slots on the front page are limited at a given time. This is already effectively on the front page, so re-posting it is effectively wasting a slot.
C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.)

That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code; it didn't take much to get inside the head of a C compiler, so you could be reasonably sure that a simple piece of C would result in a similarly simple piece of assembly out the other end.

That, of course, was well and good when it was reasonably simple to predict actual performance from glancing at assembly code, which assumes opcode performance (as opposed to, say, cache performance) dominates how fast the code runs.

Now... how many of those things still hold true on desktop and server class hardware?
Okay, but real engineers can rely on the quality of their building materials, like mortar, brick, concrete and iron, with constant quality through decades or even hundreds of years.

Contrast that with the building blocks the 'software engineer' has to work with. Microsoft might upgrade some DLLs your product depends on, overnight. Will your product still work? Your application probably relies on components written by others. Are they infallible? Can you even inspect the components for defects?

I sometimes have the idea that software is built upon quicksand, and the building blocks can and probably will change before the project is completed.
all those pictures, all this data, why doenst anyone use photogrammetry to generate 3D models of streets instead of clunky photo panoramas?

We should have detailed 3D maps of whole cities by now.
This is an oversimplification, which is not taking into account human nature and especially social dynamics, which makes things more complex.

Being offensive towards somebody, in isolation, is "normal", but in the context of a group of peers, imitation can fuel a chain reaction, which turns individual offense to group aggression. Obviously we're talking about verbal aggression, but when somebody writes about gang rape, then it's serious business even if it's not real.

There is a significant difference between "airing thoughts" and cyberbullying.

Those are not necessarily "agreed thoughts"; in the context, they can be seen as "lack" of thought, that is, groupthink of people who has little to do with their minds in a certain moment.

Selling a gun is one thing. Putting a gun in a public place with a sign with written "use me" is a very different thing. In the same way, internet comments are already used to channel anger because of their anonymity; if a medium adds groupthink and proximity to anonymity, things develop on a different level.
There are too many people seeking too few jobs. Fair compensation would thus be lower.

"Fair" does not only mean "fair" for one side.
The Matasano hiring process (to which this article refers) was designed in part because of this bad experience you've never had. I've seen it happen repeatedly over my career; people who'd pass interviews and then, over 15-20 minutes of face-to-face discussion a couple weeks on the job, not be able to comprehend the idea that a C pointer needs to point to valid memory.

That's what's so mind-blowing to me about our terrible process today. It aggressively tries to find and dispatch unqualified candidates, so much so that it forcefully repels talented people. And it fails miserably at screening out people who can't code! It is the worst case scenario of processes.

It's also really important to remember that the problem is People Who Can't Code, not "People Not Smart Enough To Code". Time and again I've "worked" with people who could very effectively critique my own code, who could participate in design meetings down to the bits-and-bytes layer, and, having taken responsibility for actually implementing some portion of those designs, could not commit usable code to save their life. I don't know what the deal with these people is, but they are out there: plenty smart, totally fluent, and completely ineffective.

I was talking to Erin this weekend about the phenomenon and realized that these people not only exist, but are actually favored by the way the market works. A smart person can last many months in a dev role before anyone realizes they're ineffective. Then, it takes many, many more months to manage them out of the team. By the time the story plays itself out, the bad team member has more than a year on the job, and when they parlay that resume line item to another prominent job elsewhere, their previous teammates aren't outraged but instead relieved. They end up with gold-plated resumes and tons of credibility.
Elon Musk's rule works pretty good for finding a "terrible engineer"

"How Elon Musk Can Tell If Job Applicants Are Lying About Their Experience"

http://www.businessinsider.com/elon-musk-job-interview-rule-...
I read both the "good" and "bad" programmer articles, and must now confess:

1. I'm a "fantastic" programmer who is "destined for more."

2. I'm a bad programmer.
I spent five years working for McDonald's, and I'll say that I've never worked for a company before or since that was so easily distracted and unfocused. The general philosophy from head office seemed to be "everything is always a priority all the time". There was never any sense of what truly mattered, and there wasn't a clear vision for the future of the company.

I'd speculate the reason for this is that when you're insulated by the sheer volume of money that McDonald's was back in the 80's and early 90's, you're effectively living in a world without scarcity. As a company, they've never really been forced to make difficult choices, and haven't developed the ability to do so. Instead, they just choose everything, and hope that if they throw enough mud maybe some of it will stick.
You're assuming incompetence where one might very well expect malice or at least interests at odds with the ones you'd prefer.
Please don't be rude. The second paragraph makes your point just fine.
Can you be more specific about the debate to which you're referring? The one with the light/heat problem?
> “The nurse said that the lights from the phototherapy treatment made the baby’s hair grow,”

> The other mother, also 18 at the time, asked another nurse why her baby lacked hair. She was told that phototherapy could also shorten hair.

Unfortunately, this kind of attitude from incompetent employees is damaging to the society, and it is quite commonplace in France.
The terminology is chosen selectively to deliver a provocative headline. At most US universities, the title "professor" is the highest academic rank (there are chaired professors, but that is just a full professor with the benefits of a chair). "I taught classes at four universities" doesn't draw the same number of clicks.
Yeah, I'm not saying there aren't terrible programmers. I'm just saying that everybody can write a 1 to 3 line "for" loop and navigate a directory structure :) That's the level of incompetence the parent was describing.
Ask HN: Should I prioritize learning algorithms and data structures?
I intend to eventually formally learn CS algorithms and data structures. So far, I haven't run into a situation where not knowing them has catastrophically hindered the viability of my code. I understand that I don't know what I don't know. [1] I often see comments along the lines of, "I learned algorithms and data structures while getting my CS degree, but rarely (or never) used them in practice. Without reviewing them, I wouldn't likely pass a technical interview that heavily relies on whiteboarding and CS theory."

Is this most often the case, or is it just the case that is most often verbally expressed? For each professional programmer who doesn't know or rarely uses CS theory in practice, is there one or more that uses it regularly? I understand there will be specific positions that rely on CS theory more often, but my questions are meant to cover the general range of professional programmers.

I prioritize the list of topics I wish to learn or improve as there's too many to learn them all within a given time period. I often push algorithms and data structures down the list below topics I immediately need to know to complete parts of projects following best practices as well as I'm aware. The strongest case I can see for learning or memorizing algorithms and data structures before I encounter a situation that requires I implement them in practice is in order to do well in a technical interview. I wonder if I'm really restricting my ability to code better because my thoughts on this are misguided. Should I at least skim through resources on CS theory so that I can better recognize situations where I should utilize it?

[1] http://en.wikipedia.org/wiki/Dunning–Kruger_effect
Really nice design throughout both this site and the open listings site!
Depends on how you define simple:

If something is simple for the compiler-writer, then simple things do yield simple results.

If something is simple for the programmer, simple things often yield quite complex results.

For example, in a language that's simple for the compiler-writer, (1/10) times 10 is only very rarely 1. 0 is a common answer, as is some fraction which is almost, but not completely, unlike 1.

In a language which is simple for the programmer, Heaven, Earth, and minor deities will be moved to make (1/10) times 10 come out to the obvious, simple answer.
> exponentially cheap

Solar is following an exponential fall, but the tail has long been wagged

http://io9.com/solar-powers-epic-price-drop-visualized-51044...
It's not uncommon for lecturers in high-paying fields to make more than tenured faculty in the low-paying fields.
Instead of unions or new laws or strong-arming from DoE, what really needs to happen is people need to realize there are far too many people trying to teach at the college level. Stories like this in WaPo are a good start.

There's no reason anyone should feel they're entitled to a career in academia anymore than we can all make a living as park rangers or porn stars.
I found this interesting:

>The article describes the conversion of Mountlake Terrace High School

> in Seattle from a large suburban school with an enrollment of 1,800

> students into five smaller schools.

> The conversion was greased with a Gates Foundation grant of almost a

> million dollars. Although class sizes remained the same, each of the

> five schools had fewer teachers.

This is really funny as there is no really sensibly put hypothesis that why the smaller schools should fare better.

So they looked at data and thought that they see that smaller schools do better but forgot to ask "why?".

Now having hypothesis that smaller classes make results better as teachers would have more time to deal with each child makes much more sense.

And this could be then tested.
I would instead measure the quality of the programmer by the volume of problems solved / tasks completed, aiming for the least amount of code possible, or preferably no code at all.
I think it grew out of very much the same idealism that still drives Ted Nelson to this date. I guess to unify all of human knowledge to reach a higher form of understanding just isn't on most people's mind. Not even those whose day job it is to do just that, as is my experience from dabbling in academic publishing.

This reminds me of an old blog post, Charles’ Rules of Argument [1]:

“5. DO NOT argue with Lisp programmers, believers in the Semantic Web, or furries”

1. http://fishbowl.pastiche.org/2004/03/21/charles_rules_of_arg...
This is not surprising at all - watching a video[1] of DBS is very moving.

[1] https://www.youtube.com/watch?v=mO3C6iTpSGo
The Apple Watch won’t save you time
Most serious investors consider this number very important when making decisions. By this number i mean the amount of reserves. Yes, some of the methods of calculating it are a little arbitrary but it is the best information investors have as to the value of a company's reserves. Thus, it is very important.

And it is not completely arbitrary. For example the rules are the same for all oil companies at the same time. So the number is by no means random. And while the results depend on the price of oil on particular days, everyone knows the price of oil and what the key days are. So if some investors believe oil will climb back up, they can do some math and arrive with a number that better suits their view of the future.
I was born two months early, via c-section, in early 1980s. There was concern I wasn't going to make it the first month or so post. I don't know exactly why they felt they had to perform the c-section so early, but I recall that my mother was given something to try to accelerate the development of my lungs.

Seems to have worked out fine, I've always been able to hold my breath for an abnormal amount of time compared to my peers, and my cardio / endurance abilities as a child were at the top of my peers.
Fair enough. I guess for me, reacting that way (trying to modify the apology) to a "bad faith" public apology wouldn't occur to me as an option, so I didn't realize they were directly connected for you.

I agree there are multiple interpretations, mitigating factors, biased accounts, etc. I've already "picked sides" and I doubt much would change that. I don't know that there really is a way to "fit the facts", because all the "facts" we have are colored by two emotionally invested adversaries, probably both speaking from a calculated PR mindset. At this point they're both also speaking through journalists, who may be adding their own spin.
> I'm not entirely sure what we're talking about here. Is it that anonymous communication is a double edged sword or that teenagers are kind of evil?

We're talking about a medium which mixes the two (and more), creating a very ill outcome (writing about group rape is no joke, and I'm sure that's not an exceptional case).

> Either way, it would be very disturbing to see a company give out customer information without a warrant or similar, wouldn't it?

This is not correct. From the article:

"A student who felt that he or she had been the target of an attack on Yik Yak could theoretically pursue defamation charges and subpoena the company to find out who had written the post."
You should look at the graph [1: the article, 2: a hotlink] labeled "Welcome to the Terrordome..." showing the prices of various oil sources vs solar over time. If the fantastic decline in solar prices continue, many oil sources will soon be not economical. And yes, I know there's storage problems and energy density problems for mobile vehicles, but oil is still a riskier bet than I think you portray.

[1] http://www.bloomberg.com/news/articles/2014-10-29/while-you-...

[2] http://media.gotraffic.net/images/iQYuKSosjb3U/v16/-1x-1.jpg
Is "static code analyzer" the new spelling for lint(1)?

https://www.freebsd.org/cgi/man.cgi?query=lint&sektion=1

I've always been a big fan of code linters. They may not be perfect, but any bug you can catch at compile-time (or earlier) could be saving you hours of trying to track down runtime problems. In languages with a managed runtime such as ruby where you don't really have the same kind of compile-time checking, a good linter is even more important.

It was a pretty crazy day when I first found RuboCop. I immediately used it on the large amount of ruby I've written over the last ~decade.
Have you actually tried to see map info on a watch while riding? I have tried while driving on my Pebble, and it does not work for me at all. The display is too small to see anything useful and the amount of time needed to comprehend what is being displayed is scary.

Perhaps if it indicated one buzz for left and two for right, it might work, but looking at a watch while driving or riding does not work for me.
It really only depends on if you define simple as "can only derive simple results."

And, you do realize that one of the simplest languages for compiler writers, lisp, doesn't have to move heaven/earth to make that calculation work out how you want it.
> The only metric I care about for a bad or good programmer is simply the ability to produce a high volume of code, quickly, with no bugs.

"This code is unmaintainable" is a bug.

There are exceptions. They don't apply to you or your business.
It did conclude that it was a threat, and amongst the finer points of the case was that Elonis argued that the test should have been whether he intended the threats or not. The jury decided that a reasonable person would have perceived the accused comments were threatening.

Even a reading of a cursory summary of this case would have told you this. Did you actually read the outcome?
The subject of the whole thread: bad engineers, and the effectiveness of our various tests for detecting them.
Nobody is policing thoughts. A tweet is not a "thought".
At least the ones who self-select into taking intro CS courses.
I'd say somewhere between 1 in 3 and 1 in 6 people that graduated with me (from a decent university!) could not actually program at the end of their three or four years.

That said, the same goes for at least two of the professors...
But 2010 may just have been when they stopped updating a version number. It looks like early 2000s material to me, based on nothing in particular. There's also this:

When I (George) started to write CIL I thought it was going to take two weeks. Exactly a year has passed since then and I am still fixing bugs in it

The CIL paper was published in 2002. Actually the whole project looks interesting—arguably more so than the currently posted page. It should have its own HN thread sometime. https://news.ycombinator.com/item?id=836735 was a while ago!
In the US "professor" means anyone who teaches at a college level. The usage is very different than in Europe.
Thanks for the tip!

a = [2, 7, 8, 9]

highest = nexthighest = None

for item in a:
if not highest:
highest = item
elif item > highest:
nexthighest = highest
highest = item
elif not nexthighest:
nexthighest = item
elif item > nexthighest:
nexthighest = item

print highest + nexthighest
That header trick is a good one.

Ok, we'll put 2010 on it even though it is likely quite a bit older. An upper bound is better than nothing.
It looks like John D. Norton has a thing about Einstein: http://www.pitt.edu/~jdnorton/Goodies/
This reminds me of another Larry Wall quote about the bad (old?) days: "It's easier to port a shell than a shell script." I'm honestly surprised and a bit disappointed that Bash isn't universal these days.

This seems like a really bad idea, since it apparently throws out good things like pipes, input/output redirection, wildcard expansion, and interactivity, but doesn't offer anything over the standard scripting languages.
This article is incorrect from beginning to end. As a simple counterpoint to this idea that "I have never once heard a firm talk about the idiots lurking in their own offices"

Here is the well documented _policy_ held by major (not just tech companies mind you) firms to fire the bottom 10% of their employees. http://en.wikipedia.org/wiki/Vitality_curve

By the way a form of that is used at Microsoft and Google, probably others as well, but the idea that Silicon Valley and Computer Programming are the only place where people are on the look out for "Secretly Terrible Engineers" is absurd, its just as absurd as the comments I am reading where no one has ever worked with one of them. As a hiring manager I turn away over 95% of candidates and even with a very selective hiring process you get people we need to let go because they can't perform at the level I expect them to even after passing a rigorous interview process, so to say they don't exist is stupid, its like claiming that no one ever gets fired for not performing their job well enough.
You don't believe shale oil is an explanation... why? Have you looked at the barrels/day production figures for shale oil? They are gargantuan.
You'll find this data interesting: a graph of the growth of management vs faculty at the UC over time [1]. Apparently UC senior administrators now well outnumber faculty! Which is pretty fucking unbelievable. Money quote:

For another comparison, the latest total number in this management category
(SMG + MSP) is 9,457 FTE (full time equivalent employees) while the number
of Regular Teaching Faculty is 8,657 FTE.

[1] http://reclaimuc.blogspot.com/2013/01/uc-administration-cont...
Classic supply shock.
Truth #10: nothing is truly random.
You're right in pointing out that bad actors in media will continue to manipulate with disinformation and low information articles.

There is a very high amount of simple incompetence/too busy/poor training.

I'll point out that in developing models for these types of story generation that work could, in turn, be done to validate that what you are reading passes some minimum bar of information quality.
Pairing git-config's include directives with a separate semver-tagged repo for your Git code sounds reasonable.

I guess what I was getting at here is that I haven't come across a good analog to npm for shell scripts or dotfiles "modules". Using node/ruby/py/etc instead of shell scripts is often overkill (debatable for gitgoodies), but having the standardized infrastructure is valuable.