Thread: What do we think about JavaScript?

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    I need a like button for that.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Make Fortran great again
    Join Date
    Sep 2009
    Posts
    1,413
    Quote Originally Posted by Yarin View Post
    Awesome.

  3. #18
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Yeah, that was some of the nonsensical stuff I was alluding too earlier. It's not actually all that funny when it's a real problem in your codebase.

    Okay, that's a lie. It's still funny.

  4. #19
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Why are we doing web asm again? Are we certain we don't hate the world? The Birth & Death of JavaScript —
    Destroy All Software Talks
    Last edited by whiteflags; 06-13-2016 at 11:12 PM.

  5. #20
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    My favorite talk of his is "A(n) Brave New World". He captures perfectly the current software development culture that has been plaguing us for 20 years or so. The tremendous lack of innovation, the false memes that have been corrupting our thinking and eroding our computer quality of life, the constant vertical growing of a software development ecosystem dependency tree that can't shave off its legacy root nodes and replace them altogether with something entirely new.

    It goes to the core of why I no longer find pleasure in programming. A culture that I can no longer respect or feel I want to be a part of. Software development is a victim of its own success. As it became increasingly widespread, it became a culture of the masses; and with this, absorbed all the trappings of popular culture.

    A month ago we were introduced here on CBoard to a new code editor. I immediately criticized for its lack of anything even resembling innovation. It is just another executable file no one really needs, that doesn't bring anything that we haven't already. And what we have already is nothing like we have been asking. In a few minutes Gary describes an editor that would be a dream to any developer. But it won't be made (that talk is 4 years old). It can't be made because not only it lacks the software infrastructure to support it, despite computers being more than able to render and execute all of its functionality and modern CPUs capable of handling its complexity and performance demands, but also because even if we ignored the terminal requirements and developed it for a GUI, no one is interested in making it as they keep distracting themselves with making code editors with mind numbing keyboard combos and cute syntax highlighting.

    This is really a Seth Godin's world. Spending 1 or 2 years not writing a single line of code (because innovation takes thinking), just hammering your brain down coming up with a code editor that _really_ solves software development problems is just not how we do software anymore. Keyboard combos, syntax highlighting and cool dark themes is what allows us to ship our software fast and ship often. Such is the sorry state of our pop culture of software development. And so we elevate to the status of divinity, such repugnant things as the Sublime Editor. And with it, we create and worship a pantheon of false gods.

    And I'm sure Seth's proud also of programming languages development over the years. We haven't improved. We have done _nothing_ to facilitate the engineering task that is software development. We ship software languages fast and ship often. They are born like mushrooms resembling all others that already exist and pretending they are better and solve our problems. But our _real_ problems stay unsolved. Because we surround ourselves precisely with all sorts of principles, building huge and complex rules on best practices and code correctness and good paradigms, forgetting that is precisely the _real_ problem of software development that we are begging to be solved. And it can only be the language that can implementing and enforce these rules. But no way that will happen. A programming language that acts responsibly towards the computer but also towards the programmer isn't going to be developed in this culture. And so programming is an absurdly difficult task and a miserable activity of constant peer checking and the consequent humiliation of public exposure to ridicule, because no one can possibly adopt all the rules.

    ---

    I am probably not intelligent enough to have come up with those things I wish in this post. But I will never know. Now it is too late. I went too fast through academia (big mistake) and straight into the job market, where for all my sins I spent too much time strapped to poor languages and no time for sitting under a tree and thinking about what I really wanted and why what I was doing was utter nonsense. Maybe, if my early choices hadn't been so bad and I had thought more carefully about my career, I would have been discussing things like Gary's editor in the first person.

    But I see myself in every fresh graduate in this day and age. Graduates completely blind to the neon lights of modern computer programming, lacking any incentive or even the realization there is a need to change the landscape of software development and that things are bad, very bad. Not great and shiny as the pop community will want them to believe.
    Last edited by Mario F.; 06-14-2016 at 04:14 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. #21
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Mario, can you please expand on some of these issues plaguing the industry? I feel like JS epitomizes a lot of the false prophets and hype. Though Node is pretty cool at times, it's not the Holy Grail people tout it to be.

  7. #22
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by Mario F. View Post
    In a few minutes Gary describes an editor that would be a dream to any developer.
    Link? I can't find this talk.


    Quote Originally Posted by Mario F. View Post
    And so we elevate to the status of divinity, such repugnant things as the Sublime Editor.
    Indeed. People need to accept Vim as the one true editor.

  8. #23
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by Yarin View Post
    Link? I can't find this talk.
    I couldn't find it either. I watched it a long time ago and turns out I only thought I knew its title. It's called "A(n) Whole New World": A Whole New World —
    Destroy All Software Talks


    Quote Originally Posted by Yarin View Post
    Indeed. People need to accept Vim as the one true editor.
    Another piece of useless crap. Yes, you can type fast in it. Great! That will not solve many coding problems, but you can write cheap lousy novels in it faster than Stephen King can publish them. *two thumbs up*
    Note: I know you was being sarcastic

    @Mutant: Will reply later, mate.
    Last edited by Mario F.; 06-14-2016 at 11:31 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.

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by MutantJohn View Post
    Mario, can you please expand on some of these issues plaguing the industry? I feel like JS epitomizes a lot of the false prophets and hype. Though Node is pretty cool at times, it's not the Holy Grail people tout it to be.
    I addressed two different things in my post. I think you are asking specifically about programming languages.

    The landscape of software development languages hasn't changed much with the years and we haven't been given anything concretely new that isn't just a rehash of existing ideas. Programming paradigms haven't evolved. They were almost all invented back in the 60s and 70s and nothing substantially new and influential has emerged since. Granted, this is likely one one area of research with a limited domain (you can only go as far), but programing paradigms are one of the most determining factors of a language identity, which results in languages offering the same paradigm being essentially the same.

    It's true that the syntax and the semantics of a language also differentiate languages. And some of these syntaxes and semantics make one language visually and structurally very distinct from another. But syntax and semantics alone don't solve the programming challenges that programming paradigms present. Every programming paradigm in software development is essentially a contract between a proposed method of solving computing problems on one hand, and the challenges that proposed method presents to the user on the other hand. There's no free lunch. No perfect solution to software development.

    I accept that contract. I don't question the obvious limitations of our still infant computer technology and the impact this has on our ability to make them perform tasks. But I do question certain choices:

    1) Development Tools
    Lack of imagination, a certain conformism, the tendency of software developers to become copycats, a moronic shipping culture, this and more has been leading to lack of any real useful tools for software development that can mitigate or facilitate transposing the challenges offered by programming paradigms. For pete's sake, we don't need another code highlighting editor! What on earth are these people thinking. Imagine the waste that is spending 3 or 4 years of your short life building and maintaining something that introduces nothing new into the world and that is exactly the same as hundreds of others and then pretending you are actually doing something useful for others to use.

    What we need is specialized tools. We need the sort of innovative thinking that brought us tools like TeamWare that inspired BitKeeper and paved the road to Mercurial and git. We need tools like syntax highlighting for sure, but they have been invented already. We need problem solvers. Tools that solve our current problems. Gary gave some examples in that video, like source file tracing in real time.

    2) Engineering Programming Languages
    You don't generally solve complex problems with simple tools. Complex problems require complex solutions. And unless you are working in a programming language tailored to solved complex problems, your ability to solve those problems in any other language becomes exponentially more difficult. Programming languages are being designed today as generic tools to solve a wide array of problem domains and targeting the mass market of developers; from hobbiest programmers to software engineers. What can possible go wrong with this idea?

    We need engineered computer languages for software engineers. They won't be afraid of using specialized languages for specialized problems. I'm not talking of semi-specialized languages like Prolog or R. We need to cater to industries specifically, and build domain languages that can handle their specific problems. Not "force" the NY Stock Exchange to use Python, but offer the stock exchange industry a specialized language that would make them never again consider a multi-paradigm language as an actual solution to their computing needs. Multi-paradigm and domain-generic languages can never be good solutions to complex problems without a tremendous cost in development and maintenance and all the risks associated.

    Would this spread too thin the programming language ecosystem and force software engineers and developers to increase even more their knowledge base? Not every representative of an industry would need to use these engineered languages, only those for whom their problems demand their use. But for them the solution to their problems would exist in the form of a much more correct tool for the task.

    Remember the mantra we keep on repeating that it's of no use to compare one language to another and we should instead just use the right language for the right job? Have you ever wondered that the right tool for most tasks is in fact any of the tens of languages currently available to us, and there is in fact no such distinction as the "right language for the job"? Well, that's because we haven't been building those languages that can actually make a difference.

    3) Stale culture
    Languages like Javascript really represent this primitive hunter-gatherer culture in software development that is repressing research into better solutions. A programing language, which only half of it can be used, has become a centerpiece of modern software development. A language that cannot solve any problem well, as become a language that today solves a vast array of different problems on both client and server machines. A language that should have never survived past its first year due to the unanimous criticism it received, has since become a massively used language around the world despite none of its upgrades ever solved any of the criticism.

    Javascript can't be used to create monolithic solutions or it will crumble under its own weight. And javascript can't be used as micro services or it will become impossible to maintain. And yet, you see it being developed either way by software developers who will gladly drink the Kool-Aid of the day. To be fair, for lack of other solutions.

    Javascript is just one representative of a stale culture that on one hand pretends to be all about change when Microsoft decides to make their toolbar monocromatic, or Gnome decides to make their DE work on cellphones, while ridiculing anyone who would prefer for these non essential things to stay the same. But that at the same time is completely incapable of coming up or accepting new solutions to essential tools that have become part of the establishment. Tools like javascript or the VT-100 terminal. Provenly bad, or ancient and just plain incapacitating, tools that unnecessarily complicate our lives and just delay the adoption of better solutions.

    These are the top nodes in the hierarchy of the software development ecosystem. From where all the other crap flows. And they should be replaced. But never are. And so, we are still today writing bash scripts in a verbose cryptic language, limiting a terminal window to 256 colors in the 21st century and incapable of rendering even vector images that pseudo-terminal systems like arcade machines and early consoles where doing in the 70s, or... doing whatever horrible nonsense you people do on javascript each day and that no one really needs to enjoy a modern web.
    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.

  10. #25
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Mario, you've given me so much to think about!

    Embedded domain specific languages. You mention creating languages that exist to solve one problem and one problem well. Well, that's only realistically feasible if we design a language that allows you write your own language in it. This is possible in many different languages but the overarching paradigm of the language itself can't help but bleed into the design of EDSL and this is oftentimes not a good thing. At all. But a language that helps you write EDSLs would be what you want. A language that allows you to fix it as you see fit.

    I must come clean though, Mario. I'm slightly hypocritical. I agree with you but my meshing is nothing new. It's been solved before. The real goal is to just solve it faster now. But it's incredibly fun. And rewarding. Learning CUDA was one of the best things I've ever done and it's because it really shaped how I thought about programming in general. Parallelizing algorithms does not create a brand new algorithm, it just creates one that solves it faster. But, man, is it fun.

    So there's value in re-implementing current technology. But there's a point of diminishing returns and I can sense that you feel like we're approaching that point. That's fair enough. I wish I was clever enough I could play a part in it but eh, I'm just gonna play with triangles.

    Edit:

    I laughed when I found out that the editor was a lie. I was so excited for a second too. I was like, "Oh man, I am so downloading this once this video is over." Talk about heartbreak. Someone should still implement something like that.

  11. #26
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    Quote Originally Posted by Mario F. View Post
    I couldn't find it either. I watched it a long time ago and turns out I only thought I knew its title. It's called "A(n) Whole New World": A Whole New World —
    Destroy All Software Talks


    I dunno, I disagree with quite a bit of this. Sure, there are some cool ideas there, but I think he's as guilty as anyone of doing exactly what he preaches against. Making this hypothetical editor a terminal rather than an IDE is a choice that would seem to be driven more by doing things 'the way he always does it' rather than because it's the right tool for the job. I think it's a great example of the very legacy burden he wants to get rid of.

    Some of his ideas are interesting, but many of them are already commonplace in modern IDEs (support for diff visualization, dependency mapping, etc.) and some of this seems like he's pushing for niche features at the expense of day-to-day. For example, although I can get a dependency map in my IDE with a few clicks, the number of times I really have a need for one is trivially small compared to the number of times I have a need for a breakpoint in a debugger. I can't imagine using a tool that made dependency mapping slightly easier at the expense of not having an integrated debugger.

    The error overlay is a genuinely cool concept. I think the even better focus is on tools to help proactively avoid errors versus making them easier to troubleshoot later, but since the latter will never catch everything for everybody, there will always need to be recourse to the former.

    On shipping, I think there's often too little emphasis on it. Sure, some people push shoddy stuff out the door, but I see more projects get mired down in development hell, scope creep, or woefully overarchitected solutions (inner platform effect, etc.) because people weren't given the right level of constraints. Having target ship dates that it is expected you must meet can, in my experience, often lead to better code, not worse. Clearly there is a balance to be struck, and in the face of some kinds of issues shipping dates genuinely should be delayed, but I think not shipping fast enough is at least as common as shipping things too fast.

    And, of course, you're designing a product for people to meet a need. Every day you go without shipping your product is one day when that need is not being met by you. It might also mean the need becomes met by a competitor first.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  12. #27
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    He doesn't care one bit about the editor, Cat. That's just his analogy for a different type of terminal, which is what he is actually arguing for. The editor just represents one possible type of application if we where to once and for all get move away from the VT-100 standard. If you watch his screencasts (unfortunately they come with a price tag), you'll see he is as much a GUI person as you and me, with the terminal being our goto solution for more complex administration tasks.

    I agree that shipping is a complex subject. But I disagree that the industry isn't being heavily influenced by Seth's ideology. You seem to believe things are more balanced. But what I see is an alarmingly growing tendency of both the commercial and open source industries to pre-ship their products and fix the errors after launch. We've come to accept bugs and incomplete features as a normal part of production software. This in itself isn't wrong. They indeed are a normal part of production status software. But most definitely not at the present scale.

    I also agree that certain markets may change the rules. In particular competitive markets. But the notion is widespread across the whole industry, not just those serving specific markets, and we even come to accept Continuous Integration as a fine practice for projects that don't or shouldn't really benefit from it. We are effectively merging the release and master branches. For what benefit, I don't know. All I see in any projects that implement CI is bug creeping, as rarely a CI project will implement proper testing (because integration tests are difficult and not for everyone, despite CI being easy to implement and for anyone).

    Meanwhile there is a whole lot to be said about competitive markets, and how "competitive" they really are. In particular among the Open Source community, where a whole lot of damage is being done to FOSS code quality. I'm certainly not a shipping minimalist. Despite my speech so far probably indicating that's where I stand, it is not. I'm just calling out against the maximalist side and have yet to present what I consider a more levelled approach. I certainly am opposed to over-engineering or the idea of near-perfect releases. But there is no doubt in my mind, that for the largest part of the commercial and open source industries serving consumer-grade software, competition isn't a business driving factor and we could all have benefited from better tested software without gaining a feeling of loss because the next version took 12 more months to ship. Often, the aggravation of bugged software and incomplete features that no one can use effectively and end up just bloating the software for the next two or three versions is what drives people insane. Not the fact they couldn't do something and need to wait some more time before they can.
    Last edited by Mario F.; 06-17-2016 at 09:01 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.

  13. #28
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by laserlight View Post
    But Javascript does have built-in support for object oriented programming, just that it does so without explicit classes via its odd but nonetheless valid prototype approach.
    Yes, Javascript was inspired by (read: ripped off ideas from) Self, which is a pure "object oriented" programming language.

    Languages such as Self and Smalltalk were invented before other languages such as C++ and Java, etc., decided to enforce the "class-based" approach to organizing objects. However, using the class based approach vs. the prototype approach has, like any other design decision, its advantages and disadvantages. Of course, its beyond the scope of this thread to go into a full discussion of these, but suffice to say that the prototype based object approach is not wrong and the class-based approach is not right. Either can be used to express the same ideas.. "Expressiveness" and "verbosity" are subjective terms, after all.

  14. #29
    Registered User
    Join Date
    Jun 2016
    Location
    London
    Posts
    5
    What I don't like about JS is that it snippets, once appended onto web pages execute on client servers immediately and therefore can also be used to exploit the user's system. While a certain restriction is set by modern web standards on browsers, malicious code can still be executed complying with the restrictions set.

  15. #30
    Registered User MacNilly's Avatar
    Join Date
    Oct 2005
    Location
    CA, USA
    Posts
    466
    Quote Originally Posted by Elysia View Post
    It may be valid, but it's at odds with how every other language does it. Frankly, in my humble opinion, I don't like it.
    This is false and a very bad reason, taken alone, for anyone to dislike Javascript.

    What does "every other language" entail? The typical programmer's bread-and-butter language such as C++, Java, which enforce a class-based object hierarchy?

    The only reason why an enforced "class-based" approach might be better is because more programmers have been indoctrinated to this way of thinking and therefore can be more productive in the workplace. This fact, however, cannot be used as a reason to say its "at odds with every other programming language."

    That said, I do think Javascript mostly sucks.. just as I think most programming languages suck.. try googling "why <programming language X> sucks" for example. You'll find a lot of weird ........ that just makes no sense embedded in Javascript's design.. In fact, I would venture to say that a language's suckiness is directly proportional to the number of people who use it. Of course, however, as a member of this board, I reserve a special place for C (and NOT C++) as the simplest language that models current hardware.
    Last edited by MacNilly; 07-06-2016 at 04:27 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