Idk, other than using `await` at the same time as `then` and the unnecessary `map` , the first version is 100x more readable. The code you wrote has almost no complicated behavior, adding all these unnecessary abstractions / single use functions just makes it more difficult to reason about. If you undo those 2 weird choices from the first version then it needs no abstractions, everything can be understood from a single glance: ```js import { readFile } from "fs/promises"; async function main() { const file = await readFile("./contacts.csv", "utf-8"); const contacts = file.split(" ").slice(1); for (const contact of contacts) { const [name, age, occupation, city] = contact.split(","); console.log(`${name} is ${age}. They work as a ${occupation} and live in ${city}.`); } } ``` Premature and single use abstractions do more harm than good. If you're hell-bent on doing abstraction gymnastics then at least do something clever like functional programming to make them ergonomic and reusable.
This topic is where you can determine the quality of a developer. I've had a lot of projects in which i needed to analyse 40 year old code and complex processes. Some guy might think it elegant to just throw 5 pointers around and somehow, by magic i guess, a string pops out with incredibly important data. Where does it come from? What does it mean? Even if people laugh at me, i always program as simple as possible. Banging rocks together is better than bugs and errors because of unreadable code. I learned this way of thinking by replacing an extremely important 2000 lines of code long SQL. Why use multiple SQLs if you can do it in one? Why use variables to compute certain formulas, that's what SQL does! ... Well too bad one table in this monster needed to be replaced and it wouldn't work anymore. Even worse, where does the 1 Cent difference come from?! Do it as simple as possible, it will safe everyone a lot of grey hairs and money.
You don 't need to split it into too many functions, you could break by "function" or responsibility: reading the file is one and printing the output (the `then` callback) as another named function instead of anonymous. you are breaking it because you assume each part could change... and you are clearly defining the expected input and output of each function. it's great especially when using typescript
For the server host, can you make it so that you've run out of credits It will automatically bill you for a predetermined amount of credits So that you don't have to buy credits manually
That’s fair! A better example may have been some more complicated validation logic, image manipulation, etc. I was more trying to think of an example that could be easily understood by more junior/beginner programmers edging their way into more advanced SE topics but I can understand that it may not be the best way to relay the overarching point.
How is this easier to read? It adds so much cognitive complexity and overload that my brain starts to hurt. In the first example you are literally letting the language lead you to the answer, by piping function calls by passing the result of the first function as an argument to the next one. Imperative code is sometimes good to have, but in this particular case, I would never do what you did and I wouldn't be so strongly opinionated about something like this.
Code.using more.lines and wrong abstracrions is harder to read than code using less lines.and a right abstraction. What is more readable - a SQL query or a mess of nested loops over arrays of structures? And in your example it should have never been javascript at all, even with map and filter. Should have used a Datalog. Or SQL.
I find boring code easier to debug, its often harder to add breakpoints, print statements to clever code.
Idk, other than using `await` at the same time as `then` and the unnecessary `map` , the first version is 100x more readable. The code you wrote has almost no complicated behavior, adding all these unnecessary abstractions / single use functions just makes it more difficult to reason about.
If you undo those 2 weird choices from the first version then it needs no abstractions, everything can be understood from a single glance:
```js
import { readFile } from "fs/promises";
async function main() {
const file = await readFile("./contacts.csv", "utf-8");
const contacts = file.split("
").slice(1);
for (const contact of contacts) {
const [name, age, occupation, city] = contact.split(",");
console.log(`${name} is ${age}. They work as a ${occupation} and live in ${city}.`);
}
}
```
Premature and single use abstractions do more harm than good.
If you're hell-bent on doing abstraction gymnastics then at least do something clever like functional programming to make them ergonomic and reusable.
This topic is where you can determine the quality of a developer. I've had a lot of projects in which i needed to analyse 40 year old code and complex processes. Some guy might think it elegant to just throw 5 pointers around and somehow, by magic i guess, a string pops out with incredibly important data. Where does it come from? What does it mean?
Even if people laugh at me, i always program as simple as possible. Banging rocks together is better than bugs and errors because of unreadable code. I learned this way of thinking by replacing an extremely important 2000 lines of code long SQL. Why use multiple SQLs if you can do it in one? Why use variables to compute certain formulas, that's what SQL does! ... Well too bad one table in this monster needed to be replaced and it wouldn't work anymore. Even worse, where does the 1 Cent difference come from?!
Do it as simple as possible, it will safe everyone a lot of grey hairs and money.
You don 't need to split it into too many functions, you could break by "function" or responsibility: reading the file is one and printing the output (the `then` callback) as another named function instead of anonymous.
you are breaking it because you assume each part could change... and you are clearly defining the expected input and output of each function.
it's great especially when using typescript
For the server host, can you make it so that you've run out of credits It will automatically bill you for a predetermined amount of credits So that you don't have to buy credits manually
Yep! That's actually on the roadmap of features to implement :)
IMO, First version of csv reader is more readable.
That’s fair! A better example may have been some more complicated validation logic, image manipulation, etc. I was more trying to think of an example that could be easily understood by more junior/beginner programmers edging their way into more advanced SE topics but I can understand that it may not be the best way to relay the overarching point.
I agree, its just the "functional" approach over an "imperative" code solution.
Doesn't change the point of OP which I agree with
bro, where can I contact you?
My email has been added to my channel’s info :)
How is this easier to read? It adds so much cognitive complexity and overload that my brain starts to hurt. In the first example you are literally letting the language lead you to the answer, by piping function calls by passing the result of the first function as an argument to the next one. Imperative code is sometimes good to have, but in this particular case, I would never do what you did and I wouldn't be so strongly opinionated about something like this.
Code.using more.lines and wrong abstracrions is harder to read than code using less lines.and a right abstraction. What is more readable - a SQL query or a mess of nested loops over arrays of structures?
And in your example it should have never been javascript at all, even with map and filter. Should have used a Datalog. Or SQL.