887 karma · joined October 30, 2009
The second sentence:
> I want a language where I can be much more productive than in C: one in which I do not fear the correctness of my memory management, and don’t have to go through major gyrations to write concurrent code.
And we see no explicit demonstrations of the memory management and no demonstrations at all of the concurrency model. It feels like the author had a more fleshed out post in mind, but either decided it was running too long or got bored before reaching the conclusion. :\
Out of all the features this is the one I am most excited about.
Of course LOC != 'contributed value'. Much as people don't assemble in thousands to see a jukebox progress through a playlist but do for the experience created by a skilled DJ, the last 5% is the most significant 5% in programming (and perhaps, all creative endeavors)
Currently at the end of the line all audio is going to be squished, at best, to 44k 16bit sampling. Most audio production and engineering is going to be taking place at quality levels than what the final CD master is, however. /During/ production working with higher quality sources such as a higher sample rate, higher bit rate FLAC sample means that you can 'do more' with it before you start running into the walls of unintended artifacts and distortions. Think of all audio processing as a destructive process - the more you have to begin with the more you can do before the destruction becomes noticeable.
Intentionally ignoring all debates on aesthetics, obviously in many artistic circumstances the artifacts and distortions are desired - but when they are you can easily achieve them in an /intentional/ way. Avoiding them is the challenge.
And there are certain contexts in which it is more noticeable: high quality club sound-systems, custom home and car audio systems, etc. My vehicle's sound system has a very easily audible difference between a 128KBS MP3 and an uncompressed 44k 16bit CD for most music, and in that context you are damn sure I want the uncompressed experience. So having an /option/ for high quality lossless formats such as FLAC available universally helps to serve such niche markets.
tldr; if you are in camp that can't tell the difference, you shouldn't download the higher quality larger files. They aren't for you. Other camps do exist, however.
edit edit: And this all ignores the annoying 'loudness war' trend in modern audio engineering to use compressors to flatten out all dynamic range anyway. Le sigh
I am not using Buzz, so if I am wrong please correct me, but isn't it like this: Google+ -> You opt in your followers to hear your broadcast. Google Buzz/Twitter -> Your followers opt in to hear your broadcast.
(And then there is FB with mutual opting)
I have almost entirely started to avoid facebook for this reason. You always just see the bright side of everyone's lives, which can make you feel depressed if you are unsatisfied with your own. Likewise HN shows you the cutting edge tech, the cool startup scene, and a lot of writing from some very VERY smart people. If you don't feel like you measure up it can be an addictive way to reinforce that feeling.
Clearly I am competing with a deeper psychological issue and the ultimate solution is to accept myself, accept my limitations, and find peace. I am working toward this and making some progress. But I wonder if my progress is being hindered by such a flood of exposure of awesome like HN.
Many (most) thoughts I have had reading HN are clearly irrational. "I can't be happy unless I am founding a startup." "I can't be happy unless I am programming in language X." "I can't be happy unless I move to SV."
I recently severed a very close relationship because I finally accepted how toxic it was, even if that toxicity was largely due to my own loose boundaries. I wonder if my relationship with HN is the same thing.
tldr: HN exposes you to so much awesome that sometimes you feel like shit in comparison. You're not.
We have a 'core' team and a number of 'project' teams. Every team works in it's own branch, which is branched off of the trunk. The trunk is kept in a stable state.
No one really uses 'feature branches', which I find to be a shame (but hey, it is SVN so feature branches are not convenient). Rather the core team creates a new branch each sprint (scrum here - 3 week sprints) and at the end of each sprint merges it back into trunk, after it has been verified as stable by QA.
Project teams can either branch from trunk and stay off in la-la land until the end of time, or they can try to keep up to date. The way they keep up to date is by merging back into trunk and then starting a new branch. This process is hand-held by the core team and goes through the same QA process to verify it is stable.
How does this work out? Well merging is a major event. Aside from the stability verification work that goes into it a core team member (usually the lead) will generally spend about a day on a merge/branch cycle.
So it feels slow and big, but we do maintain a very stable trunk.
SVN merge issues are a pain, but so long as we never do double-merges (that is, merging a branch into trunk, continuing work on the branch, then merging it a 2nd time into trunk) we seem to avoid the most common gotcha.
This system would be improved if a DVCS was used instead. The issues to adoption of that are both user and technical. We have a wide range of users of widely varying technical skill levels so the ecosystem of SVN clients is going to be difficult to usurp. We also store a LOT of very large binary data in the repository and would find it very inconvenient to separate it out (code version and asset version matching is essential), and in my tests of using git-svn (for example) it simply choked. Like an exception thrown from the bowls of the client type of choke.
Regret is suffering. It is being attached to a different reality that you "should" be experiencing that is somehow better than the reality you are in. Everything that happened in your life, every single stupid thing, was required/essential/instrumental in your life being exactly as it is right now.
I hope we can make use of this thread as a means to help us guide future decisions without it functioning as a way to make us feel regret. Do not expend energy suffering over that which is not only out of your control, but an illusion. Your past is not reality: you are, right here, right now.
This, in my mind, is the most insightful line in this post. When cloud hosts like Heroku and GAE are discussed on HN often there is cost comparison between using them and doing the sysadmin yourself on Amazon, or on your own hardware. But what doesn't figure in is that with Heroku and GAE (I suppose more with GAE) is that you aren't just getting out of doing your own sysadmin work, you are also getting out of doing a lot of scaling work yourself. This is expensive, difficult work. Of course it is the type of work that many of us here salivate over, but that's another issue... ;)