parksy

Those repellents bother my kids as well, and they're everywhere apparently but I can't hear them. Permanent tinnitus from far too many loud concerts in my 20s and 30s. All I can say to younger readers is: wear earplugs. You won't appreciate not having tinnitus until you do, then it's permanent :/

Ah, you're right, I misremembered. Has been a long time since I delved into this stuff. The main gist I guess is the two terms are an axis rather than exclusive. Thanks for the correction and apologies for any misinformation.

I can hear that frequency all the time nowadays. It follows me everywhere...

Is the basic concept of structured concurrency more about programming language design, or applicable to how a program is structured? I can do something like this in JS:

  async function doTasks(tasks = [])
    // Do some concurrent stuff:
    let results = await Promises.all(tasks.map((task) => new Promise((resolve, reject) => {
      workerpool.exec('mytask', [task])
        .then(function(result) {
            resolve(result)
        })
        .catch(function(err) {
            reject(err)
        })
    })))
    // Function pauses here until all tasks resolve.
    // do stuff with results
  }

The workerpool exists outside the scope of this function, is that kind of the crux of the distinction, or does it come down to how threads / workers are managed (by the language / first class constructs) that outlines the definition of structured concurrency?

The example above feels like a similar pattern to what I've seen in discussions of structured concurrency but as with most things I feel like there's an aha moment where I'll get what all the fuss is about.

It is thought provoking at the very least. The perspective I saw his views on abstraction from is the perspective of the product itself. Imagine there is some perfect solution for the ultimate technology. It's a perfect whole, every operation has meaning and purpose, is as optimised as it could possibly be, the hardware and software blend seamlessly with no unnecessary redundancy and so on. Maybe such a thing is so advanced we'd barely recognise it woven into the very fabric of our biology and culture, who knows.

Our human limitations and abstractions limit our ability to approach this goal, so it's not so much that the idea of abstraction is bad because it's useful to actually get stuff done. But it's more that we should always keep in mind that abstraction itself is not the goal, it's just a tool we have to use to get there, because of human limits and I would also say natural limits (like computational efficiency etc).

Obviously such a thing of beauty is a hypothetical extreme. I can see this idea being useful on a smaller scale, like in organising a team, designing a product, or a piece of software, we should pay a lot more attention to where we draw boxes around our design space.

