hvocode

Chronic fatigue syndrome has long been known to often start with a viral infection (for example: https://pubmed.ncbi.nlm.nih.gov/21756995/). Other issues can arise as a consequence of viral infections as well (e.g., thyroid problems). I don’t think this is well known amongst the general public, even if it is known in the medical field. This may be a reason why people are surprised about “long-covid” as if long term effects are something unique to the SARS-COV-2 virus.

I’m in the same boat. Due to security restrictions of my employer I can’t use cloud services to store work related stuff. I was really bummed when I discovered that a lot of the interesting features of my RM2 require their cloud service. I’ve dug through the GitHub repos of RM2 hacks and open source tools that are available, but it still feels like I’m missing out.

Reinventing known things and claiming that they’re novel is sort of his shtick. That said, he often does do interesting work - it just takes quite a bit of patience (which many people don’t have) to wade through the fluff and self-congratulating to get to the interesting technical meat of his writings.

Part of me wants to disagree since some of these features make my code shorter, but I have to agree since they commit a sin of language design that I dislike - implicit magic. Decorators are useful because they can help you shrink code by letting the decorator generate boilerplate for you. The code gets smaller, but now it’s harder to know what’s going on since you need to know what magic happened behind the scenes due to the decorator. It feels very much like issues I ran into when I used C++ meta programming libraries - my code shrank, and at the same time my understanding of what it actually did also shrank. Same with the walruses - my code gets smaller because now there’s some implicit stuff happening.

Comprehensions are a little less magical - if anything, they are more explicit. If I want to create a list where each element is generated by some function over another list, I just say it. Doing so with loops is obscuring what I wanted to say in the first place. The problem with comprehensions isn’t so much the comprehension, but the obtuse ways people can use them to eke out performance by avoiding explicit loops.

I’m all for things that are closer to what a programmer means, but less keen on features that entail obscuring details that may come back to haunt the programmer later (I see this most often with decorators).

I’m getting a little tired of articles or chats with people where you get the impression that people think the vaccines will create some sort of covid-proof bubble around them. This is the only explanation I can find for people acting surprised that vaccinated people get sick. The whole point was to prime the immune system so that when exposed, the likelihood of extreme effects would be drastically reduced. That’s it.

(E: I don’t get why people downvote this - all of the benefits of vaccination are precisely due to what I describe. Lower likelihood of individual bad outcomes, which reduces burdens on healthcare, and ideally, reduces community spread by reducing the amount of virus that replicates in an individual and can be passed on. This is why I was one of the first in line when I could get the vaccine. Perhaps daring to critique people with unrealistic vaccine expectations is unacceptable?)

The details of Windows executables are all well documented and open - it's very easy to parse a windows executable and run it. The part that's missing to run it without Windows is the implementation of system calls and system libraries. Without those the executable will run into dependencies that you are missing. This is the whole reason for things like WINE - the executables are easy, but the runtime environment that Microsoft hasn't opened up is hard.

I'm not sure it's a question of FOSS OS vs non-FOSS OS. Working with MacOS has always felt similar to working with other non-Linuxes -- it's different. When OSX first came along with Rhapsody, while it was a form of UNIX it was definitely painful - stuff rarely built out of box, and there was lots of breakage. It surprises me when people talk about how wonderful OSX used to be that they forget how absolutely painful it was for the first few years of its existence. There was a brief period between 2005 and 2013 when stuff worked reliably (the "golden age" you refer to) - and it wasn't a matter of OSX becoming more open. It was just popular, so OSX was a first class citizen in most configure scripts and the OS didn't really put up any barriers to using it like a Linux with respect to the Linux security/permissions model.

The added restrictions of recent times (e.g. SIP, the move to a non-GNU build toolchain, hard read-only restrictions on the OS region of the filesystem, etc) aren't so much a FOSS issue as them just adopting conventions that aren't present on the Linuxes. The breakage of packages and porting efforts feel very similar to when we used to have to worry about how a package would work on HP-UX, Irix, Solaris, and the various systems that were all similar but not quite identical. That was never a function of FOSS or not - it was just a function of not being all the same.

I find it very frustrating that people try to treat OSX as a Linux - it's not, and it never will be. If you want to support macOS, then support macOS - don't try to bash Linux-isms onto it since they will always feel like a hack since it isn't and never will be a Linux. If that's important to you, there's an easy solution - use Linux. I do that - I have my MacBook that I use as a Mac, and for the stuff that's simply too awkward to use natively there, I just ssh to my Linux workstation and carry on.

Oh come on. Even before the pandemic your typical anti-vaccine person also wasn’t universally against all vaccines. They usually had some subset that represented their favorite rationale for not getting it: those containing substances they don’t like, those developed with a process that had a fetal cell line somewhere nearby, those given in clusters in early childhood instead of spread later on, etc. Anti-mRNA vaccine sentiment is just another instance of the same thing. Sorry if they feel sad for having that label, but it’s the same behavior.

Competitive programming is fun. It’s amazing that some people seem to think everything is about career path optimization.

Are we not allowed to do things for fun or just to pass the time anymore without someone writing that we’re wasting our time since it isn’t boosting our career?

I wouldn’t overthink the tools. I found a mostly minimal toolset was sufficient when I did my PhD: actively used repositories to make sure I never lost my work (private repos so I didn’t have to care what I put in them), plain old emacs for editing, and a mix of Mathematica, Matlab, and Python for my numerical and plotting needs. Used physical sticky notes and cheap legal pads for notes and keeping on top of todo lists. I printed papers to read since I never found a digital method to maintain the deep focus I needed to fully read the papers. I generally discourage students from worrying much about tools: at the end of the day if you’re thinking more about a tool or workflow process than your research work, you’re not making progress towards the degree. Use whatever tools and methods allow you to be productive without thinking about the tools or methods.

I don’t get it. Why would you sign in with any personal information on a work device? Just create a free account and use it for work. I have zero sympathy for people who use personal accounts on work devices : just because they let you take it home doesn’t mean it’s not 100% work territory.

This sounds less like bad corporate policy and more like naive employees who didn’t think through the importance of separating work and personal devices.

That’s not that hard in an FP language. I routinely write code with multiple structures referring to the same thing. My usual solution is to have an identifier for the thing that indexes into an array or map, and then the other structures contain that ID instead of the object itself. It’s basically a pointer like I’d use in any other language. The details and choices for how to represent the IDs and structures is usually application specific, but that’s true in any language: how you do something should be the choice that best fits your problem. There isn’t anything about functional programming that makes it impossible or particularly difficult.

I think the point is that yes, they have always had the power to do these things - but they haven't thus far. We rely on entities with power (companies, governments, people) to exercise restraint in how they exercise it. Those that DO exercise restraint gain trust since exercising restraint demonstrates an understanding of the consequences of not doing so.

What the Apple move is doing is showing that they are willing to relax their restraint. It gets tricky because everyone agrees that the specific goal here is honorable, but the manner by which they are using their power to achieve it is generalizable to areas that are less honorable. Once they are willing to use their power to accomplish one highly honorable goal, it's not a big ask for them to use it for a slightly less honorable goal in the future. Iterate that a few times and you can find yourself in a very bad place. It's the classic slippery slope argument - when you know there is a slope that leads to dangerous places, you need to not ever start down it no matter how righteous the motive is in starting down that path in the first place. There's a reason we have the old saying "the path to hell is paved with good intentions".

The existence of power isn't what matters: it's the intention and willingness to exercise it. Apple is now demonstrating that they have changed their stance in how they choose to exercise their extreme power. That's worthy of scrutiny.

For a concrete example of where I expect this to naturally lead to: instead of a database of child pornography being the source of the hashes to search for, the Chinese government provides a set of hashes of all known digital photos of the Tianenmen square protests of 1989. Does it really seem implausible for a government like China's to NOT use this kind of technology for that purpose? It's not hard to cook up similar examples all over the place.

I’ve seen the same thing occurring in central Oregon in spots that usually are busy in the summer. You see places closing early or not opening due to staffing issues, right in the middle of the busy season when people are over there vacationing. It’s caught me by surprise when I noticed things like the grocery store closing super early, or cafes being closed on days they’d usually be open, all with signs on the door saying that it’s due to staffing shortages.

I think others addressed the "why proof not empirical data" question well, but one additional point. A logical proof is only as solid as its weakest component. In mathematics any result that has been proven may be used in a component of another proof. If you have a result that is based on empirical evidence, then every result proven based on that also inherits that empirical evidence as part of its foundation. The reason we don't do this is that if, by some weird chance, the original result that used empirical data instead of proof is shown to be false, then every result built upon it is invalidated and needs to be revisited. That would be a mess. Sticking to requiring formal proofs at least reduces that possibility - although it is still entirely possible for a proof to have a subtle mistake as well, which would have a similar cascading effect on results built upon it.

This is very important. I personally like old technologies and languages where the designers considered users who had limited technical skills, and most importantly, assumed that those users had no interest or need to improve their technical skills. Removing the assumption that users are willing to increase their technical sophistication forces a designer to think more about what they're designing. Looking at older languages is interesting - for all their warts, they do feel more intentional in their design than modern things that have a clear developer-centric mindset baked in.

Exactly. These are restrictions that have been viewed as favorable for security purposes for decades. It’s nice to see a mainstream OS actually implementing them.

The resistance to them seems to be largely due to lazy developers: it would be EASIER if the system let a developer do whatever they want with a “trust me, I’m smart” justification. But we can’t design for the occasional safe and smart developer: we need to design for the sloppy ones and the malicious ones. The smart and safe ones can find a way to work within the constraints. As for lazy and sloppy ones who can’t adapt to the constraints - adapt.

It’s an easier mode for me when standing and holding the iPad with one hand and the stylus in the other. The keyboard is nice when sitting and using both hands for sure. Same was true when using my old thinkpad tablet in the same way.

I write comments based on what I expect I will need to know if I close the editor and don’t look at the code again for a couple years and will need to jump back into it as quickly as possible. That usually means I don’t want to waste the time of future me reconstructing what the code denotes if I could just write it down in a comment in he first place.

It seems like broadly speaking everyone has just been stressed here for a few years. Not stressed about work? How about healthcare? Or the economy? Or one of many social topics? Maybe political disagreements with your family members? How about some looming climate related topic? The whole country feels stressed out for one reason or another and it’s gotten noticeably worse over the last decade. The title could very well replace “US Workers” with “Americans” and probably be just as accurate.

I'm sure somewhere in the big pile of comments someone else is saying this, but as another voice saying it:

1. The pandemic was weird, and likely a time when people didn't want to change jobs due to a need for stability. It seems like it would be normal to see a wave of job changes that have been basically on hold until people felt safe.

2. I'm assuming some people have had more of a chance than normal to think more about what they want out of their life and jobs over the last 18 months. For some people, this means they might make a job change that they didn't anticipate making in January 2020.

3. It's one thing to threaten to leave, and a whole other thing to actually do it. I've had co-workers who were "ready to quit" for my whole career, some of whom are still at the jobs they were ready to quit a decade+ later.

I've had more than one intern or young engineer that I've had to teach to resist the urge to put witty comments and jokes in project docs, comments, or errors. Especially in error messages or things that can be exposed to users/customers. Even if it's an error you think only the dev team will see, you never know if it will make its way out to audiences you didn't intend. Somehow I doubt people faced with this error message really were amused by the reference to the old Amiga OS errors....

I'm all for significantly limiting the "data economy", but I suspect too many people have become too used to getting free stuff. I see this all over the place - there are products and services that are quite expensive to build and provide, but they're free because people (often unwittingly) exchange data about themselves in place of the actual cost. If you still want those products/services without the data industry supporting it, someone will have to pay for them. I think lots of people opposed to the data economy will become less opposed when faced with actually paying for stuff it supports.

I learned this the hard way trying to sell something that competed with free tools from Facebook/Google/[other giant data monetizing companies]. Our tool was/is competitive, but we aren't in the business of data harvesting or advertising - so, the engineering cost (many years of effort) would have to be paid from actually selling the product. The response? People want the free ones, and could really care less how the engineers that built it were paid as long as THEY (the consumer of the tool) got it for free.

As long as the "someone else will pay for X so I can have it for free" attitude is acceptable and widespread, we're likely stuck with a pervasive and deep data economy.

I wish it were only leaders who are desperate to get back to the office, but it seems like the other force pushing for return to office time is the cohort of people where work IS their social circle. I can't relate to that crowd - even when I was young and single, my social circle was largely outside work and in grad school I tended to socialize outside my department.

This social argument I sympathize with - nobody likes to be lonely. But please - don't force everyone to go back to one model of working simply to support a subset of people who've chosen to make their life revolve around their employment.

I’m not seeing what’s new here compared to github, figshare, zenodo, overleaf, authorea, etc. Github is actively used for scientific papers and code development. Heck, there are open journals that are based on github for both the paper submission and review process (see Journal of Open Source Software). Figshare and Zenodo are used for artifact hosting and citation. Overleaf and Authorea are used for collaborative editing and publishing to journals and archive sites. Publons exists for tracking peer review activity. All of these have some collaboration with institutions pushing the open science movement forward, be it large research institutions like CERN, non-profits, universities, funding agencies, etc. I don’t see any connection of Researchhub to the open science movement - just some “founders in San Francisco”.

I really don’t see what this adds other than a cryptocurrency component and a leaderboard. I’m not convinced that the missing component in modern science is some form of internet points.

[Disclaimer: I’m a couple decades post-PhD, actively working as a researcher the whole time on all sides : publishing my work, peer reviewing others, and the editorial side helping the whole process work. I am very happy to see progress towards making science work better, but have learned to be super skeptical of startups sniffing opportunities in this space.]

100% agree as a maintainer of a substantial modeling and simulation project that uses Python. We use it simply because most of the people contributing ONLY know Python. If I was to rewrite large portions of the code in another language, it would be faster but a large portion of the team wouldn’t be able to effectively contribute any longer. We pay the performance price for that accessibility. I’ve already tried and discovered that moving to a new language (like Julia) will be a non-starter: the other people don’t have the time or desire to learn another language or tool chain (they’re not computing people: they’re domain experts in their non-computational fields). Any speed improvement that lets people continue working in Python would be a great benefit to that project.

It’s a shame the WFH experiment is blended with the pandemic. It’s hard to decouple the “effectiveness of WFH” from the “pervasive impact of a global pandemic on all aspects of daily life”. I think a lot of people got a negative taste for WFH for reasons that are less WFH and more pandemic.

This would be useful as part of the new repo creation workflow on GitHub too. Instead of just getting an empty readme, pick the sections you want and start with one that just needs to be filled in. Could autopopulate some sections too (eg, license). I’d rather that so I can edit in my regular editor without having to use a separate site and web editor to get that initial template.

While there is likely some truth to it, the first survey is hardly unbiased: it’s a survey showing lots of people are looking for jobs conducted by a company focused on job searching. That would be like WebMD doing a survey of people on its site to see how many people think they’re sick and finding out “wow, lots of people think they’re sick”.

That’s a good observation: I think you’ve observed not a change in programming itself, but a shift in the kinds of things large numbers of programmers are building that get talked about on sites like this. Other forums that I track still talk about the deeper aspects of programming, which reflects more on the community and it’s interests than it does any fundamental change in how hard programming is.