A Quadrillion Mainframes on Your Lap
spectrum.ieee.org
spectrum.ieee.org
This sentiment seems very much like an Eternal September reference. I think widely available is great and the use cases should naturally dilute in terms of importance. It would be weird if people today only bought computers when trying to solve problems of the Apollo scale. I like that many users are effectively using technology as a toy, it’s become so much more that many back then would have imagined. Of course, some bad with the good but a net gain IMO.
We aren't solving the same problems our forebears did. People weren't designing native apps with pencil and paper when somebody figured out how to bundle up the Chromium Embedded Framework, but they were burning tons of time duplicating effort on multiple native apps because OS platform vendors are manically determined to lock us in and stop us from writing portable code.
You might begrudge the resources used at scale, but if these programs weren't built in the first place it would be net negative. I also don't see Slack coded in GTK for instance, if it wasn't electron it would have been some Java framework, and I'm not sure it would have been better.
Comparing VSCode with Eclipse (which was optimized compared to other frameworks....), I'm pretty happy with VSCode and think we came a long way.
Java Swing is much more responsive and light when compared to Electron. Java is no longer heavy since the first Core series processors of Intel, and it's visibly optimized to be lighter and faster every release.
> Comparing VSCode with Eclipse (which was optimized compared to other frameworks....), I'm pretty happy with VSCode and think we came a long way.
Eclipse of today can run circles around both the Eclipse of yesteryear and VScode in terms of performance, resource utilization and capabilities.
I'm using Eclipse for 20 years (and still using it), and just because it's old enough to get a driver's license, it doesn't mean it's obsolete or featureless.
I don't think so. Different programs might have been built in a more efficient framework instead.
I remember a very similar complaint being made about Eclipse, Java, and Swing as you make about Electron, JS, and Node as a cancer on the desktop.
An alternative history where Java would have been huge on the desktop doesn't look to me like we'd have a heaven of well-though lightweight apps TBH.
I personnally think npm is something inevitable, and am not sure Maven for instance is fundamentally better in the grand scheme of things (I'd argue as a dev it's way more of a PITA without any specific upside, but it might be my own incompetence).
The only critic I ever faced with this was that it was not classical nor "the proper way", but the fact it loaded instantly and worked exactly the same way albeit infinitely faster managed to convince we may not need all that jazz.
You always have a choice but you'll face more resistance and worry not to go with everyone else towards suicide by a thousand dependencies.
A bit of inefficiency is alright, but things get ridiculous if modern web pages actually run less smooth than programs 40 years ago despite having quadrillion times the computing power available - because this power is wasted to write objects to JSON half a dozen times or simulate a network architecture between a virtual server and a virtual client which actually reside on the same machine - all because that's the only architecture modern web developers seem to understand.
Typescript + Next.js + Electron would be much, much faster for me to develop for than GTK + C, and even than Python + PyQT.
I wish there existed a modern cross-platform open source reactive GUI framework which was less of a resource hog than Electron, that would be great! Qt specifically is not much more economical, though the redistributable is smaller. Java is also rather nice for cross-platform GUIs, and also rather a hog.
Sadly, Electron is not so outstanding wrt resource consumption :-/
Flutter (Desktop) comes pretty close to that. Its really fast to write and your code works on IOS/Android/MacOS/Windows/Linux unless you need Platform specific API's, and even that is possible.
in the case of Electron, probably. it is comparatively difficult to release a cross platform graphical application in any other way.
in the case of other "high level" languages like Python, almost certainly not.
I remember reading something on Dropbox' engineer or developer blog about their conversion from Python 2 to Python 3 and how well it went for their desktop client, which had over one million lines of code and I had to stop and reread that a few times to make sure I read correctly.
How "high level" is Python if this many lines of code are required to create the Dropbox client? maybe Python is the epitome of a high level language, I don't know, but if it is, I don't see how one million lines of Python saves anyone any time over something low level like C or even Assembly, really. the promised tradeoff of execution speed for programmer productivity isn't there, at all, and almost no one sees it.
even if the majority of those lines of code are in libraries, why do those libraries have so many lines of code? what can they possibly be doing to need that many lines of code? it really does boggle my mind.
entire operating systems require fewer lines of code than the Dropbox client, and are written in languages that are supposedly much less expressive per line of code. so where is this supposed developer productivity when it takes over one million lines of code to write the Dropbox client?
I'm not trying to pick on Python, specifically, mind you; this is just an example I was thinking about recently. I'm quite sure that there are other tradeoffs also not delivering what they promised at all in all other languages, and I'm 110% certain no one is noticing those, either.
Unless you've spent lots of time (half a decade or more) at each layer of "full stack", it is really hard to comprehend just how mind-bogglingly fractal systems requirements get the more users you expose them to. Anytime you go b2c, or even b2b with a large enough user base, be prepared to say, "huh, I didn't see that coming" once a week or more frequently.
There are entire problem domains that lay submerged until you reach certain scales. Some code bases reflect the encapsulation of those submarine domains; some don't, most assuredly, but until the software becomes unused, at my clients I never ask the question the way you ask. Instead, I ask them to walk me through the code at successively finer-grained conceptual blocks until I reach the level where I can start attacking the problem I've been brought in to help address.
wxWidgets has been enabling cross-platform native graphics since the 1990s. Though the overall development experience is rather MFC-like, and not to many people's taste.
I do somehow agree with you, but going from Assembly to C was a huge step, from C to Java/C# a huge step due to GC and better typing.
Python indeed does not feel much higher level to me than e.g. C#, the only reason I've ever really seen why people save lines of code is the lack of braces, which doesn't really matter IMO, and because there are so many libraries. A big reason why there are so many libraries? I guess because people think it's easy, nothing innate in the language, certainly not that it's easy to package stuff.
Do you have some baseline to which we can compare? How many lines "should" it take?
I ran `git clone` on the repos of both rsync[0] and the official Dropbox SDK for Python[1]. I then ran sloccount on both of them.
---
rsync came in at a total of 51,410 physical source lines of code.
The Dropbox SDK came in at a total of 74,140 physical source lines of code.
---
(This data generated using David A. Wheeler's 'SLOCCount'.)
By no means do I wish to awaken the ghost of that infamous HN comment on how easy/why someone else had not done those bells and whistles before.
For instance when comparing VSCode to Visual Studio or Xcode, VSCode isn't universally slower, far from it. VSCode is much faster from start to first keystroke than both VS or Xcode. In other areas it's not so clear, some actions are slower in VSCode, some are faster (and before "but VSCode is a text editor, not an IDE", with the right plugins VSCode is as much an IDE as it needs to be).
So if even the Visual Studio or Xcode teams at Microsoft and Apple can't create applications that are universally better than an Electron application, why should 3rd party developers care about creating "native" applications?
The Windows and macOS platform teams don't seem to have quite understood yet that they are in competition with Electron, and in order to compete, they have to make it easier to create cross-platform applications than what Electron provides. Nobody will choose native macOS or Windows APIs just because they provide a "native look and feel" (which neither Microsoft nor Apple care about all that much in their own applications either).
I suspect that the applications that use up a core when idle would do this also if Electron is not used (e.g. it's a property of the development team, not of the framework).
Sorry, but that’s both flat out not true, and a fundamental misunderstanding of what the role of a platform vendor is.
If Apple wanted to ban non-native apps on iOS it’s hard to see what would stop them. They’re clearly fine with them. Microsoft has even embraced cross platform development wholeheartedly with many Electron apps, and more to come. They’re even plumbing the chrome engine into Windows to make sharing it more efficient.
The role of a platform vendor though is to make the best platform for native development they can. Portability to other platforms, with a few exceptions such as POSIX, just isn’t their problem. There’s no particular reason it should be. It would just stifle innovation and lead to boring me-too systems that are stuck in the past. That’s simply not in the interests of users or vendors.
Even electron apps aren't new, we already had that disease once with Active Desktop and packaged web sites.
There is some hope that like 20 years ago eventually the bubble will burst.
This is a worthy end goal.
Naturally, I fired up [Microsoft] Calculator, and arrived at something like 4kb. Later, I had to force quit a stalled process and opened Task Manager, to find that I had forgot to close Calculator.
There it was, idling at 20mb. Initially, I thought perhaps it was slowly leaking memory, so I restarted it. Just the same.
Now, I can already anticipate someone motivating why a calculator needs to exceed the computing power of calculating ~5000 space programs. To that I say, Windows 95 runs at 4mb of memory. Microsoft Calculator is not more complex than Windows 95. At least, I deeply hope that it isn't.
Resolution does nasty things to memory.
As does having every memory allocation be 64bits wide (instead of 8 or 16).
Though I agree with your sentiment.
I agree though that framebuffers put a hard lower limit onto how much RAM you have to use if you want to write a graphical application or even entire OS that saves resources.
The display is a refrigerator-sized unit with a big circular CRT in the middle. You give it vectors and characters, and it draws them with 1024x1024 resolution. It also had a light pen that you could use for interaction with the display.
Joining displays together, scaling modes, pixel, line and text drawing and conditional subroutines, and all in 30 ish pages.
When did any PC display get hardware line drawing? It would be fun to implement Logo that interacted with the light pen for creating generative L-systems.
*edit I found a video linked by Don Hopkins of Conway's Game of Life running on a 340 display https://www.youtube.com/watch?v=hB78NXH77s4
Indeed! Apple decides the amount of RAM they put in iPhones not based on projected application RAM usage, but on camera pixel count and display resolution.
https://www.macrumors.com/2021/09/15/how-much-ram-in-iphone-...
Its not that the core program has increased in size or has lost performance, but that the code required to build a good program based on that core has increased exponentially.
Also, as a developer, I usually don't care much about memory until I complete the program, check if its consuming abnormally high memory and then sit about to optimize. So, the developer for calculator.exe saw that the program consumes about 0.125% of commonly available memory size (16 GB), and probably concluded that its good enough for a program that is opened and closed, maybe 10 times a day.
Its the same with processing power. Unless you are writing highly resource hungry systems, losing a few thousand cycles here and there are not an issue.
Compounding this problem is the depth of the tech stack and the typical number of stacks used for an application have increased tremendously.
My second PC was a 80486/25MHz with 4Mb of RAM - four 1MB DIMMs. I skipped 80386!
Anyway, that box ran Win 95 eventually after DOS 6 and Win 3.1, then 3.11 W4WG. I also tried out OS/2 on it - 24 1.44Mb floppies I think. It had a new MB with a DX2/66 and loads of RAM (32Mb) later on and ran Win98.
I grew up shortly after that and Linux is my weapon errr OS of choice. Looks quite cool these days and I get less problems with Teams than my MS sporting colleagues. When I need to get something installed I ask pacman or yay to install it and then crack on, whilst my colleagues play with Google and dodgy downloads.
Anyway, on Win9x, calc ran quite happily on a box with 4Mb RAM. Word 2.0 worked too ...
You probably used more paper in your lifetime of printing and book reading and newspaper buying and phonebook and bank statement receiving than Euclid, Pythagoras, Archimedes, Euler, Gauss and Newton combined, is that a problem worth solving?
[1] first price for memory I found on Crucial.com was 8GB for $67.99. Other prices are available.
On my laptop, 114MB of 8GB. 1.3%.
I even used Windows Calculator to work out these percentages because the effort to make the "calculator" button on the keyboard load another calculator, and find another one to load, and learn to use it, to save 19MB of RAM for a few seconds is not worth it.
The ROM on the device was just a series of magnets and wires. Magnetic core memory without the extra wires to write the values. Instead the values were 'written' by having someone thread the wires through the right magnets. Thousands of times. It was a very surreal "wait, that's how they did that? ...well of course, how else would they do that?" moment.
Timestamp 2:55 https://www.youtube.com/watch?v=9IPP39OF78M
IIRC, Windows 3.0 didn't run happily in any circumstances, that had to wait for 3.1.
"I can tell you're not working. What on earth are you doing?"
"Calculating how far back in time I would have to go until my PC was the fastest computer on Earth. 1992 is the answer. It would be faster than DARPA's $90m supercomputer that filled a warehouse. If I go back to 1984 my PC is actually faster than every computing device on Earth, combined."
"I'm sorry I asked."
The machine language and corresponding assembly code is still recognizable by today's standards. It looks pretty similar to the Z-80, 6502 and 8086 assembly that I learned back in the day.
But overall I agree with you that the assembly code is fairly similar as far as the basic structure. Some of the early computers have pretty strange assembly code that requires a big mental shift. For example the Honeywell 1800 with two program counters that can go forward or backward, or the IBM 1401 with its word marks and arbitrary-length words.
For a lot of old IBM 7090 manuals, see: http://bitsavers.org/pdf/ibm/7090
Wow! What is the point of that? How is it used?
Maybe it's because it's from a typewriter, rather than a typeset manual. Maybe it's because things are in octal, instead of in assembly opcodes.
Sorry - I'm picking nits. But consider how many sites have examples of shell commands where the apostrophes and backticks are converted to something else, to where two dashes are converted to an emdash, and all I can think is how completely disconnected writers are from what appears on web sites.
Apologies for the tangent.
(Source: I used to work at the magazine and am painfully aware of previous such mistakes.)
With Bitcoin we are literally using this power to prove to each other we burned some megajoules which we could otherwise use to power some physical stuff.
The difference made so far: it is easier to pay for drugs in order to evade stupid anti-drug laws.
Aside from the fact that your comment is completely OT, what could possibly motivate you, at every tiny opportunity to do so, to spew so much negativity on a topic that - in all likelihood - has exactly zero impact on your life?
As much as I try to imagine another scenario, I find myself forced to cycle back to a nocoiner type explanation, which if correct, would be very sad indeed.
I think that’s why people are so amped about the M1 (and getting Linux into it)
And the form factor. It’s hard to do any serious work on a phone.
With the power of a modern phone, all you really need is a monitor with a USB hub to turn it into a fully fledged PC. Sure, you won't be doing too much in the way of debugging code or editing video, but for most people it should be enough. It's not like the 4K screen on your phone has that fewer pixels than the 4K monitor you hook it up to.
From what I can tell, you can run a usable desktop environment if you plug in a modern high-end Android device to a suitable monitor. Good enough for browsing the web, editing basic spreadsheets and doing homework, anyway.
IMO this could be the ultimate tool for companies with loads of employees that don't do too complex work and get fancy company phones already. Even if you don't use the power of the phone directly, you could use a thin client app to save costs there. I think eventually someone will be able to make a business case out of it, but so far all attempts have failed.
Sadly, my phone doesn't do DisplayPort out, so when I tested a standard laptop dock all it did was add a mouse cursor and a notification about the physical keyboard to my phone. I bought a midrange phone, though so that's kind of to be expected.
Most people today don't have the computing tools that you do. Yes, a consumer laptop running Numpy can process it quickly. But they have Excel, not Numpy...and Excel cannot process millions of rows. So in the context of the tools they have, it is a large table.
Anything that fits in ram, at least in the context of "a table" in a RDBM probably counts as 'micro data'...
I don’t know about “big” or “small”, but the threshold for “done properly” has to be really low for that to become a bottleneck.
Either you don't care about that query's runtime (a perfectly valid approach if your use case is "this creates a report after COB on Friday that needs to have completed before 9am Monday morning"), or you need someone who knows what they're doing take over from you (also a valid approach if this is in your tech demo or POC, and you're the Technical Founder who's now out of their depth and needs a proper engineer to build a scalable product for you).
So Big Data services could be just as useful to a small company with a mere 100GB of data once they learn how to squeeze the juice from the berries they've collected.
CPU time is essentially free now. When you price e.g. cloud instances you can nearly ignore everything except RAM and non-volatile storage. If you want more than 16GB of ram you need to go for the "mobile workstation" class devices.
CPU > Ram > Network > Disk(even the fastest).
That’s at least the most difference compared to a normal server or even a desktop. The markup on CPU cores in the cloud is insane.
Missed the colloquium two years later where the talk afterward was: Everyone will have a VAX on their desk.
(For 2nd year, we got a room full of Mac 512ks...)
First UNIX was Xenix on a PC tower that the teacher would carry around for the OS classes, where we would take turns after preparing the class material on a MS-DOS PC.
Later when I got to university they were on DG/UX with the same tyranny of a central server to telnet into.
\s
It's hard to say if the success of "mainframe" before has become the reason why IBM has been falling behind in the cloud competition.
Move forward a few years and he got himself a C64. Now we can do something with a computer!
The C64 is the most important change in history, it will be celebrated as long as we still can afford 15W.
3 billion instructions per second is an IPC less than 1. You can often expect IPCs closer to 2 even on older Skylake derived cores, so just shy of 10 billion instructions per second. Very modern top end cores do even better.
Not exactly the same position, but very similar in the ecosystem. Both of them will be blamed when the system is not available.