skysight-inc/HackerNews huggingface dataset:
Here is a Haskell action, that has the effect of waiting for 5 seconds:

sleep 5

This is in the IO monad and therefore impure. As we know, it is better to use pure functions when possible. Let us rewrite it as a pure function:

seq $ [0..] !! 1000000000

This accomplishes the same thing with no side effects, and is therefore better. Please note that spinning up your CPU fan is not a side effect.

Joking of course, but it does illustrate the point. Functions take time and time is user-visible, thus all functions are effectful in that way. And C programmers will roll their eyes at the idea that `getpid` has side effects, while allocating a million node linked list does not.

Really this is just talking at cross purposes. Haskell's notion of purity and side effects lives not on the physical machine, but in a formalism, and ghc is its imperfect simulator.
If your manager has no idea what your value is without your marketing, you work in a shitty environment.
I think you've misunderstood the implications of the technique described.

It's superficially similar to mocks, but the real power is that it defines _restricted_ effects, so that it is _impossible_ for the code under test to access, say, the current system time or to print to stdout. It is _only_ allowed to access APIs which are fully replaced in tests.

The real benefit is that the type system guarantees these tests are not flaky or intermittent - in unit tests they are guaranteed pure and deterministic.

This technique isn't applicable to languages like Python or C++ or JavaScript where any computation is free to have arbitrary side effects. In Haskell you can restrict computations to subsets of side effects, which is an enormously powerful technique, and is, for example, why Haskell's STM implementation is so great (and simple) compared to languages with unrestricted effects.
Those are pretty good, if a little verbose.
I find it hard to believe that a complete highly motivated team would need such a guidance. Unless we are not thinking about the same thing when we use the word "motivated".

To me, a complete highly motivated team (a team without any unmotivated person) would certainly feel like they should bring up some kind of organization. They are motivated, after all, and thus they want to get their work done.

