C++ build systems

@rtacconi

Professional developer here:



Well this is false at first face. Smalltalk introduced the concept of object oriented programming to the world. It provides an abstraction layer that when properly implemented separates concerns and hides details making developers more productive. If you've ever programmed in C, or Go for that matter you'd understand the level of complexity that emerges when you leave object space.

You are confusing bad developers for bad languages. A common mistake.



Functional programming is cool but let's not attribute immutability and constrained solutions to the field of functional programming. Immutability can be built into any language (hell, even javascript has it through ImmutableJS).

What you are trying to get at is not immutability but pure functions. Pure functions are a functional tool that are difficult to implement in other places. The primary benefit of functional programming is derived from pure functions in that you can compose them without concerning yourself with side effects. A major boon of this is that multi-core and distributed programming become much simpler at the expense of a far more complicated and confusing developer experience.



There's a lot to unpack here.

Go is not good. How may I count the ways.

Rust would be a good language if the community wasn't overrun with SJWs. I really can't commit to a language who's community and language standard can be so readily hijacked by militant crazies.



Jane Street has gone on record that they used OCaml primarily because their chief technology guy refused to use anything else. They ex post facto claim that it's better, and in some ways it is, but don't be confused about the reason they use it. It has a lot of problems around multicore that have yet to be solved. I would be curious how Jane Street gets around this. For the record OCaml is in the family of ML-likes. A cousin of OCaml is Haskell. Rust shares nothing in common with this family of languages.



This is referred to as static typing. To an extent you can enforce this in Python with MyPy, and many dynamic languages are actually strongly typed on the backend (common lisp for example). Funny enough, you're more likely to run into a runtime bug in a weakly typed language like C++ than any other language you listed.

Go is simple and gets the job done in most cases. It compiles much faster than any other programming language I've ever used and that alone makes it a viable tool for rapid production. Go has grown up a fair amount since its inception (module system, better garbage collection, etc.). I don't use Go for financial applications because it doesn't have a built-in decimal type, but it is possible it might in the future.

After doing my financial programming in C#, I've switched to F#. It seems to be perfect for those types of applications. The syntax is clean and concise compared to C#. However, it requires you to think functionally and it compiles more slowly. I've programmed for more than half my life and I'm not convinced that object-oriented programming is any better than functional programming.
 
After doing my financial programming in C#, I've switched to F#. It seems to be perfect for those types of applications. The syntax is clean and concise compared to C#. However, it requires you to think functionally and it compiles more slowly. I've programmed for more than half my life and I'm not convinced that object-oriented programming is any better than functional programming.

They're different paradigms for tackling a problem. Functional programming is hip right now. I programmed for 3-4 years in Scala professionally. It was nice, mostly because passing functions around was first-class. I still adapt things I learned doing FP professionally to everywhere I go (flatmapping, etc). I would argue they can approximate the same solution. I don't necessarily prefer OO but I see it's uses. I went from Scala, to Java and did that until now, where I do Python professionally. I've also done some C and C++ work. I actually really enjoy C.

As for Go I haven't experienced these lightning fast compile times. On a large project (100k+ lines) it wasn't any faster than C++. At least with C++ there are mature build systems such as LLVM, Ninja, etc that use caching to help. I will revisit Go again some day. Perhaps after it's been around for a decade.

Most of my trading stuff I've since ported to C#. I really enjoy the language because it feels like a refined Java. I've written a handful of apps in F#. F# is nice because it's OCaml with .NET bolted on so you get the best of both worlds. IIRC with very little modification you can drop an OCaml program into F# and run it.
 
You can easily learn C# I bet. .NET also has Visual Basic so you might not even have to switch language unless you have a need for that.

The main immediate difference is that the syntax is very different as C# is from the C language family. So most keywords has to be learnt from scratch even though they do the same things (mostly) as comparable keywords in Visual Basic.

It's a little more involved than this. If you are using VBA for excel, you probably aren't using WPF or winforms etc. You won't automatically have your grid of cells to work with in C#.

Most Excel VBA-only coders are essentially used to just writing 'scripts.'
 
Mostly using qMake supplied by qt creator ,but over the years have not looked under the hood.

C++ is my first learnt lang and so far have stuck to it, used it while working as game developer and in the past 5-6 years started to gradually focuse on data mining research.

Sometimes i think that i should learn faster lang for prototyping like python as qt ide supports it.
Viable ideas could always be ported to C and optimized for performace.
But now i have 50k+ lines of code written in C and i dont think you can just compile python and C together.
The interface would probably not be worth the effort.

Overall i am very satisfied with how many tasks qt libraries cover and their documentation quality+all fits well together due to same supplier, saving countless lines of code.
Setting up intel compiler on windows to have best performance C++ compiler was problematic with qt.
 
Last edited:
Back
Top