Do we really want the likes of Google and Facebook to be curators of information? They are like the phone system - the phone company does not prevent people from making false statements on the phone. If we expect Google and Facebook to do that, we give them the power to tell us what is true and what is not - and we relinquish our individual ability to decide for ourselves. Better that we have deep distrust for Google and Facebook.
Interesting. Thanks for helping me to understand this.
Ironically, in the server app space, there is a trend away from monolithic applications, toward microservices. One could draw an analogy between shared libraries and microservices - dynamically loaded independent components. While this is seen as a critical next step for scalable and flexible server apps, somehow in the desktop app space it is not.
I recall the first version of MS Word for the Mac. It had rotatable fonts - it had a-lot of functionality - it had everything that I personally use today when I use MS Word. Macs back then had something like 100K - I don't remember exactly, but it was Kb - not Mb. Today, MS Word is inching its way toward the Gb range, and I don't see the kind of functionality difference that would explain that.
To really find out what is going on, one would have to decompile these apps and analyze them. I don't have time or the setup to do that (I don't build native desktop apps - I am a server person). However, I _suspect_ (don't actually know) is that it is due to the large libraries that get linked with apps.
I wish that more people would speak up about this, and not just accept it. Something _is_ wrong, but if people don't say anything, nothing will change. I believe that we _could_ have instantaneous apps, but no one is asking for it.
I will never forget Bill Gates' comment, back in the '80s, that no one would ever, ever need more than 640k in their computer - that to use that much memory was inconceivable. And by that time, we had a-lot of pretty powerful apps. They were written in C, however, and C linkers strip out unused functions.
In the late '90s there were video players that ran in 40k memory. Today's software is bloated for some reason, and so it takes forever to load. I am not sure why, but I suspect the problem has to do with static linking of large libraries, for which an app uses one or two functions, but has to link with the whole library, which in turn includes ten other libraries, which each carry ten more. What are your thoughts on why software today is so large?
I am still skeptical that it requires hundreds of Mb. I remember when I was in college, my university had a new IBM 370 running MVS - it could (did) run multiple versions of OS370, supporting many large applications and lots of users. It had 4Mb of RAM. Boeing used to use an IBM 360 with 2Mb to run CADAM - a graphic design package - with hundreds of simultaneous users. I also recall back in 1998 running Netscape, a command window, a Java app, an editor, Personal Oracle, and about three or four other things at the same time on my 16Mb Winbook. When I see that MS Word today requires 200Mb to run, something tells me that there is something wrong in how software is built today.
Another data point: in 1994 I spent a time as a graphic designer (a career detour), and I had a large screen Mac and used Photoshop 3. It was a full fledged professional program - supported layers, masks - everything I needed to make professional quality things. I kept a copy of the program (both Windows and Mac). Years later - around 1999 I think - I had a Windows ME machine (yuck), and I think it must have had 100+ Mb of RAM, don't remember exactly. I also had Photoshop 7, and it took about 15 seconds to load, going through its splash screen, etc. Out of curiosity one day I popped in the disk for Photoshop 3 and copied the exe to my drive. I double-clicked on it, and BAM! - it was loaded and ready to go. It was essentially instantaneous - it had gone through the plugin loading and splash screen so fast that I couldn't even see it happen.
That's what I want for software. I would give up a-lot features to have instantaneous response. Maybe it's just me, though.
Notepad? That's amazing. Great tip. Won't work for me because I use a Mac, but good to know for when I am on Windows which I am sometimes.
Indeed, today's web pages won't run on Netscape 3, but that's because it doesn't support newer protocols, etc. - but it did essentially the same thing (Netscape invented SSL). I know it's not usable today, but I wish that it had been kept the same, but merely updated. It mystifies me that today's browers (all apps, actually), require hundreds of Mb to run and start up so slowly - something is wrong.
OMG I feel the same way. Javascript has destroyed the Web. If one wants to run an app in a page, it should run in a sandbox using a separate protocol - not be mashed together in the HTML. Single page web apps are not what I want - but there is no going back;-/
If one were to run Netscape 3 on today's laptop, it would load in a fraction of a second - and it did essentially the same thing. I would gladly give back whatever extra functionality we are getting for a sub-second application load - and that applies to every application, not just a browser.
I am just imagining being in a hyperloop, going 600mph, when the ground up ahead suddenly shifts 20 feet to the right, tearing the hyperloop tube and shifting half of it 20 feet, and leaving a wall of rock in its place for me to collide with at 600mph. Perhaps that is unlikely to happen, but the possibility is disconcerting because of the inescapable death of everyone on the hyperloop - entombed in a tube deep underground. In contrast, a train would derail, and some people would die, but there would be a chance... Similarly, if an airplane malfunctions, the pilot has a chance of landing it. I am not sure I would board a hyperloop, but that might not be logical.
The main reason that I stick with Firefox is the NoScript extension. If that stops being available for Firefox, I will stop using Firefox.
Javascript is the vector for 99% of the attacks on the Internet. There is no substitute for an extension that shows you what scripts a page wants to run and allows you to selective enable those sources - either temporarily or permanently.
The problem indeed, is half cultural; as I wrote in my book High Assurance Design,
The average programmer is woefully untrained in basic principles related to reliability and security.
The tools available to programmers are woefully inadequate to expect that the average programmer can produce reliable and secure applications.
Organizations that procure applications are woefully unaware of this state of affairs, and take far too much for granted with regard to security and reliability.
At this point, I think that the only way to change the culture on this issue is to make software writers partly or fully liable for the security breaches that result from vulnerabilities in the code. Nothing else will cause security to rise to the top of the priority list.
On the other hand, the problem is partly technical: the procedural Von Neuman programming paradigm leads to terrible design. Alternatives such as data flow, event-driven, and functional design are much more robust; but one needs to use languages that support those, and the popular languages are primarily procedural, so again, it comes down to culture.
Also, one should choose the right language for the task. The right language for a small office task is not usually the right language for a scalable microservice. E.g., Google discovered long ago that if an app written in Ruby or Python requires 100 servers to meet demand, but the same app written in C++ or Go requires only ten servers, then there is a substantial cost difference. (Although Go is quite terrible for maintainability - do a Google search for "Go gotchas".)
Ruby is fantastic for writing a-lot of code quickly. But it has terrible performance, and is has terrible maintainability characteristics (I recall doing global file system searches to find the file that defines something that my code requires, which is brought in by another require, and then another).
Performance sometimes matters. If one's app requires 20 VMs in Ruby, but only 2 VMs in Go or C++, then the cost difference can be substantial.
Also, Ruby - while 20 years old - is surprisingly immature. E.g., a few years back, I wrote a multi-threaded program in Ruby. It didn't work. After days of scratching my head, I discovered that while Ruby used native threads, it had a global interpreter lock, forcing the native threads to take turns. Maybe they have fixed this by now. My program needed true concurrency, so I had to re-write it using processes. Gosh - Java got threads working after the first two years.
Firms that really know how to maintain large codebases have also discovered that type-safe languages are very effective for maintainability. Check out this post: https://medium.freecodecamp.or... . I myself have experienced this: I once translated a fairly good sized codebase from Ruby to Java, and in the process discovered a large number of potential bugs - thanks to Java's type safety. I have found that when I refactor Java code, I introduce zero new bugs, but when changing Ruby code, the only thing that prevents new bugs is a large suite of unit tests. Thus, writing in Ruby _requires_ that one write comprehensive unit tests. I personally don't use TDD - I use ATDD, so my focus is on acceptance tests, not unit tests. Ruby _forces_ me to write unit tests. I don't want to be forced to work a certain way.
I am not bashing Ruby - I think it is great for some things - but people (like those at Google) have come to understand its shortcomings.
I know what theory means. You are the one wasting your own time, fella, by responding to something that you are clearly not interested in: if you are not interested in what I have to say, then perhaps you should keep your empty lowbrow thoughts to yourself and stop wasting your own time. It also amazes me how rude some people - like you - are in this forum. I really doubt that you would address me this way in person. Hidden behind a browser you are fearless. In person, I doubt you would be so fearless - and I'd probably punch your teeth in. Moron.
What a nasty reply. I will respond anyway - perhaps others are interested in actually exchange ideas instead of insults.
Observations are facts - to the observer (not necessarily to others). However, theories are not facts. Gravity is a good example, because while we thought we understood gravity, it turns out that we don't - there are some predictions that general relativity makes are in conflict with quantum mechanics. So the theory of gravity is not a "fact" - it is just a theory.
That does not mean that theories don't have predictive value: of course they do; but there is always a margin of uncertainty - sometimes very tiny. No theory is absolute - no theory is a fact.
Science is about theories - not facts. If you "peel the onion" on most theories, you find out just how few "facts" there actually are! For an interesting read on this subject, check out the book "Doubt and Certainty", by Tony Rothman and George Sudarshan (the famous physicists).
The thing I like most about today's languages is type safety - because type safety enables me to refactor without worry - and without having to write lots of tests as a safety net - but not all "modern" languages have type safety. Also, about two years back, I had to write a program to parse the output of tcpdump. I thought about writing in ruby, but that would mean that I would have to install ruby on the vm where the code would be running, so I wrote it in C. It took me about an hour to code, and was about 150 lines. It worked _the_ _first_ _time_. The first time. And I had not written a C program in 15 years. So I am not so sure that "modern" languages are that much better.
I don't think that age is relevant. I am 61, and I am completely current in my field (containers, Kubernetes). A few years back I worked at a small company populated with "DevOps" folks - all younger than me - and I ended up leaving because they were not able to mentally shift from VMs to containers. Age is not the issue. Also, while most of "middle America" is not going to turn into programmers, some of the young people in middle America who are just starting out might pick an IT career if they think there is opportunity in it - but they won't if all the jobs are taken by H1B people.
Today's AI systems are not computer programs: they are neural networks. Many AI systems use computers to simulate neural networks, since neural network hardware is hard to come by, but the underlying model is not a von Neumann computing model - it is a neural network model.
A universal basic income would have to be at a subsistence level - so it is only relevant for young college students (no house, no kids) and those who are destitute. E.g., if an IT worker were out of work, a basic income would likely be too low to even make a dent in their expenses. If the basic income were at a higher (non-subsistence) level, then most people, if they actually did not have to work to live decently, would pursue activities that they enjoy but that have little economic value. It is an idyllic vision, but unfortunately is not practical - not unless we implement communist-like control of all infrastructure and manufacturing - but we saw how well that worked.
I don't claim to know the best solution for this. I was merely sharing my own experiences. Have you used the Outlook Web client? It is pretty effective, IME. I have used it quite a bit, but I am sure there are shortcomings that I have not come across. I also wonder (I don't know) if MS apps like Word can now be deployed in a private cloud. If so, perhaps that could be a solution.
Slashdot Mirror
Do we really want the likes of Google and Facebook to be curators of information? They are like the phone system - the phone company does not prevent people from making false statements on the phone. If we expect Google and Facebook to do that, we give them the power to tell us what is true and what is not - and we relinquish our individual ability to decide for ourselves. Better that we have deep distrust for Google and Facebook.
Interesting. Thanks for helping me to understand this.
Ironically, in the server app space, there is a trend away from monolithic applications, toward microservices. One could draw an analogy between shared libraries and microservices - dynamically loaded independent components. While this is seen as a critical next step for scalable and flexible server apps, somehow in the desktop app space it is not.
I think there is a more insidious explanation.
I recall the first version of MS Word for the Mac. It had rotatable fonts - it had a-lot of functionality - it had everything that I personally use today when I use MS Word. Macs back then had something like 100K - I don't remember exactly, but it was Kb - not Mb. Today, MS Word is inching its way toward the Gb range, and I don't see the kind of functionality difference that would explain that.
To really find out what is going on, one would have to decompile these apps and analyze them. I don't have time or the setup to do that (I don't build native desktop apps - I am a server person). However, I _suspect_ (don't actually know) is that it is due to the large libraries that get linked with apps.
I wish that more people would speak up about this, and not just accept it. Something _is_ wrong, but if people don't say anything, nothing will change. I believe that we _could_ have instantaneous apps, but no one is asking for it.
I will never forget Bill Gates' comment, back in the '80s, that no one would ever, ever need more than 640k in their computer - that to use that much memory was inconceivable. And by that time, we had a-lot of pretty powerful apps. They were written in C, however, and C linkers strip out unused functions.
In the late '90s there were video players that ran in 40k memory. Today's software is bloated for some reason, and so it takes forever to load. I am not sure why, but I suspect the problem has to do with static linking of large libraries, for which an app uses one or two functions, but has to link with the whole library, which in turn includes ten other libraries, which each carry ten more. What are your thoughts on why software today is so large?
Interesting. A-lot of history - thanks.
I am still skeptical that it requires hundreds of Mb. I remember when I was in college, my university had a new IBM 370 running MVS - it could (did) run multiple versions of OS370, supporting many large applications and lots of users. It had 4Mb of RAM. Boeing used to use an IBM 360 with 2Mb to run CADAM - a graphic design package - with hundreds of simultaneous users. I also recall back in 1998 running Netscape, a command window, a Java app, an editor, Personal Oracle, and about three or four other things at the same time on my 16Mb Winbook. When I see that MS Word today requires 200Mb to run, something tells me that there is something wrong in how software is built today.
Another data point: in 1994 I spent a time as a graphic designer (a career detour), and I had a large screen Mac and used Photoshop 3. It was a full fledged professional program - supported layers, masks - everything I needed to make professional quality things. I kept a copy of the program (both Windows and Mac). Years later - around 1999 I think - I had a Windows ME machine (yuck), and I think it must have had 100+ Mb of RAM, don't remember exactly. I also had Photoshop 7, and it took about 15 seconds to load, going through its splash screen, etc. Out of curiosity one day I popped in the disk for Photoshop 3 and copied the exe to my drive. I double-clicked on it, and BAM! - it was loaded and ready to go. It was essentially instantaneous - it had gone through the plugin loading and splash screen so fast that I couldn't even see it happen.
That's what I want for software. I would give up a-lot features to have instantaneous response. Maybe it's just me, though.
Notepad? That's amazing. Great tip. Won't work for me because I use a Mac, but good to know for when I am on Windows which I am sometimes.
Indeed, today's web pages won't run on Netscape 3, but that's because it doesn't support newer protocols, etc. - but it did essentially the same thing (Netscape invented SSL). I know it's not usable today, but I wish that it had been kept the same, but merely updated. It mystifies me that today's browers (all apps, actually), require hundreds of Mb to run and start up so slowly - something is wrong.
OMG I feel the same way. Javascript has destroyed the Web. If one wants to run an app in a page, it should run in a sandbox using a separate protocol - not be mashed together in the HTML. Single page web apps are not what I want - but there is no going back ;-/
If one were to run Netscape 3 on today's laptop, it would load in a fraction of a second - and it did essentially the same thing. I would gladly give back whatever extra functionality we are getting for a sub-second application load - and that applies to every application, not just a browser.
I am just imagining being in a hyperloop, going 600mph, when the ground up ahead suddenly shifts 20 feet to the right, tearing the hyperloop tube and shifting half of it 20 feet, and leaving a wall of rock in its place for me to collide with at 600mph. Perhaps that is unlikely to happen, but the possibility is disconcerting because of the inescapable death of everyone on the hyperloop - entombed in a tube deep underground. In contrast, a train would derail, and some people would die, but there would be a chance... Similarly, if an airplane malfunctions, the pilot has a chance of landing it. I am not sure I would board a hyperloop, but that might not be logical.
Yes, so what happens when the ground shifts, as in an earthquake?
If the ground shifts above ground, you get a derailment. If you are in a hyperloop, seems like it would be full-stop - 600 to 0 in a millisecond.
The main reason that I stick with Firefox is the NoScript extension. If that stops being available for Firefox, I will stop using Firefox.
Javascript is the vector for 99% of the attacks on the Internet. There is no substitute for an extension that shows you what scripts a page wants to run and allows you to selective enable those sources - either temporarily or permanently.
The problem indeed, is half cultural; as I wrote in my book High Assurance Design,
At this point, I think that the only way to change the culture on this issue is to make software writers partly or fully liable for the security breaches that result from vulnerabilities in the code. Nothing else will cause security to rise to the top of the priority list.
On the other hand, the problem is partly technical: the procedural Von Neuman programming paradigm leads to terrible design. Alternatives such as data flow, event-driven, and functional design are much more robust; but one needs to use languages that support those, and the popular languages are primarily procedural, so again, it comes down to culture.
"Popular" != "Best"
Also, one should choose the right language for the task. The right language for a small office task is not usually the right language for a scalable microservice. E.g., Google discovered long ago that if an app written in Ruby or Python requires 100 servers to meet demand, but the same app written in C++ or Go requires only ten servers, then there is a substantial cost difference. (Although Go is quite terrible for maintainability - do a Google search for "Go gotchas".)
Ignore popularity. Make your own choices.
https://www.khanacademy.org/
Ruby is fantastic for writing a-lot of code quickly. But it has terrible performance, and is has terrible maintainability characteristics (I recall doing global file system searches to find the file that defines something that my code requires, which is brought in by another require, and then another).
Performance sometimes matters. If one's app requires 20 VMs in Ruby, but only 2 VMs in Go or C++, then the cost difference can be substantial.
Also, Ruby - while 20 years old - is surprisingly immature. E.g., a few years back, I wrote a multi-threaded program in Ruby. It didn't work. After days of scratching my head, I discovered that while Ruby used native threads, it had a global interpreter lock, forcing the native threads to take turns. Maybe they have fixed this by now. My program needed true concurrency, so I had to re-write it using processes. Gosh - Java got threads working after the first two years.
Firms that really know how to maintain large codebases have also discovered that type-safe languages are very effective for maintainability. Check out this post: https://medium.freecodecamp.or... . I myself have experienced this: I once translated a fairly good sized codebase from Ruby to Java, and in the process discovered a large number of potential bugs - thanks to Java's type safety. I have found that when I refactor Java code, I introduce zero new bugs, but when changing Ruby code, the only thing that prevents new bugs is a large suite of unit tests. Thus, writing in Ruby _requires_ that one write comprehensive unit tests. I personally don't use TDD - I use ATDD, so my focus is on acceptance tests, not unit tests. Ruby _forces_ me to write unit tests. I don't want to be forced to work a certain way.
I am not bashing Ruby - I think it is great for some things - but people (like those at Google) have come to understand its shortcomings.
I know what theory means. You are the one wasting your own time, fella, by responding to something that you are clearly not interested in: if you are not interested in what I have to say, then perhaps you should keep your empty lowbrow thoughts to yourself and stop wasting your own time. It also amazes me how rude some people - like you - are in this forum. I really doubt that you would address me this way in person. Hidden behind a browser you are fearless. In person, I doubt you would be so fearless - and I'd probably punch your teeth in. Moron.
What a nasty reply. I will respond anyway - perhaps others are interested in actually exchange ideas instead of insults.
Observations are facts - to the observer (not necessarily to others). However, theories are not facts. Gravity is a good example, because while we thought we understood gravity, it turns out that we don't - there are some predictions that general relativity makes are in conflict with quantum mechanics. So the theory of gravity is not a "fact" - it is just a theory.
That does not mean that theories don't have predictive value: of course they do; but there is always a margin of uncertainty - sometimes very tiny. No theory is absolute - no theory is a fact.
Science is about theories - not facts. If you "peel the onion" on most theories, you find out just how few "facts" there actually are! For an interesting read on this subject, check out the book "Doubt and Certainty", by Tony Rothman and George Sudarshan (the famous physicists).
The thing I like most about today's languages is type safety - because type safety enables me to refactor without worry - and without having to write lots of tests as a safety net - but not all "modern" languages have type safety. Also, about two years back, I had to write a program to parse the output of tcpdump. I thought about writing in ruby, but that would mean that I would have to install ruby on the vm where the code would be running, so I wrote it in C. It took me about an hour to code, and was about 150 lines. It worked _the_ _first_ _time_. The first time. And I had not written a C program in 15 years. So I am not so sure that "modern" languages are that much better.
I don't think that age is relevant. I am 61, and I am completely current in my field (containers, Kubernetes). A few years back I worked at a small company populated with "DevOps" folks - all younger than me - and I ended up leaving because they were not able to mentally shift from VMs to containers. Age is not the issue. Also, while most of "middle America" is not going to turn into programmers, some of the young people in middle America who are just starting out might pick an IT career if they think there is opportunity in it - but they won't if all the jobs are taken by H1B people.
Article, "How it feels to learn JavaScript in 2016": https://hackernoon.com/how-it-...
Today's AI systems are not computer programs: they are neural networks. Many AI systems use computers to simulate neural networks, since neural network hardware is hard to come by, but the underlying model is not a von Neumann computing model - it is a neural network model.
A universal basic income would have to be at a subsistence level - so it is only relevant for young college students (no house, no kids) and those who are destitute. E.g., if an IT worker were out of work, a basic income would likely be too low to even make a dent in their expenses. If the basic income were at a higher (non-subsistence) level, then most people, if they actually did not have to work to live decently, would pursue activities that they enjoy but that have little economic value. It is an idyllic vision, but unfortunately is not practical - not unless we implement communist-like control of all infrastructure and manufacturing - but we saw how well that worked.
I don't claim to know the best solution for this. I was merely sharing my own experiences. Have you used the Outlook Web client? It is pretty effective, IME. I have used it quite a bit, but I am sure there are shortcomings that I have not come across. I also wonder (I don't know) if MS apps like Word can now be deployed in a private cloud. If so, perhaps that could be a solution.