skysight-inc/HackerNews huggingface dataset:
"But seriously, does anyone really think that a beginner should learn NoSQL before learning SQL?"

Hmmmm - back in the day, I learned to use hashes, tied hashes, and BerkleyDB way before learning to use SQL and SQL libraries.
JavaScript is the most deployed interpreter in the world, and therefore almost certainly handling the greatest amount of independent data in the world. So whether or not you think it's a bad joke, it's important.
They even explicitly list the fact that Gitter uses Node.js as one of the advantage of them. I really hope they aren't teaching their students to pick third-party SaaS offerings based on whether or not they like the same tech as you do.
Sure. But the premise of the question is, what language (singular) should someone pick up to do "security for companies" (I read from that: appsec). I cheated by giving 2; formally, the right answer to this question was simply "Python OR Ruby".
in Spain Nuclear Spillage fines are cheaper than Solar Energy fines
I think I sent the wrong message with the Intercal comparison.

My point was that the logic that brings you to "you need Javascript if you specialize in Javascript security" works for any language, including Intercal.

It was not that Javascript is a language as dumb as Intercal.

If I had to make a list of 3 languages to know for security people, Javascript would probably be my #3 (Java might be #3, and Javascript #4; I'd have to think about it.)

BTW: Unlike a lot of people on this thread, assembly wouldn't be in my top 5. It is much, much more important that appsec people be able to fluently write C than it is that they be good assembly programmers. Even full-time reversers don't spend that much time reading assembly in bulk.
All these rotating pieces reminded me of Sussman's talk on watches http://video.mit.edu/watch/an-electrical-engineering-view-of...
"I wouldn't go so far as to say beginners should not learn node at all."

I'm showing my age here, but… I remember a quote (but can't recall who to attribute it to) along the lines of "Perl is not a good first programming language. It's a great _last_ programming language"
No, they are not. (Unless the concert venue is on city-owned land such as a public park.)

Grocery stores, shopping malls, and hotel lobbies & conference rooms are not public places either.

The confusion about "public" stems from casual usage vs legal usage.

casual: "I can't be seen in public without my makeup and bra." In this case, "public" just means the opposite of "not at home."

legal: The boat dock is public property but the restaurant at the shore is private property. You can shoot photographs at the dock but if at the restaurant, if management asks you to leave because you're snapping photos, you are required to comply.
He may well be allergic to something in their feathers. While I am not a huge fan of hot dogs and what goes into them I suspect that even the worst manufacturers draw the line at letting feathers into the vat.
irc supports pretty much nothing besides text. With Slack, you can format, highlight code, upload pictures and documents, it supports Google Docs out of the box, there are plugins for Trello, git, and who knows what else. And it works flawlessly on all mobile OS (good luck getting a decent irc client running on iOS).

irc is a dinosaur compared to what recent team communication software like Slack and Hipchat can do.
I've finally switched to pinboard.in - the browser addons are definitely not as good, though.
I don't know; honestly, I think the nicest part about wasm is that it might allow us to stop making more dialects of JS, get rid of JS altogether and compile to the web whatever language we like (I'm looking at you Haskell).
Expected something chess-related [1]. This appears to be a different type of game with many players and different understandings of the rules.

[1] 1.B4 Opening https://www.youtube.com/watch?v=o9jaaKUWwBI
sigh

It is 28000 words. It can't cover everything. Some things will get left on the cutting board. Get over it.
You can always sort portions of it and then merge those portions. In that case it might actually make sense to use packets on dense memory in a linked list. You could put the packet with the highest high value ahead of the other and merge middle out.
Re 2) I think that's not just "unix wackiness", but plain wackiness. But as I said, I never did like perl much -- even if I do like awk/sed/grep/sh.

Perhaps one other factor is the rise of GNU/Linux and death of Unix. Linux might still be the world's most "self-incompatible" operating system -- but it's a lot more coherent than a mix of various flavours of Unix/Solaris/BSD etc.

