What's a "real" programming language?
-
Quote:
As I recall, node.js is a google project, not a community project.
[Wikipedia article on Node.js](https://en.wikipedia.org/wiki/Node.js) "Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more. Node.js runs on the V8 JavaScript engine, and executes JavaScript code outside a web browser." Interestingly, Ryan Dahl, who created node.js, also created the TypeScript engine.
I realize it's open source as many google projects are, but I think google funds it and google staffers are primary contributors.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Quote:
As I recall, node.js is a google project, not a community project.
[Wikipedia article on Node.js](https://en.wikipedia.org/wiki/Node.js) "Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more. Node.js runs on the V8 JavaScript engine, and executes JavaScript code outside a web browser." Interestingly, Ryan Dahl, who created node.js, also created the TypeScript engine.
Digging further, it looks like I could be mistaken about Google's involvement. It looks like it gets a significant amount of it's support from the Linux Foundation, which also supports some other projects like zephyrproject that i use. OpenJS Foundation - Wikipedia[^] I'd say this counts as industry rather than community in any case, as LF is a major influencer in the direction of a lot of software technology these days.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Steve Naidamast wrote:
a crappy language if there ever was one
You need to get out more? There are a vast number of languages. Many of them very annoying. The 'standard' for SQL comes to mind. SQL, as per the standard, is not even Turing complete. But actual implementations are. The successful ones always have stuff bolted on. That is the nature of progress. But consider one of the odd ball ones that I was reminded of recently is 'Erlang'. Doesn't even rate a percentage in Tiobe index. Yet I just found out that someone decided to build another language (Elixir) on top of that one. And someone decided to build an entire business around the usage of that (which is why I even heard of it.)
I have done a ton of JavaScript in my very long career... I never liked it and never will... JavaScript was never designed for what it is being used for now. And the only reason people use it is because it is free and is part of the inherent infrastructure of web applications. This still doesn't mean that it is good language due to its popularity. And languages that continually have things "bolted" on them become bloated and sometimes even unusable. This pushes developers to find cleaner languages...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Quote:
I'm covering my bases, making sure I have a broad understanding of relevant technologies used in software these days
That is as good of a reason as any and makes good sense. I haven't had to learn JavaScript (to the depth of using it like you do when needed). So far, I have found plenty of work where C# (server app development, cloud development, web development with Blazor) is required, combined with experience in Azure native development. Converting JavaScript to C# (coding and architecture) is about as far as I have gone. If getting and keeping a job required me to learn JavaScript and using node.js, then I would do so. I have been fortunate so far. I know what the relevant technologies are, but I have been fortunate to be able to pick and choose which ones I work in. I applaud your flexibility with the projects you choose.
I probably won't end up taking a job doing web development as a primary thing, but I could see being drafted to develop a companion app to some embedded widget using Flutter or something. This not only keeps me in the loop, but it keeps me from getting rusty in general.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Bear with me, because as much as I am loath to holy roll about technology, I still have my peeves. I went about porting my DFA lexer engine from C# to TypeScript. It was primarily an exercise in teaching myself TypeScript, plus brushing up on my JS. So I implement the bones of it, and after adjusting my mental map to the JS way of doing things I got it mostly working. Then I went about trying to use a Map keyed by Sets. Turns out JS Map and Set will only compare by value for "scalar" types (presumably including strings) or otherwise it uses reference comparisons. You can't override your own equality mechanism either. how to customize object equality for javascript set - Stack Overflow[^] Consequently, there is no performant way to do subset construction to convert an NFA to a DFA in this language. I've seen others solve this problem by using string keys, but this falls down for machines of non-trivial size. Regex FA visualizer[^] is one example but I can basically crash it or stall it out for a long time at least with any non-trivial expression. This one also doesn't work properly besides, but I have no other link handy for you to try. This may be academic, but it is also basic computer science. A language should be able to allow you to implement computer sciencey algorithms and constructs - especially those that have been adapted to countless other programming languages. DFA by subset construction is basic. And you can't do it in JS. I can't even begin to imagine what LALR table generation would look like. You may be wondering why do I care? Because node.js. Because Angular Because React-Native it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be, if not Turing complete at least cover the fundamentals, or you're just spreading garbage around. Without a way to do custom comparisons at the very least on hashed containers, your language isn't going to be able to do a lot of things other high level languages can accomplish handily. Is it even a "real" language? Is it ready for primetime, or is it just being adopted because we can? :~
honey the codewitch wrote:
it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be
That is only people carrying around their golden hammer. It's nothing to do with it being "good" or "suited" and they do not care. It's being what web people know and by virtue of the explosion of the internet, web people putting up the numbers. Except it was always and only ever will be a lead hammer which we never really should've created to begin with. It's been literally a tyranny of the majority sort of situation now for many years where we must all agree to scratch our itches with angle grinders as a matter of populism.
-
I have done a ton of JavaScript in my very long career... I never liked it and never will... JavaScript was never designed for what it is being used for now. And the only reason people use it is because it is free and is part of the inherent infrastructure of web applications. This still doesn't mean that it is good language due to its popularity. And languages that continually have things "bolted" on them become bloated and sometimes even unusable. This pushes developers to find cleaner languages...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Steve Naidamast wrote:
This still doesn't mean that it is good language due to its popularity.
So what is the alternative that is good?
Steve Naidamast wrote:
And languages that continually have things "bolted" on them become bloated and sometimes even unusable.
Unusable? I haven't seen that.
Steve Naidamast wrote:
This pushes developers to find cleaner languages
Never seen anyone claim that. Certainly seen people choose tech stacks because they liked it. Certainly seen people use another language just because they wanted to. Certainly seen people use another tech because they could not figure out how to use the existing tech. Seen a tech stack used because the owners son recommended switching. I have only seen one objective decision made about a tech stack and that was a business, not technical, reason. That was because the company that owned the tech stack gave the target company (as a startup) quite a bit of money.
-
Steve Naidamast wrote:
This still doesn't mean that it is good language due to its popularity.
So what is the alternative that is good?
Steve Naidamast wrote:
And languages that continually have things "bolted" on them become bloated and sometimes even unusable.
Unusable? I haven't seen that.
Steve Naidamast wrote:
This pushes developers to find cleaner languages
Never seen anyone claim that. Certainly seen people choose tech stacks because they liked it. Certainly seen people use another language just because they wanted to. Certainly seen people use another tech because they could not figure out how to use the existing tech. Seen a tech stack used because the owners son recommended switching. I have only seen one objective decision made about a tech stack and that was a business, not technical, reason. That was because the company that owned the tech stack gave the target company (as a startup) quite a bit of money.
Why do you think C# has become so popular when compared to Java?
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
PIEBALDconsult wrote:
C# and Java "compile" to some intermediate form which runs on a VM/runtime, so are they truly compiled or just interpreted? Probably the latter.
There is no technical reason why one could not build hardware which has the Java bytecode as its machine language. Ditto for C#. Therefore, neither language is inherently interpreted.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
There is no technical reason why one could not build hardware which has the Java bytecode as its machine language. Ditto for C#.
If you with C# mean to refer to dotNET Intermediate Language (IL), you are comparing two languages at approximately the same abstraction level, but very different in form. Java bytecode, like lots of other P-code formats (strongly inspired by the P4 code of the original ETH Pascal compiler) are intended to be complete, ready for execution, with no loose ends (except for those defined by the language to be, e.g. late binding), similar to 'real' binary machine code - but for a virtual machine. The instructions (i.e. bytecodes) are executed one by one, independent of each other. IL, on the other hand, has a lot of loose ends that must be tied up before execution. It contains lots of metadata that are not the machine instructions, but indicates how instructions should be generated. Although you in principle could try to 'interpret' the IL, you would have to construct fairly large runtime data structures to know how to generate the interpretation, similar to those structures built by the jitter to compile the IL to machine code. So you are really doing the full compilation, except that you are sending binary instructions to the execution unit rather than to the executable image. The line between compilaton (followed by execution) and interpretation is fuzzy. If you with C# refer to direct source code interpretation, you have a huge task to solve. Here, you would have to build a lot more complex runtime data structures to support the interpreter. Building these would be going a long way to making a full parse tree of the source code, and then you have done a significant part of the compilation job. Compilers are so fast nowadays that I see no practical advantages in interpreting program code. For building dedicated hardware: USCD Pascal, one of the better known Pascal interpreters for PCs, used the P4 bytecode. It also ran on the PDP-11, such as the single-chip LSI-11. For this was written microcode to run P4 directly (rather than PDP-11 instruction set). It turned out to be significantly slower than running the PDP-11 software interpreter. There are lots of similar stories of hardware implementations not living up to expectations. Intel's object oriented CPU, the 432, was simulated on an 8086. The first 432 implementation turned out to be slower than the simul
-
Don't get me started on imaginary languages. :~
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Bear with me, because as much as I am loath to holy roll about technology, I still have my peeves. I went about porting my DFA lexer engine from C# to TypeScript. It was primarily an exercise in teaching myself TypeScript, plus brushing up on my JS. So I implement the bones of it, and after adjusting my mental map to the JS way of doing things I got it mostly working. Then I went about trying to use a Map keyed by Sets. Turns out JS Map and Set will only compare by value for "scalar" types (presumably including strings) or otherwise it uses reference comparisons. You can't override your own equality mechanism either. how to customize object equality for javascript set - Stack Overflow[^] Consequently, there is no performant way to do subset construction to convert an NFA to a DFA in this language. I've seen others solve this problem by using string keys, but this falls down for machines of non-trivial size. Regex FA visualizer[^] is one example but I can basically crash it or stall it out for a long time at least with any non-trivial expression. This one also doesn't work properly besides, but I have no other link handy for you to try. This may be academic, but it is also basic computer science. A language should be able to allow you to implement computer sciencey algorithms and constructs - especially those that have been adapted to countless other programming languages. DFA by subset construction is basic. And you can't do it in JS. I can't even begin to imagine what LALR table generation would look like. You may be wondering why do I care? Because node.js. Because Angular Because React-Native it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be, if not Turing complete at least cover the fundamentals, or you're just spreading garbage around. Without a way to do custom comparisons at the very least on hashed containers, your language isn't going to be able to do a lot of things other high level languages can accomplish handily. Is it even a "real" language? Is it ready for primetime, or is it just being adopted because we can? :~
Any language in which you can write working software is a real programming language. Each and every has its limitations. Although JS is being used in way too many situations, for which it was not well designed. I always thought that it should have been deprecated around 2007 for something more well designed or at least limited to client side basic UI code.
-
Bear with me, because as much as I am loath to holy roll about technology, I still have my peeves. I went about porting my DFA lexer engine from C# to TypeScript. It was primarily an exercise in teaching myself TypeScript, plus brushing up on my JS. So I implement the bones of it, and after adjusting my mental map to the JS way of doing things I got it mostly working. Then I went about trying to use a Map keyed by Sets. Turns out JS Map and Set will only compare by value for "scalar" types (presumably including strings) or otherwise it uses reference comparisons. You can't override your own equality mechanism either. how to customize object equality for javascript set - Stack Overflow[^] Consequently, there is no performant way to do subset construction to convert an NFA to a DFA in this language. I've seen others solve this problem by using string keys, but this falls down for machines of non-trivial size. Regex FA visualizer[^] is one example but I can basically crash it or stall it out for a long time at least with any non-trivial expression. This one also doesn't work properly besides, but I have no other link handy for you to try. This may be academic, but it is also basic computer science. A language should be able to allow you to implement computer sciencey algorithms and constructs - especially those that have been adapted to countless other programming languages. DFA by subset construction is basic. And you can't do it in JS. I can't even begin to imagine what LALR table generation would look like. You may be wondering why do I care? Because node.js. Because Angular Because React-Native it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be, if not Turing complete at least cover the fundamentals, or you're just spreading garbage around. Without a way to do custom comparisons at the very least on hashed containers, your language isn't going to be able to do a lot of things other high level languages can accomplish handily. Is it even a "real" language? Is it ready for primetime, or is it just being adopted because we can? :~
I'm not sure I could define a "real" programming language, but if I could, JS would fail to meet the definition. Not declaring variables coupled with case-sensitivity was enough for me to loathe the stuff.
-
Daniel Pfeffer wrote:
There is no technical reason why one could not build hardware which has the Java bytecode as its machine language. Ditto for C#.
If you with C# mean to refer to dotNET Intermediate Language (IL), you are comparing two languages at approximately the same abstraction level, but very different in form. Java bytecode, like lots of other P-code formats (strongly inspired by the P4 code of the original ETH Pascal compiler) are intended to be complete, ready for execution, with no loose ends (except for those defined by the language to be, e.g. late binding), similar to 'real' binary machine code - but for a virtual machine. The instructions (i.e. bytecodes) are executed one by one, independent of each other. IL, on the other hand, has a lot of loose ends that must be tied up before execution. It contains lots of metadata that are not the machine instructions, but indicates how instructions should be generated. Although you in principle could try to 'interpret' the IL, you would have to construct fairly large runtime data structures to know how to generate the interpretation, similar to those structures built by the jitter to compile the IL to machine code. So you are really doing the full compilation, except that you are sending binary instructions to the execution unit rather than to the executable image. The line between compilaton (followed by execution) and interpretation is fuzzy. If you with C# refer to direct source code interpretation, you have a huge task to solve. Here, you would have to build a lot more complex runtime data structures to support the interpreter. Building these would be going a long way to making a full parse tree of the source code, and then you have done a significant part of the compilation job. Compilers are so fast nowadays that I see no practical advantages in interpreting program code. For building dedicated hardware: USCD Pascal, one of the better known Pascal interpreters for PCs, used the P4 bytecode. It also ran on the PDP-11, such as the single-chip LSI-11. For this was written microcode to run P4 directly (rather than PDP-11 instruction set). It turned out to be significantly slower than running the PDP-11 software interpreter. There are lots of similar stories of hardware implementations not living up to expectations. Intel's object oriented CPU, the 432, was simulated on an 8086. The first 432 implementation turned out to be slower than the simul
trønderen wrote:
IL, on the other hand, has a lot of loose ends that must be tied up before execution. It contains lots of metadata that are not the machine instructions, but indicates how instructions should be generated. Although you in principle could try to 'interpret' the IL, you would have to construct fairly large runtime data structures to know how to generate the interpretation, similar to those structures built by the jitter to compile the IL to machine code. So you are really doing the full compilation, except that you are sending binary instructions to the execution unit rather than to the executable image.
I sit corrected. :)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Daniel Pfeffer wrote:
There is no technical reason why
There is a commercial reason though because when they tried that long ago with Pascal it failed.
I'm aware of that. We were having a technical discussion, not discussing the commercial viability of such an implementation.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Bear with me, because as much as I am loath to holy roll about technology, I still have my peeves. I went about porting my DFA lexer engine from C# to TypeScript. It was primarily an exercise in teaching myself TypeScript, plus brushing up on my JS. So I implement the bones of it, and after adjusting my mental map to the JS way of doing things I got it mostly working. Then I went about trying to use a Map keyed by Sets. Turns out JS Map and Set will only compare by value for "scalar" types (presumably including strings) or otherwise it uses reference comparisons. You can't override your own equality mechanism either. how to customize object equality for javascript set - Stack Overflow[^] Consequently, there is no performant way to do subset construction to convert an NFA to a DFA in this language. I've seen others solve this problem by using string keys, but this falls down for machines of non-trivial size. Regex FA visualizer[^] is one example but I can basically crash it or stall it out for a long time at least with any non-trivial expression. This one also doesn't work properly besides, but I have no other link handy for you to try. This may be academic, but it is also basic computer science. A language should be able to allow you to implement computer sciencey algorithms and constructs - especially those that have been adapted to countless other programming languages. DFA by subset construction is basic. And you can't do it in JS. I can't even begin to imagine what LALR table generation would look like. You may be wondering why do I care? Because node.js. Because Angular Because React-Native it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be, if not Turing complete at least cover the fundamentals, or you're just spreading garbage around. Without a way to do custom comparisons at the very least on hashed containers, your language isn't going to be able to do a lot of things other high level languages can accomplish handily. Is it even a "real" language? Is it ready for primetime, or is it just being adopted because we can? :~
Javascript is filth. I thought everyone knew this. It's because the Document Object Model is filth: you have to have filth in order to process it. The two things together represent the decline of programming as a skill.
-
Why do you think C# has become so popular when compared to Java?
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Why do you think C# has become so popular when compared to Java?
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Because of Visual Studio. Without VS, the number of problem solutions under Windows would have been a small fraction of what it is. That would have reduced the number of customers finding Windows a viable platform to a fraction. Which would have reduced MS to a fraction of what it is. Developing VS and letting individual developers and small businesses use it for free is the best investment MS ever did.
Religious freedom is the freedom to say that two plus two make five.
-
Bear with me, because as much as I am loath to holy roll about technology, I still have my peeves. I went about porting my DFA lexer engine from C# to TypeScript. It was primarily an exercise in teaching myself TypeScript, plus brushing up on my JS. So I implement the bones of it, and after adjusting my mental map to the JS way of doing things I got it mostly working. Then I went about trying to use a Map keyed by Sets. Turns out JS Map and Set will only compare by value for "scalar" types (presumably including strings) or otherwise it uses reference comparisons. You can't override your own equality mechanism either. how to customize object equality for javascript set - Stack Overflow[^] Consequently, there is no performant way to do subset construction to convert an NFA to a DFA in this language. I've seen others solve this problem by using string keys, but this falls down for machines of non-trivial size. Regex FA visualizer[^] is one example but I can basically crash it or stall it out for a long time at least with any non-trivial expression. This one also doesn't work properly besides, but I have no other link handy for you to try. This may be academic, but it is also basic computer science. A language should be able to allow you to implement computer sciencey algorithms and constructs - especially those that have been adapted to countless other programming languages. DFA by subset construction is basic. And you can't do it in JS. I can't even begin to imagine what LALR table generation would look like. You may be wondering why do I care? Because node.js. Because Angular Because React-Native it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be, if not Turing complete at least cover the fundamentals, or you're just spreading garbage around. Without a way to do custom comparisons at the very least on hashed containers, your language isn't going to be able to do a lot of things other high level languages can accomplish handily. Is it even a "real" language? Is it ready for primetime, or is it just being adopted because we can? :~
-
Daniel Pfeffer wrote:
There is no technical reason why one could not build hardware which has the Java bytecode as its machine language. Ditto for C#.
If you with C# mean to refer to dotNET Intermediate Language (IL), you are comparing two languages at approximately the same abstraction level, but very different in form. Java bytecode, like lots of other P-code formats (strongly inspired by the P4 code of the original ETH Pascal compiler) are intended to be complete, ready for execution, with no loose ends (except for those defined by the language to be, e.g. late binding), similar to 'real' binary machine code - but for a virtual machine. The instructions (i.e. bytecodes) are executed one by one, independent of each other. IL, on the other hand, has a lot of loose ends that must be tied up before execution. It contains lots of metadata that are not the machine instructions, but indicates how instructions should be generated. Although you in principle could try to 'interpret' the IL, you would have to construct fairly large runtime data structures to know how to generate the interpretation, similar to those structures built by the jitter to compile the IL to machine code. So you are really doing the full compilation, except that you are sending binary instructions to the execution unit rather than to the executable image. The line between compilaton (followed by execution) and interpretation is fuzzy. If you with C# refer to direct source code interpretation, you have a huge task to solve. Here, you would have to build a lot more complex runtime data structures to support the interpreter. Building these would be going a long way to making a full parse tree of the source code, and then you have done a significant part of the compilation job. Compilers are so fast nowadays that I see no practical advantages in interpreting program code. For building dedicated hardware: USCD Pascal, one of the better known Pascal interpreters for PCs, used the P4 bytecode. It also ran on the PDP-11, such as the single-chip LSI-11. For this was written microcode to run P4 directly (rather than PDP-11 instruction set). It turned out to be significantly slower than running the PDP-11 software interpreter. There are lots of similar stories of hardware implementations not living up to expectations. Intel's object oriented CPU, the 432, was simulated on an 8086. The first 432 implementation turned out to be slower than the simul
-
Because of Visual Studio. Without VS, the number of problem solutions under Windows would have been a small fraction of what it is. That would have reduced the number of customers finding Windows a viable platform to a fraction. Which would have reduced MS to a fraction of what it is. Developing VS and letting individual developers and small businesses use it for free is the best investment MS ever did.
Religious freedom is the freedom to say that two plus two make five.
-
honey the codewitch wrote:
it's not just for web front ends anymore. JS is an almost virulent technology these days. It needs to be
That is only people carrying around their golden hammer. It's nothing to do with it being "good" or "suited" and they do not care. It's being what web people know and by virtue of the explosion of the internet, web people putting up the numbers. Except it was always and only ever will be a lead hammer which we never really should've created to begin with. It's been literally a tyranny of the majority sort of situation now for many years where we must all agree to scratch our itches with angle grinders as a matter of populism.
As I've come to use it I can't help but agree with you. This is hours of my life I can't get back.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix