18 ms·
And what's your bad first project for javascript? I'm curious because I think javscript, despite the bad parts, is on average pretty forgiving. my two cents fo
by matthewaveryusa 8y ago
And what's your bad first project for javascript? I'm curious because I think javscript, despite the bad parts, is on average pretty forgiving.
my two cents for C++:
-Anything where you revert back to C-style memory-management and wonder why the code is so complex/segfaulty
- apendleton 8y agoFor JS: straight-forward batch processing. Open this CSV, iterate over the data, munge it in some way, spit it out again as a new CSV. This kind of thing is like a 4-line Python script but in JS/Node requires readline or some other kind of standard library thing, nest-y callbacks and/or promises, or maybe async and understanding how that works (which, for a brand new dev... have fun with that), etc. If you need to do IO but don't have a task that benefits from async, things in JS tend to feel unnecessarily torturous.
- jdlshore 8y agoIt's not so bad. const fs = require("fs"); const filename = process.argv[2]; const fileContents = fs.readFileSync(filename, "utf8"); const output = munge(fileContents); process.stdout.write(output); It's worse if you want to use async IO, mostly because the ecosystem is still catching up to async/await. But with a bit of boilerplate or a willingness to use experimental APIs, it's also not bad: // This API is still experimental const fs = require("fs").promises; // This will become unnecessary when top-level await is supported run().catch((err) => console.error(err)); async function run() { const filename = process.argv[2]; const fileContents = await fs.readFile(filename, "utf8"); const output = munge(fileContents); process.stdout.write(output); } My Node.js projects' tooling is all written in Node.js and I enjoy it.
- apendleton 8y agoThe specific situation I've encountered is that it's a file that's bigger than I want to hold in memory and I want to read it and process it a line at a time, but I don't want to do anything fancy or threaded or concurrent. Read a line, do something to it, write a line. Bog-standard ETL stuff. And yeah, async/await helps, but is unambiguously ergonomically worse than: import csv incsv = csv.reader(open('file1.csv')) outcsv = csv.writer(open('file2.csv', 'w')) for row in incsv: outcsv.writerow([row[0], row[1] + ' blah']) and also just requires understanding a lot more stuff before you can be productive if you're new to the language. I'm not saying it's not possible to do it in JS, just that it's not a task that plays to JS's ergonomic strengths, just like it's possible to write a linked list in Rust but kind of sucks.
- jdlshore 8y agoI would call it a weakness of JS's ecosystem, not an ergonomic problem. I believe JS could allow nearly the same code. Haven't tried it, though: const fs = require("fs"); const csv = require("some-csv-package"); const incsv = csv.reader(fs.createReadStream("file1.csv")); const outcsv = csv.writer(fs.createWriteStream("file2.csv")); for await (row of incsv) { await outcsv.writeRow([ row[0], `${row[1]} blah` ]); } Granted, that package doesn't exist, and the popular CSV package for Node [1] makes my eyes cross. As for me, none of the scripting I do with Node involves files that exceed Node's 1GB memory limit, so I take the cheap and easy way out and just readFile(). Which I suppose proves your point, although, again, I would argue it's an ecosystem problem, not a ergonomic problem. [1] https://csv.js.org/project/examples/ https://csv.js.org/project/examples/
- univerio 8y agoFor JS, implement a Map data structure that is keyed by the value (not identity) of arbitrary objects.
- xiphias2 8y agoAfter I implemented this and compared with just encoding the key with JSON, it turned out that JSON.stringify is so fast, that it's not really worth the effort.
- deleted 8y ago[deleted]
- jerf 8y ago"And what's your bad first project for javascript?" Since I'm trying to target not hypothetically bad things, but things I've specifically seen numerous people try, I don't have an answer because I'm not involved enough in that community. Ten years ago I would have said "anything involving a massive, browser-freezing computation", where "why did this O(n^3) code freeze the browser?" being very common, but I'm not sure if that's current. I'd suspect a newbie armed with a fresh tutorial is more likely to overuse promises nowadays rather than underuse them (i.e., very similar to the Go example I gave; yes, if you're doing a huge computation you may want to break it up but you do not want to literally yield a promise for every integer addition). But those with experience in the community may be able to speak to that. Twenty years ago it would have been trying to do too much purely in the client side. That's definitely out of date. (Single Page Apps kinda have an interesting history. They're difficult, and by modern standards, impossible in 1999, and today merely one established option in an array of options, but I wouldn't say it was any one browser advance that changed it... it was a long series of incremental advances. I remember trying to take some relatively intelligent for the time client code for IE4, which at least in theory had a dynamic HTML engine much like today's browsers (albeit one that crashed very, very, very frequently) and make it work in Netscape 4's "layers". Yeowch.)
- nicoburns 8y agoThe really big enabling feature was XmlHttpRequest (released with IE 5), which allowed client side JavaScript to make HTTP requests for the first time. And then, as you say the improvements in performance, reliability and consistency of the APIs between browsers made a big difference.
- jerf 8y agoI agree that was the biggest individual piece, but even XmlHttpRequest had to grow up over time. After all... just look at the name... it was not initially a generic "run a web request without a page refresh" object. :)
- jungler 8y agoJS: Code that manipulates bits, code that needs a notion of value type structs to be well-optimized.