Computer Science and why it's necessary even for web developers
I know that in some countries a degree in CS is expensive or unattainable, and that some companies do unnecessary algorithm interviews.
This thread is not about degrees or interviews, it's about CS itself.
I know that in some countries a degree in CS is expensive or unattainable, and that some companies do unnecessary algorithm interviews.
This thread is not about degrees or interviews, it's about CS itself.
CS is important because of general concepts and patterns that you will find everywhere when programming.
It's vital to have some knowledge which is *indirectly* applied.
E.g. trees, graphs, data structures, graph search (breadth-first, depth-first), languages
It's vital to have some knowledge which is *indirectly* applied.
E.g. trees, graphs, data structures, graph search (breadth-first, depth-first), languages
Data structures are ways of organizing data, e.g. in JavaScript:
- Array
- Object
- Set
- Map
- Array
- Object
- Set
- Map
Some data structures are "trees". 🌳 You can find them everywhere:
- Simple directories in the file system
- JSON is a tree
- HTML is a tree
- DOM is a tree
Some data structures are "graphs" 🔗:
- JS Objects (can have circular refs)
- GraphQL ( graphql.org/learn/thinking… )
- Simple directories in the file system
- JSON is a tree
- HTML is a tree
- DOM is a tree
Some data structures are "graphs" 🔗:
- JS Objects (can have circular refs)
- GraphQL ( graphql.org/learn/thinking… )
It's not enough to just organize data, we also need to read and update data inside these structures:
- Array has push/pop
- Object has get/set through [ ] brackets
- DOM has appendChild etc
- GraphQL has mutations
- Array has push/pop
- Object has get/set through [ ] brackets
- DOM has appendChild etc
- GraphQL has mutations
Even though there are many data structures, certain read/update patterns are common because many of these can be classified as trees or graphs or lists.
It's great if you can learn strategies for trees so you once you know how handle JSON, you can handle the DOM, both are trees.
It's great if you can learn strategies for trees so you once you know how handle JSON, you can handle the DOM, both are trees.
Hey, that's actually the Virtual DOM! A tree-structured JS object representing the desired tree-structured DOM 
Sometimes you will need to do advanced search on these data structures.
npm install does an advanced graph search, while creating a *tree* (package-lock.json). Usually if some processing takes a lot of time (npm i), creating a temporary data structure (package-lock) helps.
npm install does an advanced graph search, while creating a *tree* (package-lock.json). Usually if some processing takes a lot of time (npm i), creating a temporary data structure (package-lock) helps.
Every tree is a simpler type of graph, so that's why processing package-lock.json is faster than processing the dependency graph from zero.
Computation can be light/heavy in two basic dimensions: time spent versus storage spent. There's a whole subfield dedicated to heaviness.
Computation can be light/heavy in two basic dimensions: time spent versus storage spent. There's a whole subfield dedicated to heaviness.
But graph search methods are usually simpler, and are one of these two:
- Depth-first (prioritize going deep)
- Breadth-first (prioritize going evenly through all children)
Maybe you've found a bug once where one of these modes was the wrong choice for the use case.
- Depth-first (prioritize going deep)
- Breadth-first (prioritize going evenly through all children)
Maybe you've found a bug once where one of these modes was the wrong choice for the use case.
For instance, even if there are no explicit graph data structures in this #RxJS topic on schedulers, often people get a bug because the default scheduler is depth-first, and they could choose a breadth-first scheduler:
github.com/ReactiveX/rxjs…
github.com/ReactiveX/rxjs…
Or maybe once you tried to parse some HTML with regex.
With some knowledge of formal languages, syntactical analysis, grammars, and compilers you could save hours of regex attempts by knowing that it's mathematically impossible to parse HTML with regex.
With some knowledge of formal languages, syntactical analysis, grammars, and compilers you could save hours of regex attempts by knowing that it's mathematically impossible to parse HTML with regex.
All of this is big picture knowledge that will be useful forever, no matter what's the hot framework or library of the year.
I don't want anyone to feel pressured to get a degree, I just want to encourage reading on Wikipedia basic CS concepts.
Have a nice week! 💾
I don't want anyone to feel pressured to get a degree, I just want to encourage reading on Wikipedia basic CS concepts.
Have a nice week! 💾
Oh more juicy examples:
Ever built an array B based on another array A?
const B = []
for (let x of A)
B.push(`${x} €`)
That's a "map" operation:
B = A.map(x => `${x} €`)
Ever built an array B based on another array A?
const B = []
for (let x of A)
B.push(`${x} €`)
That's a "map" operation:
B = A.map(x => `${x} €`)
Ever used an if inside a for loop?
const B = []
for (let x of A)
if (x < 100)
B.push(x)
That's a "filter" operation:
B = A.filter(x => x < 100)
const B = []
for (let x of A)
if (x < 100)
B.push(x)
That's a "filter" operation:
B = A.filter(x => x < 100)
What if you would create a DSL (a language) that allows you to pick data from a database using Map and Filter etc?
- SELECT == map
- WHERE == filter
Oh cool that's half way to recreating SQL
It's rooted in relational algebra.
- SELECT == map
- WHERE == filter
Oh cool that's half way to recreating SQL
It's rooted in relational algebra.
Pretty much anywhere you look in programming, you'll find reusable patterns for information processing. Those patterns are Computer Science.