Shell scripting makes more sense if you can assume a certain lower common denominator of GNU sed/grep/awk and posix and/or bash. Along with more or less consistent file system layout, location/availability of special files etc.

Add to that the rise of XML, then json, and perls built in regular expressions doesn't set it so far apart any more -- you'll need a library/tool for parsing/serializing anyway.

Still think it a bit odd to call it the "vacuum left by perl" -- it's probably more the flood created by python/ruby/newcomers...
And C compilers can generate specializations if everything is in the same translation unit. What I was trying to point out is that less abstract doesn't imply better performance. It isn't C > C++ > Python. What the machine ultimately has to do is what matters.
> So we have no alternative but to switch.

It seems unlikely that all 5000 people are actively using their Slack account - if you started automatically deactivating accounts that haven't logged in after 3+ months (a pretty easy Cronjob using the API), you would most likely stay well south of the limits. You can always Email people with something to the effect of, "Hey! We've turned off your account, if you visit the site again, we'll turn it back on, no big deal".
Thank you for the reminder -- I had found that at some point, the forgot about it. For other's wondering, a version of hn lives in the lib-folder (news.arc).
While I agree that they had totally unrealistic expectations (and you forgot to highlight the 5 service integrations bit that he also complained about later), slack does also advertise "no limit on users" when they do in fact have a limit.

http://i.imgur.com/kNTkFGT.png

"Small teams" and "no limit on users" aren't really compatible, and it's pretty normal for people to just read the bit they like and ignore the rest.

Slack should probably just put a 100 (or even 500) user limit on the free plan to discourage people from signing up with such unrealistic expectations.
I have to say I am guilty of this. I don’t spend any time mentoring anyone and I probably should.

On the positive side I don’t both going to listen to any of the so-called experts.
> If you hire someone to do 9-5 job and you expect them to do more than that, it's your fault if that fails, not theirs.

I think the biggest teller of an unmotivated person is a generally negative, problem-focussed attitude. No matter the hour of the day, "We can't do x, because..." will destroy nearby "We can do this, if...." people, eventually.
Marketing and promotion is just as costly, if not more costly, than it ever was. I know too many wonderful open source projects that failed and left their author bitter because they thought that merely creating a great program was good enough.

The "build it and they will come" is a stupid Hollywood fantasy. Even the Beatles went nowhere until they hooked up with promoter George Martin.
Note it is now http://designernews.co but your url will redirect
Thanks for the reply

> we're terrible at estimation and "no" is your most powerful way of fixing that situation.

This is also my problem half the time, and that's what made me wonder if I keep realizing my estimate was off, and it's taking me more time to complete my original estimated work, does that make me a "9-5, unmotivated worker"
Read it again... he only gets paid if the photo is used by the media outlet specified in the contract.
Hackers ground 1,400 LOT passengers at Warsaw airport
I think you're more describing a heuristic or a rule of thumb, aren't you? I think the root problem of all of this is that it's impossible to tell ahead of time when it's more efficient to use shortcuts, and when it's actually worth the time to go through the exhaustive analysis.
He is obviously talking about engine programming. For tools and back ends game studios will use whatever.
After reading this I have but one request; please stop teaching people to code.

Your solution to a problem you have with some software is to suggest they simple throw engineers at it is sadly pathetic.
I agree with you in spirit, but it's simply inaccurate to suggest that a shopping cart does not deal with mission critical data.

the fact is, Amazon does use Dynamo for a mission critical financial purpose. If Dynamo lost data Amazon would not use it for arguably one of the key pieces of their success.

the article I linked covers how they do this, and how it stays accurate, scalable, and robust.

anyways cheers, I hope we have not hijacked this thread about MySQL bugs too much.
Didn't everyone use this all the time to pause 300 & 1200 bps output in the days before screen and scrollback terminals? :-)
I actually don't think you need to know assembly all that well to do exploit dev and reversing. What you need is:

(a) native-level proficiency with C and the memory hierarchy that C tries to abstract (ie: you want to understand what goes in registers, when, and why, and how a stack frame is laid out and why)