But I am kind of with you when it comes to the broader-sweeping implications. How far does this concept go, and what power do individuals have without some social techno-revolution to make any broader architectural changes to basically anything? I have a mobile phone that communicates via radio with centralised systems. These centralised systems exist to govern access and enforce payment for services, because that's how society itself is structured. Perhaps there's key value stores at various layers of this architecture. There is a store (again because money) where I can choose my own apps (because of human desire for freedom of choice) or view ads (money), all human constructs. (It's all becoming quite philosophical, another human trait.)

But is that the best possible solution for the problem of networked personal computer devices? Is mobile networked computing even an optimal solution for biological lifeforms, is it a technological evolutionary dead end or a precursor to some broader construct we're yet to discover, and if so then what do those superior structures look like from a design and organisational perspective? Perhaps on some alien world they have figured it out, and maybe their solution doesn't include radio communication or key value stores, or maybe it's something we wouldn't even recognise as technology, who knows.

What I take away from it is a call to think about why we're designing things the way that we do. Is there a way we can draw the design space differently and organise teams to consolidate or reimagine the problems they're solving in order to rule out truly unnecessary abstraction and keep only that which is necessary?

I can't imagine how it might look, but I am sure if someone figured out a more optimal way of organising hardware and software that served the infinitely variable needs of humanity securely and efficiently with less abstraction for the same or greater flexibility and that would continue to do so in perpetuity, that person would become rather rich (unless that solution made money obsolete, here we go again).

Atheism is a rejection, non-acceptance, or indifference to theism, which boiled down to its essence is just a non-acceptance of deities being the creator or essence of reality. One can be atheist and hold hard-line rationalist views about the nature of reality, but one can also have spiritual beliefs and be atheist.

Agnostics believe that in some way, metaphysical intelligences are involved in the creation or fabric of the universe, but the very nature and depth of this involvement is in varying degrees indecipherable, unknown, and not-yet-known. Agnosticism doesn't require either the acceptance or rejection of theism.

Put together it technically means the person doesn't believe in a theistic god but holds agnostic views about broader metaphysical concepts.

More colloquially I've noticed a lot of people use the atheist agnostic / agnostic label interchangeably to indicate they haven't made their mind up one way or the other, but it's possible to be either atheist agnostic or theist agnostic.

I mean a lot of what you said applies but that doesn't make the entire concept BS.

On the one side of the coin you're right, it doesn't matter for a huge percentage of startups - until it does, and then it can matter quite a lot, very quickly.

Yes most startups fail so technical debt isn't a primary concern. But on the flipside if a startup becomes successful they'll have the budget and experience to clean up technical debt. Only at that point it's like repairing a car while the engine is running - when you're scaling fast, suddenly you have millions of new users flooding in, you can't take your systems offline and rebuild them on the fly - users demanding new features and improvements takes priority over fixing invisible stuff they can't see, etc. I'm sure you understand this.

I can think of a few companies who were big players in our local / national sphere who hit it off, got splashed all over as the next big thing, and their systems totally failed during their big events, or were seen as industry leaders only for a breach to sink them overnight.

I see part of the problem is technical debt often only gets raised retrospectively, when it would take huge efforts and expense to deal with. It doesn't take an insane order of magnitude of time to move a little slower and make more calculated decisions to build something with scalability and longevity in mind. A sensible balance should be struck between velocity and engineering. Technical debt should be raised early in the process and used proactively in decision making.

I suppose it doesn't matter if you're an investor or owner just trying to get ahead of the market and sell it off for profit, you can flip Gartner-as-a-Service products all year long and still come out ahead even if a good portion of them fall over their own feet at some point in the future.

I've seen this sentiment a few times. I'm not totally against it, and a better analogy is always worth considering.

I'm sure it's not the final iteration of analogies we use to garner more budget or help clients understand that always pushing for the cheapest solution isn't the best idea. But I think it does a reasonable job. It abstracts away the finger pointing of "you coded it badly" vs "you never give us enough time to do it well."

Taking terms to a client like clutter, bad code, spaghetti code, and other more direct terms I've seen lead straight to uncomfortable questions about capability, experience, and so on.

I think if it's explained with the idea of compound interest it conveys the growing impact over time if it's left undealt-with, and it's an analogy most people are familiar with.

It's definitely easier to push back on taking a shortcut using the debt analogy than by saying it will force us to make their product badly and please pay us for the privilege.

I totally get what you're saying, personally I will always speak my mind and put my foot down where appropriate, I avoid working with people that constantly just push for more with less. Even then though people still often want things done and don't understand what they're asking for.

It's definitely better than the house-building analogy that causes eyes to roll so far back they roll out of the boardroom and down the hallway. Trying to explain how code complexity really works puts everyone to sleep and no one understands it anyway.

I'd be really interested in a compendium of boardroom analogies come to think of it. Could be a fun read.

Happy birthday, the web.

We're still ironing out a few things and I hope we figure it all out some day.

One other thing I would check is disabling or removing the submit button after the first click. Just an onclicked event to set the disabled attribute will go a long way.

Double-clicking on a lot of sites will submit the form twice. If people are waiting, they will click again, and again.

I also would like to be corrected in what my error was, for what it's worth.

That's a good point, people in Finland use more per capita than 80% of the global population, so if everyone were to have the same energy standards as Finland we'd probably need more like 10k reactors and 600 per year give or take.

Or we stick with the status quo, force everyone into their lane, and probably need like 3000 to 4000 reactors to serve current needs, and 150 to 200 per year. Give or take.

I think that's still in the same ballpark orders of magnitude-wise.

Here in Perth a good third or more of my electricity is keeping the house cool so some of that is going to average out. We don't have saunas but we do have hot water.

There's going to be an obvious error of margin either side of my napkin calculations but I think the order of magnitude is in the ballpark.

People just need to be able to speak freely. Likes and dislikes and other scoring systems just encourage echo chambers and are almost purpose-built tools for astroturfing.

People are afraid to say their opinion because of the backlash. Not everyone has a well thought out opinion, that doesn't mean they deserve to be punished. The human experiment can only move forward with open displays of ignorance coupled with open-minded discussion and acceptance.

It's idealistic to think this could happen easily, but I see no other way for global civilisation to come to terms with our historical cultural differences.

We're either going to devolve into systems where nothing matters and everything goes, which frankly we already have with 4chan, or allow certain views to prevail over others, which literally every forum or approval-based channel has these days, or find a different way to share differences and come to terms with them, which I hope somebody invents soon.

By population that's one reactor of this scale per million people. To replace all other sources of electricity, 8 thousand such reactors would feed the current world's population. We'd need just shy of 500 more to keep up with population growth by 2030 - or at least 500 new reactors globally per decade.

(edit - assuming everyone uses the same amount of power globally as the average person in Finland which - why shouldn't they be able to - and - obviously they don't)

One of the first principles I learned in programming was coupling and cohesion. This type of graph-based measurement of program complexity already existed some 60 years ago.

I think your hunch is on point, I think because the author conflates running time of a busy beaver with benchmarks of programmatic coupling and cohesion.

Busy beaver algorithms are single-purpose programs. An eCommerce website is layers upon layers of interrelated modules and functions.

I get where they're going, reducing a problem space down to its simplest representation is ideal. I just don't on first pass understand how busy beaver accomplishes this.

Everyone has different experiences but my view of the problem is that it's not so much down to developer laziness as it is technological ignorance and reactive direction from higher up - the people who actually fund and approve the work.

Outside of the bigger providers I don't think most APIs are designed with general consumption in mind. The impetus usually seems to be reactive - "we've got this idea for a mobile app using data from our legacy WMS/CRM/whatever, and it needs to be finished yesterday!"

So generally (not always but usually) what I've seen is whatever the underlying system supports and requires gets reflected into the API, and there's minimal proper engineering or sensible abstraction, partly because of time limits and also because the requirements are discovered mid-flight.

"Oh... Products have options in a separate entity? Oops. Uh, we'll add an options endpoint. Easy."

Several years later, the app is mildly successful, the business decides to whitelabel the API for some of their B2B clients, there's no budget for a redesign, "It works doesn't it? If it ain't broke don't fix it..."

Where possible I try to design and build APIs with some forethought and push for as much information on requirements and capabilities of existing systems beforehand but quite often the stakeholders don't really know and don't want to pay for a few weeks of in-depth analysis.

The endless facepalming of hearing the cycle of "Don't overengineer it" when I ask too many questions people can't answer, through to "Why didn't we pick up on this requirement" and having to listen to "we can all learn from this" when something fails because of some if/else statement buried in the legacy business logic, right back to "Don't overengineer it" when you propose the clean way of encapsulating that in the API, has left a permanent indent on my skull. So much leakage of black-box logic into the clients which bloats frontend logic and provides plenty of double handling and scope for unknown business logic to be missed, and no one in charge really gives a shit other than the developers and engineers, and that's fine because we can deal with it and it's their fault for not thinking of it anyway... they're the smart ones right?

You'd think this is just a problem with SMEs but some of the biggest national and multinationals I've worked with have a ton of horrid shit in their API designs. One industry-wide government-mandated reporting spec you'd post a SOAP envelope that wraps an undocumented XML document (they had an example document and the envelope was documented, but no doctype or anything to go off for the contents), a major real estate interchange format has you polling a REST API for an update flag, then loading and saving CSVs over FTP. Some godawful affiliate marketing API essentially just exposed their nth normal form relational database as an API. One government department just used HTSQL for their API using a python script to reflect some of their silos into PGSQL and called it a day (even though whether or not your interactions would work or made sense depended entirely on their internal application logic which wasn't represented or documented).

