What's a "real" programming language?
-
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
-
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 read your message in the daily insider and kept it for after my vacation. I'm still on vacation, but I'm at my computer for a moment. Way too long ago (2016-2017), I wrote a LINQ library in JavaScript. The one thing I really couldn't copy was the dictionary because of a lack of hashes. Here's how I worked around it (it's not a true dictionary anymore, but as far as usage go it's the same as C#): Arrgh.js - Bringing LINQ to JavaScript[^] Probably not very useful for your use case, but you might find it interesting.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
TypeScript (JS really in this case, since TS is just syntactic sugar and validation) doesn't imply a web app anymore, which was part of the point I was making in my original, arguably too verbose post. It's used on the backend (node.js). It's used on the desktop (angular, react-native). Kevin only knows where next? My concern is it doesn't seem ready for it. As far as computer sciencey algorithms not being needed, consider that constructs in computer science make up nearly every programming problem you'll ever solve. DFA by subset construction is not the only place you'd ever need custom equality. From ECMAScript 6: maps and sets[^]
5.2 Why can’t I configure how maps and sets compare keys and values? Question: It would be nice if there were a way to configure what map keys and what set elements are considered equal. Why isn’t there? Answer: That feature has been postponed, as it is difficult to implement properly and efficiently. One option is to hand callbacks to collections that specify equality. Another option, available in Java, is to specify equality via a method that object implement (equals() in Java). However, this approach is problematic for mutable objects: In general, if an object changes, its “location” inside a collection has to change, as well. But that’s not what happens in Java. JavaScript will probably go the safer route of only enabling comparison by value for special immutable objects (so-called value objects). Comparison by value means that two values are considered equal if their contents are equal. Primitive values are compared by value in JavaScript.
Read that carefully and you'll see the problem is more fundamental than simply maps and sets. You can't override equality. You can't implement custom value equality for objects. That hamstrings your ability to use Sets and Maps in the first place, but that's not the only place it limits you. It also speaks to a large issue of - if this is missing/incomplete/problematic-to-implement based on how the language works under the covers, what else can't it do that is fundamental?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I've gotten so used to garbage collection that I've learned to accept it. I don't like it but it's no longer a huge deal for me.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I've gotten so used to garbage collection that I've learned to accept it. I don't like it but it's no longer a huge deal for me.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
It's not a matter of garbage collection. Java, C# and even Python have finalisers that support adding code that is executed when an object is reaped by the GC. This becomes essential when providing a C++ implementation of an object in the target language (say via Emscripten) to arrange for the C++ destructor to be called when the owning object is destroyed by the garbage collector. Lack of finalisers mean the C++ implementation is limited to PODs (plain ordinary data types), whcih is pretty damn limiting.
-
It's not a matter of garbage collection. Java, C# and even Python have finalisers that support adding code that is executed when an object is reaped by the GC. This becomes essential when providing a C++ implementation of an object in the target language (say via Emscripten) to arrange for the C++ destructor to be called when the owning object is destroyed by the garbage collector. Lack of finalisers mean the C++ implementation is limited to PODs (plain ordinary data types), whcih is pretty damn limiting.
That's fair enough. I didn't realize that limitation of emscripten.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
