shawxe

I very regularly refer to the act of writing code as "hacking the Gibson."

But... how is this easier than the solution proposed by OP?

I'm pretty sure the page is supposed to be satirical. It's poking fun at the number of software projects that have been around for several years (or maybe even a couple of decades), have had dozens to hundreds of releases, and yet are somehow still at major version 0, which flies in the face of both semantic versioning and general common sense.

To respond to another part of this, it doesn't matter if we can look at a brain scan and predict perfectly exactly what the scanned subject is thinking. That only answers the question of "how do thoughts occur" not the question "what are thoughts?"

We have no way of even constructing the concept that gets around this. "This brain state corresponds to these thoughts." Okay, but where/what are the thoughts? In order for something to corresponds to the thoughts, they must exist in some capacity, right? So long as consciousness exists at all, which anyone who experiences it can say with certainty that it does. If I drink a beer, I feel a certain way. Neurochemically, we understand exactly why this is happening. What we don't understand is how there are "ways to feel" in the first place.

Understanding how objects interact with one another doesn't answer the question of what those objects are; they just are. Understanding the effects of electromagnetic force doesn't answer the question of what electromagnetism is; it just is. With objects, we can actually break things down into a small number of basic components (particles) that depending on their organization make all objects. But these particles are already a thing with no reason; just an axiom we've been able to use to get a mostly logically consistent view of objects.

Consciousness, we have been totally unable to break down into anything. We can see evidence of it in others, and feel it in ourselves, and we can understand how to make it seem to go away, and also what seems to bring about certain effects in it's space (red, happy, warm, salty, etc.), but our understanding is not of those effects--it's only of how a certain material arrangement seems to bring them about.

Because the web application is only an emergent phenomenon once consciousness has already entered the equation. Without an observer, the website is nothing more than the sum of its parts; only we view it as something else. The CPU, machine code, all of the I/O mechanism, eventually just create an illuminated image on a screen that is only its emergent whole when viewed by a conscious observer who sees it that way.

Far from having an even remotely non-referential understanding of consciousness, we don't even have a non-referential understanding of the referent website as it exists in our perception--it just comes back to the same questions that a lot of physicalists seem to refuse to even acknowledge. I know that when I view this screen I see what I see as red, and I know that the material of my brain and the screen are responsible for that, but that does nothing to address what the referent red is in the first place.

How can consciousness be an emergent construct when emergent constructs are only identifiable as distinct from the sum of their parts by making use of consciousness?

I've been testing out a new workflow I'm Git in some personal projects that basically works like this.

Basically, I make a single wip branch, which contains all of my messy/frequent commits, then when I feel that things are in a good state and I'm ready to cut a release off that branch, I tag that commit with "wip-vX.Y.Z".

Separately, there is a "release" branch (which is basically master/main/trunk) that only ever gets code that was first committed into wip. When there's a new release tag in the wip branch, I run the following command on the release branch: "git cherry-pick -X theirs -n wip-vA.B.C..wip-vX.Y.Z", where A.B.C is the tag of the previous wip version and X.Y.Z is the tag of the current new wip version. This has the effect of taking all of those changes from the wip branch and staging them to be committed on the release branch. I then commit them with a descriptive commit message and tag that commit "release-vX.Y.Z".

What you end up with, as a result, is a "release" branch with a very clean commit history and a "wip" branch with a very detailed commit history. If you want to run a more detailed blame or bisect, all you need to do is checkout the "wip" branch. If you want to use code that's stable enough to be called a release, all you need to do is checkout the "release" branch. Rather than squashing/amending wip commit history out of existence or maintaining on a series of scattered branches, this workflow makes it all conveniently available in one place, without directly polluting the main branch.

As for the wip commits themselves, I do try to have them all be mostly atomic and to have them always build. But I feel much less concerned with having a couple of commits that try some idea then a couple more later on that undo it. Polluting a main branch with these sort of no-ops has never seemed particularly appealing to me, but not has simply deleting them, or tucking them away somewhere difficult to find. I've only been using this new workflow for a couple of weeks, but so far it seems to solve that problem and in general be working great.

My best attempt at Japanese:

その場合、彼女は監視されていたはずであろう。

> Essentially it means “it must have been the case that, at the moment we’re speaking of, someone was watching her.”

Another native English speaker here. This would be how I would parse "She had to have been being watched," but I think it's not quite the full picture in this sentence's case. It's important to note that the "would" adds the implication that this conclusion is being drawn based upon some other (possibly unspoken) observation or proposition.

I would say the meaning is probably closer to "In order for some unspoken condition to be true, it must also be true that, during the moment of time in the past about which we are speaking, someone was watching her."

You should take a look at Zig.

So first of all, I just want to echo the general sentiment here and say that all of this is beyond awesome. Cosmopolitan libc seems to have the potential to literally re-define what constitutes portable code.

With that out of the way, am I understanding correctly that the way this works on Linux/Unix is that the modifies itself (by overwriting the EXE file header with an ELF header)? This seems to have the consequence of making that specific file no longer portable. If I'm understanding things correctly, it also looks like the QEMU hack for non-x86_64 architectures will only work once per file, since after the first time running the file it will no longer run as a shell script on Unix so the QEMU invocation will be unreachable.

Have you considered adding workarounds for this?

re: でしょう, without seeing the original Japanese, my guess is that a more atural English translation for your first example would be "Your brother is supposed to be a man, right? He's supposed to be an adult, right?" or something more along those lines.

This may be a tangential, but I've recently found that it really is useful to track all/most of these pieces of personal data. I spent a long time trying to figure out the best way to go about this before ultimately just settling on plaintext files and Git. Some of my data goes into CSV files that I generally just manually edit with Vim, some (ie. notes) just goes into literal text files. Sensitive data lives in a separate repo and is encrypted using GNU pass

Since this is how I'm used to keeping track of code and configurations, the friction has been surprisingly low; I'd even go so far as to say I find it fun. I'm sure my specific setup is not what's right for everyone but it feels right for me and I think that's the whole point.

This isn't really true. If you're capturing by reference, you can easily say that defer can only be called on variables declared in scopes no deeper than the beginning of the defer block and you still have a very useful feature. If you're capturing by value, the "closures" are probably just getting created in the stack like normal auto variables. Either way, this doesn't really seem to be a deal breaker.

Who said anything about better? Cheaper energy = cheaper everything, but that doesn't mean that quality is necessarily constrained by current energy prices (although that also doesn't mean there aren't ways in which it could be).

Slam dunk response. This is exactly my problem with how so many developer tools and services are branded. Just give it to me plain, please.

> To be fair, if this was truly a big deal, it would be a political issue with bipartisan support and taken care of short order.

Are you serious? Since you're using the term bipartisan, I'm going to assume you're also from the US. Have you been following the news/current events recently (and by recently, really I mean any time at all over the course of the past forty or fifty years)? Almost nothing actually gets "bipartisan" support these days. Our government is in a constant state of gridlock and it is next to impossible to get anything done.

> In times of strife, at least there's one thing you can always count on: Democracy. It never fails. If you can just remember that one thing, you should be able to sleep soundly at night. (It works for me at least, I used to be a constant worrywart until I learned this trick from my therapist, and I've been golden ever since.)

I'm really having a hard time telling if this comment is sarcastic. I'm not trying to cause you to lose sleep or anything, and honestly, I commend your optimism if you're serious, but the fact is that democracy is an abstract concept that is almost never put into practice perfectly. Even if democracy's promise of "most people being happy" meaning 51 people are happy while 49 people are not is actually sufficient, even that idealized version is very far from our actually political system in the United States.

I think one thing most Americans actually would agree with is that the way we do things here, right now, in terms of government, doesn't work so well. I think there is a lot of disagreement about what should change, and how, but it seems like very few people are satisfied with the current state of affairs. The more I think about it, the more I think this comment just has to be sarcastic, so this reply is probably a waste of everyone's time, but in any case, wow. I wish what you were saying here were actually true. That would be a nicer world to live in than this one (although, frustrating as it might be at times, this one is also not so bad).

