4 ms·

I am sort of arriving towards the conclusion that an SICP is not possible for the web dev space. Web development is dominated by moving targets, moving industry

I am sort of arriving towards the conclusion that an SICP is not possible for the web dev space. Web development is dominated by moving targets, moving industry standards, and not-well-thought-out libraries/ patterns etc.. There is clearly no agreement on what counts as the core of web dev (in contrast - what counts as the core of programming, which is the purview of SICP, is generally easy to define).

runarberg 5y ago
I think it is deeper then that. Web development has a pretty clear distinction between front and back end, where the values and design goals of each is vastly different. SICP would it self teach you valuable lessons for the back end while only be marginally beneficial to a subset of front-end programming. In fact, in my experience (and this might be a hot take), the front end suffers from back end programmers taking their lessons to the front end where they don’t apply, and may even be considered harmful [fn-1]. This might in fact be the core reason for your stated “not-well-thought-out libraries/patterns” on the front end. As a front end developer my self I’d argue that the front end has a core by it self which is independent—and sometimes even incompatible—with the core of programming. On the front end your user is such an unknown while still being your most important target. General programming doesn’t have this, where your user is most often just you at a later time, and maintainability is often the most important goal. Then there is the living standards a front end developer must design around. A general programmer has a definite compiler (or an interpreter) they can write for. A front end developer should be aware which technology they can use given their audience’s clients. A front end stack that targets an audience with modern clients will be structured a lot differently then for audience that might have legacy clients. If you suspect your audience might use legacy clients, you have to accommodate that by adding different tools and techniques to your code base. I don’t think SICP—and other literature for generic programming—provides any insight into this. (and why should they?) --- fn-1: I’m not gonna go as far as stating that SCIP considered harmful for front end developers. I don’t think that is true.
- quickthrower2 5y ago
  Do you think there is any commonality between web front end and desktop programming or native app programming that could be captured in a general way in a SICP type book. I think React, MVVM, “rx” style and what might be called “stateful components” might be the common patterns to talk about across all front ends.
- pull_my_finger 5y ago
  > A front end developer should be aware which technology they can use given their audience’s clients. A front end stack that targets an audience with modern clients will be structured a lot differently then for audience that might have legacy clients. If you suspect your audience might use legacy clients, you have to accommodate that by adding different tools and techniques to your code base. If everyone wrote standards compliant code then the browser vendors and would be forced to update, and the web would be a more coherent place. Browsers that don't stay up-to-date would (rightfully) become quantifiably inferior products and people would likely stop using them if they couldn't render pages (their intended purpose). It's ridiculous that we have to keep compiling code to old standards so big corporate can save a few bucks not upgrading their computers and work stations.

runarberg 5y ago

I think it is deeper then that. Web development has a pretty clear distinction between front and back end, where the values and design goals of each is vastly different. SICP would it self teach you valuable lessons for the back end while only be marginally beneficial to a subset of front-end programming. In fact, in my experience (and this might be a hot take), the front end suffers from back end programmers taking their lessons to the front end where they don’t apply, and may even be considered harmful [fn-1]. This might in fact be the core reason for your stated “not-well-thought-out libraries/patterns” on the front end. As a front end developer my self I’d argue that the front end has a core by it self which is independent—and sometimes even incompatible—with the core of programming. On the front end your user is such an unknown while still being your most important target. General programming doesn’t have this, where your user is most often just you at a later time, and maintainability is often the most important goal. Then there is the living standards a front end developer must design around. A general programmer has a definite compiler (or an interpreter) they can write for. A front end developer should be aware which technology they can use given their audience’s clients. A front end stack that targets an audience with modern clients will be structured a lot differently then for audience that might have legacy clients. If you suspect your audience might use legacy clients, you have to accommodate that by adding different tools and techniques to your code base. I don’t think SICP—and other literature for generic programming—provides any insight into this. (and why should they?) --- fn-1: I’m not gonna go as far as stating that SCIP considered harmful for front end developers. I don’t think that is true.

quickthrower2 5y ago
Do you think there is any commonality between web front end and desktop programming or native app programming that could be captured in a general way in a SICP type book. I think React, MVVM, “rx” style and what might be called “stateful components” might be the common patterns to talk about across all front ends.
pull_my_finger 5y ago
> A front end developer should be aware which technology they can use given their audience’s clients. A front end stack that targets an audience with modern clients will be structured a lot differently then for audience that might have legacy clients. If you suspect your audience might use legacy clients, you have to accommodate that by adding different tools and techniques to your code base. If everyone wrote standards compliant code then the browser vendors and would be forced to update, and the web would be a more coherent place. Browsers that don't stay up-to-date would (rightfully) become quantifiably inferior products and people would likely stop using them if they couldn't render pages (their intended purpose). It's ridiculous that we have to keep compiling code to old standards so big corporate can save a few bucks not upgrading their computers and work stations.