Burn Baby, Burn!
-
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
-
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
Quote:
I somehow feel that something is wrong with the way we write software today
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something. The reason I chose a limited number of languages contrary to popular beliefs are: 1. Bring quality into the fold when learning. 2. Stop coders from getting jobs just because they can write a few lines of code in some lesser known language. 3. Standardization: this will make data transfers between apps faster. 4. Stop Big Companies especially Google from thinking they can ask consumers to upgrade their hardware specs when they make an update on their software. Sadly this scheme will never be implemented because most of the companies would lose monopoly over the products that require a specific tech stack. P.S. Slashes (/) represent exclusive OR not inclusive.
-
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
Quote:
3840 bytes of RAM 69120 byte ROM 85,000 CPU instructions executed per second.
Sound like basically a slow Arduino to me. We can do a lot on those, if you don't have to carry around file systems, threaded OSes, Grabage collectors or JIT compilers.
Quote:
The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today.
The web happened. The suddenly, everything got slower, less responsive, more crashy and most of all, more hungry for RAM, CPU and drive. Nobody makes native apps anymore, ever since google has convinced the world that native is irrelevant and web is the future. As a result the most professionally used chat app uses 1.5 GB of RAM because "native is bad, that's what they did in Windows time, lol". You think I may exaggerating? Check out the next post.
Quote:
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something.
1. Humans very rarely use assembly today, only in special cases and only in embedded. It's just too prone to errors and is completely unreadable and unmaintainable code. 2. C for apps? You must be a kernel developer. Maybe C++ but it's far from ideal, even though I love it for embedded. 3. This is where you piss me off. You claim the best managed languages out there with literally millions of apps (all Android and UWP apps are in Java and C#, respectively), aren't needed. 4,5,6,7. Then you spout a bunch of random web jargon words and claim these are way more important than kernel or app languages. 8. Only Tiobe and managers consider SQL a programming language. It's not the languages. It's people like you (I'm not trying to be disrespectful), who believe the world revolves around the browser instead of the people. People who don't value d
-
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
Also, most of my friends and colleagues insist that with anything less than 32 GB RAM, your computer will be slow as molasses. I open the Resource monitor and point at the bar showing that they currently, with lots of software running/waiting, 5 of 32 GB is in actual use, and most likely, 80% of even the "in use" part hasn't been addressed for at least half an hour. And I point to the CPU display: Half of the cores are not at all active, the rest are 1-5% loaded, except in very short bursts. When I generate a digital video, or convert from one format to another, I manage to load my 6 core (with HT, making them appear as 12) to 95-100% for minutes at a time, but that is the only group of tasks where I would not be well served by a CPU with 1/10 the processing capacity.
-
Also, most of my friends and colleagues insist that with anything less than 32 GB RAM, your computer will be slow as molasses. I open the Resource monitor and point at the bar showing that they currently, with lots of software running/waiting, 5 of 32 GB is in actual use, and most likely, 80% of even the "in use" part hasn't been addressed for at least half an hour. And I point to the CPU display: Half of the cores are not at all active, the rest are 1-5% loaded, except in very short bursts. When I generate a digital video, or convert from one format to another, I manage to load my 6 core (with HT, making them appear as 12) to 95-100% for minutes at a time, but that is the only group of tasks where I would not be well served by a CPU with 1/10 the processing capacity.
And I thought Android Studio was a beast, that isn't practical to run with less than 8GB of RAM and a good SSD.
-
Quote:
3840 bytes of RAM 69120 byte ROM 85,000 CPU instructions executed per second.
Sound like basically a slow Arduino to me. We can do a lot on those, if you don't have to carry around file systems, threaded OSes, Grabage collectors or JIT compilers.
Quote:
The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today.
The web happened. The suddenly, everything got slower, less responsive, more crashy and most of all, more hungry for RAM, CPU and drive. Nobody makes native apps anymore, ever since google has convinced the world that native is irrelevant and web is the future. As a result the most professionally used chat app uses 1.5 GB of RAM because "native is bad, that's what they did in Windows time, lol". You think I may exaggerating? Check out the next post.
Quote:
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something.
1. Humans very rarely use assembly today, only in special cases and only in embedded. It's just too prone to errors and is completely unreadable and unmaintainable code. 2. C for apps? You must be a kernel developer. Maybe C++ but it's far from ideal, even though I love it for embedded. 3. This is where you piss me off. You claim the best managed languages out there with literally millions of apps (all Android and UWP apps are in Java and C#, respectively), aren't needed. 4,5,6,7. Then you spout a bunch of random web jargon words and claim these are way more important than kernel or app languages. 8. Only Tiobe and managers consider SQL a programming language. It's not the languages. It's people like you (I'm not trying to be disrespectful), who believe the world revolves around the browser instead of the people. People who don't value d
Thanks, André; you said what I was thinking.
Software Zen:
delete this; -
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
I give someone 1 hour to do a 10 minute task, they will take 1 hour. This is something about how we fill out time, which also includes space. And NO does not apply to all people, but a large amount. computer resources, I think we find ways to fill it. More ram and cpu, ohh i can get a 4k monitor now. now make that 2x4k monitors, computer can handle it. OS loads a bunch of stuff. Lots of ram, ill leave 2gb of recently used files, where only maybe 400mb maybe used every 10min, the remaining just used the once in that last 3 hours. I find the same amazement with how much game devs got out of snes and other 90s games consoles. see Game Hut on youtube.
-
I give someone 1 hour to do a 10 minute task, they will take 1 hour. This is something about how we fill out time, which also includes space. And NO does not apply to all people, but a large amount. computer resources, I think we find ways to fill it. More ram and cpu, ohh i can get a 4k monitor now. now make that 2x4k monitors, computer can handle it. OS loads a bunch of stuff. Lots of ram, ill leave 2gb of recently used files, where only maybe 400mb maybe used every 10min, the remaining just used the once in that last 3 hours. I find the same amazement with how much game devs got out of snes and other 90s games consoles. see Game Hut on youtube.
maze3 wrote:
I give someone 1 hour to do a 10 minute task, they will take 1 hour.
If you're lucky. More likely, they'll spend that hour procrastinating, thinking "I've got plenty of time", and then ask for an extension on the deadline. :laugh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
-
Quote:
I somehow feel that something is wrong with the way we write software today
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something. The reason I chose a limited number of languages contrary to popular beliefs are: 1. Bring quality into the fold when learning. 2. Stop coders from getting jobs just because they can write a few lines of code in some lesser known language. 3. Standardization: this will make data transfers between apps faster. 4. Stop Big Companies especially Google from thinking they can ask consumers to upgrade their hardware specs when they make an update on their software. Sadly this scheme will never be implemented because most of the companies would lose monopoly over the products that require a specific tech stack. P.S. Slashes (/) represent exclusive OR not inclusive.
You only need one - machine language.
-
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code: "Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^]. "Touch me not" at Line 72: Noli me tangere[^] They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon. - 3840 bytes of RAM - 69120 byte ROM - 85,000 CPU instructions executed per second. I'm writing this post from my development workstation: - 34,359,738,368 bytes of RAM - Quad-core Xeon capable of performing over 3 billion operations per second. The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today. Best Wishes, -David Delaune
Randor wrote:
but I somehow feel that something is wrong with the way we write software today.
Programmers have gotten lazy. Once upon a time efficiency and accuracy were more important than time-to-market. The proliferation of programming tools and frameworks are to make the programmer's life easier and faster, but the developer is actually the least important stakeholder: making an application behave easily, predictably, accurately and efficiently for the END USER should be the primary goal!
-
Quote:
I somehow feel that something is wrong with the way we write software today
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something. The reason I chose a limited number of languages contrary to popular beliefs are: 1. Bring quality into the fold when learning. 2. Stop coders from getting jobs just because they can write a few lines of code in some lesser known language. 3. Standardization: this will make data transfers between apps faster. 4. Stop Big Companies especially Google from thinking they can ask consumers to upgrade their hardware specs when they make an update on their software. Sadly this scheme will never be implemented because most of the companies would lose monopoly over the products that require a specific tech stack. P.S. Slashes (/) represent exclusive OR not inclusive.
I agree with your assessments, with one or two exceptions. One would be to get rid of JavaScript altogether since using a back-end language such as C# on the front-end such as what is being done with Micrsoft's Blazer and its use of Web-Assembly makes more sense than having to rely on a broken-down scripting language such as JavaScript. I would also add VB.NET to this list. It is as fast as C#, since it compiles to the CLR just like its more popular sibling. Having Java, C#, and VB.NET as options will fit all the personalities that tend to code all forms of business applications. Back-end languages should be the same as the front-end as just noted since the use of a single language would substantially reduce defects all around as well as the time it takes to produce a quality product. I would also eliminate PHP and Node.js. PHP is in decline and cannot be used as a general purpose language forcing a developer to know an additional language for other work. Node.js is JavaScript and such frameworks are more problems than they are worth. During the mainframe days we all used a limited but similar tool-set no matter where we worked. This allowed us to always concentrate on application development design and their requirements. Today, everyone is concentrating on tools and so the entire business end of the profession has become a complete mess with everyone creating their own tools and frameworks as the #MeToo meme has taken substantial hold in the field. Finally, I would suggest a movement to return to the development of client\server applications. They are far more efficient to develop for small and medium sized applications that will have limited use. Web development is not need for many applications today and comes with a substantial amount of complexity that increase costs of development and maintenance substantially. Though more difficult in Java, the Microsoft .NET environments are perfect platforms for such development and there are several options to create the necessary tiers for such development; Windows Communication Foundation (WCF), Service-Stack, and ZeroC's magnus opus, ICE. Less, in our work, always means more. However, you are correct to assume that such suggestions will never win out among the technical masses since so many have personal investments in the way the profession has become structured in the past 10 years or so...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@ix.outlook.com
-
Quote:
I somehow feel that something is wrong with the way we write software today
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something. The reason I chose a limited number of languages contrary to popular beliefs are: 1. Bring quality into the fold when learning. 2. Stop coders from getting jobs just because they can write a few lines of code in some lesser known language. 3. Standardization: this will make data transfers between apps faster. 4. Stop Big Companies especially Google from thinking they can ask consumers to upgrade their hardware specs when they make an update on their software. Sadly this scheme will never be implemented because most of the companies would lose monopoly over the products that require a specific tech stack. P.S. Slashes (/) represent exclusive OR not inclusive.
I like your general point. Personally, I would replace #4 with CSHTML5 (uses XAML and C#) for web development. While it still generates HTML/CSS/JavaScript as an output, the developer only needs to deal with XAML and C#. But, that is a subjective, personal preference to stay out of the HTML/CSS/JavaScript swamp as much as possible. :) I would use C# for #6, but then, I do prefer the ASP.NET/MVC route. Again, a subjective view.
-
I like your general point. Personally, I would replace #4 with CSHTML5 (uses XAML and C#) for web development. While it still generates HTML/CSS/JavaScript as an output, the developer only needs to deal with XAML and C#. But, that is a subjective, personal preference to stay out of the HTML/CSS/JavaScript swamp as much as possible. :) I would use C# for #6, but then, I do prefer the ASP.NET/MVC route. Again, a subjective view.
MSBassSinger wrote:
CSHTML (uses XAML and C#)
CSHTML uses HTML and Razor, not XAML. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Also, most of my friends and colleagues insist that with anything less than 32 GB RAM, your computer will be slow as molasses. I open the Resource monitor and point at the bar showing that they currently, with lots of software running/waiting, 5 of 32 GB is in actual use, and most likely, 80% of even the "in use" part hasn't been addressed for at least half an hour. And I point to the CPU display: Half of the cores are not at all active, the rest are 1-5% loaded, except in very short bursts. When I generate a digital video, or convert from one format to another, I manage to load my 6 core (with HT, making them appear as 12) to 95-100% for minutes at a time, but that is the only group of tasks where I would not be well served by a CPU with 1/10 the processing capacity.
I developed an app once that had to discover and communicate with potentially thousands of computers concurrently. I used the .NET Task Library for the parallel processing of the TCP connections to those computers. With networks of 5,000 computers, it ate up a lot of processor time with the concurrent communication. Aside from that, my observations are similar to yours - a lot of RAM and cores go unused, except for me when developing and testing cross-platform apps. Emulators can eat up a fair amount of RAM and processor time.
-
I agree with your assessments, with one or two exceptions. One would be to get rid of JavaScript altogether since using a back-end language such as C# on the front-end such as what is being done with Micrsoft's Blazer and its use of Web-Assembly makes more sense than having to rely on a broken-down scripting language such as JavaScript. I would also add VB.NET to this list. It is as fast as C#, since it compiles to the CLR just like its more popular sibling. Having Java, C#, and VB.NET as options will fit all the personalities that tend to code all forms of business applications. Back-end languages should be the same as the front-end as just noted since the use of a single language would substantially reduce defects all around as well as the time it takes to produce a quality product. I would also eliminate PHP and Node.js. PHP is in decline and cannot be used as a general purpose language forcing a developer to know an additional language for other work. Node.js is JavaScript and such frameworks are more problems than they are worth. During the mainframe days we all used a limited but similar tool-set no matter where we worked. This allowed us to always concentrate on application development design and their requirements. Today, everyone is concentrating on tools and so the entire business end of the profession has become a complete mess with everyone creating their own tools and frameworks as the #MeToo meme has taken substantial hold in the field. Finally, I would suggest a movement to return to the development of client\server applications. They are far more efficient to develop for small and medium sized applications that will have limited use. Web development is not need for many applications today and comes with a substantial amount of complexity that increase costs of development and maintenance substantially. Though more difficult in Java, the Microsoft .NET environments are perfect platforms for such development and there are several options to create the necessary tiers for such development; Windows Communication Foundation (WCF), Service-Stack, and ZeroC's magnus opus, ICE. Less, in our work, always means more. However, you are correct to assume that such suggestions will never win out among the technical masses since so many have personal investments in the way the profession has become structured in the past 10 years or so...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@ix.outlook.com
Quote:
One would be to get rid of JavaScript altogether
I agree on that point, but I added it for two reasons 1. I've been told that I have some personality differences with JavaScript. & 2. Weather anyone (including me) likes to admit or not, JavaScript has over the years become the mainstream language on almost every platform for almost everyone. So I just included it in secret hopes of someone saying exactly that.
Quote:
I would also add VB.NET to this list
I considered it and then excluded it in favor of C# due to lack of existing developer-base (the same reason I included JavaScript). Also I have never written a line in VB.Net, C# on the other hand I've used many times for smaller problems and school problems, while professionally I've stuck with Java. Yeah I'm not as old as you. Mainframes? I some times wish I could see one in person.
Quote:
PHP is in decline and cannot be used as a general purpose language
True but just as my earlier points it is widely used and understood. Agree with all of your other points wholeheartedly.
-
Quote:
3840 bytes of RAM 69120 byte ROM 85,000 CPU instructions executed per second.
Sound like basically a slow Arduino to me. We can do a lot on those, if you don't have to carry around file systems, threaded OSes, Grabage collectors or JIT compilers.
Quote:
The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today.
The web happened. The suddenly, everything got slower, less responsive, more crashy and most of all, more hungry for RAM, CPU and drive. Nobody makes native apps anymore, ever since google has convinced the world that native is irrelevant and web is the future. As a result the most professionally used chat app uses 1.5 GB of RAM because "native is bad, that's what they did in Windows time, lol". You think I may exaggerating? Check out the next post.
Quote:
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something.
1. Humans very rarely use assembly today, only in special cases and only in embedded. It's just too prone to errors and is completely unreadable and unmaintainable code. 2. C for apps? You must be a kernel developer. Maybe C++ but it's far from ideal, even though I love it for embedded. 3. This is where you piss me off. You claim the best managed languages out there with literally millions of apps (all Android and UWP apps are in Java and C#, respectively), aren't needed. 4,5,6,7. Then you spout a bunch of random web jargon words and claim these are way more important than kernel or app languages. 8. Only Tiobe and managers consider SQL a programming language. It's not the languages. It's people like you (I'm not trying to be disrespectful), who believe the world revolves around the browser instead of the people. People who don't value d
André Pereira wrote:
assembly...completely unreadable and unmaintainable code.
To those that are unfamiliar with the language, not unlike any other language. Well written assembly, along with good comments are important, as is the necessary hardware specific knowledge of the person looking at the code.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
Randor wrote:
but I somehow feel that something is wrong with the way we write software today.
Programmers have gotten lazy. Once upon a time efficiency and accuracy were more important than time-to-market. The proliferation of programming tools and frameworks are to make the programmer's life easier and faster, but the developer is actually the least important stakeholder: making an application behave easily, predictably, accurately and efficiently for the END USER should be the primary goal!
Another trend I have noticed when comparing new versus established languages is the complaint that the established language 'is boring'.
-
MSBassSinger wrote:
CSHTML (uses XAML and C#)
CSHTML uses HTML and Razor, not XAML. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Quote:
3840 bytes of RAM 69120 byte ROM 85,000 CPU instructions executed per second.
Sound like basically a slow Arduino to me. We can do a lot on those, if you don't have to carry around file systems, threaded OSes, Grabage collectors or JIT compilers.
Quote:
The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today.
The web happened. The suddenly, everything got slower, less responsive, more crashy and most of all, more hungry for RAM, CPU and drive. Nobody makes native apps anymore, ever since google has convinced the world that native is irrelevant and web is the future. As a result the most professionally used chat app uses 1.5 GB of RAM because "native is bad, that's what they did in Windows time, lol". You think I may exaggerating? Check out the next post.
Quote:
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc. IMHO there should only ever be 8 languages: 1. Assembly. 2. C/(maybe)C++ One that you can use to build apps. 3. One from either (Java/C#). This one may or may not be needed much. 4. One language to design webpages HTML/HTML5/CSS. 5. Front End scripting language (JavaScript/TypeScript) 6. Backend Language (PHP/Node.JS/Python). 7. Database Querying language SQL. 8. Maybe I'm missing something.
1. Humans very rarely use assembly today, only in special cases and only in embedded. It's just too prone to errors and is completely unreadable and unmaintainable code. 2. C for apps? You must be a kernel developer. Maybe C++ but it's far from ideal, even though I love it for embedded. 3. This is where you piss me off. You claim the best managed languages out there with literally millions of apps (all Android and UWP apps are in Java and C#, respectively), aren't needed. 4,5,6,7. Then you spout a bunch of random web jargon words and claim these are way more important than kernel or app languages. 8. Only Tiobe and managers consider SQL a programming language. It's not the languages. It's people like you (I'm not trying to be disrespectful), who believe the world revolves around the browser instead of the people. People who don't value d
Quote:
This is where you piss me off. You claim the best managed languages out there with literally millions of apps (all Android and UWP apps are in Java and C#, respectively), aren't needed.
I just considered Java/C#/VB and other with C++ and thought they all can be eventually replaced with C++. And why not, its not like you can't have C++ libraries. From what I understand the reason Python has become so powerful and is currently being accepted so actively nowadays is because it uses native C++ written libraries.
Quote:
4,5,6,7. Then you spout a bunch of random web jargon words and claim these are way more important than kernel or app languages.
I didn't actually, but I can see why you thought that. I took into account the user-base of different languages and presented a list. I also took into account the general like and dislike towards these languages; the reason I said Java/C# may or may not be excluded. I am a Java developer and last thing I want is to kill Java, cause otherwise I'd need to learn either C# or C++ since other languages drive me nuts. While making the list I realized that there are just too many languages out there that I haven't personally used, so I kept my list to the most used/popular ones. Also I decided to include different sets of languages for front-end and back-end development, since most of the devs I know are happier and prefer it this way. My humblest apologies if you thought I am a non-native advocate. I am in fact the exact opposite. So in the end I came up with a simple list that describes the different levels at which these languages may be needed. The same reason I left out 8.
Quote:
8. Only Tiobe and managers consider SQL a programming language.
I have no idea what Tiobe means; but I get your gist, in my defense I only reluctantly added it knowing full well it is not a language but it still requires a different set of developers. P.S. SQL point was actually 7th.
