i definitely agree that it would've been nice to have images in the book as it was hard to get a sense of exactly how well Boquila was mimicking neighbouring plants!
but in reference to the linked article, i will say that the researchers interviewed in the book (and i got that sense for Zoe as well) were in agreement with you that the research didn't support a vision-based mechanism. but everyone agrees that the imitation is going on. the researchers in the book suggest a gene transfer-based mechanism instead! (mentioned briefly in your linked article)
not sure if you will still see this 7 days later, but the claim "we work more hours than medieval peasants did" jumped out at me so i looked into a bit and am curious if you have more thoughts on it!
my brief takeaway was that the claim might be true if "work" means "working for an employer for wages", but not if "work" includes "necessary labor for shelter, food, clothing, survival".
but it's an interesting thought though so i'm curious if you have other related resources to dig into.
I too have had to use Next but didn't want to feel locked into Vercel.
this is the biggest effort I'm aware to run Next with a full-ish feature set outside of Vercel: https://opennext.js.org/. Supports AWS, Cloudflare, and Netlify. You can also run Next as a normal node webserver. I've only used the Cloudflare integration and it was a bit janky but worked (and seems to be entering 1.0 soon so may be less janky).
AFAIK this is completely unsupported by the Next team, but would love to be proven wrong!
the biggest headache i had in particular was different ways of handling environment variables, but the different adapters at OpenNext have had a rolling list of caveats/unsupported features for as long as i've been following the project so i didn't want to outright say "full". hopefully the effort on Next's side to build a standardized adapter API will help with this!
Ah, fair. That is an area we struggled with. We run next in kubernetes (GKE) and really wanted to be able to promote the Docker/OCI image up through our environments (ie: not bake environment variables into the build artifact). We settled on having them dumped in a meta tag in the root document, and then have some helper functions to access those. We still have to use process.env for any secrets though, which makes them inaccessible to the frontend code (but that's sort of the point).
you don't need to send 100kb+ of JS over the wire to build a static site in react: for example https://vike.dev supports static HTML-only output for a site built with React.
as for "why React", speaking just for myself it's really nice to just have one tool that can do everything (static HTML-only, static with JS, SPA, SSR) and not have to context switch or potentially even have to split my site into two projects just because I want to hop between one or the other approach. and React has the biggest mindshare and ecosystem.
I think you just proved the point by introducing yet another frontend framework to learn.
And you absolutely don't want one tool to do everything. HTML/CSS is native and understanding it is a requirement for React. It also doesn't require Node and a build step.
I think all software engineers in the world who know HTML/CSS (like who doesn't?) beg to differ
Really funny how some devs think they know the secrets of engineering simplicity and everyone else is a fool for not knowing what they know (HTML/CSS).
Read this thread. There are some comments about using React components for everything and never touching HTML tags and CSS. And they probably call themselves senior frontend engineers.
If not React it's just another abstraction (including whatever you come up with) that is arbitrary and shitty in a different way. Front-end/mobile is so boring and unimportant that it absolutely makes sense to just pick a thing and use it everywhere, and save your brain capacity for interesting problem solving. I say this as someone who's been doing front end for 10 years.
If frontend is boring and unimportant, what is exciting and important? saving records in a database? UX is what makes money and it is done through frontend.
Client side is only interesting in complex generic reactive programming problems, state machines, domain modeling in the client, local first patterns. The part about browser or mobile platform intricacies is very lame.
Coding and algorithms are just some of the tools available for frontend and software engineering. UX is another layer that most software engineers can't grasp, it involves art, sociology, politics. Calling it boring and unimportant when you are not good at it is a misunderstanding of software's true purpose.
No one even mentioned agorithm. If you are really user focus as you claim to be, you should love cross platform, focus on delivering values and not be a simp for these "native" tribal knowledge. Talking about misunderstanding software's true purpose.
Obviously I love to reduce front-end to generic problem solving and abstract the platform aways which contradicts directly with your amateurish "looks ma how minimal and artisan my html & css are".
> HTML/CSS is native and understanding it is a requirement for React.
It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.
> It also doesn't require Node and a build step.
The point is assuming you already have node and a build step. You already know React. So just use it for everything. Everyone who thinks they can "just write HTML/CSS" ends up introducing Hugo or Gatsby or whatnot (or, worse, writing their own "simple" Makefiles and shell scripts) and gradually adding more and more features until it's just as complex as React. Just use React.
> It's not necessary and the ROI is poor IMO, especially for CSS. Better to just use React for everything and not worry about the implementation details; yes those details will sometimes help you debug, just like knowing machine code will occasionally help you debug your compiled code, but it's not something to put a lot of your learning budget into.
...what? What are you writing in React if not HTML tags and CSS classes? How can you even write anything in React without that? React doesn't do anything CSS specific either, so I don't understand how you'd even style anything if HTML and CSS were not a "necessity."
> I try to avoid having to know or care about the underlying implementation details.
This feels quite ignorant. I'm not sure, in some ways I understand it, for example, when running software on the JVM, I typically don't think about how it's implemented, so I share some of that ignorance.
At the same time, specializing to just knowing one technology (e.g. React) and not caring about up or down the stack can also be limiting - both for any career moves (Vue? Angular? working with how the resources are packaged and deployed?) as well as just debugging things in more detail (since one can feasibly imagine cases where you need to look at both the output HTML/CSS/JS to understand why certain things are happening, not just a React plugin in DevTools).
You don't have to learn things that are of no value right now, but you probably shouldn't go out of your way to not learn things. Staying curious is generally pretty nice!
I mean, sure, I do actually know a bunch of the details and it's occasionally useful for debugging. But I look for ways to work at the React level if possible (e.g. using the React dev tools to debug the component hierarchy rather than using the raw browser dev tools where possible). IME it's better to fully specialise in a small set of technologies than to dabble across a wider range.
And what are in those components? Divs with a className property I assume? Or are you literally only using components other people have made in UI libraries with no changes of your own?
I generally use preexisting components, there's not a lot of value add in creating my own date picker or dropdown box or whatever. Obviously I put my own content in, and compose together existing components to make bigger new components if the component I want doesn't exist (e.g. if I couldn't find an address entry component I might make one out of individual text entry components). I think some of the components I use might actually be or correspond to "basic" HTML tags, but that doesn't make any difference at the point of use.
If a component doesn't have built-in styling support (i.e. configurable via React properties) then I'll use Tailwind so I can at least ignore all the selectors and cascading nonsense of CSS. (I remain hopeful that the world will eventually see that inline styling is the way to go; with Tailwind I meet them halfway)
Okay, well you do realize you're not the average programmer right? I'd even say this is junior level if you are not really creating your own code and components, so it's not accurate to say that HTML and CSS are not "necessary" unless you're doing what seems to be very basic work. And Tailwind is still CSS, again, so without knowing what things like flex actually do, you can't use Tailwind either. I'm beginning to suspect you may just use AI to build much of your code for you.
If your company has a good component library, you can really stay in that circle for 95% of the time. If you need that 5%, usually there's a library unless you're doing something really bespoke like canvas/webgl.
And AI really can do a lot of work nowadays. I met a founder who built their entire mvp with v0.dev. 5 pages, multiple flows, modals with photo taking/uploading and working color picker. They only needed to add the api-calling logic.
> I'd even say this is junior level if you are not really creating your own code and components
Must be a case of the midwit meme, or https://cspages.ucalgary.ca/~robin/class/449/Evolution.htm . Intermediate programmers satisfy their ego by writing everything themselves; a real experienced professional knows that custom code or a complex technology stack is a liability, and delivers the functionality the business needs in the way that will impose the smallest maintenance burden.
> it's not accurate to say that HTML and CSS are not "necessary" unless you're doing what seems to be very basic work.
Disagree. You need to be able to lay things out, compose components, and hook up behaviour. But you don't need to use the lowest level languages to do that, any more than you need to write all your programs in machine code. You need to understand the DOM, but that doesn't mean you need to express it in HTML, and similarly for layout.
> Tailwind is still CSS, again, so without knowing what things like flex actually do, you can't use Tailwind either.
You need to understand layout and styling properties, sure. But you can skip the things that make CSS CSS - selectors, cascading, and the like - which the industry is ever so gradually starting to recognise for the failures they are.
> I'm beginning to suspect you may just use AI to build much of your code for you.
LOL. Is this projection, or just reaching for any possible way to smear me? The AI fanboys are happy to mix a dozen technologies in their project because the AI "understands" all of them equally well - mix React and CSS and HTMX and what have you, why not? I'm actually genuinely curious about your thought process here (if you had one), can you talk through what lead you to this bizarre idea?
Pretty much none of that is blocking first paint. Disable JS and see that my site works just fine. I have interactive examples on some pages but all the extra stuff is just “nice-to-have”.
Disable JS and see that my site loads just fine. Fonts are nice-to-have. Interactive examples (on other pages) are nice-to-have. None of this is render-blocking.
probably adding a confirmation message the first time the alias is used for each command would be good, it would be nice to know when i'm invoking git and when i'm invoking a third party binary regardless of any exploit attempts!
culture war aside, there are many other more accurate ways to say "details omitted for brevity" than "obviously" and "it is easy to see that"
this is also something that makes me want a more interactive publishing format, though i understand the good reasons to stick to the static quo. if it's easy to see, it shouldn't be too hard to write out in a collapsible sidebar for those interested
This might actually be nice, and its probably not that difficult to set up in PDFs or similar.
Would be cool, just because you could see that the details were actually "omitted for brevity" and not "omitted because they're sketchy". And if you rrrreally want to look through the details, then they're fairly easily available.
Downside, it might have a chilling effect on papers because the scale of writing necessary.
Like everything in mathematics, "obvious" is a term of art. Broadly speaking, it refers to a fact, proof, consequence, which is necessary for the proof to advance, but which is already established elsewhere, so it does not in itself aid in understanding the proof being presented.
A proof is either providing a new result, or is proving an established result in a new way. Almost always, a proof will need other results, in a way that isn't "interesting" (another term of art). The point of introducing these results as "obvious" is basically to say "here is something which isn't proven by the proof I'm presenting, we need it, but there's no need to derive it to follow this proof", ideally, with a footnote. As language, it is a bit sly: if something is obvious in the normal sense, it will be left out.
It's a problem that the modern style is to elide anything obvious in this sense, rather than in the sense of "anyone who might reasonably read this paper may be expected to know this". But labeling these things as obvious isn't meant in the sense "if you don't know this, you're stupid or uninformed", or in fact "this will be instantly clear as soon as I mention it", it's meant to mean "if you were to follow the breadcrumbs and check up on the 'obvious' thing, it wouldn't help you much in following my proof, so take my word for it. Or, y'know, knock yourself out if this step is interesting to you".
As a working mathematician, I would say "obvious" is most often used for omitted arguments whose analogues are widely established elsewhere.
As an elementary example, in an analytic number theory paper one might need to know that for some constant C we have
5x + x^3 + ln(x) < Ce^x
for all positive x. (In practice, one would not need to determine such a C, just know that one exists.)
Such a claim would usually be described as "obvious" or else stated without any justification. I doubt you could find precisely this claim in the literature, but one can find plenty of very similar arguments in textbooks, and anyone doing research in analytic number theory would find this "obvious".
> Like everything in mathematics, "obvious" is a term of art. Broadly speaking, it refers to a fact, proof, consequence, which is necessary for the proof to advance, but which is already established elsewhere, so it does not in itself aid in understanding the proof being presented.
"Trivial" is a term of art (and doesn't mean exactly this) but I'm not sure that "obvious" is.
I think that something already proved is called an immediate corollary if it's a very small step, theorem if it's not that small but well known, a previous result (with a citation!) if not well known, or if you can't cite anything, at least say it's part of "mathematical folklore".
so, yes, pythagoras did not create a dead simple mathematical model that captures the entire complexity of human musical experience several thousand years ago. BUT i think the ongoing study of consonance/dissonance is a very interesting area of the intersection of math and music
the basic idea being, different timbres lend themselves differently to different tuning systems. so we can parameterize our models of tuning systems based on timbre
an important thing to keep in mind: consonant/dissonant doesn't mean "good/bad" or "pleasant/unpleasant". they're the output values of a mathematical model which we have a complex intuitive relationship with. other ways of thinking about it might be "simple/complex", "resolved/unresolved", "release/tension", but all are inaccurate in their own way
some areas i'd love to see progress in:
- the work i've seen focuses on computational models, i.e. take a simple mathematical model of timbre, and directly compute the consonance/dissonance curve from it. but real instruments' timbre varies across many dimensions, some prominent ones being pitch, time, and dynamics. can we instead burn some CPU cycles and generate curves from a waveform?
- what does this look like for triads? tetrads? ...?
- put this in the browser! would make it so much easier to play with and present the ideas to less technical audiences
- how can we use this to generate new instruments? can a synth automatically adjust its tuning system based on its parameters? can we start from a set of desired consonant/dissonant intervals and generate an instrument with a matching curve?
To simplify what youre saying - I think its just a matter of opposites/differences. Music is a pattern of differences. You can take any two things that are different and create a pattern, a rhythm and humans will find it interesting to listen to and make sense of it. This moreover has a 1:1 relationship with a visual representation. That is, every piece of music has an equivalent visual representation.
the historical expectation is that class methods will dispatch dynamically but free functions will not. so if you only have structs, functions, and UFCS you either:
1. don't dispatch on the first argument,
2. make the first argument privileged and dispatch on it, or
3. dispatch on all the arguments
the first solution is clean, but people really like dispatch.
the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.
the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.
the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.
nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html
so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!
1. patients invented and self-prescribed the pill originally
2. the doctor has concluded that the pills are harmful by studying what happens who do not have the illness the pills are meant to treat take the pills
3. the doctor didn't really keep track of what doses were given to different patients
i.e.
1. trigger warnings were not originally forced on people, they were created by people who found them helpful to help themselves
2. the studies in the meta analysis are all on general populations, in particular mechanical turk and college students
3. there is no discussion of the different effect different implementations of content warnings can have. for example, the only study that measured physiological responses instead of using self-reported anxiety showed the highest anxiety response. probably, because it also gave a completely general and non-specific content warning that went like this: "The next page has the link to the movie clip. Researchers have been asked to give a trigger warning for the clip". so they showed that when told some arbitrary but highly disturbing thing could happen at any point during a video, people in general will be more anxious when watching the video. and concluded that content warnings are a harmful practice.
4. The doctor didn't keep track of of how many patients ditched him, forever, because the doc doesn't understand the above
-----
Thank you for a thorough reply and debunking of the argument by broken analogy.
The whole idea of content warnings is giving the audience a choice; it's about informed consent — a concept that both HN and the researcher seem to struggle with.
No shit Sherlock that a content warning of the form "some thing you won't like will happen, BUT I WON'T TELL YOU WHICH THING NOR WHEN IT WILL HAPPEN is anxiety inducing!
For fuck's sake, that's a bad faith thing to say.
How about:
>"Warning: I'm going to talk about rape, about 15 minutes into the talk, for about 5 minutes. I'll give you a heads-up, so you don't have to worry. If you don't want to hear about rape today, you can skip this part and stay with us for the rest."
This is a trigger warning.
It enables informed consent to consume any/all parts of the content.
Similarly, "what follows in 10 seconds is a depiction of rape" is a warning.
A trigger "warning" without the option to opt out of consuming the content warned about isn't a "warning", it's a threat.
And a "warning" that isn't specific about either content or time is torture.
>"Somewhere in this talk, we'll show something that we know you asked us not to show you out of the blue. We'll still show it out of the blue, but we're warning you about it now. No, you can't leave"
— apparently, we need a research article to tell HN that this is fucking bullshit.
The cherry on the pie remains what I said in the first place: that the natural outcome of such "warning" (i.e. lack of warning) is that affected people won't choose to interact with you again — and that's exactly what this study doesn't measure.
but in reference to the linked article, i will say that the researchers interviewed in the book (and i got that sense for Zoe as well) were in agreement with you that the research didn't support a vision-based mechanism. but everyone agrees that the imitation is going on. the researchers in the book suggest a gene transfer-based mechanism instead! (mentioned briefly in your linked article)