I would say that ATL is a domain-specific language (DSL). To be more accurate, I would refer to it as a horizontal DSL (as opposed to typical DSLs, which are usually focused on some vertical subject domain or industry). Another thought is that, if I were writing HPC-focused software today (and, especially, tomorrow), I would definitely much prefer Julia to ATL or similar niche solutions. Thanks to (likely) not much of, if any, loss of performance, but an incomparably wider spectrum of potential applications and covered domains. Plus, an additional benefit of lack of the two-language problem.
Well, firstly, milestones is a standard term and even in this article the author points to the expected definition (reference to Wikipedia article). His "special version of milestones" does not imply another definition, but rather just some specific attributes / requirements / expectations for milestones to be used. Secondly, the author presents project and milestones as a dichotomy ("Most engineering organizations focus on delivering projects. They should focus on milestones instead." - emphasis mine), whereas, in fact, you cannot define milestones outside of the context of a project. Thus, it is not an either/or situation, but rather one where both concepts simply exist. One more note: while both concepts are orthogonal, they are not fully independent; meaning that milestones must belong to a project and a project can have milestones.
If you would decide or have to use Vue for a complex project today, would you use Tailwind with Vue? If yes, why? If no, why not? Would your answer and rationale change in cases, when you decide or have to use a Web application framework like Nuxt or a UI component library like Vuetify and PrimeVue?
I'm happy that we agree on this. Having said that, I would note that your example, while certainly valid, is IMHO of a too small scale (literally and figuratively - the latter with regard to complexity) to comprehensively illustrate the "mental models" concept. When I think about mental models, I'm thinking more about analysis frameworks typically applied to much larger and usually much more complex systems than technical ones, mostly sociotechnical and socioeconomic systems (e.g., open source ecosystem, startup ecosystem, innovation, science, corporations, stock market, finance, economy, policies, politics, society, history).
I think that "mental models" is not what you imply and others in this thread talk about. A more appropriate term would be [life | work | other] "principles".
Congratulations on your launch and good luck! The following are my initial impressions and thoughts upon a brief review of your product. Hope this helps.
1. It seems that pretty much all of the functionality that your platform offers could be quite easily re-implemented (assuming relevant in-house B2B sales knowledge and experience) by using one of comprehensive general team collaboration & task management platforms (e.g., Asana). It would be much cheaper on a per-seat basis in the long term as well as incomparably less limiting in terms of external application integrations.
2. It appears that your unique selling proposition is bundling B2B sales functionality with relevant playbooks (in the form of templates) and on-demand help by B2B sales experts.
3. Apparently, your platform belongs to the "sales enablement" category of SaaS platforms (with the focus on B2B sales). If I'm right on the classification, how do you position your product among relevant competing platforms (e.g., Outreach, Salesloft, Reply, Dock, Gong)?
4. Application integration limits are not attractive. So is the platform fee (apparently, it's not refundable if, for whatever reason, your customer decides to bail out in several months after onboarding). Pricing seems to be on the high side (see my point #1). Moreover, considering that this is a B2B-focused platform, I would make the solo tier free. That would not decrease your revenue much, since B2B sales is mostly a team sport, but might enable you to use the strength of now very popular Product-Led Growth (PLG) strategy to grow revenue in a more organic fashion (yes, I know that you offer a free trial, however, AFAIK it doesn't have as large of a positive effect as a free tier).
5. Last point is more of a curiosity question: why does a 13-person startup need a 24-person(!) Product Advisory Board?
Just ran across this relevant nice little article, which I found quite interesting: https://arstechnica.com/gadgets/2021/09/android-to-take-an-u.... I hope that people who interacted with me in this sub-thread (and other folks here) will enjoy reading it as well.
Good points. Though I'm a bit confused by your reply. Are you saying that LineageOS folks do not always or, at least, mostly use the latest AOSP common kernels for their relevant ROMs (as opposed to "some open source kernel fixes")?
Obviously, not all devices have up-to-date kernels. It depends on whether they are supported by relevant Android distributions. That's why I used the phrase "quite up-to-date" instead of just "up-to-date". Unfortunately for you, LineageOS has stopped supporting i9300 Samsung Galaxy S3 with the latest official release being 14.1, which is based on Nougat (Android 7.1.2).
Having said that, I ran across the following post that describes successful installation of LineageOS 18.1 (Android 11) ROM on Samsung Galaxy S3 i9300: https://devsjournal.com/install-lineage-os-in-galaxy-s3-i930.... This is just FYI. So, if you understand relevant risks and feel adventurous, you can try to install it on your device. Disclaimer: I'm neither affiliated with the author of the post, nor responsible for any damage that might be associated with following the advice contained in the above-linked post.
> underneath it runs a crusty old 2017 kernel full of holes of different sizes
> LineageOS and other projects can’t fix things in kernels they can’t compile
I think that you're wrong on this, that is unless you decided to use term "kernel" above too liberally, referring to all software running on a device. AFAIK, alternative Android images, such as LineageOS, include relevant - and quite up-to-date! - AOSP common kernels (aka Android common kernels or ACKs; https://source.android.com/devices/architecture/kernel/andro...), which are open source, plus some manufacturer-specific proprietary binary drivers and firmware (though there exist a related, but slowly-moving, project Replicant focused on creating and maintaining a fully open, i.e., kernel + drivers + firmware, Android distribution: https://replicant.us).