A not motivated person, however, needs to be pushed, not in a bad way, but in some way, because he/she is unmotivated (don't feel like wanting to get any job done), and thus the hierarchy comes into play.

Most people fall in this "unmotivated" category. And that is (I think) the actual true reason why management exists in the real world: to push (unmotivated) people, so they get their work done.

Note: by "push" I don't mean "being an idiot". I believe that the presence of the manager is already sufficient for most people to feel like they should work, even though they don't want to.
Only a tiny percentage of websites uses a dark color scheme.

I have a small bookmarklet for nuking colors, which I can run via some shortcut (ShortcutKey2URL).

javascript:for(var e of document.querySelectorAll('*')){e.style.color=window.getDefaultComputedStyle(e).color;e.style.backgroundColor='#fff'}void(0)

Kinda crude but it works well enough.
WikiLeaks says it's leaking over 500,000 Saudi diplomatic documents
It depends. In this case, I would say it would be at least 100x, probably much more. But, that's because this only compiles BF (It is basically a POC after-all), and thus you have to use that as an intermediate language. BF is extremely un-optimal, and the compiler here spits out a completely unoptimized one-to-one conversion of the BF source to assembly that uses only `mov` instructions. Thus, the size of the assembly will balloon extremely quickly simply because it takes a lot of BF to express fairly simple things. Branching using only `mov` is also impossible, so the code instead uses a flag to control where the assembly writes it's results. Because of this, even when you hit the condition of a loop, if your condition check is before the loop's code, then it results in you running the entire loop's code another time, and just throwing out the results. It's extremely wasteful.

Based on this POC alone, it's pretty much impossible to guess how much slower a real `mov` only compiler would be vs. a regular compiler. It depends a lot on how much of this can be optimized. Directly compiling C to this via clang or gcc would be a good start. I have no idea how much work that would take though, and compiling anything more complex then BF is a real challenge in itself because of the branching problem.
After reading the deck I have no idea what exactly do you do. Given that it's in the context of "investing money", lack of this information makes me think it's a scam.

Wealthfront and Betterment provide a service similar to what I think you plan to do except I understand how they work: they take my money and invest it in stock or bonds based on my risk profile.

You take my money and do what exactly with it to grow it? The deck doesn't say and that's kind of the most import part.

You talk about blockchain which alludes to some connection to bitcoin but don't explain what does it have to do with investing money.

My advice: make it clear how exactly are plan to grow $N dollars I give you into $N + $M dollars.

If it's by introducing another fake money like BitCoin, then thanks but no thanks. Your deck mentions how people don't trust Wall Street. How do you expect people to trust BitCoin-like currency after so many bitcoin exchanges were either hacked or scams to begin with and loosing people's money?
It's a venue to bring up problems that could be bottled up. Properly conducted 1-on-1's don't have to be dreadful and can end quickly if so desired.

Manager can probe with questions such as "What's the biggest obstacle you're facing right now?" and "Anything you need from me to help you out?", but there are some weeks where nothing will come up, which would end the session.
Well, Turing machines do not have random access memory (which changes the big-theta complexity of algorithms), and that operations such as multiplications would be complicated and multi-cycle, whereas conventional CPUs can easily parralize them.

If you were comparing the performs of mov-only programs, a specialized cpu would likely be faster. Otherwise, there is a good reason we do not actually use Turing machines.
A Functional Programming Primer for Spark
Home Built Scanning Tunneling Microscope Electronics
> most people only end up unmotivated because of poor management
I don't find this to be a self evident truth. Can you provide some argumentation around this?
Thank you for helping fight the Dijkstras of this world.

thoughtpolice: "because it shouldn't take very much thought to see why HTTP servers are fairly complex pieces of software"

Dijkstra: "He was the first to make the claim that programming is so inherently complex that (...)" (from Wikipedia)

Down with industry pessimists and "astronauts" that think everything must be complex.
What Happens If You Fall into a Black Hole? [video]
If you can't fire or promote them are you really their manager?
Show HN: Best Quotes Book-Ultimate Source of Motivation and Inspiration
Imagine if some of the NSAs offensive budget had been used to update and secure these old systems instead. In terms of security I believe that the pay-off would have been much greater.
Hi, I have personal experience working with the some of the best software engineers on the planet for the last decade and despite everyone's best efforts, when a unit test suite grows to thousands and thousands of tests, there will always be some that are flaky. Perhaps they call into a code path which was unwittingly refactored to access a local database. Perhaps they read the current time for some time-dependent string formatting. Perhaps they mutate some global state and forget to clean it up. Perhaps they call into some code that opens a TCP connection to some third-party service.

Every large test suite I've seen in every language at every company I've worked with has intermittent or flaky tests. Maybe each test on average is 99.9% reliable. But across the entire suite, you will have some low-level degree of intermittent test failures. Then you need a team of people whose job it is to triage, investigate, and either fix or ignore those failures. This is a complete waste of human capacity, and it's not a very career-enriching task either. Haskell's ability to define restricted subsets of generalize IO is extremely powerful and sidesteps this entire problem.

The power of the technique in the article is that your tests are _guaranteed_ reliable by the type system, because it is no longer possible to accidentally call into some general IO action. Code under test must go through the World API, which is fully and deterministically mocked in tests.
>The workplace here and now is far kinder and gentler than almost any time or place in history (with the possible exception of contemporary, developed nations).

We had kinder and gentler workplaces 30-40 years ago.

We can thank the business community for destroying our unions for that, and neoliberal economists for providing a plausible sounding rationale for why it was in our best interests.

Also, while we haven't quiet brought back debtors prisons, child labor, back breaking labor and 18 hours days, we are certainly headed squarely in that direction.
I think that is an other can of worms. I would assume there will be some law to not allow that esp if it is a govt. issued document. Right now they might not be connected to govt database, but if they ever do then one can be in unnecessary trouble. All for an useless (imo) account.
DankMeow – Get your cat high
Two things:

1. The use-case I have in mind is an in-memory database because a. that is a significant part of what I do and am most familiar with and b. because in the age of large RAM, its most effective use is embedding large parts of the database within the application process (whether as an actual product, or replicating some part of a database's functionality ad-hoc). While doing so in an environment without a GC is certainly possible, it is both much harder and/or (depending on the effort spent) less scalable with increasing numbers of cores. I have come to that conclusion after spending many years trying doing that in C++.

2. I have no doubt that Rust -- and I take great joy in this fact -- makes a whole lot of things much easier than C++. But there is also no question that Rust is harder to program than most GCed languages. The question from my perspective, then, is not "why not do it in Rust?" but "why not in Java?". There is a good answer to that question: Rust is much more suitable than Java (in terms of performance and RAM footprint) when running in constrained environments. But unless you're targeting a constrained environment, why work even a little harder at all?

More generally, I believe that the most efficient form of memory management in unconstrained environments, in terms of both throughput and worst-case latency -- and I've had this discussion on HN with pcwalton -- is an environment that allows three types of memory: stack, scoped arenas (including a permanent scope), and a GCed heap. Real-time Java (RTSJ) provides exactly that. Combining arenas with Rust's beautiful scoped threads is a great idea. I believe that reference counting has no place in such unconstrained environments.
The thing is, I think, there are a lot of would be spawn campers. Capitalism keeps most of them busy farming resources
> Facebook is selling you as the product, and does not care about making your life easier or better, or making it easier to connect with friends and family.

Why can't it be that they can care about both of these things and acknowledge that it's a balance which can shift in either direction depending on the product they're putting out?
When I was living in China I had difficulty recognizing handwritten 9's and 1's. Their 9's are less half-circular than Westerner's are, and the 1's have a long stroke the top that looks like a sloppily written 7 to me. I would frequently look at a handwritten number and have to analyze what it was.
Wait... you believe that the NSA is easier to compromise than the computers of reporters from multiple international news agencies with various levels of computer security policies and knowledge?
>This is just basic economics.

"Basic economics" as some people call it, is a religion, not a science.

Basic neoliberalism, as taught in econ 101, is just as much a shallow pretext for maintaining existing power structures as Stalinism/Marxism was in the Soviet Union, and its predictive power is close to non-existent.

Guess why, for example, David Koch donated to Florida State University and then demanded the right to determine their economics syllabus? So he gets to dictate what counts as "basic economics".
That's not always true. Sometimes people end up unmotivated because the organization shifts its mission in one direction while they shift their values in another, and so what starts out as great mission-alignment falls out of alignment. Sometimes people grow out of a role when the role doesn't grow with them. Sometimes peoples' life circumstances change and they don't have as much attention to devote to work. Sometimes people are just looking to collect a paycheck and don't care about the work at all.

A manager should always start by assuming that a motivation problem is something he can address, and work with the employee to figure out what the real reason is and see if they can make the necessary changes. But sometimes, the employee and organization just aren't a good fit anymore, and it's better for both of them if they part ways and find new situations that are a good fit.
> after only a few decades of work (say, 1948 to 1993), turbo codes were discovered.

But LDPC codes were shown by Gallager in 1963[0], and while they were not feasible to implement at the time, saying that the theory waited for turbo code discovery is wrong.

[0] https://en.wikipedia.org/wiki/Low-density_parity-check_code#...
You're right, they never actually do any jumping. From what I can tell, they use a variable called `on` to control where every set of commands write their results too. They do some funky `mov` stuff to do a comparison, and then set `on` with that comparison. They use a stack of `on` variables and then pop off the value of `on` from that stack when you exit a loop.

They cheat to get a jump without using anything but `mov`'s by executing an illegal set of `cs` using `mov`, and then use the sigill generated to execute a signal handler, which is just the same spot that the code starts at. IMO, it doesn't really count, so a `mov`-only program requires at least one jmp instruction to work.

I think loops are achieved by simply running the code to the end without saving any of the results, and then hitting the singal and going back to the beginning - ignoring all the code until you hit the loop you're executing. But, the `mov` code is fairly hard to understand so I could be wrong on that.
In terms of data collection, I think this one is actually pretty harmless.
Imgur censors images that point out the dangers of obesity, and promotes images that encourage obesity. Use slimgur instead.
First, let's separate two kinds of effects: memory effects and IO. While PFP treats memory effects as side-effects separate from program logic, imperative languages do not (either approach has its pros and cons). As the post talks about IO, let's restrict ourselves to that.

If you believe that the main contribution of this approach is by absolutely preventing any kind of uncaptured IO (I think it is extremely valuable even without this language-supervised restriction), then this too, is trivially possible in, say, Java (or all other JVM languages). Just install a security manager in your tests, and it will make sure you don't accidentally access IO by bypassing mocks.

This would still have the advantage of not writing your program in any special way to accommodate this technique and it would apply to third-party libraries, too.
It's all fun and games until someone [XOFF]
I've been on the receiving side of "no ability to promote", and ultimately the best thing a manager can do in that situation is to have an honest conversation about what is and isn't possible.

In addition, don't just give up. Keep talking and helping out. It could be advice on how to stay motivated or at least not demotivated, carving out space for interesting projects or developing new skills, or even helping that person find a new opportunity outside the company.

Dealing with unmotivated unproductive people you have limited ability to actually manage is beyond my experience.
It's also how every single one of the Asian tigers built themselves up from 3rd world countries to 1st world countries.

There's a reason why Thailand and South Korea started off in the same place and South Korea developed. That reason will profoundly irritate anybody who pledges allegiance to the holy altar of free markets, though.
I have worked with huge test suites. If your test suite contains tests that fail for the reasons given, and the result is a shrug, your test suite becomes useless very quickly, and then triaging which tests are allowed to fail, which are real problems, and so on becomes a much bigger waste of time and treasure. Making a big deal out of it when tests are added that mutate global state or call 3rd party APIs is an investment that pays back very quickly. Shrugging and saying "98% of the tests passed, that's probably good enough" means your test suite itself is a waste of time and resources and you could be getting the same result by just doing a quick happy path minimal set.
> I'm not sure why the author thinks Facebook should let her know who flagged the account.

Isn't that Facebook's whole argument thought? You should be accountable for your actions in real life by using your real name on facebook? If pseudonyms are against their philosophy, being fully anonymous should be even worse.
> the team is either too large

Not really. It can be tough even at 8-10 reports, 30 minutes each (some may go over): 4-5 hours of meetings. It's hard to schedule them literally back-to-back because of everyone else's schedules, so it winds up taking up two afternoons or whatever (it won't literally take up two full days from morning to evening).

> If it leaves someones voice hoarse as a manager, it makes me think they're not listening enough.

Very cute. Maybe I don't have the stamina for non-stop talking as others do :-P
Augmented vs. Virtual Part 1 – Virtual Reality
our whole system has it internally. very very useful for least squares systems and covariance propagation, etc.
>Even in HotSpot you don't need to scan the old generation if references in it don't change. You only scan (roughly) those old objects who hold references that have been mutated since the last collection.

>This is also possible when mutation is allowed (see Red Hat's Shenandoah[1][2], A new GC for HotSpot), and immutability doesn't make the challenge significantly easier (there is added overhead for mutation only).

You pay for this with barriers and implementation complexity.

>To summarize, current (and future) HotSpot GCs punish you for mutation, but not for the possibility of mutation; you get all the benefits of immutability automatically when you simply don't mutate references. Immutability -- as you note -- might indeed simplify the GC (though not in the case of Clojure, which does allow quite a lot of mutability -- not everywhere, but enough that you have to account for it not as an outlier), but it doesn't make it faster.

>A good JIT (like HotSpot) does this a lot better. It is true that Clojure is nowhere near as crazily-dispatched as, say Ruby, but it does rely a lot on Java-like interface-based dynamic dispatch. If your type inference is really, really good, you might be able to identify a great deal of the monomorphic call-sites, but a good JIT finds all of them and makes those calls virtually free, something an AOT compiler can never hope to achieve. Besides, HotSpot's optimizing JIT is a state-of-the-art compiler. You won't do any better with LLVM.

Rust code doesn't pay for write barriers at all - my point isn't that Clojure on Rust would be faster than Clojure on JVM, it's that Rust code allows much more deterministic performance, better tools for manual optimizations and native interop than JVM and you'd write the performance sensitive code in Rust. Clojure is then a high level tool to consume Rust code.

I think you're looking at this the wrong way and missing the obvious benefits - you would get a simple almost pauseless parallel GC and a high level language with trivial native/safe rust interop (which JNI isn't).

Because of Rust type system you could even isolate threads that have no access to the shared heap and not collect/pause on those - so no chance at pauses at all. And AoT compilation also gives you deterministic performance.

Anyway it would be a lot of work for sure, I doubt it would be a straight port of clojure (would need to make it more static to fit to AOT nicely) and you would have to modify Rust to generate metadata so that the dynamics parts could run (or just ditch the dynamic part completely and force everything to be resolved at compile time with a simplified/constrained type system that would be simpler to infer without explicit typing).
I wonder if it's illegal to fire someone for being depressed per the American Disabilities Act, since it protects those with "mental impairments": http://www2.nami.org/Template.cfm?Section=Helpline1&template...
I didn't know you could use Java SecurityManager to implement a similar system. That's cool. Do you know anyone who does that in their test suite? I'd love to chat with them.

The imvujs test framework for JavaScript tries to achieve the same effect by disabling known common sources of test intermittency: https://github.com/imvu/imvujs/blob/master/src/imvujstest/te...

Sadly, this technique, like any blacklist, doesn't work for types of IO that can't be prevented, like mutations to document.location.

The technique described in the article is effectively a named whitelist of IO operations (called World) that, say, all HTTP request handlers are restricted to.
ITU: 5G network to boost connectivity speeds up to 20Gbps
Changing Trends in Unmanned Aerial Vehicles (2014)
I think this misinterprets something deliberately, and misses some things entirely.

It mentions that wages have been stagnant as proof that it isn't that people aren't applying for jobs that have low pay, but only uses wage statistics as evidence for that, which doesn't really indicate one way or the other that such is the situation.

I think the thing it really misses is the increased conceptualization of open positions that makes it so about the only person in the entire world qualified for a job the way it is posted is either the person that had the job previously, or the exact skills of some other team member.

I assisted in hiring a technical person at a previous job over a decade ago, and after finding no one with the skills we wound up just hiring the most enthusiastic person, and they wound up over achieving.

After harassing HR at my company, I finally made a lateral move where my manager told me he thought at the time of hiring that they needed someone and they thought I might be able scrape by, but now they want me to find someone else just like me.

I've read other studies drawing parallels to online dating and in the face of abundance you keep holding out for something better.

Either people have to do the hard work to generalize the description of the kinds of skills they are looking for that doesn't wind up into yet another set of impossibilities, or the entire hiring process needs a complete reset in some other way. While we're at it we should probably throw degree requirements out the window, and the silly hiring puzzles everyone has been upset about.
Most people who leave their jobs do so and cite management.

Whether or not that has to do with their motivation is unclear.