I switched to Positron a few months ago and have mostly found it seamless.
I'm an academic bioinformatician/data scientist and I mostly use R to do my data visualization and table wrangling. I use quarto documents. Before positron I used RStudio as well as VSCode with lots of extensions to add R functionality there.
My main gripes with Positron are no inline plots underneath code chunks, and some bugs where sending code to the console from code chunks occasionally stops working until restarting the program, and View() occasionally stops working. But the better file explorer, integration with Claude Code, and access to most of my VSCode extensions make it worth it for me.
# variable A has three causes: C1,C2,C3
C1 <- rnorm(100)
C2 <- rnorm(100)
C3 <- rnorm(100)
A <- ifelse(C1 + C2 + C3 > 1, 1, 0)
cor(A, C1)
cor(A, C2)
cor(A, C3)
# If we set the values of A ourselves...
A <- sample(c(1,0), 100, replace=TRUE)
# then A no longer has correlation with its natural causes
cor(A, C1)
cor(A, C2)
cor(A, C3)
I think my most challenging diagnostic problem was a channel hanging the system. I used a 360 I/O channel test box that connected to the channel and when a error or hang condition would occur it had recorded the last several instructions and the channel responses to those instruction. IBM sent a factory engineer to the site and it was determined that a test I/O instruction to a 3271 was generating a device end status when it should not generate any new status. The fix was a EC to the wiring of the 3271.
My most unusual repair was not in the maintenance manual. One morning about 2 am I had a bad 12v power supply in a disk controller unit. I asked the customer to bring me a 12volt car battery. I rewired the 2841 to the battery sitting in the floor beside it. The 2841 powered up and ran for about 15 minutes before it started getting disk read errors. I asked the customer to bring me a battery charger which I connected to the battery. The computer ran two days with the battery supplying the 12v until I could get a power supply.
Sometimes experience and good luck are the troubleshooters best tools. In 1988 I was in China helping the Chinese with their computers and received a call from The Bank Of China as their system was down and they had closed the bank because of it. My assistant Chen Wei and I walked into the computer room and I looked at the console. The console showed a MPX channel error. I looked around the computer room and saw several sections of the raised floor were pulled up which indicated the Chinese service company had been moving boxes around. Due to past experience I knew the buss and tag cables could be switched and would cause a MPX channel error. The first box I checked had the cables switched and Chen Wei switched them correctly. Everyone in attendance thought I was a true computer expert but it was experience and good luck.
I never considered leaving my IBM Field Engineering job. The job was rewarding and gave me a great sense of purpose; however it was very stressful and had a lot of high expectations. With the 360 line of computers the field was flooded with engineering changes (ECs) to be installed and IBM eventually hired part time people just to install ECs. The ECs eventually fixed the many problems with the 360s and the job demands settled down to more normal.
Every form of memory storage I was exposed to worked well except for the delay line storage unit in the controller for 2260 CRTs. IT WAS VERY TEMPERATURE SENSITIVE and required a lot of maintenance. THANKFULLY it was not around very long.
I was in a resident territory 60 miles from the home office and we stocked a good supply of parts but far from any part you would ever need. My branch office stocked a higher level of parts and would send them to me via taxi if needed. The regional parts center in Atlanta would air freight over night to the Birmingham airport and I would meet the airplane. I had a part removed from a production line machine and sent to me for a repair. Part support was very good. In the 1990s when I was working for TSS we did get vans so we could have some parts with us.
I do not know about IBM today but during my time working for the company they were the greatest company to work for if business was good but in bad times for the company their number one priority was the bottom line.
I have no idea where computing will be in 60 years. The tool I miss most is the oscilloscope. It was great fun and satisfaction to set up the scope and computer and be able to see the display of the electronic signals while you looked for a missing or erroneous signal. You had outsmarted the computer. The top do in my days was if you did not have a good handle on a problem in two hours call for help. grandfather
I do not remember people being concerned about computers replacing them because in the 60s and 70s computers were creating a lot more jobs than they were replacing and automation had not taken over at that time. IBM had a very good support network all the way to the plant if necessary.
I did not work on the computers you referred to and my favorite computer was the 360 model 40 (2040) because it was very reliable and relatively easy to work on because by then I understood the microcode much better. grandfather
I was a hardware tech and we installed updates or patches to the computer micro code many times without replacing the entire code. I think most programmers preferred to fix the problems rather than start over. grandfather
I do not remember any transistors being inside the core house but sometimes the welds inside the house would break loose and if you could find the broken weld you could resolder it. IBM core units did not have spare positions. Sometime the entire core house would have to be replaced. - Grandfather
Hacking was not a problem in the early days of computing as there was no internet and computers talked to each other over dedicated telephone lines. - Grandfather
This playlist[0] from TangoTek shows him developing a mod to improve villagers in minecraft. Definitely nothing compared to DF, but still much more interesting than vanilla. Spoiler is that development is paused, not sure if anyone has continued to develop it.
I noticed one of the captions mentioned it was a Kodachrome slide, and I found this website which has old photos and searched for Kodachrome slides (note I have ublock on, I think the website might look pretty terrible without it):
As an example, maybe you want to know if freshmen from different dorms had more or less satisfaction that average, but wanted to deal with the fact that different dorms had different response rates or could even have different reasons for not responding. The fear is that the data are not "Missing Completely at Random," (MCAR) meaning the missingness of the data is correlated with some of your predictors, e.g. freshmen who are too busy having a great time at one dorm, or students who are ultra-depressed at another dorm didn't check their email.
One solution would be to impute your missing data taking into account what data you do have about the missing participants (e.g. maybe dorm, major, gender). In a bayesian context you can include this imputation as part of the model fitting, which means uncertainty gets appropriately added to the results.
This is a good primer on how to handle this using the `brms` package in R:
That was a good read for me - someone who has heard of Mastondon and ActivityPub but hasn't really grokked the tech and definitely didn't know other alternatives.
(I'm not GP) My answer would be that it's the difference between "Why do mosquitos have differential attractions to humans" vs "Why do mosquitos like Subject 33 more than Subject 28." The untestable assumption is that what makes Subject 33 more attractive to mosquitos than Subject 28 is generally applicable to the population at large. I agree intuitively with GP that finding 1/64 to be highly attractive in one sample and 2/5 in another would be surprising if this were following some binomial distribution, but the methodology for determining attractiveness was different between those participants (live test vs exposing mosquitos to a nylon that had been worn by the participant).
I'm an academic bioinformatician/data scientist and I mostly use R to do my data visualization and table wrangling. I use quarto documents. Before positron I used RStudio as well as VSCode with lots of extensions to add R functionality there.
My main gripes with Positron are no inline plots underneath code chunks, and some bugs where sending code to the console from code chunks occasionally stops working until restarting the program, and View() occasionally stops working. But the better file explorer, integration with Claude Code, and access to most of my VSCode extensions make it worth it for me.