3 ms·
> All of these things I've had to suppliment myself dating > back into highschool when I started programming. I'm lucky > I got a head start. There's graduate
by Ar-Curunir 10y ago
> All of these things I've had to suppliment myself dating
> back into highschool when I started programming. I'm lucky
> I got a head start. There's graduate students at my school
> who couldn't for their life tell you what historically
> important programs/protocalls are like vim or telnet is,
> who don't know who RMS is, who don't know what Bell Labs
> is, who don't know that by writing code they own it to
> some degree acording to our country's legal system.
You really don't need to know the history of computing to make a dent in research; why should a protocl like telnet be relevant today, when we have much better alternatives? To learn from its mistakes? No, that's why you take design classes that you seem to dislike.
Leaving aside the lack of need to know those ancient things (I say this as a heavy user of vim), you seem to conflate engineering with computer science. There's a lot of CS that doesn't have anything to do with network protocols and UNIX programs
- gravypod 10y ago> why should a protocl like telnet be relevant today A lot of software uses "telnet" as in TCP sockets with \r\n and ASCII encoding. That's all telnet is and that's how a lot of data is shifted around all the time. > To learn from its mistakes? Telnet wasn't a mistake. It was an obvious step from terminals via RS232 to terminals via TCP. Also, telnet is everywhere. If you went into research and someone said "just hook into the telnet stream for $SENSOR" and you said "What's telnet" that wouldn't end well. > No, that's why you take design classes that you seem to dislike. No one in their right minds would call telnet, sending text over TCP, a bad design. It's a bad design for some things, but others it's the simplest way to do things. You can do a lot with it since it is very robust. What can go wrong with a telnet stream? 1) Client/Server drops connection to you 2) ... What else? That's a tenant of fantastic design. > Leaving aside the lack of need to know those ancient things (I say this as a heavy user of vim), you seem to conflate engineering with computer science. I don't conflate it. Everyone in industry does. I'm marketing myself to industry so I will use their terminology. Their terminology associates Computer Science with "The programmer". > There's a lot of CS that doesn't have anything to do with network protocols and UNIX programs I and most places you'd go to work in industry aren't mainly concerned with those problems. Different data structures? Great yea I'd love to learn them. Proving some code mathematically? Ok, sure, I guess. I'll probably only do that once or twice. Memorizing Algorithms? Nope, you've lost me. I need to know how to design my own algorithms, understand abstractions of these algorithms, then design the algorithms I'm good at designing and leave the rest to experts in their portion of the field. > Leaving aside the lack of need to know those ancient things I think this is completely wrong. You might what to watch this video series to see how much important and enlightening information comes from history: https://www.youtube.com/watch?v=JxAXlJEmNMg https://www.youtube.com/watch?v=JxAXlJEmNMg Why is it important to know? You can easily see which arcane practices are still needed and which are just superstition. You also learn why specific systems were desgined and how they were implemented. They are usually far more basic and robust then current solutions and if we religate that all to the history books we'll loose all of that innovation from the very exciting dawn of computer science.
- Ar-Curunir 10y agoYou were talking about grad students; those people are training not to be in the routine industry jobs.
- gravypod 10y agoAh so it's only ok for the ignorant to stay in academia. Sounds reasonable. Those dolts shouldn't be expected of anything anyway.