The irony of reading this, over two thousand years later, translated into a different language, presumably by someone who is, even after all this time, still able to read the original--it's almost like writing helps us remember, as a species, in ways that would have otherwise been almost completely impossible.

> Sure, and if you do strlen(s) without checking if there is actually a NUL first then:

>> finding the end of a string may place you into invalid memory if there are missing trailing bytes.

You're really losing me here. Either you have a NUL terminated string or you already know the length of the string or you have no way of determining the length of the string that exists in memory that it is safe for you to access and what you have is garbage.

Just because data is "valid UTF-8" doesn't make it safe to read. If the end of your string isn't marked and you don't know how long the string is already, it's over.

I think OP is talking about the fact that it is possible to represent and transmit sound via an electromagnetic medium and that therefore this limit is not a limit on sound information (which is nothing but generic information that can be transmitted at the speed of light) but rather a limit on sound as it occurs physically (in the way that you've described).

I see comments like this often and I find them deeply confusing. To me, it seems like most of the different programming/scripting languages you've listed excel at completely different things. I would be curious to hear what type of work you're doing where all of these languages have been, in some form or another, appropriate.

From many of the comments in this thread, one might think that FAANG companies invented the concept of open source software or that software doesn't exist outside the context of a "profit model." Whatever is going on at Mozilla right now, the notion that a piece of open source software even needs to be profitable (let alone supported by a single large company) in order to continue existing is ridiculous.

I'll concede that there are unique challenges associated with developing a web browser (it's certainly a moving target) and that there need to be several people working on it full time, but is that really something that can only happen when one big company/organization is funding the project? As for Rust, maybe someone could point me in the direction of the one benevolent large company that's backing GCC/G++ or CPython or Ruby?

I'm not saying what's going on with Mozilla isn't absolutely terrible, but the notion that Firefox or Rust are going to somehow just go away (and that this is what was destined to happen all along because Mozilla is not profitable) just doesn't really make any sense.

You really aren't kidding about Tcl. I recently discovered that with tclreadline, Tcl can be used completely in place of Bash in interactive mode, in a way that something like Python absolutely cannot.

A lot of people seem to have negative opinions about Tcl (maybe because it's more of a LISP than its syntax seems to imply), but as someone who is just discovering it, I'm shocked at how powerful it is for how unpopular it seems to have become. It's like some kind of unexpected cross between Bash, LISP, and (with Tk) Visual Basic. There's something about it that's just kind of fun.

I have a small personal recipe blog. I tend to structure my posts like this:

1. Ingredients.

2. Instructions.

3. Notes/thoughts/musings/etc.

Sometimes section 3 is quite long, sometimes it's completely absent. It is *never" the first thing you see, ever. Why? Despite the fact that I'm one of the people who enjoys reading/writing that kind of stuff, most of the time when I'm looking at my blog I'm looking for ingredients ratios and instructions, so they are first.

I don't want to have to scroll through a bunch of noise when I'm trying to cook. Just like the reviews on sites like Amazon don't appear on the page before a picture of the product and its price/description, so are reflections on a recipe out of place before the recipe itself has been listed.

I agree with this completely. It's a lot easier for me to read through a list of things in some category than it is for me to scan through a bunch of irregularly sized tiles for the icon and description of the configuration I need. For me, all of the pictures just lower the density of the information and cause it to take longer to parse every single time.

I also question the basic premise that the tabbed interface is somehow more intuitive for new users. Like many UI related assertions, absolutely no concrete evidence is being provided to support this point. I would think that it would be easiest for new users (as it is easiest for myself) to have options sorted into neat menus with uniformly sized elements where information is laid out in a vertical list (which is how lists are written in basically all left-to-right and right-to-left languages) so that it is easier to parse quickly.

I'm not sure a big spoon of salt will make you any less sick than a big spoon of sodium benzoate, but that's fair. I definitely agree that people should avoid eating things they do not understand; I think most of my disagreement with your original post is semantic, but I do still appreciate it. :-)

