Thread: What do we think about JavaScript?

  1. #46
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by whiteflags View Post
    I think MacNilly means rather that C is close to the hardware in the sense that you could insert assembly code or understand what the assembly would look like from C code.
    Yes, that's a large part of what I meant in my post.

    By a "simple" language I mean one with less "features" as compared to more. In exchange for (possibly) increasing programmer's productivity and reducing number of lines of code to perform a task, a more complex language increases mental demand on the programmer, because he or she needs to (should!) understand how all those extra features interact in a variety of situations. It's a double-edged sword.

    As far as "modeling current hardware".. C seems to me to provide the least possible complexity (in terms of features and also length of formal language specification) in a language which is capable of programming a Turing machine.. which is basically how modern hardware works, unless I am missing something. For example, functional programming languages like Scheme make an effect to NOT model the hardware that the programs will eventually run on, but instead to abstract away this dependency. On the other hand, things like Brain........ shows that a language still needs to be human-understandable to be at all practical, even though even simpler than C.

    Also, I do not wish to incite any argument in this thread and I am sorry it seems to have turned out that way..
    Last edited by MacNilly; 07-08-2016 at 11:33 PM.

  2. #47
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,688
    I took a crash course in Java Script a few years back and to be honest, hated it. I had to
    do it for a work-related study group thing (which I won't bore you with the details of it).

    I've never been a "scripting" person, so that's probably the main reason I could never quite
    get my head around it. PHP however, I am sorting learning in my spare time - quite enjoying it.
    JS does get some bad rep, however could the Internet really survive without it?
    Double Helix STL

  3. #48
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by swgh View Post
    I've never been a "scripting" person, so that's probably the main reason I could never quite
    get my head around it.
    I think there is nothing really different from a "scripting" language than any other "real" programming language, other than the pejorative usage. In common parlance, the application of the term "scripting" to a programming language seems to imply its primary use as a control language to some system. There is nothing stopping Java"script", or any other "script" from being compiled directly to machine language.. also, one could even consider C as a "scripting" language for a real processor...

    However, in the case of Javascript, if it was compiled directly to machine language, would likely not work as intended due to the ubiquitous and idiomatic usage of concepts such as the "window" object, etc. -- which would NOT necessarily exist in a native environment. But these dependencies need not (and probably should not) be an integral part of the language itself.
    Last edited by MacNilly; 07-09-2016 at 02:53 AM.

  4. #49
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,688
    Quote Originally Posted by MacNilly View Post
    also, one could even consider C as a "scripting" language for a real processor...
    That's actually quite true. If you think about it, C is just a thin more human Assembly language. Unless you are coding
    in pure ASM, C is the lowest language to the computer metal you can get. Of course if you could program in pure
    binary:

    Code:
    00100101101


    You could rule the world.

    But yes, you make some good points there McNilly.
    Double Helix STL

  5. #50
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by MacNilly View Post
    Yes, that's a large part of what I meant in my post.

    By a "simple" language I mean one with less "features" as compared to more. In exchange for (possibly) increasing programmer's productivity and reducing number of lines of code to perform a task, a more complex language increases mental demand on the programmer, because he or she needs to (should!) understand how all those extra features interact in a variety of situations. It's a double-edged sword.
    I think quite on the contrary, that C demands more lines of code to perform comparable tasks and by extension increases code complexity and demands more of the programmer. Although I still think that functional programming offers superior code organization than OOP, C ends up not taking advantage of that because of the extended and complex execution path it eventually forces on the user. And while C++ may introduce more boilerplate code, C isn't too far off in its own demands for code correctness, memory management or the previously mentioned macro magic. Take a look for instance on the techniques you must use in C if for some reason you need to emulate C++ namespaces.

    The obvious simplicity of the language definition is only illusive. Like the apparent simplicity of the assembly language definition, this only means that the developer will be the one taking the blunt of the complexity.

    I think the key thought to keep in mind when discussing a language complexity is that the abstraction ideas that make the core of any programming language today will always present the exact same level of complexity. For all languages, without exception. This is so because that complexity is inherited upstream by the system architecture and to some extent the operating system kernel. And that complexity can't go away. What languages do is decide how they will abstract that complexity. A simpler language specification means much of that complexity is not going to be abstracted away, or be thinly abstracted, and will be exposed to the programmer as a result. So a "simpler" language is more complex to code and produces more complex code.

    Like distinct players sitting in front of a chess board, they will have to tackle the inherent complexity of the game that is common across them. A C programmer will bring just a few notes, A C++ programmer might come with a cheatsheet on opening moves and endings, and a Python programmer may bring an entire book on how to win the game. The burden on the players' will be different. The code inside their brains necessary to process the game will be different. The C player, who traveled light, will have the biggest headache at the end of the game. While the Python player who packed more than he needed, will likely have to think less about the game.


    Quote Originally Posted by MacNilly View Post
    As far as "modeling current hardware".. C seems to me to provide the least possible complexity (in terms of features and also length of formal language specification) in a language which is capable of programming a Turing machine.. which is basically how modern hardware works, unless I am missing something.
    Modeling is the wrong word, and one of the two words that got me here. C doesn't model the hardware, it precisely aims to not do that. C, like any other high-level language, can be many things, but not a modeling tool. Maybe I am being too pedantic, because I DO understand where you are coming from, but it's really a pet-peeve of mine. This idea that languages like C or C++ are "closer to the metal" than languages like Scheme or Java, really needs to be put in context.

    All these four languages mentioned are high-level languages and they do indeed share different rungs in the abstraction ladder. But they stay an equal distance from the processor instruction set. Frankly the idea that a language like C has a better 1-on-1 map to the processor instruction set isn't good enough. It's not even correct. For one, that mapping is purely arbitrary because it depends entirely on the compiler. On the other hand that mapping isn't correct, because C code will not tell you anything truthful about stack positions, storage locations or how values are returned. Only by checking the executable will we finally get a glimpse at true and functional assembly language. But that is true of any other language. The C mapping, or that of any other high-level language for that matter that shares a similar predisposition for the so-called 1-on-1 mapping, like Go, is just and only a toy. It requires an intimate knowledge of the specific compiler, after which it will still remains largely useless for the aforementioned reasons and also because many other constructs with a common use in the language have more complex or even unpredictable mappings.

    I think a better notion that a high-level language is "closer to the metal" is made by looking precisely at its specification and how far it goes in abstracting the complexity of the machine. That's where I agree with you. But not on the idea of assembly mapping.

    Sorry for the long post. ugh! Where's whatsisname when we need him? Haven't seen our resident TL;DR master for quite a while... I do miss him.
    Last edited by Mario F.; 07-09-2016 at 06:47 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #51
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    So... I agree with Elysia's post that started this entire debate.

    I think C is too bare nowadays to make it more practical over C++. Now that I feel like I'm finally starting to get C++, I could never go back. The things C++ allows you to do are amazing. The issue is its steep learning curve.

    So, C and up are all high-level languages. I agree with Mario in that regard. So they're all logically equivalent. What really separates them is the level of their abstractions (again, as Mario noted). C is a high-level language that offers low-level abstractions. C++ offers both but if you're not doing high-level C++, it's because you were like me and coming from a C background.

    I also think it's an abhorrent thing to say that functional programming yields better code structure than OOP. Namely just because making an absolution about a paradigm is an instant kiss of death and will likely shoehorn your codebase into a hole it has no business being deformed to fit into. But I think that's because Python offers some FP concepts.

    And I'm certainly not saying that FP isn't incredibly powerful or useful. FP has a lot of good ideas. Functions as variables, thinking in terms of functional compositions, pushing for immutability, lazy evaluation, support for recursion (this often lowers cognitive overhead, both while writing and reading code). I'm sure there's some things that I've missed but FP is great. To a point. I think it's the point where you get into monads that FP goes on the rails and it's the reason why it fell into obscurity. I didn't really "get" monads until I read this.

    And I realized that monads are literally just classes. And then I learned that classes are types. And then I got amazing at templates in C++ because it was all so simple now. Imagine how excited I was when I found out there's a proposal for a Expected monad in C++! It's similar to a Maybe only actually useful.

    JS is great because the web is largely solved by FP (hence Mario's affinity for Python and the FP support it has). Someone wrote a "Validator" monad in JS which is basically C++'s Expected but marketed as, "Hey, use this to validate your forms!". And as someone who's written some decently intense client-side validation in JS, a Validator monad is the best thing to ever happen ever.

    But I don't really expect FP to be widely used and understood. For one, it's marketed all wrong. And I've never seen anyone have a more straight-forward explanation of monad than, "Imagine you have this class that...". Seriously, if I see one more blurb about parallel computing in FP, I'm going to have an aneurysm because as someone that feels like they've invested a good amount of experience into threading and asynchronous reasoning, what makes FP good for parallel computing isn't exclusive to FP. At all. And let's put it this way, Nvidia didn't write their GPGPU API in Haskell, they chose C++. And C++ does it well because it supports fundamentally lower abstractions which is great because CUDA needs like another 5 years at least.

  7. #52
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Actually I did make a mistake in that post. I meant to say procedural programming, not functional programming.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  8. #53
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by Mario F. View Post
    I think quite on the contrary, that C demands more lines of code to perform comparable tasks and by extension increases code complexity and demands more of the programmer... The obvious simplicity of the language definition is only illusive. Like the apparent simplicity of the assembly language definition, this only means that the developer will be the one taking the blunt of the complexity...A simpler language specification means much of that complexity is not going to be abstracted away, or be thinly abstracted, and will be exposed to the programmer as a result. So a "simpler" language is more complex to code and produces more complex code.
    I think you must have misunderstood my previous posts, because this (spliced) quote is exactly what I have discovered to be true, and what I was trying to convey in my series of posts here. We seem to be in agreement, then, after all.

    I see what you mean that trying to implement abstractions in C, which are more cleanly accomplished in a language which provides syntax for that abstraction (exception handling vs. longjmp/setjmp, object-oriented programming, etc.) , would definitely increase the demand on the C programmer as compared to the X language programmer where language X provides those features as a core part of the language. However, these features introduce extra complexity into the language which may not be needed by a low level language such as C.
    Last edited by MacNilly; 07-13-2016 at 02:21 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. ajax response javascript=>c#=>javascript
    By xddxogm3 in forum C# Programming
    Replies: 1
    Last Post: 03-14-2012, 01:22 PM
  2. Replies: 2
    Last Post: 03-10-2009, 08:36 PM
  3. javascript
    By Redseal in forum Tech Board
    Replies: 8
    Last Post: 06-16-2007, 07:36 AM
  4. javascript
    By xddxogm3 in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 12-07-2003, 10:50 AM
  5. javascript
    By bluehead in forum Game Programming
    Replies: 4
    Last Post: 12-04-2001, 09:13 PM

Tags for this Thread