And too many projects where it turns out the promised APIs didn't even exist until the app was well into development. "Don't worry about it, that's their problem and gives us an excuse when the inevitable delays occur..."

No wonder we're hearing of massive breaches daily, from top to bottom the entire industry is barely held together by glue and sticky tape. It seems like an engineering problem but I think it goes much higher than that, it's a cross-industry failure in planning and management. Engineers are not given the time and budget to do the job that the data deserves. The market self corrects though, massive breaches have closed more than one business down for good.

It feels futile but I do support and encourage people to work towards just reasonable and well-documented endpoints, I doubt there's one true standard, but just some level above slapping it together at the last minute would be nice. I don't care if it's JSON or XML, or whether paths follow some semantics or another. As long as the relationships, types, and mandatory vs optional fields are explained clearly and succinctly, and the auth mechanism isn't a nightmare, and I can work with it.

Sorry for the rant this is just one area that triggers me. I've seen too much bad practice, and fighting against it for decades and still hearing the same lack of concern in the architecture phase has left me more than a little jaded.

I am so used to articles with a meaningless header image that I totally skipped that the map they're talking about is right at the top of the page. My brain filtered it out. After going back and looking at it, I think the map is pretty cool and would be great if it were dynamic and navigable in a leaflet container or something of the sort.