> There's a distinction between processed and ultra-processed (or highly processed). For example, canned fish is processed (added salt and oil), while a frozen TV dinner is ultra-processed (many ingredients added, some of which you probably don't have in your kitchen).

Sure, but OP said ban all processed food. That's what I'm responding to, not "ban all ultra-processed food." That said, I do find your categorization to be troubling. Just because something is a frozen dinner doesn't necessarily mean that it's bad for you. Whether or not something is good or bad for you is based entirely on its chemical composition; it has absolutely nothing to do with how it has been put together or what form factor its being distributed in.

It may sound like I'm being pedantic, but I think these kinds of short cuts are actually genuinely harmful. I've known many people who have thought "cheeseburgers from McDonald's are unhealthy not because cheeseburgers are unhealthy but because they are processed" and then gone right ahead and made themselves cheeseburgers that have three to four times the calories, fat, and salt of the McDonald's counterpart.

Does that make McDonald's a healthy option? Absolutely not. But why is McDonald's unhealthy? It's because the food they serve is unhealthy. It's not that the food that is served at McDonald's is unhealthy because McDonald's is unhealthy.

> Processed food is fine assuming you're aware of what's in it, how it's processed, and make sure you're not overeating any of it.

s/Processed//

If people want to eat healthier, they need to pay attention to the ingredients in the things they're eating. If we're going to regulate something, we need to regulate the ingredients that go into things people eat. Using buzz words like "processed" and "ultra-processed" with definitions that are, at best, not well understood by the general population just leads to people working around personal/social rules/regulations.

Just because your t-bone steak is local organic grass-fed whatever does not make it good for you. That food is just not healthy, even if it is the only ingredient. We did not evolve eating food like that with any kind of regularity. If you want to be healthy, you need to just not eat it.

In general, I agree with a lot of what you're saying here about eating more vegetables and way less sugar being the way to go health-wise, but I do want to respond to some specific things you've said.

> You can find really good junk food everywhere, or pay a really high price to eat in high-level Italian restaurants for example, but it is very difficult to eat standard meat-with-vegetable-without-sugar-added, except in Asian restaurants

Restaurants are typically not where I go to eat healthy food anywhere in the world, although I do think you have a pointed that American restaurants are often relatively junk food oriented.

> ban every processed food, sauce, appetizer....

There is nothing inherently wrong with "processed" food; it is entirely possible to use industrial processes to make a perfectly healthy and wholesome food product. Take for example, (this is by no means an endorsement) Larabar [1]. They make snack bars that typically contain 2-3 ingredients that are all just dried fruit. Should they be banned as "processed" food because of how they are made?

> If you would not eat a spoon of every single ingredient of some food, don't eat it

This is a ridiculous statement and is one of the main reasons why I'm commenting. I wouldn't eat a spoonful of yeast, should I not eat bread? I wouldn't eat a spoonful of salt, should I not eat... anything?

> It looks like this is hard to do in the USA: you don't easily find, for example, yogurt without sugar added.

I've never lived in an area in the United States where I've ever had any problem finding anything like this.

[1] https://www.larabar.com/

I think this is a very good and very underrated point. I'd like to see some evidence why there's any reason to assume repetitive movement with less stretching is somehow less harmful than repetitive movement with more stretching. I've been typing on the qwerty layout for about twenty-five years at this point, and I'm up to around 110WPM, so it would really take a gigantic amount of evidence for me to be bothered with trying to rewrite all of that muscle memory. There seems to be a tacit assumption that these alternate layouts improve something that qwerty is doing wrong, but as it stands I'm not convinced that premise has any merit.

Still an interesting article, none the less.

Obviously anecdotal, but in my personal experience this is pretty close to the truth.

> Another solution, more along the lines of what I was thinking, is simply to associate the hash table with a hashing function which processes the type as a structure, hashing the members individually rather than as a pad of memory.

This solution is probably what I would go for in most cases as well. The most compelling reasons I can think of for going the other way would be if there were a desire to use a specific hashing function/algorithm on all keys regardless of type or if there were a desire to have keys of different types in the same map.