Could you elaborate? I cannot see how a functional programming language would have protected you from reading a non existing value while not providing a default
It's more that functional languages just happen to be stricter in various ways that would've mitigated against this. You could quite happily design a functional language that has an unsafe equivalent to sscanf in its stdlib, or has big parts of the spec which are "undefined behaviour" that may differ depending on the underlying OS/compiler/runtime/stdlib in use. But the more popular functional languages have gained traction in part because they tend to have a "if you model the types correctly, the program basically works" philosophy around them. I don't think things like Haskell, Ocaml or F# would allow this if you wrote idiomatic code, you'd probably need to do something a little hacky or sketchy.
It simply would not have allowed you to write code which did that. And you wouldn't have a function like sscanf() either. You'd probably end up with a much more normal looking parser function that returned a value-or-error type.
I've never heard of a functional language that would allow you to initialize a value to whatever value the system memory already had in that memory location. In languages that allow nil, it would at least be nil; in languages that don't, you would have gotten an error about an uninitialized and undefaulted value. In any typed language, you would have also gotten an error.
It's true that C may be unique-ish in this regard though- this bug also couldn't happen in Ruby, which is not a functional language, but Ruby certainly still makes undefined behaviors much more possible than in other languages like Elixir.
I don't mind. Many of the comments are about my incorrect use of the term Linux. In a way, they are right. But if one wants to teach Automotive Technology to future BMW mechanics, you start them working on a VW Beetle. Wax on wax off.
It might be because it's a teaching tool, but the introduction contains a lot of fundament misunderstandings and factual mistakes.
Take networking, one of the screenshots shows the output of ifconfig. That teaches you almost nothing about Linux networking, because ifconfig in Linux and OpenBSD are two very different tools, and you'd probably not teach people to use ifconfig on a modern Linux distro. Same for the boot process... rc and systemd are not the same, not even close.
It is a very cool project but almost all references to Linux is wrong.
Which is weird, because the stated purpose of MinC is: "MinC was written to help children at vocational education learn Linux without the hassle of virtualization." And it does this by running OpenBSD on Windows? That's really strange. Why not just run linux if the goal is to teach/learn linux? Perhaps the actual goal is not well stated, or I misinterpret what is really meant by those words.
Sure, it's confusing. But the suggestion here is that this single word implies a "lot of fundament misunderstandings and factual mistakes" (sic), and therefore the many negative comments in this thread about that word are warranted, and frankly that's just ridiculous.
Notably, from a teaching "Unix tools 101" perspective, the difference is super unimportant. If the author's goal is to get students to open a terminal for the first time in their lives (on their Windows laptops!) and type some ls commands and maybe pipe stuff into sed once or twice, they can learn this on a BSD and apply it in any Linux (or the reverse) just fine.
I think the author means it literally. His goal is to teach students some Linux basics, and his method is to put a BSD into their Windows. It's kinda nuts, but you gotta agree it's kinda "mad genuis" nuts.