(b) at least limited working proficiency with compiler theory, most especially the analysis of control flow graphs

As time goes on, knowing little working-programmer details like how LEA gets used for multiplication is getting much less important, and understanding compiler IRs (particularly LLVM) is getting more important. Weirdly (but awesomely), both exploit dev and reversing is becoming more and more theoretical (predicate translations and satisfiability, symbolic execution, &c) and less and less systemsy, and the systemsy stuff is getting larger-scale: like, writing whole-system emulators to reverse firmware targets.

I guess my argument would be: you don't ever need to learn how to write a decent assembly program to get to (a) and (b), and by the time you have (a) and (b), you'll easily be able to pick up whatever assembly you need as you go.
I try to visit his site every Friday. I like his no nonsense videos.
Demoscene – The Art of the Algorithms (2012)
Reed Hastings startup story: Netflix
From my experience I haven't seen anything like this in the last few years. Botnets are controlled primarily from C&C web services or other SSL/TLS (+encrypted messages) transport via web.

The brute force ddos attacks I've seen are on illegal private server emulators and Minecraft et al. Maybe this is just a completely different experience by being in differnt part of internet.
Another interesting data point is libFirm: http://pp.ipd.kit.edu/firm/ which regalloc's directly over SSA.
http://www.americaherald.com is another site like that. I would have never known it existed, until someone randomly emailed my wife and let her know that the site was using a picture of her taken off of a university website and saying she was a journalist working for them. It was actually kind of creepy.

I was surprised that a site like this could make it into Google News results.
Is it not intellectual work? Sleep deprivation really wrecks my ability to think clearly.
I Don’t Understand LinkedIn
Libscore: View the growth of open source libraries
In the case of this magazine, it's clear that software security is not on the minds of the professional programmer who wrote the issue. It's also not a concern of the editor or any of the team that contributed to it.

From what I have seen, that neglect is not unique to Bloomberg.

This was a surprisingly dumb and disingenuous thing to see from Bejtlich, who should know better. In particular: Bloomberg (the company) has for the past decade or so managed one of the better application security teams in the business. He meant to pick on the magazine, not the company, but sauce for the goose, die by the gander.

Bejtlich is not a software security person (his background is in network security and IR). I am. I thought the Bloomberg Code article was wonderful, accomplished exactly what it set out to do, and picked a very worthy thing to accomplish.

We get to better software security by having more people understand code.
thanks for the reply

> I don't count the hours that I put in anymore. It's either getting a task done

how do you define task? if you have a task estimated at 1 day, and by the end of the day you're not finished with it, do you finish it or count it as wrong estimation and finish it later?
Also a pinboard user--it's fast, minimal, and reliable. Definitely recommended.
This changed with V8, IIRC the PC can only be updated on branch or an exception...
You're missing the biggest difference: longevity. An album can sell for 50+ years whereas an app... well, let's just say it's one step above "ephemeral".

All the more reason app developers shouldn't/wouldn't go for such a deal.
It seems like you could, but it would make the opening process more complicated, because you'd have to rotate a revolution for each additional rotor for all the rotors to catch.
So you think scripting languages that have no type constraints will somehow advance to the point of being the same as writing native code?

Or.. do you think that maybe you know only scripting and dynamic languages and you want to believe that at some point a solution will come to you instead you having to learn programming at a lower level?

I've seen the latter attitude in plenty of people. It is better to just bite the bullet and learn a lower level language. And there is always Julia.
Sixteen out of a hundred thousand? That's a lot lower rate than I'd have expected.
I was pretty impressed with the circular saw lap joint, myself.
Personally I do not perceive software as SaaS if it is not browser based. That's where the synergy comes from - easier to debug, maintain, etc.
I try not to make a habit of reading reviews written by people who have not actually read the thing they're reviewing.
I've heard of people negotiating 4 or 4.5-day work weeks for 80% or 90% of the position's full-time salary. In the few cases where I've seen that happen, someone in the company had prior work experience with the candidate and knew that they would be worth bringing in even on a part-time basis.
They where only using slack for two months and hit the limit (of almost 9000).
No questions, just a thanks for making your videos. You're on my short list of regular 'YouTubers', despite the fact that I have zero woodworking experience, and don't have any plans to change that...

