541–550 of 639 posts
Earlier quoted context omitted.
Not if they're tenured. Then you can assume they'll never move.
Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.
Earlier quoted context omitted.
There are parts of Go that are similarly odd. Arrays and slices, and the hoops you have to jump through to do something as simple as adding a new item to a list, are very unlike anything else, for example. In Python, the weird stuff is generally easy to avoid/ignore until it's actually needed.
In Java you do the exact same reallocation dance as append does behind the scenes when using arrays.
Earlier quoted context omitted.
There are parts of Go that are similarly odd. Arrays and slices, and the hoops you have to jump through to do something as simple as adding a new item to a list, are very unlike anything else, for example. In Python, the weird stuff is generally easy to avoid/ignore until it's actually needed.
Very true, but if you're teaching CS then this also exposes students to the topic of ownership-versus-reference in a much gentler way than C.
Or do you mean value vs reference semantics? In that case, I think C pointers are simpler as a fundamental concept, and slices are best defined in terms of pointer + size.
I'm an idiot, I read the headline and thought these were banned from Git entirely. As in, you couldn't commit them to any repo using Git, at all. Thought that seemed a bit harsh. Turns out you just can't use them when you contribute code to the Git project. That makes sense, and seems reasonable.
Critiquing poor code practices is beyond the scope of git at this time
Edit: wait, I can't use strcpy?! Screw that, then I'm not open sourcing my AGI!
Earlier quoted context omitted.
Strings have nothing to do with objects. You can write a string library, eg. [sds]( https://github.com/antirez/sds ). It's just not standard.
The challenge is not to write a string library, but to write a "nice" string library. Let's say, something that's easier to use and doesn't have all the footguns of the char arrays. The library you link doesn't come anywhere close to that. It's 99% like the standard library and it has the exact same issues.
In fact there are several libraries for string-like objects; the main barrier to use them is that none of them is standard. You can at least acknowledge that before talking about nice-ness, which is a whole other point.
While I think such rules are a good idea it only makes sense if it is done consistently and depends on how religiously the tooling (duct-tape and "process") enforces them (even so, you're still only one `#ifdef` away from undoing that "safety"). Having GCC[1] now support static analysis is a killer feature for this type of problem.
On the other end of the spectrum we have Huawei which instead of linting their code is finding creative ways to trick auditing tools and hide such warnings from auditors:
[0] https://news.ycombinator.com/item?id=22712338
[1] https://developers.redhat.com/blog/2021/01/28/static-analysi...
Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.
I think the key is to understand the historical context of C, what it was competing with, and what concerns people writing C had. Compared to the alternative (straight assembler) at the time as a systems programming language, C is a massive step up. Also, the UNIX way was independent processes, so the APIs did not need to be thread safe, as there was no threading in the target architectures. Now given the massive amo…
Earlier quoted context omitted.
It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.
Together with parent comment, this is exactly how I feel every time I use something that is not C (I do mostly embedded). Like: ok, I can use a slice here, but what is a slice? what thing is it doing that I don't know? where's the catch? how does it look like in memory? is it calling a function when I access it? is it being copied or referenced?. And so on...
Earlier quoted context omitted.
Medicine has been more poorly paid than FAANG software engineering in the last two places I've lived (South Africa, Australia)
FAANG engineers are also massively over paid, compared to your average software engineer in any random country. When people on HN discuses salaries, or I see a job posting from a Silicon Valley company I can't help think that we don't even pay our CTO that much. Frequently you could get two developers for the same price here in Denmark.
Think about what your CTO could do in that setting and realize that he's probably worth more to FAANG shareholders than to you hence the salary differential.
For the record, I do not work at a FAANG.
Earlier quoted context omitted.
This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.
I don't understand your concern. How is teaching programming in school discriminatory? Would it be better to not teach programming at all?
Or imagine math was taught by giving kids all the axioms and requiring them to derive the other rules needed to solve tasks as needed :)
Kids from well off families would be ok - it would just be considered another random thing you have to teach your kids to help them make it.
But other kids would suffer and think "English and math is not for me".