342
What are your programming hot takes? (lemmy.ml)
submitted 3 years ago by to c/programming@programming.dev
894 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 6 points 3 years ago (7 children)

Why exactly is it horse shit? It does have it's quirks but I wouldn't go that far

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 2 points 3 years ago (4 children)

    I think it suffers from the same problem as SQL. A bunch organizations and companies would need to agree to make improvements, you don't want to break compatibility, so nothing really improves. You just get some extensions to it here and there which just makes it messier.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 years ago (3 children)

    Isn't the "extension" problem the same with almost all programming languages?

    For example, does 80s C compile under gcc with 2015 features? If it does, then it's no better than JS.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 years ago (2 children)

    Yeah but with JS, you have to consider the browsers that are out there already. I think this is getting better now that IE is killed off, but there's still a consideration about whether to use a new feature that doesn't work on older browsers.

    With C, it's compiled so if you're distributing the binary, you're done. And if you're sharing the source to another developer, that dev will be likely to be technically proficient enough to update gcc and any needed libraries to the right version to get it to compile.

    When it's an interpreted language that is interpreted by browsers made by different companies and organizations (so they have to agree on changes), with users not being reliable of keeping their browsers up to date, it's going to be messy. Also there's security concerns, you need to make sure when implementing the extension it won't allow bad actors to make scripts to take over the users computer.

    It's not anyone's fault, it's just a significantly more difficult problem to extend a language that is going to be sent to user's computer on the fly from arbitrary websites and have those extensions be reliable, secure, and consistent across the various companies implementing it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago (1 child)

    browsers that are out there already C is compiled

    JS makes heavy use of pollyfills where needed, bridging the gap between old browsers and new ones.

    A binary might still require a specific shared lib version, specific architecture, whatever, it's not a magic bullet.

    update gcc and any needed libraries

    Doesn't always work when working with legacy unupdated dependencies.

    security concerns... ...scripts to take over the users compurer

    Wouldn't having compiled code running in the browser (via webassembly) be actually worse for security? With JS you can at least see the source that's being run, with compiled WA, not so much. Don't really understand this point.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 years ago

    A binary might still require a specific shared lib version, specific architecture,

    Yeah but those issues are dealt with at compile time by a developer. The problems don't manifest themselves at runtime as they do with an interpreted language.

    Doesn’t always work when working with legacy unupdated dependencies.

    Also compile time, not runtime.

    With JS you can at least see the source that’s being run,

    You could disassemble compiled code and read the assembly code. Yeah that's difficult, but about the same difficulty as reading JS that's been run through an optimizer. Nobody has time for that, and users certainly don't have the skill to do that, so the the organizations that make the browsers are ultimately responsible for making sure any new addition to JS isn't going to cause the security problem.

    Wouldn’t having compiled code running in the browser (via webassembly) be actually worse for security?

    About the same for security. I don't know much about web assembly but it has similar problems. I mean the reason I don't know much about it is because it's too new, can't count on it being widely supported, etc. Similar problems as JS. But being compiled to a common language might shift the pain of dealing with a lot of problems with language changes to the people who write the compilers for it. Time will tell.

    But the thing is, most languages aren't designed to be primarily interpreted by a browser. Nobody is going to say "Hmmm we better think about how this will affect web browser security if we add to the language." Because use by browsers as a web assembly isn't the primary use case. If a language change negatively affects a browser, that's their problem to sort out.

    But with JS it is primarily being used as an interpreted language implemented by browser makers. Which means the browser makers have a huge amount of influence over the decision making process. If google says "we have concerns over security with this feature so we aren't using it in chrome" then well it's not a feature that developers can use because it's not going to work for most users.

    I think you're trying to make this a fair comparison, but my point is that it is not a fair comparison. What the languages are used for and how they're deployed impacts process for improving them. The requirements for JS in terms of what it's primarily used for and how it gets deployed makes it difficult to change, which is why it is as messy as it is. Takes a lot longer to get changes accepted by all the parties that need to accept them.

  • permalink
  • fedilink
  • source
  • parent