But I agree I got tired of the prose about a third of the way in. I appreciate it, and can tell what they are getting at but I think regular hacker news readers are in a demographic that is already keenly aware of the interconnected nature of raw material extraction, supply chains, applied and theoretical sciences etc. I mean it's in our nature to process these thoughts because we're always looking for some missing connection, a forgotten or undiscovered niche, (edit to add, not to forget the human and environmental impacts of all of this as another user mentioned) etc etc.

I do think there's plenty of folk who might see this as eye opening, especially the average consumer for whom devices just materialise out of money. I imagine the philosophical angle would be more thought provoking for someone who hasn't sat down and thought about it a whole heap.

(second and final edit to add - on more thought I think if they made the map dynamic, and put the prose on little markers, that would be way more impactful to me at least as I think the spatial context would add a ton of value).

Dang, I read that book not long ago, the priming narrative is also pretty strong in marketing etc. I'll have to brush up on the subject before I bring it up again.

Though if priming is dead, it seems interesting the people who punched the bag seemed angrier or more vindictive afterwards according to the OP study.

Our local one is https://www.noizemaschin.com/ - they're based in London and Perth Australia, it's kind of a hybrid maker space / underground scene. Good folk from all walks of life.

Not sure about Denver but I did some searches for experimental music, perhaps jump on the local subreddit as it seems there's a small noise music scene but I wasn't able to pinpoint anything specific.

There's a group in my city who meet every month to generate wacky noises from all sorts of things. With this thing's built-in generator and layout I feel like you could build a primitive step sequencer with those switches and dials and deliver a godlike performance of audio and engineering prowess.

Even better if you can voltage control the frequency. Then if you can introduce a delay in the oscillator output, filter it, then feed back into the variable resistor(?) that controls its frequency, you have the basis of a mini-FM synth - if you can get it to stay stable in the normal human hearing range of course...

Nothing really to add on the engineering side, just seeing how it looks, I want to hear it making some noise, although it's not its intended purpose.

Nice work on figuring out how to get it going again!

If we're going to reductio ad absurdum then OS's shouldn't let programs run if they interact with a device and don't explicitly handle exceptions for those devices. The OS is just a program and if it allows programs to crash it, isn't that the OS's fault?

"Researchers first criticized essays written by the study participants and then told some of them to hit a punching bag. Afterward, they gave them all an opportunity to blast loud noise at the person who had insulted their writing. People in the bag-hitting groups reported experiencing more anger and were more likely to blast noise than those who did nothing."

This does sound like a selection bias and priming.

You have a group of people who are criticised. Some of those people are told to do something physically violent. All were then told to push a button to blast a noise.

Blasting a noise is a mild aggression. Hitting a punching bag is much more aggressive. It's no surprise that the group primed for violence reported more anger and was more primed to the milder form of aggression.

Also how did the people hit the bag? Did any resist and needed encouragement. Did they punch it full force or just tap it so they could get their reward and leave?

There is no way this study can draw conclusions on people who are victims of sustained physical and emotional trauma. It only proves that people who had college essays criticised are more likely to press the beep button and feel angry if they're forced to punch a punching bag.

