Hot answers tagged

70

1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is. At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular: if two tasks try to access a variable ...


15

Just guessing here to demonstrate a problem in your approach. I can't test it against the real implementation as there is no link anywhere... I'd say it is because invariants are not always expressed by the value of one variable, and 'one variable' is not sufficient to be the scope of a lock in the general case. For example, imagine we have an invariant ...


14

A decade or so ago Brendan Eich (the inventor of JavaScript) wrote an essay called Threads Suck, which is definitely one of the few canonical documents of JavaScript's design mythology. Whether it is correct is another question, but I think it had a big influence on how the JavaScript community thinks about concurrency.


12

This seems like a very bad idea to me. defining css rules for classes and adding those classes to the html is a great way to make your css reusable. The way you're suggesting, with a complex selectors, sounds like a recipe for mangled stylesheets. Sure, your html is clean as a whistle, but now the css is a pain in the butt to maintain. Consider: ...


9

Atomic access does not translate into thread-safe behavior. One example is when a global data structure needs to be invalid during an update like rehashing a hashmap (when adding a property to an object for example) or sorting a global array. During that time you cannot allow any other thread to access the variable. This basically means that you need to ...


6

Is your approach going to significantly improve performance? Doubtful. You really need to prove this. Is your approach going to make it easier/faster to write code? Definitely not, multithreaded code is many times harder to get right than single threaded code. Is your approach going to be more robust? Deadlocks, race conditions etc. are a nightmare to ...


6

On languages such as Haskell, most datatypes have instances which allow their values to be used as keys of structures such as Maps. It's the same in ECMAScript. Any object, including primitives, can be used as the key in a Map. Even NaN, even though NaN !== NaN // true does the right thing and can be reasonably used as the key in a Map. JavaScript ...


5

I think I would want my function to be more relevant to the actual job/data being processed rather than a generic sounding shouldDeselect(). That doesn't tell you anything really. Maybe something more inclusive of why deselection is flagged? As an example: if(martians_have_landed()) { cancel_all_shore_leave(); } How we discover if martians have ...


5

If one makes a change to an application which will cause a three weeks manual test cycle, the person or the team is not "always done", not even close. If that is your situation, then it should be obvious that keeping the change locally is clearly the better option. However, if you have an automatic test suite at hand with a high test coverage, which can do ...


4

If by compiler error, you mean syntax errors then yes they are. Console also gives the runtime error as for example, when trying to access an undefined property of some object at the runtime. JavaScript is an interpreted language so we cannot call them compiler errors but instead parsing errors. Browser console shows us the following: Syntax errors at ...


4

*sigh*... This is why immutable needs to be the default. Even the referenced Java answer suggests this. Note that that answer does not recommend removing final modifiers, just that the author of that answer wouldn't add them in new code (for local variables) because they "clutter up" the code. However, there is a difference between JavaScript and Java ...


4

I think the operations you're doing are variations of SQL joins, because in most cases you're taking tuples of data, picking a kind of value from each one to associate, and returning the combination(s) that could be linked. I'd suggest you look into the jargon, algorithms, and research-papers of RDBMs systems as your first place to mine for more ...


4

Your proof that you will always reach a previously used 'i' appears to imply that your mapping function is topologically mixing. This in turn suggests that your function is probably chaotic. If it is chaotic, then by definition there is no faster way of producing the result than iterating your mapping function. Looking at it less rigorously, the modulus ...


3

