91–100 of 191 posts
It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never checked and everything is expected to always succeed, throughout the source tree.
There are languages that don't allow the programmers to do such kind of failures.
The more I read, the more I felt that the author was long-windedly discovering FSM's, only describing them using the language de-jour - i.e. JavaScript-ecosystem-ism's. Is this the state of things today - that kids start off as highfalutin' "developers", whereby 95% of their apps are written by others (because: "npm -i "), and then .. eventually, from the top-down, trickle through the stack learning "the things", giv…
The reverse is true. I meet quite a lot of low to middle level programmers that stick to what they know because it's "the basics", and hence completely lack in experience in: 1 - Writing elegant modern code Working with experienced C / Java coders to write proper Python is a challenge. They tend to use twice to many lines, ending up with slower and less readable code. They don't use the additional productivity to pro…
2) Funny, there's a near-constant stream of articles on how companies who succeed have to spend significant amounts of money money and time re-write their code, because those nested loops weren't just fast enough, and were causing the company to hemorrhage money.
3) "put that in redis" At which point you incur a network roundtrip to the redis server.
"you have JSON/YAML/TOML" So, which one? They're not cross compatible. Oh, and don't forget to add custom encoding for non-JS compatible values. JSON is just the latest iteration of XML these days, complete with XSLT, X-Path, XSD, processing directives, and namespaces.
"you have sqlite" SQLite has been available for decades, and in use by programmers just as long. Oh, and it's written to a file on the filesystem. And doesn't support transactions.
"Arrays and JSON types in PostGres" Oof. Hope you don't want performance to go with that. Joins are much more performant, and have the bonus of being flexible when the user spec changes.
"You have bson, msgpack, protocol buffers" Binary serialization formats have been around as long as there have been computers. People have been sending raw structs with checksums over the wire as long as there have been wires.
"Plus the server has 32 cores so just go with it." This again. Doesn't scale, and will cost your company when you do have the scale.
4) I'll be honest, I don't get your point here. Low level programmers can't keep up with user expectations? Why do you think `ls` has several dozen flags? Users wanted them.
The more I read, the more I felt that the author was long-windedly discovering FSM's, only describing them using the language de-jour - i.e. JavaScript-ecosystem-ism's. Is this the state of things today - that kids start off as highfalutin' "developers", whereby 95% of their apps are written by others (because: "npm -i "), and then .. eventually, from the top-down, trickle through the stack learning "the things", giv…
There is plenty to re-use in C, eg. BSD's queue.h or linux' list.h for linked list alone. Because the author choose not to do so doesn't mean it is the fate of the whole language. Though, it is indeed a little harder than firing "npm".
On (Debian) linux boxes apt-get install -dev and away you go, there's literally the whole platform ecosystem there for you to use.
It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never checked and everything is expected to always succeed, throughout the source tree.
The reason for not checking malloc is that it's most likely to kill your program instead of returning a failed allocation
The more I read, the more I felt that the author was long-windedly discovering FSM's, only describing them using the language de-jour - i.e. JavaScript-ecosystem-ism's. Is this the state of things today - that kids start off as highfalutin' "developers", whereby 95% of their apps are written by others (because: "npm -i "), and then .. eventually, from the top-down, trickle through the stack learning "the things", giv…
Is this the state of things today...from the top-down, trickle through the stack learning 'the things' Yes, the path most people will take today is from high-level languages and high-level abstractions, down to low level abstractions. It's not any better or worse than a bottom-up approach for learning. The fact that people are going down through the stack, trying to learn and understand things as they go is to be cel…
I think the analogy holds here.
Earlier quoted context omitted.
One, who just has a free 6 months? Two, do you honestly think you can fit a comprehensive CS education that would satisfy people like you in six months?
1. Most westerners born outside the USA. And in the USA anyone willing to take out a loan. 2. The core requirements for a cs major at a typical university (read: not CMU,MIT,Stanford,Berkeley) and especially at a non flagship is basically 4 or 5 courses, which you can for sure cram into 6 months if that's all you're studying. Personally, I'd rather work with people who learn some part of that on their own (or even no…
Not at my university, with the amount of stuff we had to do, unless in the 20+ years that have gone by, they got the quality level down.
Earlier quoted context omitted.
I don't think the article was that bad for "junior-JS-to-JS-dev talk", which I think is clearly the main audience. Yes, I'd agree, for any seasoned dev, an article about the basics of functional programming, state machines, and the basics of unit testing and API design is a tad boring ;-). But that's no reason to get that upset about an article that clearly wasn't written for such an audience. Rather, such a response…
> such a response is not exactly encouraging those "kids" to learn complex programming concepts/languages in the first place, I think, and instead seems a bit offensive, to be honest. Yes, exactly. I mean, this dev is someone who clearly is working toward a deeper level of understanding of CS concepts, and here some people seem to be criticizing him for that. It's frustrating.
function handleAddTodo(state) {
if (!newTodoField) {
state.error = 'Empty field!'
}
state.todos.push(state.newTodoField)
state.newTodoField = nil
return state;
}
Earlier quoted context omitted.
There is plenty to re-use in C, eg. BSD's queue.h or linux' list.h for linked list alone. Because the author choose not to do so doesn't mean it is the fate of the whole language. Though, it is indeed a little harder than firing "npm".
Is it? On (Debian) linux boxes apt-get install -dev and away you go, there's literally the whole platform ecosystem there for you to use.
Earlier quoted context omitted.
It's because the challenge he set himself isn't hard and he didn't do a particularly good job of it either (other comments have covered that so I wont reiterate it) yet he is soapboxing his experiences as if the topic isn't entry-level stuff. And I mean "entry-level" quite literally as you learn about event-driven programming in high school or equivalent IT classes. This isn't something you need a CS degree to learn.…
>I'd expect anyone working as a developer in IT to have learned this much before calling themselves a professional. According to author's webpage[1], he's a "student at the University of Waterloo, class of 2021" . So probably age 17 or 18. He's not passing himself off as a "professional". If majority of HN readers feel this article was beneath their skill level and a waste of time, that's more on the submitter (mxstb…
> So probably age 17 or 18. He's not passing himself off as a "professional".
Fair enough, though I am still surprised he hadn't learned that in formal education already. I was taught about event driven programming before I got to university. The schools I went to weren't particularly good either so it's not like I had a "better" education or come from privilege.
Maybe they just don't teach event-driven programming any more? :(