I think Cast does something like that? I haven't used it myself, so I'm not 100% sure what features they offer. But it sounds like they handle streaming audio between co-hosts, recording individual tracks, and doing the post-show editing. https://tryca.st
From the popular (in game development circles, at least) stb libraries:
>Why single-file headers?
>Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)
>There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.
>Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)
>Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.
How does header-only versus header+impl file have anything to do with deploying libraries? Versus a separate header + DLL, sure. But having an impl file isn't gonna matter if you link it all in. This sounds more like a source-vs-bin issue. What am I missing?
Worth noting that only the first two points there are relevant here, since these are not single file libraries. Also, the STB libraries work massively differently from C++ header only libs (#define STB_FOO_IMPLEMENTATION, for example).
Also, fwiw Sean Barrett also has gone on record as saying that he's not really a fan of C++ before. I'm struggling to find a specific link, but it's not really a secret.
(As a side note, to anybody who is in the need for what they do, the STB libraries are really absurdly high quality and can do exactly what you want them to 99% of the time. Highly recommend!!)
> Windows doesn't have standard directories where libraries live.
Visual Studio certainly does:
Microsoft Visual Studio 11.0\VC\include
Many people argue don't put libraries there - well then you are back to the original problem. Just as long as you don't overwrite a provided library - there are no issues. And if you do overwrite it - you get a rolled up newspaper and start beating the person who overwrote it.
It's a different directory for every version of Visual Studio (and obviously mingw doesn't use it), ergo it's not a standard directory like /usr/include
His point is that it's arguably simpler to tell people to copy a single source file to their project's source tree, than it is to help them find the include dir for whatever compiler they happen to be using. And that it's probably easier to have to manually update this file when the library is patched, than it is to coordinate manual library updates across an entire team without the use of a package manager.
The biggest value is that you don't have a link-time dependency, only compile-time. This means that you don't have to concern yourself with a lot of the versioning problems that plague C++ application deployment simply because your dependency is compiled into the binary.
You could use this technique to examine the man page for a program and infer from that what valid command line arguments would be: some terminal shells (fish, for one, possibly zsh as well?) do something like this already to support autocomplete.
Because then the thumbnail where you see your own face behaves more like a real-world mirror, which is easier to reason about if you want to adjust your position.
Retina for games may not be a big deal, but Retina for text definitely is: I notice the difference when reading on my iPad 2 vs my iPhone 4S. The distinction doesn't seem like much when you're in the middle of reading, but your eyes will definitely notice when you go from a screen that's Retina to one that isn't.
Well, the iPad Mini has a pixel density somewhere in the middle: it's higher than an iPad 1 or 2, but lower than a Retina iPad or iPhone (in fact, it's density is exactly equal to the pre-Retina iPhones)
The overall size of the screens affects your perception, too, I think: a large iPad screen feels different than a pocket-size phone screen.
As someone who knows both Javascript and Objective-C, this is less readable than either.
Underscore.js may have some useful abstractions, but they'd be better exposed as Objective-C categories rather than trying to shoehorn everything into Javascript syntax.
Looks really similar to Coffeescript. Is it safe to say that this new Javascript feature is a direct result of Coffeescript's influence? I hope so: Javascript is full of little horrors like the 'this' keyword, and it seems like it took a whole new language to convince people that it needs fixing.
I think its absolutely because of languages like coffee script that JavaScript is changing, but don't take my word for it. You can find statments from standards makers to the same effect.
This is a great talk to watch about the development of JS. It's been a while since I watched it, but the point I was making, and the point I gleaned from this talk, is that new ideas need a test bed, and according to Eich Coffeescript is one of those places where new ideas are tested, and derived from.
I don't think it matters what came first. CoffeeScript has had a great effect on hearts, and minds because you can use it. It matters that CoffeeScript exists because people can wrap there head around new concepts and ideas. Only once people really understand an idea can we determine if it's good, or bad.
Fat arrow is well understood in the JS community because of CoffeeScript, and that is one reason why people are pushing for fat arrow to be accepted. I personally think CoffeeScripts has had a very large impact on the idea.
I think it's safe to say. Arrow functions have existed in many different languages, but this particular flavor of using the fat arrow to declare a "lexical `this`" function, where the value of "this" within the function body preserves the value of "this" outside, is in CoffeeScript:
Jeremy, would you mind sharing what the inspiration was for CoffeeScript's fat arrow? Was that token inspired by another language or was it something you just came up with on your own?
Sure -- the syntax for arrow functions has been floating around for ages, in Haskell, C#, and probably most relevant for me, the "stabby lambdas" in Ruby 1.9.
One of the first ideas with CoffeeScript was to simplify function syntax, mostly because JavaScript's anonymous functions are so useful and pervasive that you end up with a lot of this:
... where the "word" function there doesn't really tell you anything meaningful about what you're trying to accomplish.
Arrows were appealing for a shorthand function syntax because of their visual representation of what happens in a (pure) function. Input goes in one side, output comes out the other. The input determines, or points to, the output. Since we use parentheses symmetrically to group parameters to a function, both when you define a function and when you call one, we arrive at this:
(input) -> output
... or with our initial example:
_.each toRemove, (key) -> delete data[key]
That was the thinking. CoffeeScript actually originally used => for all functions, but the fat arrow distinction was introduced when we introduced bound (lexical "this") functions as an alternative to normal (dynamic "this") functions.
Thanks for the detailed response. I thought it might have been inspired from Haskell or Ruby, but was surprised to find out that C# has a similar syntactic feature. So I was curious if there was an "official" etymology. Sounds like an amalgamation of all of the above.
iOS and Mac apps are a lot of fun to write and work with, for two reasons:
1) Objective-C is a pretty decent language. It's not perfect, it has some baggage, but overall it's pretty neat and has enough flexibility to build a good platform.
2) Apple has built two good platforms, in AppKit (Mac) and UIKit (iOS). These frameworks are the real secret sauce, not the language. They're comprehensive and generally well-built, and make working on Apple platforms a joy. They actually take advantage of the unique features of Obj-C.
If someone could produce a web framework of the same caliber as UIKit, I think Objective-C would make a great server-side language. But building such a framework is not easy.
https://feedbin.com
https://www.reederapp.com