I really enjoy watching your approach to design and problem solving (and obviously your precision and craftsmanship).
You could go to more numbers. Though it gets awkward to dial, and cumulative precision become an issue.
Airbnb and Uber’s sharing economy is one route to dotcommunism
Don't worry.

It won't be long before the marketers focus on us -- the marketers for arthritis, incontinence, gout, and erectile dysfunction medication that is.
> An example of "innocent intermittence" recently came up
> at my current employer: there was a test that invoked a
> web service twice, verifying idempotence. It then
> asserted the responses were identical.

This is not innocent intermittence, this is a bad test. No-one should get in trouble for it, but I would certainly expect senior developers to get involved to find out:

Why is idempotence being tested for on the response side rather than on the execution end? If the call is truly idempotent, then a changing date-stamp means that the test has captured the information envelope as well as the data payload, and is testing that, which is sloppy - you'd probably be upset to see the HTTP headers being tested in the same string, so why other pieces of the envelope too? If a test is calling a "web service", then it's either an integration test (so why's it testing for idempotence, rather than testing the envelope?) or it's a unit test gone awry. Are there other tests that do this too? Could this all be abstracted out in to a sensible library to make it easier for more junior developers to not make these mistakes?

The moment you start accepting less than 100% test pass rates as being OK, the moment madness descends and you lose much of the value of your test suite.
I think there's definitely value in this kind of JavaScript-in-JavaScript type of dev utility. The main advantage is cross-browser dev utilities - which brings us closer to a cross-browser dev environment.

Browsers have historically opted for hiding runtime management (debugging, etc) behind myriad APIs, most of which can't be accessed from the running program itself. I would love to see a cross-browser way to hook into these sorts of things without extensions or at least with standard APIs.

Overall this would be much better for us as coders. And this would open the way for all sorts of cool tools. Consider V8's live code reloading functionality. But imagine if it worked cross-browser and could be called from the program itself. Your webserver could send a signal over websocket, and you could perform hot-swapped deployments of your webpage, and all connected browsers would be updated. The browsers could be customers', or they could be inside that mobile device that's a pain to debug.

It would also be much easier to prototype new dev tools and ways of coding. For example, programming against Chrome's extensions APIs (as great as they are) is somewhat limiting - last I checked you lack direct access to the embedded CodeMirror editor for example. There are a lot of security-focused restrictions. So people workaround this. They rewrite editors and file managers from scratch so they can get the desired flexibility (lighttable, brackets, atom, etc).

Personally I love to see projects like MetaES because I feel like they are inching us closer to something that could be the next step.
It wasn't really by plan. I quit my job at Blackberry (then called "Research in Motion" and decided not to work for a while. The website was good to spend time on, and it just grew from there.

Looks like I answered too many comments, cause hacker news is telling me to slow down. Oh well. No more answers!
Intro to Spark
Sure.

If you want a good survey of the world of optimal register allocation/scheduling, someone just wrote one.

http://arxiv.org/pdf/1409.7628.pdf

It's pretty darn well written, and covers the world as it exists today.

The author later went to publish a nice thesis on optimal integrated RA + scheduling.
https://www.sics.se/~rcas/publications/TRITA-ICT-ECS-AVH-14-...
I never really have understood this kind of sentiment. There are a huge number of people who like js, to the point that it is used in a bunch of places that are not the browser. In terms of dynamic scripting languages, it's a fast, easy, and flexible option.
Futures for Crystal language
Hope and life are indeed flowing here in Seattle. For some into bank accounts, for others into dump trucks. Thrilling isn't the word I'd pick, but how could newcomers know what's been lost? Expecting empathy from them is unreasonable. As absurd as expecting someone to see around corners.
Some people want a statically-typed language for larger apps. Tooling support can be made a lot better for statically-typed languages because it's easier to analyze.
Expert Distributed Systems Engineer Needed at Blockspring
VERY well said
Interestingly enough, the only people who have a hard time with callbacks are those who have been coding synchronous code for a long time. Anyway though, with async/await, the callback days are coming to an end. Other than that, the article is just complaining that express and mongo are too low level. Seems almost better to teach people low level stuff first.
Well, for IB I can't comment much. I'd say there's a lot of downtime, playing with basic models, etc.

In S&T it's quite different and depends if you're on a quant desk; relatively illiquid trading desk, like some kind of structured product where you'll get a few trades a day; or a more normal fixed income or commodities desk where you'll be making markets throughout the day constantly trading, analyzing, and monitoring the markets.

On my desk - which falls under FI, although I won't say which area - it's quite liquid, client-focused, and fast-paced.

6am-7am - Making sure all your systems are launched, working, and then analyzing what your colleagues in London, Hong Kong, and Tokyo were up to while you were asleep. Often your book will be managed by those folks and so you'll want to know what/how they executed (assuming they didn't call you through the night to get your opinion, which does happen depending on the product you trade).

