For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | tobr's favoritesregister

Also, would it be quorled?

Yep! I worked there from 2007-2012, and at the time we used Photoshop, which on the surface sounds counter-intuitive (being a primarily raster-based program.) We would take screenshots of product (or get screenshots from HI if we weren't allowed access), and would redraw everything in Photoshop at a minimum of 288ppi (4x) using vector shapes and type layers, lots of nested smart objects, and layer effects (back in the iOS <6 days everything had gloss and shadows and reflections.) Content teams pop in retouched photography, photos of employees as avatars, names of employees to go with those avatars, and text to tell a story for that launch. Our 4x vector screens (sometimes well over 2GB PSBs) would then be shared with international teams for translation, and translations would come back to HQ for a final approval. We would also sometimes scale these screens as high as 32x for output to MacWorld / WWDC hero banners which was fun. You better believe we put our names in all these screens (mine appears once in the linked article!)

You can use One Weird Trick with generator functions to make your code "generic" over synchronicity. I use this technique to avoid needing to implement both sync and async versions of some functions in my quickjs-emscripten library.

The great part about this technique as a library author is that unlike choosing to use a Promise return type, this technique is invisible in my public API. I can write a function like `export function coolAlgorithm(getData: (request: I) => O | Promise<O>): R | Promise<R>`, and we get automatic performance improvement if the caller's `getData` function happens to return synchronously, without mystery generator stuff showing up in the function signature.

Helper to make a function that can be either sync or async: https://github.com/justjake/quickjs-emscripten/blob/ff211447...

Uses: https://cs.github.com/justjake/quickjs-emscripten?q=yield*+l...


I always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.

I don't understand how we got to such misuse of "PWA" in this context (e.g, on both sides of the conversation).

Progressive Web Apps are not a standard. Rather, it is the idea that a an application - presented through a web browser - can use additional features provided by browser _if_available_. The term is based on the concept of "Progressive Enhancement".

Everyone's pet feature - service workers, single site browsers, offline mode, push notifications, video codec support - gets branded "PWA" in their rant that such and such browser is not keeping up. However, writing your web application to require a feature that not all of the common browsers support means fundamentally your application is _not_ written for progressive enhancement.

The reality is that the term "Progressive Web Apps" was coined by Google as they started pushing harder for web apps to perform like native apps - but at the time they had a strategic initiative to have web apps instead of native apps (ChromeOS and the ChromeBooks, pre Android support). None of the other browser or OS platform vendors have that level of strategic investment in supporting web apps as a new 'native' format - especially considering the security model is usually different than that of the native platform.


I analyzed the online searches of thousands of SaaS buyers to uncover exactly what information they want when considering a SaaS purchase.

These are the top five highlights from what I learned:

1. The most sought-after (and often 1st) piece of info sought by SaaS buyers is pricing -- by a large margin.

Have a pricing page! If you can't share exact pricing for some reason, try one of these alternative approaches (created by an acquaintance of mine): https://businesscasualcopywriting.com/show-pricing-on-websit...

2. '[brand] alternatives' is the 2nd most-frequent search pattern.

It seems obvious to have a page on your website targeting '[your_brand] alternatives] that positions your offering against your competitors.

But only 2 of the 50 biggest SaaS companies do this!

Ex: https://www.atlassian.com/software/jira/comparison

3. SaaS buyers literally search for 'why [brand]'.

This is another under-leveraged opportunity.

Buyers want someone to spell out for them why they should spend money on your solution.

Make it easy for them!

Ex: https://www.hubspot.com/why-go-hubspot

4. Security is a big concern for SaaS buyers. They want to know how you're going to protect them from loss and litigation.

They're even checking out your privacy policy and GDPR terms! (Keep those things up-to-date.)

5. Your 'About Us' page matters.

Startups fail all the time. It’s not a secret.

Buyers want to know that the effort they put forth–convincing management, setting up and integrating your solution, convincing employees to use it–is going to be worth it in the long run.

Does your company have meaningful funding? Well-known investors? Is it profitable and self-sustaining? Does it have experienced leadership?

In your company’s About Us page, make sure you convey anything that can reassure buyers that the company is robust and set up to thrive.


You seem to be arguing two different things: first, Fox News does not influence public opinion; second, that it shouldn't matter if they do because adults should think for themselves.

The second is fundamentally a subject view of the world, so you are neither right nor wrong. I disagree with you strongly. We should be concerned about things that harm the our civic health even if we ourselves to blame for them. I think there's a clear parallel to our actual health: when 80% of our population is overweight or obese, it's maybe time to think beyond "adults are responsible for what they eat" and towards "the world would be better if we could make progress on this issue". Ditto our past history with smoking. We know that people are subject to persuasion and psychological manipulation and exploitation of their cognitive biases. A model of the world that has everyone as solely responsible for their own destiny is a pretty useless one, in my opinion.

But, your first claim -- "Fox News doesn't 'swing public opinion'" is an empirical one. Either it does or it doesn't. You're either right or wrong.

DellaVigna and Kaplan's 2007 piece in the Quarterly Journal of Economics investigates this question. They exploit the fact that the phased roll-out of Fox News between 1996 and 2000 impacted 20% of the country. This allows for a natural experiment where some markets are "treated" by Fox News and others are not.

Okay, so, first, should we believe this design? If the entry of Fox News into a market was random, then this is an experiment and we have a treatment effect. If the entry of Fox news into a market was conditional on market characteristics that we can assess, we have "selection on observables", and we can recover a treatment effect. We need only a good selection model. It is also the case that if entry into a market was non-random, but conditionally ignorable with respect to the potential outcomes of the market (e.g. random with respect to politics), we can get a treatment effect without knowing the full selection model. So we have some different routes to the answer here.

The answer is between #2 and #3 -- Fox News did enter markets in a non-random way, but not based on demographics or past voting history, based mainly on geographic considerations. Given the regulatory and infrastructural component of entering a new market, this is probably not surprising, but it does guard against "Fox entered conservative markets first" as a counterclaim.

Now, having clarified the design based considerations, the authors find that Fox News was responsible for a ~0.5 percent vote share increase in Republican vote share in the presidential election of 2000. Whether you consider that large or small depends on your frame of reference. My sense would be that 0.5 percent is small cosmically, but it's maybe possible that you could have an election where that kind of margin is decisive. Remind me again, was the 2000 election close?

This is a fairly credible and careful design published in a good journal and widely cited (1486 citations, which is quite high for a nonmethods economics paper). That doesn't make it true, but it does suggest that the field of Economics views this as an important paper and that it has been exposed to scrutiny from a wide variety of sources.

If there's a little contempt in my reply here, it's because I think your off-hand claim that media diet, priming, and framing effects are solely demand driven and have no actual impact on viewers seems to fly in the face of like 50 years of communications, economics, and political science research. In other words, it feels like your first reply was "50 years of research doesn't matter, humans aren't influenced by any of this stuff". Maybe that's not what you meant, but when I see someone flippantly respond without evidence, I think "Welcome to hell" -- imo, that's the kind of thing we get when we don't teach people to argue.


I stared in shock as the red mist speckled my glasses. After a few moments I managed to stammer a response.

"My god, that worker just fell in! Why haven't you stopped the machine? Why isn't anyone doing anything?"

The foreman who was leading my tour made a plaintive gesture and stared into space for a moment.

"It's complex, you see. The machine is certainly dangerous. That's the third worker this hour."

"The third?!"

"Every 10 minutes, like clockwork. But on the other hand, the machine is quite valuable. You must understand. Our competition all has machines just like it, and if we stopped ours, well, it wouldn't make much of a difference, would it? They're building more every day and we simply must keep up. That's the business."

"But those are people- human lives!"

The foreman looked tired. He'd given this speech many times.

"Our workers sign all the necessary releases. They're fully informed. Our legal team will assure you there's a great deal of paperwork involved, and we cross every T and dot every I. Totally above-board. I didn't build the damn machine, I just keep it running, and this is how it's done in the industry. Now, if you'll all follow me- just step over that mess for now, the cleanup crew are already on their way- I'll show you the way to our recruiting department. Turnover is a bit high here, but we've been working on some great new internship programs with elementary schools..."


Pretty much every synthesiser for 15 years had the same two-row LCD interface as the DX7. My first job out of university in 1995 was as assistant editor of Keyboard Review magazine (UK), and the vast majority of synths I reviewed - wonderful beasts from Ensoniq, Roland, Korg, technologically way ahead of the DX7 - had exactly the same bloody awful UI. Akai's S-series samplers, which everyone was using back then, did provide a decent display... but at a price. When someone finally made a sampler affordable by the home market (Ensoniq's ESI-32) it too had a greatly compromised display, though at least four rows rather than two.

