Hey everyone,
I'm not too active on the forums but I've been lurking in the background following the series here and there, mostly referencing parts of interest and not following in a sequential matter.
Recently I came across the idea of a unity build and it blew my mind in a good way. I'm not really as interested by the compilation performance benefits (although those are nice), but the epiphany was the realisation that most model languages seem to conflate code organisation and dependency management.
Now as a *cough* web developer *cough* I'm pretty familiar with the idea of organising code into modules/namespaces and using some kind of import mechanism. Conceptually most modern languages end up building up a graph of code dependencies that can be difficult to reason about of often result in annoying issues like cyclic dependencies where there cycle is a few steps removed.
Conceptually it's much simpler (and in my mind simpler is generally better) to conceptually think of most of you application as a single file/compilation unit that is split among multiple files.
When researching unity builds I noticed that the general sentiment tends to be that they are good as some kind of "compilation performance hack", but not really as a way to structure programs. I've been looking through some open source game engines (gemrb, stratagus, etc) and unexpectly none of them use a structure like this.
How common is it to structure projects where is compilation unit is a unity build in practice? My feeling is that it is uncommon, and if so is there a good reason why one might not want to build their application this way?
I'm a Clojure developer by trade so I'm pretty unfamiliar C/C++ normals and common industry practices in general so I'd love to hear opinions from people who work with C/C++ on a regular basis.
I'm not too active on the forums but I've been lurking in the background following the series here and there, mostly referencing parts of interest and not following in a sequential matter.
Recently I came across the idea of a unity build and it blew my mind in a good way. I'm not really as interested by the compilation performance benefits (although those are nice), but the epiphany was the realisation that most model languages seem to conflate code organisation and dependency management.
Now as a *cough* web developer *cough* I'm pretty familiar with the idea of organising code into modules/namespaces and using some kind of import mechanism. Conceptually most modern languages end up building up a graph of code dependencies that can be difficult to reason about of often result in annoying issues like cyclic dependencies where there cycle is a few steps removed.
Conceptually it's much simpler (and in my mind simpler is generally better) to conceptually think of most of you application as a single file/compilation unit that is split among multiple files.
When researching unity builds I noticed that the general sentiment tends to be that they are good as some kind of "compilation performance hack", but not really as a way to structure programs. I've been looking through some open source game engines (gemrb, stratagus, etc) and unexpectly none of them use a structure like this.
How common is it to structure projects where is compilation unit is a unity build in practice? My feeling is that it is uncommon, and if so is there a good reason why one might not want to build their application this way?
I'm a Clojure developer by trade so I'm pretty unfamiliar C/C++ normals and common industry practices in general so I'd love to hear opinions from people who work with C/C++ on a regular basis.
occamin
they are good as some kind of "compilation performance hack", but not really as a way to structure programs.
Exactly. Unity builds are just a way how to get good compilation performance for C/C++ compilers. Not because its "easier" to organize the code like that. Just because otherwise your compile times will be in minutes if not hours. For other languages like C# or Java this is less of an issue. You don't need to do this for these languages, because they will be doing something similar internally anyways.
occamin
I'm a Clojure developer by trade so I'm pretty unfamiliar C/C++ normals and common industry practices in general so I'd love to hear opinions from people who work with C/C++ on a regular basis.
I would express to you the opposite!
I'm a proponent of low-level things and have lived my (admittedly short) professional life encouraging folks to be close to the machine. That said, I'm exploring other programming models so I may take insights from solving problems in those languages back into my daily grind -- and perhaps every programmer should do this at some point.
I purchased Seven Languages in Seven Weeks, and one of their languages is Clojure. A book is great, but I'd love to hear a summary of your experiences developing software with it.
Hey Abner,
My overall opinion of Clojure is mixed but positive.
Clojure is quite an opinionated language (functional programming, immutable by default, data oriented, etc). These opinions tend to benefit long running applications that deal with lot of information and multithreading.
A lot of the insights you might gain from Clojure could be gained from any functional programming language in my opinion. The most interesting/unique feature of Clojure is REPL based development, that when used properly can lead to a really tight programmer feedback loop. Other languages support REPLs, but it tends to be easy to get into an inconsistent state because of mutability.
Clojure tends to favour immutable hashmaps and vectors as a way to represent data. Rick Hickey has some talks on why this is a good idea, but I think the focus on data as a way to model a problem more simply is well expressed in this talk.
Clojure has a bunch of downsides that aren't really ever discussed in my opinion:
1. The solution to every problem tends to be more abstraction. Most people who use Clojure has little idea of how things are implemented or what to do about things when they go wrong.
2. Clojure is pretty fast for a dynamic language (2-4x slower than similar Java) and takes the stance that "memory is cheap", but when you run into performance problems it can be incredibly hard to reason about (see 1). Doing low level stuff is possible but awkward and tedious in Clojure.
3. The community has gotten worse over time. In the beginning there were a lot of smart, humble people working on hard problems. Maybe it's because there are less scientists and more enterprisey web development types in the community nowadays, but fanboyism is rampant and critical thinking relatively scarce.
To be fair, I think that many communities have similar problems. I'm interested in getting closer to the machine but one of the things that I really like about Handmade Hero is that Casey calls it as he sees it without any kind of agenda. He challenges bad ideas and that is a rare thing nowadays.
Feel free to hit my with any specific questions about Clojure if you have any now or in the future.
My overall opinion of Clojure is mixed but positive.
Clojure is quite an opinionated language (functional programming, immutable by default, data oriented, etc). These opinions tend to benefit long running applications that deal with lot of information and multithreading.
A lot of the insights you might gain from Clojure could be gained from any functional programming language in my opinion. The most interesting/unique feature of Clojure is REPL based development, that when used properly can lead to a really tight programmer feedback loop. Other languages support REPLs, but it tends to be easy to get into an inconsistent state because of mutability.
Clojure tends to favour immutable hashmaps and vectors as a way to represent data. Rick Hickey has some talks on why this is a good idea, but I think the focus on data as a way to model a problem more simply is well expressed in this talk.
Clojure has a bunch of downsides that aren't really ever discussed in my opinion:
1. The solution to every problem tends to be more abstraction. Most people who use Clojure has little idea of how things are implemented or what to do about things when they go wrong.
2. Clojure is pretty fast for a dynamic language (2-4x slower than similar Java) and takes the stance that "memory is cheap", but when you run into performance problems it can be incredibly hard to reason about (see 1). Doing low level stuff is possible but awkward and tedious in Clojure.
3. The community has gotten worse over time. In the beginning there were a lot of smart, humble people working on hard problems. Maybe it's because there are less scientists and more enterprisey web development types in the community nowadays, but fanboyism is rampant and critical thinking relatively scarce.
To be fair, I think that many communities have similar problems. I'm interested in getting closer to the machine but one of the things that I really like about Handmade Hero is that Casey calls it as he sees it without any kind of agenda. He challenges bad ideas and that is a rare thing nowadays.
Feel free to hit my with any specific questions about Clojure if you have any now or in the future.