7am-5pm - You're constantly trading; analyzing your positions; looking at your risk; calling middle/back office to get things analyzed; on the phone with colleagues in London, Tokyo, etc.; perhaps stepping into the odd meeting, getting someone to watch your monitors; talking to your sales people, giving them ideas, feedback, what clients should like a certain thing at a certain level, etc.

5pm-7pm - Making sure back office completes your risk, analyzing and amalgamating your PnL for the day, chatting with other offices just as you did at the start of the day.

7pm-11pm - Perhaps you'll go home and go to bed early (9pm or so), or, depending on your area, you may go to dinner with clients or have some other social engagement until 10-11pm.

---

Trading is incredibly diverse, but I think this largely captures the roll of a sell-side (Goldman) trader in most front-office trading rolls. Quant-traders, like you'd find at certain quant hedge funds, tend to be less common at sell-side shops. You'll usually have traders, who just trade, with maths, comp sci, etc. undergrads who work with the quants (who have PhDs in those fields and don't trade at all) to get the data, systems, etc. they want. As a result traders generally, well, spend their entire day trading. Even on quiet days you'll be glued to your screen waiting, reviewing, thinking about what to do next. Market making doesn't involve letting clients dictate where the market moves necessarily, it involves being a liquidity provider and risk mitigator, which is what I'd say traders on the sell-side largely are.
Apple should keep the free trial, but pay revenue only to artists who aren't multi-millionaires or extremely popular.

Then when Taylor still refuses to let iTunes sell her music she'll be seen for what she really is.
Can we get over all this native JavaScript junk and finally move to either platform independent llvm bytecode (wasm as I understand it) or just use the damn jvm? There's no need other than faster Dev times (which can be handled in other ways) to keep the code in a non compiled format anymore. It's nuts and super inefficient. Let's move on already.
Fun fact: Gibson got the idea for NAS from Pana Wave, a Japanese cult whose members believe that ordinary radio waves are harmful and go around in white sheets or something.
I suspect her ability to refuse apple the right to stream her album is also a product of her success. I doubt smaller artists have that right in their agreements.
Have you ever considered using a laser cutter, CNC, or the like?
Right, I think when you have a Dyn, you import all untyped code as type Dyn or containing Dyn. Then the idea is, when you unwrap a Dyn function at runtime, to distribute the function checks to the domain and range of the function.

Say you had some untyped function `f` that is Dyn -> Dyn.

(defn f [a :- Dyn] :- Dyn
a)

Running

(inc (f 1))

would wrap 1 in Dyn, then a Dyn exits as a return value, so no further wrapping is needed. Now it's `inc`'s responsibility to ensure it's really being passed a number, so it unwraps the Dyn and finds an int inside.

So you're right - it only works with first-order values without this kind of machinery, which end up looking pretty much like what I talk about in the article.