Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "real story of a programming language"
The Absolutely True Story of a Real Programmer Who Never Learned C.
I have a young friend named Sam who is quite a programming prodigy. Sam does know C! I need to make this clear: he’s not the titular programmer.
But a couple years ago Sam told me a story about a different programmer who never learned C, and I liked it so much that right on the spot I asked his permission to repeat it. (I could never just steal such a tale.)
Sam wasn’t always a programmer—actually he started in his later teens, in part because he was more of a jock, and in part because he was related to programmers and wanted to do his own thing. But, like all great programmers, once he was bitten by the bug he immersed himself completely in it.
One day Sam happened to be talking programming with his uncle, who was also a programmer but from way, way back.
“Hey,” said Sam, “I’m learning this language called C. You must know a lot of languages, did you ever study C?”
“No,” said the uncle, to Sam’s surprise. “I am one of the very few programmers who never had to learn C.”
“Because I wrote it.”
Oh, Sam’s last name is Ritchie.
What I love about this story is the idea of Dennis waiting Sam’s entire life to deliver this zinger. Just imagine sitting on a line that good, watching your nephew grow up and waiting, waiting until the one day he finally starts learning to code. Did he work on the line in his head at night? Like, “Hmm, how should I word it so I can deliver the punch line perfectly? Should I say ‘I never took a class on C?’ Nah, too awkward…”
The great thing about geniuses is how much effort they put into everything.
Courtesy : Wil Shiply.5
Okay, story time.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18
when i was 8 years old dad order me an arduino and i started to look at the code ofcourse i tried pascal and that things before but this was my first real step into programming then after a mounth i decided i should try programm some app so i was learning C from english sites and then started to get a timer done without any library only the basics library for math and when i finished it i feel i want to do that for rest of my life but before my dad learn python so i said i want to learn a programming language Python but in this age it was hard so i taked pascal that was like wow when Hello world appears on screen and then when i was 10 years old i created 2 apps without bug what was woooow for me ofcourse small apps but woooooow and today
after 8 years of programming in lots of languages i choose d my 2 primary C and Java (i still need to learn a java) but mainly C and thats my story how i started orogramming and whats make me to think about programming and my dad to buy me an arduino so the moment when he started electronics looking on PC components and so on and that was the moment when its all started im happy from me that i dont fail
I really love helping and teaching others about code. Recently I had a friend that wanted to get into web development. Being me, I told him that i would teach him all he wants but that he needs to do some research first to show me that he feels comfortable with as a minimum requirement. I told him to research the minimum technologies required to build a web page and to tell me about the request response cycle and stuff like that. When he came back I was expecting small explanations such as "html stands for bla bla and is used for bla bla".No. this dude comes back all proud to tell me about flipping Laravel. I sit there quietly listening to him go on about the "Laravel programming language". He likes anime, I like kendo (and have trained in it) so while he is talking I slowly move us into the part of my office where I keep my boken (wodden sword). As soon as he sees me sitting down with the sword he asks what am i doing with it.
"Well, remember when in some anime that you like you see teachers beating their studets over stupid shit?"
..."WHAT DOES HTTP STANDS FOR?"
"The...the err the web language that.. er"
"Like the updates thing?"
:) guarantee he wont forget what http is after that and what js and Laravel are from now on :) needless to say he will continue learning with much more care.
Coding dojo for real mofockas, ya dig?3
WARNING - a lot of text.
I am open for questions and discussions :)
I am not an education program specialist and I can't decide what's best for everyone. It is hard process of managing the prigram which is going through a lot of instances.
Speaking about schools: regular schools does not prepare computer scientists. I have a lot of thoughts abouth whether we need or do NOT need such amount of knowledge in some subjects, but that's completely different story. Back to cs.
The main problem is that IT sphere evolves exceedingly fast (compared to others) and education system adaptation is honestly too slow.
SC studies in schools needs to be reformed almost every year to accept updates and corrections, but education system in most countries does not support that, thats the main problem. In basic course, which is for everyone I'd suggest to tell about brief computer usage, like office, OS basics, etc. But not only MS stuff... Linux is no more that nerdy stuff from 90', it's evolved and ready to use OS for everyone. So basic OS tour, like wtf is MAC, Linux (you can show Ubuntu/Mint, etc - the easy stuff) would be great... Also, show students cloud technologies. Like, you have an option to do *that* in your browser! And, yeah, classy stuff like what's USB and what's MB/GB and other basic stuff.. not digging into it for 6 months, but just brief overview wuth some useful info... Everyone had seen a PC by the time they are studying cs anyway.. and somewhere at the end we can introduce programming, what you can do with it and maybe hello world in whatever language, but no more.. 'cause it's still class for everyone, no need to explain stars there.
For last years, where shit's getting serious, like where you can choose: study cs or not - there we can teach programming. In my country it's 2 years. It's possible to cover OOP principles of +/- modern language (Java or C++ is not bad too, maybe even GO, whatever, that's not me who will decide it. Point that it's not from 70') + VCS + sime real world app like simplified, but still functional bookstore managing app.
That's about schools.
Speaking about universities - logic isbthe same. It needs to be modern and accept corrections and updates every year. And now it depends on what you're studying there. Are you going to have software engineering diploma or business system analyst...
Generally speaking, for developers - we need more real world scenarios and I guess, some technologies and frameworks. Ofc, theory too, but not that stuff from 1980. Come-on, nowadays nobody specifies 1 functional requirement in several pages and, generally, nobody is writing that specification for 2 years. Product becomes obsolete and it's haven't even started yet.
Everything changes, whether it is how we write specification documents, or literally anything else in IT.
Once more, morale: update CS program yearly, goddammit
How to do it - it's the whole another topic.
Thank you for reading.