edit - I am biased. I endured a tough childhood with bipolar parents, physical and emotional abuse was involved. I know there is a venting trap where you can get comfortable and wallow, but that's like finding a local minima, without any form of catharsis you never heal, with undirected catharsis you get stuck, but catharsis coupled with guidance and reinforcement really does help.

I generally agree on all those points, there's a bunch of things I could critique, like shrinking the search bar behind an icon, or things I like such as the more concise breadcrumbs which make the hierarchy a bit clearer.

But overall I guess after thinking about what I did and didn't like about the design, nothing really stood out as a showstopper for me. I like the old design a lot more, but MDN has always been a reference and I dip into dozens of different references every week, getting used to design differences is par for the course. As long as they don't mess with the overall content hierarchy which is great as-is I'm not too impacted.

So my takeaway was if they invest the same energy into the content hierarchy on a page, I think that would add some value. Keep what they have, don't overstuff it, but just making it easier to see "you are here" and "here be dragons". Like on that example you linked there's a "warning" about tabindex that doesn't explain why you should never add one to a dialog - seems obvious to experienced frontend developers but it would leave juniors and people who might benefit most from such a warning scratching their heads or developing a cargo-cult mentality to certain things. I can envisage a content sweep of their warning / gotcha boxes would add more value than a design refresh.

Also generally since their content is constantly expanding, something that makes it easier to get your bearings in the existing content, adding more context cues etc, and quicker navigation between adjacent paradigms or some "maybe you meant this" suggestions that would be neat. I think that's what they were going for by elevating the "related content" on the left - but that's just showing a list of stuff on the same level as the current item. Why would I care about <summary> on a <dialog> page? If you use their search for "proxy" you might end up on a page talking about web proxies, or javascript proxy objects - disambiguation would be awesome for people who are trying to get their bearings.

