• bvs23bkv33 (unregistered)

    Vaalidator typo

  • Quite (unregistered) in reply to bvs23bkv33

    You did that wrong, you should have entered "Friist".

  • Ulysses (unregistered) in reply to bvs23bkv33

    Is it really a typo or a poke at sheeple coding? :-D

  • Sally Flynn (unregistered)

    I feel like the code's not WTF-y enough yet...

    safetyLockValidator = function (input, target) {
        return new Promise(function (resolve, reject) {
                return !(input !== target) === true ? resolve() : reject('Wrong code')
        })
}

    That's better! :D

  • Noodles (unregistered)

    What do mean JavaScript "started life as a badly designed language, often delivering badly conceived features". It's STILL a badly designed language full of badly conceived features.

  • JS Dude (unregistered)

    safetyLockValidator = (input, target) => new Promise( (resolve, reject) => !(input !== target) === true ? resolve() : reject('Wrong code') )

    Use Arrow functions they say...

  • (nodebb) in reply to Noodles

    I think the point is that it was always like that, rather than acquiring those faults with the passage of time.

  • RFOMI (unregistered)

    I have seen the Promise Land.

  • Oliver Jones (google)

    I have been to the mountain, and I have seen the Promise land. I may not get there with you ...

  • my name is missing (unregistered)

    I promise to have safety and equality.

  • ========= (unregistered)

    At least they used === instead of == as == can throw an exception if an object can not be converted... Only to reject with a string instead of an Error.

  • ZB (unregistered)

    I see Remy is one of those knuckleheads who conflates JavaScript the language with the dreadful browser DOM it initially had to deal with.

    No, you wouldn't write an operating system in JavaScript, but for what it was designed for, it's a remarkably powerful little language. Sure it has some warts and pitfalls, but every language of any consequence does.

  • siciac (unregistered)

    I see Remy is one of those knuckleheads who conflates JavaScript the language with the dreadful browser DOM it initially had to deal with.

    Right, it was the DOM that caused Javascript to have an unusable == operator, unusable iterators, incredibly dangerous eval, kludgerific rules for "this", stupid scoping rules, stupid magical semicolons, inscrutable prototype based inheritance, user-visible boxing of primitives in a dynamic language, etc.

    Of the basic language constructs that aren't deprecated or don't have serious caveats, there's a pretty nice language in there. (I don't use CoffeeScript, but it demonstrates that point pretty well.) It's not the dumpster fire of PHP, but it is, fundamentally, a science project that took off.

  • siciac (unregistered)

    Sure it has some warts and pitfalls, but every language of any consequence does.

    That's simply not true. Plenty of major languages don't have basic constructs that are fundamentally broken. Most successful languages don't have problems comparing values or iterating over a list of things. You've become conditioned to working with garbage, you're like a carpenter who just assumes blunt tools are the norm and that it requires a heroic effort to make things come out square.

  • Sole Purpose of Visit (unregistered) in reply to siciac

    And before any JS-head (or for that matter, PHP-head) comes out with the sentiment that "it's a poor workman who blames his tools ..." that is precisely the point.

    A good workman tends to his tools. A good workman sharpens his tools. A good workman improves his tools. A good workman abandons tools when they become dangerous, and replaces them with better tools.

    We're stuck with ECMAScript 5/6/7, because "worse is better," and you don't write in a language that isn't supported by 99% of target platforms. But the least that a decent development organisation could do is to work on a more coherent language and then transpile the result. Otherwise we're going to be stuck with fragments of broken "just about works" unmaintainable crap like this forever.

  • Sole Purpose of Visit (unregistered)

    The interesting thing about the "incredibly dangerous eval," as Siciac mentioned above, is that Java Applets were originally expected to be the choice for dynamic programming on web pages. Complete with four levels of security, sandboxes, etc etc. This didn't last long (I think it began to erode after the release of Netscape 4), because -- and the careful security layers had a lot to do with this -- using the stupid things was just too damn clunky and expensive for consumption over a 19.2K modem. I would guess that nobody at Sun recognised this fact, because they were all on a decent ethernet LAN during testing and deployment.

    Consequently, we are stuck with a language developed in two weeks or so that is a magnificent example of how to build sandcastles on top of a pot-pourri of whatever functional language paradigms du jour occurred to Brendan during said caffeine-fuelled fortnight. Unsurprisingly, you get a combination of incoherence and insecurity ... which, luckily, was exactly what the market demanded at the time. May I take a step further? No? Well, I'm going to, anyway. Postel's nitwit notion that you should be "liberal in what you accept, but conservative in what you emit," is utter bollocks when it comes to network security of any kind.

    In one of the major malapropisms of the Internet Age, this is now known as the "Robustness Principle."

    It is nothing of the sort. It is simply a flag of convenience for those who will defend unadulterated Javascript by under-educated ninny ad hominem attacks on people like Remy, who has been around long enough to know better.

  • Decius (unregistered)

    All programming languages that are Turing-Complete, and not any more powerful, are equally good.

    Some programming languages are harder for humans to learn to be good in.

  • (nodebb)

    I always thought that the problem with Javascript was that it had the name "Java" in for no real good reason.

  • Sole Purpose of Visit (unregistered) in reply to Decius

    What an interesting concept. Do please share your definition for "any more powerful." I don't suppose that "the ability to reason clearly, quickly, and safely" comes into it.

    Solving the halting problem, perhaps?

  • Jesse Slicer (google)

    Obligatory: https://devnull-as-a-service.com/

  • PenguinF (unregistered) in reply to Sole Purpose of Visit

    I'm sure he only wanted to cover all the cases in the domain, like true software developers tend to do. And so include any potential programming languages which are as Turing-übercomplete as they are inconceivable. Not that any human could wield that kind of power successfully, but yeah.

  • Decius (unregistered) in reply to Sole Purpose of Visit

    Turing Finite State Machines don't have the ability to reason at all.

    And yes, a more powerful computational process would be one that could behave differently (in calculable time) if an arbitrary Turing machine halted.

    Current commercially available hardware is incompatible with anything more powerful that Turing.

  • David (unregistered) in reply to Decius

    I fail to see how a Turing tar pit is as good as a real programming language, if by good we mean anything resembling the way good is normally used. A good tool minimizes the work and danger behind doing a job. Languages like Intercal or Minimal BASIC makes for more work and makes it more likely the program will contain nasty bugs. That makes them bad tools.

  • foxyshadis (unregistered) in reply to Sole Purpose of Visit

    There was a bigger problem with Java applets: Enormous memory requirements, and strong tendency to crash even when they didn't run out of memory. (Partly because early interpreters were bad, especially the first version of HotSpot, and partly because Java was so new that no one knew wtf they were doing.) The same people who were hacking together HTML with missing or interleaved close tags and the idea that desktops should be set to a specific resolution to properly view a site were now being let loose on this brave new world of compiled software hosted in the browser, without having to get the user to trust you enough to install a C plugin first.

    I was so glad when they died an ignominious death, especially as the once-secure plugin had become one of the largest breach vectors of all. Then I found out enterprises still had their love affair with it, and had to support it up until just a few years ago, security holes and all.

  • (nodebb) in reply to Noodles

    The point is "started [em]life[/em]". JavaScript is something undead by now.

    (Unless it was undead since its very beginning.)

  • Another Anon (unregistered)

    1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.

  • code_goddess (unregistered)

    Would it really be called EaaS or would it be called =aaS?

  • Patric (unregistered)

    You're ful lof shit, JavaScript is the best language.

  • Sprinkly Bits (unregistered) in reply to Noodles

    Disagree completely, @Noodles - JavaScript is definitely a massively misunderstood language, but not a badly designed one, its all those curly braces that are confusing you: JavaScript is a pretty well designed flavor of LISP.

    Don't believe me? Ask Brendan Eich. The rest are just mediocre programmers and newbs thinking it's a weird Java version where everything is a Hashmap making a mess of things. Oh, and helped by a lot of good intentions to pave the way (I'm looking at you, npm)

  • isthisunique (unregistered)

    I see this a lot with academic coders. However an innocent explanation would be if this is for form validation where some rule are instant and some are asyncronous. Even then this isn't the best solution to the problem. The only things that should be asyncronous are the things that need to be in an asyncronous language.

    but not a badly designed one

    It was originally meant to be extremely minimal and light weight but also simple, for browsers. In a way, due to that it was depending how you look at it badly designed from the start or rather wasn't designed much at all because it was simple and minimal. Then despite being a functional language someone from marketing decided it had to be like Java so it then had a bunch of weird OO features lumped in while still remaining minimal. To add insult to injury bits have been lumped on here and there plus actual implementations in browsers have been skewed. The number of odd things in JS is phenomena but on the other hand it does tend to do very well as an async language.

  • Dr. λ the Creator of Variables, Binder of Variables, Applicator of Terms and β-Converter of Redexes (unregistered)

    I AM ALL FOR EQUALITY BUT THIS IS TAKING THINGS TOO FAR

Leave a comment on “Promising Equality”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article