I've always suspected this actually influenced the electronic music styles of the time. The 90s were the start of the analogue resurgence. Sure, an 808 or a 303 is a fabulous-sounding beast in itself. But twiddling knobs is just so much more rewarding and responsive than spending hours squinting at a two-line LCD.


One thing I'd love to explore (but can't because of my employer's IP policies) is how to get selectors running in sublinear time the same way "immutable data structures" get reducers to run in sublinear time.

Like, for an "add order" action, in a redux app you might often see something like

    return [...oldState.orders, newOrder];
Or, for the Python-inclined,

    return old_state.orders + [new_order]
Which is great, no chance anyone playing with the new array of widgets will mess up anyone looking at the old array of widgets, but terrible because we've bought that safety by making that "update" (which in an old-school app would have been an amortised constant-time append) into a linear time array concatenation. And the same thing happens with hash table insertions+deletions.

So someone invents immutable data structures (like Clojure has, and like Immer and Immutable.js and probably any number of nice libraries) that use trees under the hood for their "arrays" and "maps" to get those operations down to logarithmic time while preserving the nice "value-copying" semantics.

But then for a redux app you might make a selector to calculate some "derived state" from your base data. Maybe you want to show the total price of all orders to a user, so you write a pure functional selector to do it:

    totalPrice = state => {
      total = 0;
      state.orders.forEach(order => {
        total += order.price;
      });
      return total:
    };
