5 ms·
It probably does apply to all languages, but I prefer to speak from experience, which in my case is mostly JS. Architecture and the related abstraction is defin
by gbuk2013 7y ago
It probably does apply to all languages, but I prefer to speak from experience, which in my case is mostly JS. Architecture and the related abstraction is definitely the hardest thing about programming in my experience, and what really separates good programmers from the bad.
Loose types, pass by reference, near-limitless mutability, scoping rules (without “use strict” to save the day) and asynchronous nature of the things it is used for are some of the things that come to mind with JS.
All of these are actually very powerful features that make it into the language I love, but care is definitely needed. ;)
- chrismorgan 7y agoYeah, I really wouldn’t link it in any way to the language. It’s just mostly more obvious when it’s in JavaScript, because that’s associated with the user agent having to fetch the code and run it from scratch every time, and as a user you can more easily inspect where the time is going, compared with an app or backend processes, which are both much more opaque to the user. It’s more about architecture and discipline, and far, far more about simply caring about performance. (And larger teams make it much harder to care about performance.) For personal background in my firm agreement with capableweb, I work primarily in JavaScript professionally, tend to use Rust privately, and have used a variety of other languages and worked with both good and bad code bases (mostly good); and I care very much about performance.
- gbuk2013 7y agoDon’t get me wrong, I actually love Javascript. I have written code in quite a few languages but JS is the one I am most productive and happy in by far (within the area of network services and web apps that I work in). It has also been very profitable. :) But the language has such a low threshold that it allows for incredible productivity while writing shitty code. But by the time you realise just what you have done (or someone else realised when they have to work on your codebase) its too late and it’s time for a rewrite. What makes JS special is how accessible it is and just how much mess you can make before reality bites. That said, I will take a Javascript mud-ball over an enterprise Java one any time! ;)
- littlestymaar 7y ago> Loose types, pass by reference, near-limitless mutability This sounds like almost every programming language which is not a functional one actually (it even fits C!).
- gbuk2013 7y agoIt is true that C is capable of those thing by virtue of being capable of everything, including writing a functional Javascript engine. But you have a choice. You can have strict typing in C, you can pass structs by value and most C programs work in a synchronous manner. (I actually mentored a good C programmer to teach him JS for working on our team and asynchronous code was the thing he had most difficulty wrapping his brain around.) With Javascript you cannot have strict types and you cannot pass objects by value and asynchronous programming is the norm. C is also a lot less forgiving so it takes more skill to even be able to create a mud-ball of a reasonable size. ;) In my limited experience, functional programming languages just move a significant amount of difficulty up-front to the code. Perhaps it makes for less difficulty in architecture - I never suck around for long enough to find out. The difficulty threshold is enough to keep out lesser programmers, which certainly helps code quality. The price is that far fewer people use the language.
- filleduchaos 7y ago> pass by reference I'm not quite sure why so many people think JS is pass by reference. Everything in JS is passed by value. In fact, unlike some other languages (Swift, C++, etc), the only thing you _can_ do is pass by value. That some of those values are actually references doesn't really have anything to do with evaluation strategy.
- gbuk2013 7y agoSimple types are by value, objects are only by reference - feel free to verify in your friendly local debug console. More than that, assignment of an object is also only by reference which is super useful and great potential for spaghetti code at the same time. How it is implemented under the hood I could not care less because it is not exposed to me as a programmer (unlike in C).
- bryanrasmussen 7y agono - I believe the parent comment is right it's passed by the value of a reference as seen here from the console var changeref = function(ref) { ref = {}} var changeable = {prop: "something"} changeref(changeable); changeable; Object { prop: "something" } var changeprop = function(ref) {ref.prop = "anything"} changeprop(changeable); changeable; Object { prop: "anything" } the use of changeref does not turn ref into an empty object, because you passed the value of the reference, but the use of changeprop did change the property of the object because you are changing the prop on the reference. at least this is my understanding of how it works. Interestingly enough I totally blew a simple programming test on the phone recently because I forgot about this (well my whole mind went blank and I couldn't do anything so even if I had remembered this it wouldn't have been enough - it was lucky I remembered my name) on edit: console used, Firefox developer.
- filleduchaos 7y agoYes, precisely. In a language that supported call by reference, your `changeref` function would actually cause `changeable` to point to an empty object/map (assuming, of course, it had been passed by reference).