For a good base, I recommend the book "The Design and Implementation of the FreeBSD Operating System" by Marshall Kirk McKusick. It's really in depth and I was able to follow it without previously taking an OS course.
Don't forget about Objective-C++! That's where the true powers of the dark side are.
Side Note: Objective-C is such a criminally underrated language. I often see people complaining about the syntax, but it's just syntax. Once you get over it, I find that the language makes the OOP paradigm a joy to work with.
Honestly, I never seriously considered it. I thought it was more-or-less an "Apple thing". OFC it is supported on other platforms, but seemingly not widely used (I write scientific code that really only has to work on Linux).
But after looking at its feature set, I wonder how easy it is to get by without templates? It seemingly uses weak typing instead like Go for scenarios that would normally require generics/templates. My attitude towards templates/generics is that they are absolutely necessary for a good standard library and core containers, but implementation of new templates in your own code should be rare.
Also, I do like namespaces in general, although not necessarily C++'s implementation of them.
I'll be a contrarian here and say that Objective-C is an ugly mess, and not even "because brackets". It's the language full of terrible hacks, historic baggage, and bolted-on features. Objective-C++ is basically the worst of both worlds. :)
Programming languages have advanced a fair bit since the 80s, it's time for Objective-C to die peacefully.
Yes, agreed. IMO, curly braces would have made much more sense. It's not even bikesheding, really. It's just a fact that curly braces are less used in most written languages. I would also argue that curly braces are a better signal to the programmer that "something programmatic is happening here", due to their prevalence as scope delimiters in most popular languages.
Swift's string interpolation doesn't catch my eye like, say, Ruby's does: `#{my_var}`. It's very easy to gloss over `\(something_like_this)`. I suspect they were going for a more "elegant" syntax at the cost of pragmatism.
I definitely think a general guideline for language designers could be "when in doubt, make it look like Ruby". The language has its issues, sure, but damn if it didn't get syntax just right.
I think we will have to agree to disagree on this. Personally, Ruby code is only marginally better than Perl in terms of line noise I can't read, a dubious distinction.
It wasn't lifted from the docs. The tutorial is a tic-tac-toe game, while the example in the post is an AddTodo function [edit: there appears to be an add todo section, but the code is completely different]. Furthermore, all the examples in the tutorials show a pattern where you reference functions instead of writing them inside JSX.
" Using props and state, we can put together a small Todo application. This example uses state to track the current list of items as well as the text that the user has
entered. Although event handlers appear to be rendered
inline, they will be collected and implemented using event delegation. "
Fair enough - it's a todo app. The code isn't structured in the same manner as the author's, however, so my point stands. It doesn't look like the code was lifted from the docs, as you said, but instead transformed to look like spaghetti.
I don't see where the parent suggested no framework. It's likely he or she prefers working a different framework or library, like vue.js or even jQuery.
For me, jQuery is the bare minimum requirement. I would never attempt to write a large app in pure JS, even with babel. You would definitely run into some of the problems you mentioned.
EDIT: I see now where he mentioned no-framework JS
I have written relatively large (35k lines) project in pure JavaScript (without even jquery) and have never faced any of the issues mentioned by the parent, (Babel helped). I write native first and then run babel to appease my older browser faring users.
The advantages of native are that it's extremely snappy to use and fast to load. Bears smaller memory footprint (have to use angular.js at work and god it's awful) and with newer things like async await, ES16 classes, etc code management is very good. Can't recall the last time I had to take care of a specific browser quirk.
I really don't see how jQuery would help you much there. It doesn't provide any sort of common structure at all, and it's nowadays arguably not very helpful for its helpers either.
Regardless of these complaints, the job market for React is just too damn good to ignore. I bit the bullet and began learning. As a newbie, I understand the sentiment of this article. However, it's really not as bad as the author makes it out to be.
Also, className instead of class took all of 3 seconds to learn.
className is a small inconvenience when porting over an existing app to react (e.g. pasting in existing html), as is the requirement for style parameters to be objects. className is a quick find replace, but style is a more lengthy transpose process.
These are small frictions, but in the same way that every ounce/gram counts to a hiker, minimizing process frictions makes a big difference in productivity during times you already have a high cognitive load.
If you're interested in iOS/Cocoa development, Swift is a top-notch statically typed language with lots of paradigm flexibility. Unfortunately, it isn't used as much outside of that domain.
When I'm not on medication I'm prone to manic/psychotic episodes and usually begin to hear voices. Maybe drugging isn't the best solution, but for me it's the only one that lets me live a normal life.
Thanks for the tip - just bought a Kindle copy. I was going to get the hardcopy, but Yikes, WHAT has happened to the cost of freight recently?!? It was going to cost minimum $45 to ship a $35 book to Australia!!
Programming Phoenix is one of the few programming books I've read cover to cover. Not only does it cover the nuts and bolts of how to do things it also goes into why things are as they are because it was written by the same team responsible for Phoenix itself.
