I'll take this opportunity to plug Bo Qian's C++ videos on youtube if anybody is interested in learning modern C++. They are to the point, code-focused, don't waste time on basic syntax, and cover a lot of ground (lvalues and rvalues, move semantics, inheritance types, etc.). Only issue is they are only current to C++11.
I learnt C++ in 2018 and have no regrets
161–170 of 259 posts
Re: I learnt C++ in 2018 and have no regrets
#162Earlier quoted context omitted.
I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. I wish I had stayed with it since college b…
Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.
I'm sure Rust works great :) But vcpkg was made by Microsoft and I suspect is rather easy to get working on that platform. On the other hand, I've used conan and had no problem e.g. getting FFmpeg working. And, thanks to conan's awesomeness, I can even make it work with clang on windows -- so that e.g. I can use all the latest c++17 features on a library like Boost.Hana and range-v3 (of Eric Niebler fame).
Re: I learnt C++ in 2018 and have no regrets
#163Earlier quoted context omitted.
Then again, why would you want to choose a language based on whether it's "OO" or not? OOP is just a way of structuring code that fits well in some domains, and fails spectacularly in others[0], and that happens to invite a lot of philosophers (the same way FP invites a lot of mathematicians). It's better to think about the capabilities the tool gives you - what kind of software you can write, what kind of software t…
Wouldn't the main definition of OOP be defined as merging data and functions into a single unit? When using libraries, I find this concept unavoidable for UI and games. I agree though, that having the entire program be a graph of objects is actually usually the worst pattern.
> I agree though, that having the entire program be a graph of objects is actually usually the worst pattern.
This is what I was primarily thinking about, and this is what is most written about in OOP books. OOP is a big bag that wraps itself around a lot of things, and which appropriated quite a lot of concepts. The concept of gluing together a bunch of data and code in order to treat them as a single entity is indeed useful (at least for imperative code), and while it is the foundation of OOP, I don't think it's really the distinguishing thing about various OOP approaches. For the class-based OOP, it's the composition of data+behaviour, encapsulation, polymorphism and inheritance that together create a particular philosophy - one that I find much less useful than advertised.
The building blocks are no doubt useful - a proper type system is great, but you don't need classes and objects for that. So is polymorphism, and again, you don't need Java-style classes to get method dispatch (see e.g. Common Lisp multimethods for an arguably better way of doing this, and one that doesn't even treat methods as parts of classes!).
I'll concede that OOP approach fits UI libraries unusually well (though you can hit some conceptual roadblocks there too; I'm not sure I've ever seen a good OOP design of tables, nor do I know how to design it well). But then again, I was recently writing some React code in ClojureScript, and it turns out that functions and plain data can handle building stateful UI components well too.
What I mean by saying that OOP appropriated things - I've seen people thinking, and even myself I used to think, that "abstraction" is something that a class creates, and is what you achieve with OOP. I gradually grew out of that belief, and I vividly remembering that reading SICP made it finally click in my head that quite a lot - if not most - of the software engineering practices discussed and attributed to OOP are in fact more general concepts applicable regardless of your programming paradigm.
Re: I learnt C++ in 2018 and have no regrets
#164Earlier quoted context omitted.
It's worth pointing out one measure of complexity: the Stroustrup book (4th ed) is 1376 pages, and that was 2013. Since then there's been how many layers more on top? As a contrast, the description of Common Lisp syntax fits on a sticky note, but the library and semantics spec take about the same number of pages to describe a similar amount of functionality. The two extremes represent different locations on the synta…
> The two extremes represent different locations on the syntax-vs-library complexity tradeoff continuum. I'd say it's a syntax x language semantics x libraries triangle. Common Lisp may have trivial syntax, but there are some hidden gems of complexity in the language semantics level. To this day I don't really understand eval-when, and I've been using Common Lisp for the past 9 years.
Yeah that sounds about right. It's a 3 space.
Re: I learnt C++ in 2018 and have no regrets
#165Earlier quoted context omitted.
C++ is commonly used for large complex projects. The problem with opinions is eventually you come across something that the opinion will not allow. For a small project an opinionated build system makes things easier and you essentially never run across something that can't work. For very large projects that is not true and so you end up fighting opinions in some place.
Examples? As a maven advocate I've commonly seen this claimed ("we have to have an ant build because we need to do x/y/z custom thing") but I've never seen an example that held up under scrutiny. E.g. there's no reason any project would ever need a custom source directory layout. No project needs to run tests before compile (and if you really need build step x to happen before build step y, you can always separate th…
As one (slightly abnormal) example that I've worked on. We would build the meat of the solution, then run our tests. Upon success, we'd generate language bindings (think swig), compile them and run API tests against those. The languages included C++, C#, Java and Excel 12 bindings (which required their own .cpp files). I can easily see this type of special case worm its way in to larger projects and be valid, yes.
Re: I learnt C++ in 2018 and have no regrets
#166Earlier quoted context omitted.
Wouldn't the main definition of OOP be defined as merging data and functions into a single unit? When using libraries, I find this concept unavoidable for UI and games. I agree though, that having the entire program be a graph of objects is actually usually the worst pattern.
Not really. In fact in Lisp OO is the opposite, the functions are explicitly keeped away from the data. For Alan Kay it was all about messanging but I dont think most people think about that. Structs with some kind of dynamic dispatch based on the type would be the most general discription I think.
> Not really. In fact in Lisp OO is the opposite, the functions are explicitly keeped away from the data.
Common Lisp really opened my eyes here. Initially it felt weird to have methods[0] living completely independently from classes, but over time I realized that where classes and objects implement nouns, generic functions and methods represent verbs, and in a language the verbs are an independent domain from nouns, representing their own generalized concepts that's unrelated to the taxonomy of nouns.
--
[0] - A "method" in CLOS is an individual implementation of a "generic function". So e.g. you could have a generic function `(defgeneric draw (device figure))`, and then specific implementations dispatching on any combination of arguments; e.g. `(defmethod draw ((device printer) figure)` to draw any kind of figure on a specific device, or `(defmethod draw (device plotter) (figure circle))` to draw a specific thing on a specific device, etc.
Re: I learnt C++ in 2018 and have no regrets
#167I studied C++ during university days and after that I never got a chance to learn it seriously due to my job commitments as a web developer. I did work on C# but not C++ professionally. I always admired my friends who could write good C or C++ code.
So many times I wish to learn it seriously but these new editors for web development and Python made me lazy enough that I wish to have some environment and way to write and compile C programs easily.
I heard modern C++ is way better than what it was in early 2000. I want to give it a try, hopefully, I will be able to learn and implement Pointers properly.
Re: I learnt C++ in 2018 and have no regrets
#168Earlier quoted context omitted.
For the most part, the world is messy ;-)
Everything in the world is made out of a single unit: Atoms. Complexity and messiness arise from different compositions of Atoms. I feel we should build our programs the same way. Bottom up from a small set of simple primitives. Not top down like C++.
There are three sets of primitives I can recommend for you to get some experience with: the Turing machine; the Lambda Calculus; the Lisp primitives (CONS, CAR, CDR).
Re: I learnt C++ in 2018 and have no regrets
#169I studied C++ during university days and after that I never got a chance to learn it seriously due to my job commitments as a web developer. I did work on C# but not C++ professionally. I always admired my friends who could write good C or C++ code. So many times I wish to learn it seriously but these new editors for web development and Python made me lazy enough that I wish to have some environment and way to write…
I had the same problem and I decided on start building a few Qt apps for command line tools I had made. This worked quite well for me because it wasn't too complex or large, you tend to write in a 'modern' style (although the downside here is I guess that qt is also somewhat idiosyncratic) and you get a build tools so you don't need to worry much about that.
Re: I learnt C++ in 2018 and have no regrets
#170Earlier quoted context omitted.
I do not understand the mentality of "opinionated" frameworks or tools being a good thing, and the trend toward said frameworks disturbs me greatly. What people call "opinionated" is nothing more than something being "architected". Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you. Using these types of frameworks short-circuits the proces…
> Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you Opinionated also means that these decisions will be the same in other places/projects I may join. In the medium and long term, that advantage may easily offset the value of custom decisions.
Some subset of those decision are also things which just don't matter, like which side of the road to drive on— the value is in a critical mass of people all doing the same thing more than it is in the merits of either approach.
A lot of stylistic stuff like filesystem layout falls into this bucket.