or in Python,

    def total_price(state):
        return sum(order.price for order in state.orders)
And maybe you memoize that function based on the identity of `state` in case you call it a bunch with the same input. And that's all well and good, but that calculation takes linear time, so when you add an order your view update is still going to take linear time.

In the "bad old days", when you were mutating orders and getting a constant-time append, you'd probably have a variable somewhere to store the total price, and you'd do a `+=` when adding an order, getting a constant time update of the total price.

Is there some way to get back to sublinear time, like we did with updates to underlying state?

I think so. Remember that immutable data structures (mostly?) use trees under the hood. "Appending" an item to an "array" makes a new tree, where almost all of the nodes are shared with the old tree, and a small number (including the root) are new. Naively, the root's left child is from the old tree and its right child is new, and its right child's left child is old, and its right child's right child is new, all the way down to the new rightmost element.

If we could memoize `totalPrice` for subtrees, we could calculate the updated sum in log time. We would get the total for the each node's left child in constant time (because they'd be memoized), and only have to do any new computation for the new nodes in the tree down the "right-right-right" path.

Anyway, I don't know if a data structures library could make this ergonomic enough to make any added efficiencies worthwhile, and I'd love to program it up and play with it and find out, but aforementioned employer prohibitions mean this is probably always going to be just a thought experiment.


This article, and it's sentiment, reminds me a lot of the very current "zero waste" movement.

Bear with me ...

When you are sufficiently detached from every mode of production and delivery and generation (like growing food, or building houses or working in the back of a kitchen) then it's very easy to look around your (modern, remodeled, beautifully appointed, first world) kitchen and ... stop buying plastic baggies or only use reusable containers, etc.[1]

But in reality, several levels below your level of life and consumption, an enormous amount of waste is being produced just to maintain the very modern life you lead. It's really not that interesting or impactful that you cut out most of the 1% that you actually touch inside the walls of your house.

This article sounds like the same kind of self-delusion ...

After violently conquering a continent, enslaving or killing or (otherwise subjugating) the indigenous population, and maintaining a political and economic lock on more than half the world (through direct and indirect warfare, economic colonization, and otherwise), the author, who holds an equal share with all of us on whose behalf this was done, opines (possibly from that same kind of kitchen) that he can't think of any use for power over others.

In reality, an enormous amount of power and violence has been, and continues to be, wielded on the author's behalf. It's really not that interesting or impactful that he doesn't want to "boss other people around".

[1] All very positive actions and not to be impeached.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You