What you really want is a Map, not an object: Map You need to check if the support you need to provide fits with the Map supported browsers, but that´s what you really want as objects only take strings or symbols as keys while a map can take anything Here is an example of its usage: var point1 = {"x": 7, "y": 8, "z": 9}; var point2 = {"x": 6, "y": 5, ...


3

Since it took Java a decade to go from having everything necessary to cleanly support it (i.e. since Java 5) to adding it; C# still hasn't added it to the standard library though it's been able to for about as long; and the idea has been in common use in (statically typed) functional languages since, at least, the '70s, I would actually say JavaScript is ...


2

You're probably looking for "Syntax error". The linked Wikipedia article says about this: For compiled languages syntax errors occur strictly at compile-time. A program will not compile until all syntax errors are corrected. For interpreted languages, however, not all syntax errors can be reliably detected until run-time, and it is not necessarily ...


2

Your implementation is not just about introducing concurrency, rather its about introducing a specific way to implement concurrency i.e concurrency by shared mutable state. Over the course of history people have used this type of concurrency and this has lead to many kinds of problems. Ofcourse you can create simple programs that works perfectly with using ...


2

As shouldDeselect() doesn't carry out the deselect action itself it can be named checkDeselect(), which I would find more clear (and consider a more common naming pattern), and I would even add what to check, e. g. checkDeselectUsers(). But as DavidArno already mentioned this is as opinion-based as many naming decisions, and I expect the opinion police to ...


2

To a certain extent, it's purely a matter of opinion. Both approaches will have their fans and neither is inherently wrong, save for under one circumstance. If the test/action code isn't atomic, then that approach should not be used, ie: if(shouldDeselect()) { // could a call to shouldDeselect() ever return false here? deselect(); } So for ...


2

This is the case for most new features and need time to be adapted and integrated. If you plan to work with multiple browsers then until it is matured I would say no as it would just be increased maintenance, however if you are in a position where you can choose what browsers your clients need to run on then by all means make the best of it and hopefully ...


2

In JavaScript, functions are just objects. As such, there is no particular reason not to pass them around as parts of other objects. In fact, may JavaScript libraries do this, for instance, letting you pass in an object containing a success and an error callback. As a way of doing OOP in JavaScript, that's a perfectly reasonable way of doing things, and ...


2

By wrapping the whole thing in an IIFE, you can create private variables and functions. This way, the exposed API can wrap the private functions any which way, and persist would only be called when using the public delete: var obj; (function() { function realDelete(id) { delete obj.users[id]; //maybe some other code (ui manipulation) ...


2

Why is this not done by default? For some reason, it wasn't done in the earliest versions of the language we now know as Javascript. Unfortunately, changing it now would break tons of existing code, so we're stuck with it. Why not make this an "opt-in breakage" like strict mode? Probably because strict mode is focused on a small set of the most ...


1

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL. That is a legitimate concern. Using JSP's also ...


1

This is needed. The lack of a low level concurrency mechanism in node js limits it's applications in fields such as math and bioinformatics, etc... Besides, concurrency with threads doesn't necessarily conflict with the default concurency model used in node. There are well known semantics for threading in an environment with a main event loop, such as ui ...


1

This is not an anti-pattern. This is a code smell, which is to say that this is the sort of thing you should avoid when it's feasible to do so, but there may be legitimate cases where nothing else does the job. I thought the Promise.all should fail fast. Yup. This is exactly why the default behavior of Promise.all is to fail fast. The rationale ...


1

If you have no additional requirements besides what you mentioned in your question, this is perfectly fine. See KISS and YAGNI. You should only consider doing something more complicated right now if you know you're going to need something like internationalization, since deciding on a satisfactory getCorrectStringForCurrentLanguage() mechanism and porting ...


1

By "separate execution context" the doc means in particular that this will be different in all likelihood. In the browser, JavaScript code of one page is always executed in a single thread. Only JavaScript that is run in a separate worker or page can run in parallel. One reason for this is that JavaScript has direct access to the DOM and getting that to ...


1

No, it doesn't. "Execution context" doesn't mean "thread", and until recently Javascript had no support for anything resembling threads. What actually happens is that an event is pushed onto the event queue that's set to execute in the number of milliseconds specified by the second argument to SetTimeout/SetInterval. The consequence of this is that if you ...


1

But does this mean it executes in parallel to any other code that is currently in process? No, it does not mean that. It will just execute later, when the given time has passed. Javascript fundamentally does not support multithreading because there are no language facilities to prevent data corruption from simultaneous access nor for having isolated ...



Only top voted, non community-wiki answers of a minimum length are eligible