> Some would use laptops, others would opt for tablets or mobile phones. Not all of them could even use the programming language that was the subject of the test: the statistical language R. “We had no control, really, over what devices those students were using,” says Stagg.
Surely the problem here is much bigger than WebAssembly vs native code. What does it even mean to give students a test on using a software package if they aren't even willing to buy a computer? How are you supposed to do professional stats work after university on a mobile phone? They don't even expose a file system.
Learning how to use a full workstation-class computer is a basic pre-requisite of doing science and many other types of professional work; these universities are just hopelessly lost if they're not making that clear to students up front and requiring or provisioning the equipment they need. Degrees awarded on the back of tests like these are worse than useless, they're outright deceptive to future employers. If someone claims they studied scientific computing and then turned out to not understand files, folders, packages, multiple windows and other basics then they'd be completely unable to do the job.
>How are you supposed to do professional stats work after university on a mobile phone?
Generally your employer or institution will supply you with a computer (or access to one in the case of students)? The test described was devised during the lockdown because people didn't have had access to the university's facilities.
At my university we were able to use an RDP client to log into windows machines with all the engineering software installed on them. Performance sucked, which is why people only did it if they had too. But it was manageable. R was one of the software packages.
While I mostly agree on the computer comment, I largely disagree on phones (not apple, iphones are pretty IoT paperweights without a lot of hoop jumping and prostrating to apple). You can absolutely do some amazing things on a phone. I've been living in terminal (via termux) on my phone (android) for a while now as a little personal challenge, using micro to write python TUI apps as I need them. I have file system, etc. and since I have access to sensor data I can make some pretty nifty things happen fast. Need an app to remind me to set parking app so I don't get another fine? Easy done, can do it on my walk to the office. I think we're all ignoring phones a bit due to the learning curve and inconvenience when compared to traditional computing.
Now I couldn't imagine doing some serious analysis via phone but also with things such as jupyter notebook or similar for R, it isn't a stretch to believe you could get some rudimentary step by step kinda stuff going.
Hands down, I would choose a proper keyboard and multi-monitor setup any day of the week, but the difference expressed through metaphor in terms of working cars puts phones more in line with a hatchback than a scooter as most people seem to think. A hatchback is often perfectly sufficient and at times, preferable.
Right, but that's really using Linux not Android. You can also run Linux on Chromebooks or just SSH to a Linux server using iOS, but someone has to teach students those skills. Just knowing how to use a smartphone in general won't work.
> For instance, modern operating systems can handle 64-bit numbers. WebAssembly, however, is limited to 32 bits, and can access only 232 bytes (4 gigabytes) of memory. Furthermore, it cannot directly access a computer’s file system or its open network connections. And it’s not multithreaded; many algorithms depend on this form of parallelization, which allows different parts of a computation to be performed simultaneously. “A lot of older code won’t compile into WebAssembly, because it assumes that it can do things that can’t be done,” Stagg says.
I am surprised by the memory and 32 bit limitations... Are there plans to overcome them?
>Furthermore, it cannot directly access a computer’s file system or its open network connections.
Those are its two strongest features, not bugs. If you're not going to respect those, just use native code, and the broken ambient authority model of computing, which never works out in the long run.
Edit: The article doesn't focus much on these limitations, but I think that putting up with the current limitations of WASM in terms of memory size or lack of threading might suck, but it's worth the ability to just try things out and run them without risking your whole computer.
Younger folks who never had a PC with only write protectable floppy drives missed out on a wonderful care-free period when you could just TRY OUT any new software, and your other data was safe, no matter what.
> Younger folks who never had a PC with only write protectable floppy drives missed out on a wonderful care-free period when you could just TRY OUT any new software, and your other data was safe, no matter what.
This goes so far now with sandboxing and virtual machines. I think the experience spawning VM to run and test new software is annoying but I guess it is still better than the annoying stuff from that era.
Disclaimer: I am one of those younger folks and probably naive in terms of that era.
It's so appalling to me to see such brazen advocacy for read only computing. This is such a teenie tny narrow little window of computing. Nothing should be consigned to sch irrelevances.
The quote is a bit misleading. Traditional WASM (wasm32) does have 64-bit numbers (both a 64-bit integer type, and 64-bit floats), but the address space is limited to 32-bits (and thus pointers are 32-bits too).
AFAIK the downside of wasm64 is that it cannot use some virtual memory tricks to get rid of software range checks, so if memory access performance matters and a large address space isn't needed it probably still makes sense to stick with wasm32 even when wasm64 is available.
Wait, can't web assembly use workers? It would be the same kind of architecture like with workload shared over a range of devices and receiving responses in random order, but in this case from worker threads
We had code execution in the browser over 25+ years ago, with Java applets. Sure, they were bloated and sluggish back then. On today's hardware, you wouldn't even notice.
Don't see this happening scientists are totally happy installing R or Matlab etc. Often a lab even sticks with windows b/c of some drivers for a sensor that only exists for windows
One thing that I found mind blowing initially was that unbricking my pixel 5 involved simply going to Google's install page for it in Chrome with the usb connected and it reflashed successfully.
Of course, there's nothing fundamentally new there, I'm sure Java applets could have done it on a serial port if somebody tried, but it was impressive given how gimped most os-level access is in a browser.
So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.
The knife cuts both ways, though: webusb / webhid / webmidi allow raw access to physical devices which weren't designed for it, and therefore don't have any protections for it. You're just one nag screen away from having your devices be permanently hacked by some random website.
It's quite worrying seeing the Chrome team have such blatant disrespect for basic security. Rather than using an allowlist for known-good devices or using some kind of handshake to validate the device is okay with a certain website talking to it, they use a blocklist to prevent a website from messing with things like keyboards/mice/u2f keys. It's a massive footgun waiting to go off.
Firefox refuses to implement those APIs due to security concerns, and until they do a serious design overhaul it'd probably be better if Chrome hid it behind a default-off feature switch too.
> So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.
Yes, delivering device control software in a browser with webusb from a cloud platform will usher in a whole new chapter of keeping people from truly owning the scientific research equipment they have procured!
Enterprise companies have huge issues with installing, securing and maintaining open-source software though. Using browser based tools doesn't really resolve the underlying organizational and competence issues, but at least it lets people do their jobs.
From what I see helping some friends not well versed with programming doing their PhDs, FORTRAN still has a lot of penetration with scientists. Lots of climate models are FORTRAN code.
Also, through helping them I can see the dire state of scientific code, it's a mess, if departments had the budget to employ 1-2 professional programmers to help them mentor staff it could be extremely helpful for science code to be more easily shared and reasoned about, some of the code I've seen is basically throw away code after the contributors aren't around anymore...
I get the impression that you think that Fortran is a bad language for science.
Modern Fortran is a nice language for many scientific computing tasks. For me, I like Fortran because it's basically the easiest statically-typed compiled language (I rarely have to think about pointers, for instance), it's basically as fast as C, it has some good features for my variety of scientific computing (arrays in particular), and it has many compilers. Certainly, a better language could be designed without the legacy baggage and some features I'd like (better generics in particular), but I haven't seen anything better yet myself.
Now, legacy FORTRAN (note caps) is often a mess. It wasn't until the Fortran 90 standard that the capitalization changed, and the language changed a lot with that standard as well. I suspect the issues that you're seeing are more from many scientists not modernizing, and not from Fortran in itself.
A lot of scientific code is worse than a mess, it outright doesn't work and yields incorrect results, a problem which is then routinely covered up. I've seen this first hand :( The worst part is that universities don't realize how much they don't know. On the rare occasions outsiders notice what's going on they are faced with a wall of baffling excuses and justifications for why so much doesn't work, like "if it didn't crash it must be correct" or "scientists don't need unit tests, we just look at the results and know they are right because we're experts". Academics are happy to pronounce that professional coders can't judge the correctness of their work and do so loudly and publicly.
As for money, well departments do have the budgets to hire developers. Science funding is in the high billions in most western countries. The problem is not departmental budgets, it's a social problem. Universities love the practice of spreading money amongst as many professors and tiny departments as possible in order to lay claim to every possible area of human knowledge/experience. Combine that with a culture of low standards and coverups and you've got a recipe for disasters (e.g. invariably critical bug fixes that corrupt data are described as not affecting the final results even when that clearly can't be true).
Readit News
Surely the problem here is much bigger than WebAssembly vs native code. What does it even mean to give students a test on using a software package if they aren't even willing to buy a computer? How are you supposed to do professional stats work after university on a mobile phone? They don't even expose a file system.
Learning how to use a full workstation-class computer is a basic pre-requisite of doing science and many other types of professional work; these universities are just hopelessly lost if they're not making that clear to students up front and requiring or provisioning the equipment they need. Degrees awarded on the back of tests like these are worse than useless, they're outright deceptive to future employers. If someone claims they studied scientific computing and then turned out to not understand files, folders, packages, multiple windows and other basics then they'd be completely unable to do the job.
Generally your employer or institution will supply you with a computer (or access to one in the case of students)? The test described was devised during the lockdown because people didn't have had access to the university's facilities.
Now I couldn't imagine doing some serious analysis via phone but also with things such as jupyter notebook or similar for R, it isn't a stretch to believe you could get some rudimentary step by step kinda stuff going.
Hands down, I would choose a proper keyboard and multi-monitor setup any day of the week, but the difference expressed through metaphor in terms of working cars puts phones more in line with a hatchback than a scooter as most people seem to think. A hatchback is often perfectly sufficient and at times, preferable.
Mine does.
I am surprised by the memory and 32 bit limitations... Are there plans to overcome them?
Edit: found it, https://github.com/WebAssembly/memory64
Those are its two strongest features, not bugs. If you're not going to respect those, just use native code, and the broken ambient authority model of computing, which never works out in the long run.
Edit: The article doesn't focus much on these limitations, but I think that putting up with the current limitations of WASM in terms of memory size or lack of threading might suck, but it's worth the ability to just try things out and run them without risking your whole computer.
Younger folks who never had a PC with only write protectable floppy drives missed out on a wonderful care-free period when you could just TRY OUT any new software, and your other data was safe, no matter what.
This goes so far now with sandboxing and virtual machines. I think the experience spawning VM to run and test new software is annoying but I guess it is still better than the annoying stuff from that era.
Disclaimer: I am one of those younger folks and probably naive in terms of that era.
AFAIK the downside of wasm64 is that it cannot use some virtual memory tricks to get rid of software range checks, so if memory access performance matters and a large address space isn't needed it probably still makes sense to stick with wasm32 even when wasm64 is available.
PS: see discussion here: https://github.com/WebAssembly/memory64/issues/3
Of course, there's nothing fundamentally new there, I'm sure Java applets could have done it on a serial port if somebody tried, but it was impressive given how gimped most os-level access is in a browser.
So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.
It's quite worrying seeing the Chrome team have such blatant disrespect for basic security. Rather than using an allowlist for known-good devices or using some kind of handshake to validate the device is okay with a certain website talking to it, they use a blocklist to prevent a website from messing with things like keyboards/mice/u2f keys. It's a massive footgun waiting to go off.
Firefox refuses to implement those APIs due to security concerns, and until they do a serious design overhaul it'd probably be better if Chrome hid it behind a default-off feature switch too.
Yes, delivering device control software in a browser with webusb from a cloud platform will usher in a whole new chapter of keeping people from truly owning the scientific research equipment they have procured!
Also, through helping them I can see the dire state of scientific code, it's a mess, if departments had the budget to employ 1-2 professional programmers to help them mentor staff it could be extremely helpful for science code to be more easily shared and reasoned about, some of the code I've seen is basically throw away code after the contributors aren't around anymore...
Modern Fortran is a nice language for many scientific computing tasks. For me, I like Fortran because it's basically the easiest statically-typed compiled language (I rarely have to think about pointers, for instance), it's basically as fast as C, it has some good features for my variety of scientific computing (arrays in particular), and it has many compilers. Certainly, a better language could be designed without the legacy baggage and some features I'd like (better generics in particular), but I haven't seen anything better yet myself.
Now, legacy FORTRAN (note caps) is often a mess. It wasn't until the Fortran 90 standard that the capitalization changed, and the language changed a lot with that standard as well. I suspect the issues that you're seeing are more from many scientists not modernizing, and not from Fortran in itself.
As for money, well departments do have the budgets to hire developers. Science funding is in the high billions in most western countries. The problem is not departmental budgets, it's a social problem. Universities love the practice of spreading money amongst as many professors and tiny departments as possible in order to lay claim to every possible area of human knowledge/experience. Combine that with a culture of low standards and coverups and you've got a recipe for disasters (e.g. invariably critical bug fixes that corrupt data are described as not affecting the final results even when that clearly can't be true).
https://dev.lfortran.org/