You won't get much insight from a study period measured in hours. CT has actually been incredibly beneficial for computer science. Monads were first used to give denotational semantics to imperative languages. CT has also influenced Haskells design, giving many general and consistent abstractions across it's libraries. Looking ahead, CT is teaching us how to build software in total languages.
There is significance coverage of OOP features, hence my Java-like comment. I would have personally left OOP out for a beginner book, it isn't really fundamental. Another advantage to using Java in the first half, could be to use Java closures to implement Lox closures.
My minor nit pick is that it uses mostly the Java language to implement a Java-like language. What have we gained? Surely something Python-like in C would be more rewarding, one would be gaining a level of abstraction.
Microsoft may be negligent in selling a product unsuitable for these applications. Windows is unsuitable precisely because it can be brought down by third party updates, such that it cannot recover without manual intervention by technical experts. Third party vendors are forced into writing unsafe kernel drivers because Microsoft does not provide sufficient user mode APIs.
Windows has a dated design and a security model no longer fit for purpose. As for your other example, it could be protecting users from malicious programs that may delete data, simply by having a better security model, like Android and iOS.
It's interesting to me that lay people are asking the right questions, but many in the industry, such as the parent here, seem to just accept the status quo. If you want to be part of the solution, you have to admit there is a problem.
Linux and open source also have the potential to be far more modular than Windows is. At the moment we have airport display boards running a full windows stack including anti-virus/spyware/audit etc, just to display a table ... madness
Hopefully now people might wake up to the idea that these tech monopolies are not leading to safe, secure and reliable systems. They will wonder how a third party component could cause such breakage. I expect many will be calling for regulation.
Yes but my point is that these problems are as hard as we want to make them. For a simple language implemented in C, maybe it's fine to never free any memory until the process quits.
It doesn't have to be a crazy amount of work, see Lisp-in-Lisp in the original SCIP book or a lambda calculus interpreter in Haskell (fits on a screen).
A type checker is only going to add limited value if you don't put the effort in yourself. If everything string-like is just a string, and if data is not parsed into types that maintain invariants, then little is being constrained and there is little to "check". It becomes increasingly difficult the more sophisticated the type system is, but in some statically typed languages like Coq, clever programmers can literally prove the correctness of their program using the type system. Whereas a unit test can only prove the presence of bugs, not their absence.
A better way to deal with this versus dependency injection frameworks is to allow the generator to be configurable and to be honest about where the seed is coming from. The random seed is an implicit input read from the runtime environment as a side effect. Future languages should treat side effects as first class and allow, for example, custom handlers to be installed to intecept or modify their behaviour.
Absolutely it is about trade offs, sometimes bugs are just an inconvenience and time-to-market is more important. But bugs can result in lost business and even lost lives, for example UK Post Office Horizon. Horizon was built (bungled) on the cheap, but the overall cost of that saving must be dwarfed by the financial cost of the resultant scandal.
> the user can’t know that something over there made it so something over here can’t type check
To the Swift developers: just add source positions to your type AST, in addition to the term AST, then you'll know where a type has come from. It lets you give error messages like: expected type A (line X) but got type B (line Y).
Hindley-Milner type checkers perform well in Haskell and OCaml. I don't think this type system can be blamed entirely for Swifts problems.
I don't think the "failures" are necessarily always technical, e.g. upstart versus systemd or GNOME versus Unity. To me it looks like Red Hat has possibly too much control and influence.
I switched to Capture One. Not as easy to use as Lightroom, but the RAW processing is actually superior. It's a one time purchase. The professionals can choose to upgrade every year, the casual users can upgrade less frequently.
By what measure? Haskell can be a huge productivity multiplier. The standard library is built upon many powerful, unifying and consistent mathematical abstractions. For example, there is almost no boilerplate to write for any traversal, mapping, error handling etc. The average Pythonista simply has no idea what they are missing. But Haskell doesn't have anywhere near the third party ecosystem of Python, so is less productive by some measures.
They drove me off Lightroom, I was just a causal user. The upsell spam and ads in Adobe Reader has also driven me away from that too. I would have considered buying an upgrade for both, but the price was never right for casual home use. Now I don't use any Adobe products at all.
Yes. Our imagination allows extraordinary levels of doublethink. We know there is crisis underway and yet Nvidia, Microsoft and Apple are the most valuable companies in the world.
Are they really deleting menu bars? Wow. Maybe in ten years time they'll figure out that two hamburgers is better than one; and that they'll need names like "File" and "Edit".