(then again I usually just hit back, go to my google results, and pick the next page if it's not what I was looking for...)

From what I gather the actual lattice requires neutrons. Their current setup uses an electron source (dynamitron) on tantalum which generates gamma rays. The gamma rays have the energy needed to push neutrons around inside the lattice. It seems they're saying it would be more energy efficient just to directly generate neutrons without having to go electron -> gamma -> neutron.

No dramas, understood re 1 it's no doubt beyond trivial to create a bidirectional transpiler. I wouldn't even know where to begin so good work on what you've managed so far.

Re 2, shouldn't be a problem as we already have build processes in place. Most projects I work on have npm build steps, I'm not sure how that figures in with rust (I really need to get off my butt and check it out sometime), but if it could be pulled in as an npm dependency that would work. If it could be done inline even better (e.g. inline melody within a JS file, compiles to the expression inline...)

Anyway good job again so far, have followed the repo, all the best once more!

The antidote outside of ruthlessly moderated special-interest "walled gardens" is a system no one really wants I think. It would need to avoid mechanisms that give community or interest groups powers to promote some content over others. It would need to avoid algorithms that automatically determine and recommend certain content. Other than pruning illegal contributions and obvious spam, it would need to avoid giving virtually any moderation powers to select individuals or the community. It couldn't allow paid promotion or require payment to participate as that merely enables those with greater financial means to contribute and have their content seen.

Introduce any one of these things and the whole system becomes gameable. Within these constraints it seems the outcome would be a loose graph of content tied to known individuals. It would grow amorphously over time, be largely undirected, and lacking the capability of being fully gamed, would probably avoid the attention of marketers and influencers. And probably general users too, since it wouldn't be easy to find interesting and relevant stuff and be quite boring for the average attention span.

The constraints bring to mind the early 90s web which basically had all of these properties. Outside of bulletin boards and UseNet that is. People wanted more convenience, hence search engines became the defacto way of finding entry points into these networks, which caused changes in how these networks presented and arranged themselves, point being even if we designed the perfect ungameable system, as you alluded to if any search engine or aggregator crawled and ranked its content, it would just be meta-gamed into uselessness.

Personally I've come to the conclusion we just have to accept that for the majority of online community-driven content, high SNR is here to stay, and we have to take what value we can individually as it comes. Unless we're willing to forgo conveniences like search, or relevant content recommendations, which I think for the majority of the web is a big old no.

For enthusiasts, building their own walled gardens with in-tune moderation is probably the way to go. Hacker News I think though not perfect is a good example of this, the SNR here is fairly decent compared to the broader web.

Some thoughts I had for the developer:

Does it (or are the plans to) reverse compile? If I could input my regex and output melody script one could create an excellent interactive learning tool, and also more selfishly help with adoption in teams with crusty old devs like me who like our magic rituals and prefer typing our regex by hand.

Also are there plans to support runtime compiling in JS? Something like...

someMelodyObject = <initialise and configure melody> String.replace(someMelodyObject.toRegexp(), someString)

This I think would make it a compelling library for inclusion into projects assuming it were fairly efficient and lightweight. Not sure how or if you'd have to deal with performance and caching but it would probably go a ways to improving adoption among web developers at least.

Anyways good luck with the project. Regex is often considered a dark art when it's actually fairly concise and expressive, opening it up to more people at a higher level could lead to greater understanding of regex in general. Also what an interesting and challenging project to undertake, definitely a nontrivial challenge all told.

I had a similar reaction. I haven't heard of the author or their modelling prior, so haven't had much time to process the data, but I thought I'd bite, and took a look at some of the spreadsheets.

The bit I was unclear about is where the predictive modelling takes place. I can see the raw numbers and how they've been composed across the main variables like education spending, education level, workforce participation and income, social benefit from workforce participation, and cost of crime.

But I'm not seeing how the model itself is predictive. Where would I look to see the effect of dropping education spending by 50%. How does that impact crime rates and costs? What about the generational effects of deeply-connected criminal families and their children vs having more opportunities to participate and contribute to innovation etc.

Does the model assume a linear relationship, i.e. n times the number of criminals = n times the crime rate = n times crime costs, or does it account for network effects such that n times the criminals have n^n crime rate, and crime costs are n^n - and is there a point where criminal justice processes break down and crime breaks out?

Anyway save from writing a novel, it seems like the author did some homework to pull the various numbers together but I think some high level diagram of their model, inputs, calculations and outputs would be a better way to capture interest. Analysing something like this is a job, relying on the kindness of friends and internet strangers seems like a funny thing to get caught up on when the author themselves acknowledged the time and energy they had to spend pulling all of this together.

I'm maybe going out on a limb but the lack of interest probably doesn't indicate that no one cares about the numbers, nor must it indicate people would rather use emotional intuition, just that there's probably better and more complete models out there used by social scientists and economists that follow tried and tested conventions that take many more factors into account, not my wheelhouse though, if no such standard models exist I'd be very surprised.

"What has been will be again, what has been done will be done again; there is nothing new under the sun. Is there anything of which one can say, 'Look! This is something new'? It was here already, long ago; it was here before our time."

I mean ~2000+ years ago people understood this. Day to day relatable ideas generally come to anyone involved in the cutting edge of any era of humanity, and such ideas will generally resonate with one's contemporaries who are likely thinking similar things. Billions of us can't really claim to have found something new. We didn't invent countability, or factoring, or primes.

But it's also a bit of a cynical lie that may comfort some of us, that being ordinary is okay, because ordinary is normal. Over the millennia we managed to turn philosophy into science, mathematics into machines, and miniaturise them into our hands, generate energy and resources unthinkable to our ancestors, and create networks of algorithms complex enough we offload a significant portion of day to day thinking and planning. These are new things.

Is it true wisdom? Define true wisdom - my understanding is there is no objectivity in such matters. There is only the balance and friction between forces of imagination wrought out by human minds and hands, always building on knowledge that came before. Take away all knowledge, and the cycle will continue, it's just what people do. We think, we imagine, we create.

I ramble but it probably feels day to day like nothing is ever new, and everything is always being recycled, but it's in this compost heap that new ideas ferment and take root, so that is an analogy I'll be adopting henceforth (not in the least as it makes me less disappointed in my own unpursued ideas).