I also think that the GC of D is really a nice feature. Sometimes you want manual memory management in low level code, but there is also a ton of stuff where it doesn't really matter and a GC just makes things easier. For example, if you're writing an in-memory cache service, you really don't want the cache entries themselves to be tracked by the GC since the GC is often unaware of the actual access patterns and just gets in the way, but most of the other components of that service are better served with a GC.
On unexpected nice feature of the GC is it makes compile time function execution easy, as the engine for it doesn't have to emulate your custom storage allocator.
One of our goals was to reduce as much as possible a R4RS compliant REPL, because it is quite reasonably sized and doesn't support macros (we managed to fit it in 6.5KB!). We considered R7RS, but it was a bit too ambitious for a first goal. We plan on supporting R7RS eventually !
If you want to read more, section 4 of "A R4RS Compliant REPL in 7 KB" explains our rationale behind the choice of R4RS :
I can't answer as to why the current version is R4RS specifically. The original version Marc and I wrote was running a subset of R4RS. We tried to minimize the code as much as possible (hitting the 4K mark), so it's very possible we just wanted to get everything out of the way (it has been a while)
Have you tried playing around with the humidity? If I have it set too low, that definitely makes a big difference. There are also other treatments for sleep apnea that you could look into which might work better.
Heated humidification is a crux. You only "really" need it when you have a mouth leak ( or if it's awfully cold and dry in your bedroom, like an igloo?). It also vastly increases the amount of maintenance you have to do on your CPAP device. It makes your masks wear our quicker. It makes your hose more susceptible to growing mold etc.
The real trick is to fix your mouth leak. Getting on the right pressure helps with that. Fixing your sleeping position can help. Mouth tape can help. A cervical collar can help. Anything that will help you keep your mouth shut at night.
Humidification is necessary in any place where winter is cold. Cold air can't hold much absolute moisture, and as you warm it up to room temperature, the relative humidity of that air drops. In Canada you will often find the relative humidity of the room to be below 10% in winter, which is uncomfortable even in the absence of CPAP.
I don't use the heated hose, but the humidity is invaluable since my sinuses often end up clogged if I don't use it. However, I also live in a desert and regularly have ~20% humidity in my house.
I don't think doc comments are warranted in every case and definitely don't think you need to document every single parameter, return value, etc. for every single function, but they sure do come in handy for complicated APIs.
> In recent years I see more people arguing that whys do not belong in comments either, that they can be embedded into LongFunctionNames or the names of test cases.
Who is arguing this? Usually, if I'm adding a comment on why something is done a particular way, it's something that is going to take at least a full sentence to explain if not a whole paragraph.
Best practice IMO would be to wrap the closable thing in a wrapper object that handles the case where Close is called multiple times and then defer close that one as well as closing at the end of the function. Another idea would be to define a small lambda that either returns the input value or returns error if Close returns an error if you want to use early returns.
You missed the ole' reliable, temp tables. I always end up using them heavily for non-trivial analytic queries since it gives you so much control over query execution.
In terms of actually using SQL more effectively, I think the ideal is just a small utility to use reflection and map a ResultSet (or equivalent) into a strongly typed object using reflection.
Even inserts can get tricky because there are so many different knobs you can tune. It's pretty rare that people just need to insert into a single table with no additional selects beforehand which means there is room to play around with preemptive locking, isolation level, etc.
This really doesn't reflect the actual structure of Western music for those without absolute pitch (the vast majority of people). Instead, it's pretty much just relations that matter between pitches which makes things way more difficult to visualize. Mixing red and blue gives you a different color than red and green, but A-C is pretty much the same as Bb-Db, they're both minor thirds.
If you want to analyze it algorithmically, you probably need to start looking at topology or something so that you can correctly relate musical structures in a way that is resistant to transposition.
> This really doesn't reflect the actual structure of Western music for those without absolute pitch (the vast majority of people).
It’s worth mentioning that this includes the majority of musicians (professional and otherwise). Having perfect pitch is in no way necessary to be an excellent player or composer of music. Most of the greats didn’t have it. It is a very rare skill.
> A few years ago, I had a student who had taken one of these teach-yourself-perfect-pitch courses, and I was fascinated. From time to time I would fire random notes at him in an attempt to catch him out... and I never could! When I asked him how the system worked, he explained that the best analogy was to think in terms of colours. For argument's sake, he said, think of Bb as sounding blue and D as a greenish colour.
> Intrigued, I played him a Cmaj7 chord and asked him to identify that. He shook his head in despair, and gave up almost immediately.
> "Can't you just home in on each note in turn and identify the separate colours?" I suggested. "Then you could look at your list of notes and figure out what the chord is."
> "No, you don't understand," he replied. "All chords sound brown to me!"
- Guthrie Govan, from Creative Guitar 1 (which, incidentally, I had to dig out to find the quote)
I imagine that Guthrie's student might have been able to combine his pitch training with some ear training and have a better shot of hearing something other than mud when he heard a chord, but this always stuck in my brain and I'm reminded of it every time I see discussions of perfect pitch. It seems like perfect pitch is barely even desirable, in this framing.
And that makes sense, as discussed elsewhere in the thread, what you really want as a musician is a great sense of relative pitch, and a good mind-body connection between the fingers and ears that lets you easily turn what you're hearing in your mind - where your ear wants to go - into actual music.
And probably more of a curse than a blessing. Having to listen to Kind of Blue with the awful knowledge that it's 1/3 of a tone flat from concert pitch: that's something I'd rather live without.
Among professional musicians who have perfect pitch, it's considered more of a curse than a blessing.
It's very rare, and also not very correlated with musical skill. Some people just have it, seemingly inherently, even without any formal musical training.
> If you want to analyze it algorithmically, you probably need to start looking at topology or something so that you can correctly relate musical structures in a way that is resistant to transposition.
Here's some alternative keyboard layouts that explore that idea:
reply