Week 0: Turtle Roadmap

Josh Filstrup  —  3 years, 4 months ago [Edited 30 minutes later]
Turtle aims to be a very simple, efficient podcast application. It will be written in C++, particularly, it will be written in a relatively modern dialect of C++. My philosophy on this differs from many in the HMD community on this point, as many prefer C89, or a very restricted subset of C++. Their reasons for doing so are perfectly reasonable(template hell, compile times, etc), however, I choose to reach for a few abstractions which I have vetted over the years and have found their value to outweigh the problems. While our approaches may be somewhat dissimilar, our goals are the same: to write software that respects the users time. In the context of Turtle, this means instantaneous load up times, multithreaded background file fetching and a latency-free user interface. I believe all of these things to be perfectly achievable with good planning and diligence.

In keeping with the notion of good planning, I'd like to lay out a roadmap for Turtle's development. My weekdays are fully consumed by my day job(coupled with a currently atrocious commute), so development as well as updates such as this one will usually happen on weekends.

With respect to diligence, I plan to have some nice performance tracking metrics once the initial implementation is in place. This will allow me to be very directed and quantitative in my approach.

There are four major areas of implementation: fetching, parsing, playback and user interface. Data parsing is where I'll be starting my efforts, as its the area I'm most familiar with. This involves writing an RSS parser to understand traditional podcast feeds. In the coming days I'll release a technical post detailing my initial implementation for the parser.

Stay Tuned!
Bill Strong  —  3 years, 4 months ago
This sounds great. Have you thought about grouping Audiobook features into your application? Audible seems like the only good audiobook player I have found, and it doesn't really play audiobooks from other sources. The only constraints that adding it would cause would be the idea that Audiobook order is important, and some audiobooks can be more than 5 hours long in one file. I would assume that pausing and bookmarking your place would all be features added for podcast playback.

Adding support for the M4B format as a feature would be required as well, I guess. (Yes, I know this is how feature bloat starts.)

These two use cases seem to be closely aligned as far as I can tell. I could be wrong, and would love to know where I am wrong if so.
Josh Filstrup  —  3 years, 4 months ago
Hey Bill,

Thanks for checking it out! I think that's a totally cool idea. I'll probably wait until I get the podcasting portion to a place where I'm happy with it, but that sounds like a worthwhile evolution for it in the future.
Jay Waggle  —  3 years, 4 months ago
This project sounds interesting! :) I don't want to derail the discussion about your plans (or worse, start a war), but I'm curious which "abstractions" or features of C++ you find value in.
Josh Filstrup  —  3 years, 4 months ago [Edited 8 minutes later]
Hey ZedZull,

Thanks! I'm happy to have an open discussion about it(no wars here :)). Here's a small rundown of features I can recall:

  • constexpr: Provides a type-safe way of achieving the same thing.
  • strongly typed enums Again, provides a type safe alternative to traditional C-style enums which can be implicitly converted to ints.
  • nullptr Type safe alternative to NULL.
  • static_assert: Compile time asserts can be really useful.
  • vector/algorithm Most of my code tends to be centered around linear arrays. I don't see any point of reimplementing things like a binary search or more complex things like rotating/gathering sections. With that said, a lot of the STL is bonkers(unordered_map comes to mind, it will wreck your cache) and I don't like using it.
  • range-for/auto Unless I need access to an iterator/pointer, this is easier
  • braced-initialization This is just a convenience I find useful, especially in functions returning some struct-type.

Feel free to follow up on anything you disagree with or just want to discuss further.
Log in to comment