The core technical challenge was Entity Resolution. I didn't want to burn thousands of tokens feeding raw threads to an LLM just to identify common terms like "W\u00fcsthof" or "VG-10."
My solution was a 4-step "Inverse Masking" pipeline:
Local Fuzzy Match: Fuse.js scans text against a local catalog of ~500 brands/steels. This catches 80% of entities for zero cost.
Masking: I replace found matches in the text (e.g., "[ENTITY_FOUND]") to hide them.
LLM Discovery: I send the remaining text to an LLM (via OpenRouter). Because the "loud" common entities are masked, the model is much better at spotting obscure artisan makers or slang that the fuzzy matcher missed.
Sentiment: The LLM assigns context-aware scores (-1.0 to 1.0) to distinguish between "I want to buy X" (Neutral) and "X chipped immediately" (Negative).
The Findings (from 542 threads):
MagnaCut is the technical winner (28:1 positive ratio).
Ginsan (Silver 3) is the practical kitchen favorite. It beats premium powdered steels simply because users almost never complain about chipping.
VG-10 is the most controversial. Highest volume, but statistically the highest ratio of "micro-chipping" complaints.
Stack is Node.js and MongoDB. Full charts and breakdown are in the post.
I'm curious if others are using this "Fuzzy First -> LLM Second" pattern for NER tasks to save context window, or if I should just move to vector embeddings for the initial lookup?
https://new.knife.day/blog/reddit-steel-sentiment-analysis"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"I built a hybrid Fuzzy/LLM pipeline to rank knife steels from Reddit"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://new.knife.day/blog/reddit-steel-sentiment-analysis"}},"_tags":["comment","author_p-s-v","story_46913051"],"author":"p-s-v","comment_text":"Text I built a scraping project to solve a niche domain problem: figuring out which chef knife steels are actually "good" vs. just marketing hype, based on r/chefknives archives.
The core technical challenge was Entity Resolution. I didn't want to burn thousands of tokens feeding raw threads to an LLM just to identify common terms like "W\u00fcsthof" or "VG-10."
My solution was a 4-step "Inverse Masking" pipeline:
Local Fuzzy Match: Fuse.js scans text against a local catalog of ~500 brands/steels. This catches 80% of entities for zero cost.
Masking: I replace found matches in the text (e.g., "[ENTITY_FOUND]") to hide them.
LLM Discovery: I send the remaining text to an LLM (via OpenRouter). Because the "loud" common entities are masked, the model is much better at spotting obscure artisan makers or slang that the fuzzy matcher missed.
Sentiment: The LLM assigns context-aware scores (-1.0 to 1.0) to distinguish between "I want to buy X" (Neutral) and "X chipped immediately" (Negative).
The Findings (from 542 threads):
MagnaCut is the technical winner (28:1 positive ratio).
Ginsan (Silver 3) is the practical kitchen favorite. It beats premium powdered steels simply because users almost never complain about chipping.
VG-10 is the most controversial. Highest volume, but statistically the highest ratio of "micro-chipping" complaints.
Stack is Node.js and MongoDB. Full charts and breakdown are in the post.
I'm curious if others are using this "Fuzzy First -> LLM Second" pattern for NER tasks to save context window, or if I should just move to vector embeddings for the initial lookup?
https://new.knife.day/blog/reddit-steel-sentiment-analysis","created_at":"2026-02-06T14:13:54Z","created_at_i":1770387234,"objectID":"46913052","parent_id":46913051,"story_id":46913051,"story_title":"I built a hybrid Fuzzy/LLM pipeline to rank knife steels from Reddit","story_url":"https://new.knife.day/blog/reddit-steel-sentiment-analysis","updated_at":"2026-03-05T23:31:15Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"Jet_Xu"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"Thank you for such detailed and thoughtful feedback! Really appreciate the time you took to analyze our claims and point out the areas needing more clarity.
You're absolutely right about the marketing copy - we should be more precise and transparent about what we actually do vs. what's aspirational.
Regarding "understanding code relationships and dependencies": We're building a knowledge graph of the entire repository that captures code relationships, function calls, and module dependencies. This graph is then used with GraphRAG to fetch relevant context for each PR, allowing the LLM to understand the broader impact of changes.
Important to note: We take privacy very seriously. All code analysis happens in-memory during PR reviews - we don't permanently store any source code or build persistent knowledge bases from customer code. The knowledge graph is generated and used on-the-fly for each review session.
This approach helps us work around context window limitations while providing meaningful insights. However, I should note that this feature is still under active development - we're continuously improving the graph construction and relevancy matching.
Would love to hear your thoughts on this approach. We're committed to building something genuinely useful for developers rather than just another LLM wrapper."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: LlamaPReview \u2013 AI GitHub PR reviewer that learns your codebase"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/marketplace/llamapreview"}},"_tags":["comment","author_Jet_Xu","story_41996859"],"author":"Jet_Xu","comment_text":"Thank you for such detailed and thoughtful feedback! Really appreciate the time you took to analyze our claims and point out the areas needing more clarity.
You're absolutely right about the marketing copy - we should be more precise and transparent about what we actually do vs. what's aspirational.
Regarding "understanding code relationships and dependencies": We're building a knowledge graph of the entire repository that captures code relationships, function calls, and module dependencies. This graph is then used with GraphRAG to fetch relevant context for each PR, allowing the LLM to understand the broader impact of changes.
Important to note: We take privacy very seriously. All code analysis happens in-memory during PR reviews - we don't permanently store any source code or build persistent knowledge bases from customer code. The knowledge graph is generated and used on-the-fly for each review session.
This approach helps us work around context window limitations while providing meaningful insights. However, I should note that this feature is still under active development - we're continuously improving the graph construction and relevancy matching.
Would love to hear your thoughts on this approach. We're committed to building something genuinely useful for developers rather than just another LLM wrapper.","created_at":"2024-11-01T06:03:56Z","created_at_i":1730441036,"objectID":"42014442","parent_id":41998664,"story_id":41996859,"story_title":"Show HN: LlamaPReview \u2013 AI GitHub PR reviewer that learns your codebase","story_url":"https://github.com/marketplace/llamapreview","updated_at":"2024-11-01T06:04:40Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"cosmoblk"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"I co-founded SmartrMail (email marketing SaaS, 12K ecommerce customers, acquired 2022). When I left, I no longer had access to the sending data I'd spent years learning from, billions of sent emails, deliverability patterns, things that actually move email engagement
Cos' I don't have this data anymore, I built the best thing I could to help with the email marketing I currently do:
---
my research process
Multiple sprints across all major email marketing topics. The crawler pulled 908 sources: Litmus, Klaviyo, HubSpot, Campaign Monitor, and Salesforce annual reports; practitioner blogs; academic research; platform documentation; Reddit threads; Shopify forums; and community discussions on X. From those, I extracted 4,798 discrete insights. Every claim that made it into the guide has a source. Anything that was unsourced opinion got cut.
That produced EMB v4: Over 80k words across 16 chapters. After two editorial passes, cutting duplicates, consolidating overlapping sections, removing anything that didn't earn its place it landed at 55,000 words. I reached out to all the email experts cited for their feedback too, over half contributed and made changes. I was stoked with that.
---
the skill vs bible issue
The full 55K-word guide is too big for a context window. You can't just point Claude at the whole thing and expect coherent answers.
So the SKILL.md is a separate, condensed extraction: the key frameworks, benchmarks, practitioner names, and tactical thresholds that fit in context. When you ask Claude a question with the skill installed, it's drawing on a structured summary rather than trying to retrieve from a raw document dump.
but this creates a problem not solved yet: the skill and the Bible can drift. As the Bible gets updated (experts send corrections, better data emerges), the skill needs to be manually kept in sync. The obvious fix is an MCP server that connects them so changes to the Bible automatically propagate to the skill. I'll probably build that with the next big update to the bible.
---
the data gap
I saw on smartmail that occasionally "conversion wisdom" or email best practise would actually not line up with our real, aggregate sending data. Eg "best time of the week to send a newsletter is 9am tue/thurs". Nope. Was absolutely a case by case solution and the rule of thumb here would often hurt email engagement. \nSo, the weakness of this project is it's built on published research, not proprietary sending data. Published benchmarks are backward-looking, aggregated across wildly different use cases, and often produced by ESPs with an incentive to make email look good.
What I'd really want is anonymised send-level data from real campaigns. Subject line \u2192 open rate, across list sizes, industries, send times. Body structure \u2192 click rate. Flow configuration \u2192 revenue per recipient.
If anyone is working on this or has access to send-level data and wants to contribute, I'm very interested.
---
the ESP integration problem
The other thing I'm frustrated by is AI connections into ESPs are still terrible. Most platforms have API coverage for basic CRUD operations but nothing close to what you'd need to actually run a campaign from Claude. You can pull subscriber counts. You can't meaningfully analyse flow performance, trigger segment rebuilds, or get real deliverability diagnostics programmatically.
A few ESPs are starting to add MCP servers (it's mentioned in Ch 14 of the guide), but it's early and patchy. Until that's solved, the skill is advisory, it can tell you what to do, it can't do it for you. That gap is worth building toward.
---
what's live now
Install:
git clone https://github.com/CosmoBlk/email-marketing-bible.git ~/.claude/skills/email-marketing-bible\nMIT licensed. No paywall. No email gate. No affiliate links.
Happy to answer questions!"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["marketing"],"value":"Show HN: I built a 55K-word email marketing knowledge base and Claude Code skill"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://www.emailmarketingskill.com/"}},"_tags":["story","author_cosmoblk","story_47096335","show_hn"],"author":"cosmoblk","children":[47097358],"created_at":"2026-02-21T01:08:21Z","created_at_i":1771636101,"num_comments":2,"objectID":"47096335","points":10,"story_id":47096335,"story_text":"I co-founded SmartrMail (email marketing SaaS, 12K ecommerce customers, acquired 2022). When I left, I no longer had access to the sending data I'd spent years learning from, billions of sent emails, deliverability patterns, things that actually move email engagement
Cos' I don't have this data anymore, I built the best thing I could to help with the email marketing I currently do:
---
my research process
Multiple sprints across all major email marketing topics. The crawler pulled 908 sources: Litmus, Klaviyo, HubSpot, Campaign Monitor, and Salesforce annual reports; practitioner blogs; academic research; platform documentation; Reddit threads; Shopify forums; and community discussions on X. From those, I extracted 4,798 discrete insights. Every claim that made it into the guide has a source. Anything that was unsourced opinion got cut.
That produced EMB v4: Over 80k words across 16 chapters. After two editorial passes, cutting duplicates, consolidating overlapping sections, removing anything that didn't earn its place it landed at 55,000 words. I reached out to all the email experts cited for their feedback too, over half contributed and made changes. I was stoked with that.
---
the skill vs bible issue
The full 55K-word guide is too big for a context window. You can't just point Claude at the whole thing and expect coherent answers.
So the SKILL.md is a separate, condensed extraction: the key frameworks, benchmarks, practitioner names, and tactical thresholds that fit in context. When you ask Claude a question with the skill installed, it's drawing on a structured summary rather than trying to retrieve from a raw document dump.
but this creates a problem not solved yet: the skill and the Bible can drift. As the Bible gets updated (experts send corrections, better data emerges), the skill needs to be manually kept in sync. The obvious fix is an MCP server that connects them so changes to the Bible automatically propagate to the skill. I'll probably build that with the next big update to the bible.
---
the data gap
I saw on smartmail that occasionally "conversion wisdom" or email best practise would actually not line up with our real, aggregate sending data. Eg "best time of the week to send a newsletter is 9am tue/thurs". Nope. Was absolutely a case by case solution and the rule of thumb here would often hurt email engagement. \nSo, the weakness of this project is it's built on published research, not proprietary sending data. Published benchmarks are backward-looking, aggregated across wildly different use cases, and often produced by ESPs with an incentive to make email look good.
What I'd really want is anonymised send-level data from real campaigns. Subject line \u2192 open rate, across list sizes, industries, send times. Body structure \u2192 click rate. Flow configuration \u2192 revenue per recipient.
If anyone is working on this or has access to send-level data and wants to contribute, I'm very interested.
---
the ESP integration problem
The other thing I'm frustrated by is AI connections into ESPs are still terrible. Most platforms have API coverage for basic CRUD operations but nothing close to what you'd need to actually run a campaign from Claude. You can pull subscriber counts. You can't meaningfully analyse flow performance, trigger segment rebuilds, or get real deliverability diagnostics programmatically.
A few ESPs are starting to add MCP servers (it's mentioned in Ch 14 of the guide), but it's early and patchy. Until that's solved, the skill is advisory, it can tell you what to do, it can't do it for you. That gap is worth building toward.
---
what's live now
Install:
git clone https://github.com/CosmoBlk/email-marketing-bible.git ~/.claude/skills/email-marketing-bible\nMIT licensed. No paywall. No email gate. No affiliate links.
Happy to answer questions!","title":"Show HN: I built a 55K-word email marketing knowledge base and Claude Code skill","updated_at":"2026-03-05T23:36:51Z","url":"https://www.emailmarketingskill.com/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"BryanLegend"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"Notes from Andrej Karpathy (https://twitter.com/karpathy/status/1781028605709234613)
Releasing 8B and 70B (both base and finetuned) models, strong-performing in their model class (but we'll see when the rankings come in @ \n@lmsysorg\n :))\n400B is still training, but already encroaching GPT-4 territory (e.g. 84.8 MMLU vs. 86.5 4Turbo).
Tokenizer: number of tokens was 4X'd from 32K (Llama 2) -> 128K (Llama 3). With more tokens you can compress sequences more in length, cites 15% fewer tokens, and see better downstream performance.
Architecture: no major changes from the Llama 2. In Llama 2 only the bigger models used Grouped Query Attention (GQA), but now all models do, including the smallest 8B model. This is a parameter sharing scheme for the keys/values in the Attention, which reduces the size of the KV cache during inference. This is a good, welcome, complexity reducing fix and optimization.
Sequence length: the maximum number of tokens in the context window was bumped up to 8192 from 4096 (Llama 2) and 2048 (Llama 1). This bump is welcome, but quite small w.r.t. modern standards (e.g. GPT-4 is 128K) and I think many people were hoping for more on this axis. May come as a finetune later (?).
Training data. Llama 2 was trained on 2 trillion tokens, Llama 3 was bumped to 15T training dataset, including a lot of attention that went to quality, 4X more code tokens, and 5% non-en tokens over 30 languages. (5% is fairly low w.r.t. non-en:en mix, so certainly this is a mostly English model, but it's quite nice that it is > 0).
Scaling laws. Very notably, 15T is a very very large dataset to train with for a model as "small" as 8B parameters, and this is not normally done and is new and very welcome. The Chinchilla "compute optimal" point for an 8B model would be train it for ~200B tokens. (if you were only interested to get the most "bang-for-the-buck" w.r.t. model performance at that size). So this is training ~75X beyond that point, which is unusual but personally, I think extremely welcome. Because we all get a very capable model that is very small, easy to work with and inference. Meta mentions that even at this point, the model doesn't seem to be "converging" in a standard sense. In other words, the LLMs we work with all the time are significantly undertrained by a factor of maybe 100-1000X or more, nowhere near their point of convergence. Actually, I really hope people carry forward the trend and start training and releasing even more long-trained, even smaller models.
Systems. Llama 3 is cited as trained with 16K GPUs at observed throughput of 400 TFLOPS. It's not mentioned but I'm assuming these are H100s at fp16, which clock in at 1,979 TFLOPS in NVIDIA marketing materials. But we all know their tiny asterisk (*with sparsity) is doing a lot of work, and really you want to divide this number by 2 to get the real TFLOPS of ~990. Why is sparsity counting as FLOPS? Anyway, focus Andrej. So 400/990 ~= 40% utilization, not too bad at all across that many GPUs! A lot of really solid engineering is required to get here at that scale.
TLDR: Super welcome, Llama 3 is a very capable looking model release from Meta. Sticking to fundamentals, spending a lot of quality time on solid systems and data work, exploring the limits of long-training models. Also very excited for the 400B model, which could be the first GPT-4 grade open source release. I think many people will ask for more context length.
Personal ask: I think I'm not alone to say that I'd also love much smaller models than 8B, for educational work, and for (unit) testing, and maybe for embedded applications etc. Ideally at ~100M and ~1B scale.
Talk to it at https://meta.ai\nIntegration with https://github.com/pytorch/torchtune"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Meta Llama 3"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://llama.meta.com/llama3/"}},"_tags":["comment","author_BryanLegend","story_40077533"],"author":"BryanLegend","comment_text":"Notes from Andrej Karpathy (https://twitter.com/karpathy/status/1781028605709234613)
Releasing 8B and 70B (both base and finetuned) models, strong-performing in their model class (but we'll see when the rankings come in @ \n@lmsysorg\n :))\n400B is still training, but already encroaching GPT-4 territory (e.g. 84.8 MMLU vs. 86.5 4Turbo).
Tokenizer: number of tokens was 4X'd from 32K (Llama 2) -> 128K (Llama 3). With more tokens you can compress sequences more in length, cites 15% fewer tokens, and see better downstream performance.
Architecture: no major changes from the Llama 2. In Llama 2 only the bigger models used Grouped Query Attention (GQA), but now all models do, including the smallest 8B model. This is a parameter sharing scheme for the keys/values in the Attention, which reduces the size of the KV cache during inference. This is a good, welcome, complexity reducing fix and optimization.
Sequence length: the maximum number of tokens in the context window was bumped up to 8192 from 4096 (Llama 2) and 2048 (Llama 1). This bump is welcome, but quite small w.r.t. modern standards (e.g. GPT-4 is 128K) and I think many people were hoping for more on this axis. May come as a finetune later (?).
Training data. Llama 2 was trained on 2 trillion tokens, Llama 3 was bumped to 15T training dataset, including a lot of attention that went to quality, 4X more code tokens, and 5% non-en tokens over 30 languages. (5% is fairly low w.r.t. non-en:en mix, so certainly this is a mostly English model, but it's quite nice that it is > 0).
Scaling laws. Very notably, 15T is a very very large dataset to train with for a model as "small" as 8B parameters, and this is not normally done and is new and very welcome. The Chinchilla "compute optimal" point for an 8B model would be train it for ~200B tokens. (if you were only interested to get the most "bang-for-the-buck" w.r.t. model performance at that size). So this is training ~75X beyond that point, which is unusual but personally, I think extremely welcome. Because we all get a very capable model that is very small, easy to work with and inference. Meta mentions that even at this point, the model doesn't seem to be "converging" in a standard sense. In other words, the LLMs we work with all the time are significantly undertrained by a factor of maybe 100-1000X or more, nowhere near their point of convergence. Actually, I really hope people carry forward the trend and start training and releasing even more long-trained, even smaller models.
Systems. Llama 3 is cited as trained with 16K GPUs at observed throughput of 400 TFLOPS. It's not mentioned but I'm assuming these are H100s at fp16, which clock in at 1,979 TFLOPS in NVIDIA marketing materials. But we all know their tiny asterisk (*with sparsity) is doing a lot of work, and really you want to divide this number by 2 to get the real TFLOPS of ~990. Why is sparsity counting as FLOPS? Anyway, focus Andrej. So 400/990 ~= 40% utilization, not too bad at all across that many GPUs! A lot of really solid engineering is required to get here at that scale.
TLDR: Super welcome, Llama 3 is a very capable looking model release from Meta. Sticking to fundamentals, spending a lot of quality time on solid systems and data work, exploring the limits of long-training models. Also very excited for the 400B model, which could be the first GPT-4 grade open source release. I think many people will ask for more context length.
Personal ask: I think I'm not alone to say that I'd also love much smaller models than 8B, for educational work, and for (unit) testing, and maybe for embedded applications etc. Ideally at ~100M and ~1B scale.
Talk to it at https://meta.ai\nIntegration with https://github.com/pytorch/torchtune","created_at":"2024-04-18T18:57:11Z","created_at_i":1713466631,"objectID":"40079537","parent_id":40077533,"story_id":40077533,"story_title":"Meta Llama 3","story_url":"https://llama.meta.com/llama3/","updated_at":"2024-09-20T16:52:28Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"akinmaurice"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"Hey HN
I\u2019m one of the founders of DailyStack.
Like many of you, my workday used to start with a "tab crawl." I\u2019d open Gmail, then Outlook for the corporate stuff, then scan Todoist, check the Linear board for dev tickets, and finally peek at Asana for the marketing syncs. By the time I actually knew what my day looked like, I\u2019d already context-switched five times and lost the "deep work" window of my morning.
We built DailyStack to solve this. It\u2019s a single, high-signal brief that aggregates your day before you dive into the noise.
How it works
We currently support Gmail, Google Calendar, Outlook, Todoist, Linear, and Asana. Instead of just giving you a long list of notifications, we pull the "delta" from the last 24 hours:
Email: Highlights threads that actually need a reply vs. newsletters.
Tasks: Correlates what you finished yesterday in Linear/Asana with what\u2019s actually due today in Todoist.
Calendar: A unified view across Google and Outlook so you don't double-book your life.
The "No-Storage" Architecture
We know that asking for access to your email and task managers is a massive request. We decided early on to build this with a zero-persistence mindset for your private content:
Ephemeral Processing: We don't save your email bodies or task descriptions to a database.
On-the-go Summaries: When you request your brief, we fetch the data via OAuth, process the summary in memory, and serve it. We don't "store and mine" your data to build a profile or train models.
Token Security: We only store the encrypted refresh tokens needed to communicate with the APIs.
Why we\u2019re doing this
There have been a hundred "all-in-one" inboxes that failed because they tried to replace the tools themselves. We aren't trying to be a new email client or a new task manager. We just want to be the 5-minute summary you read before you open those tools.
We\u2019d love your brutal feedback:
The Trust Gap: If you see a summary of a Linear ticket or a Gmail thread, do you feel an immediate urge to go verify the "real" version? How can we make the summary feel authoritative enough to trust?
Missing Pieces: What is the one tool that, if missing, makes an aggregator like this useless for you? (We're looking at GitHub and Notion next).
The Workflow: Does a "Morning Brief" actually fit your routine, or do you prefer to live in the raw feeds all day?
We\u2019re pre-revenue and still figuring out the best way to make this indispensable. I\u2019ll be in the comments all day to talk about the ETL challenges, API rate-limiting nightmares, or anything else.
Thanks!"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: DailyStack \u2013 Aggregate your work tools into a 5-minute morning brief"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://dailystack.ai/"}},"_tags":["story","author_akinmaurice","story_47247650","show_hn"],"author":"akinmaurice","created_at":"2026-03-04T14:17:00Z","created_at_i":1772633820,"num_comments":0,"objectID":"47247650","points":1,"story_id":47247650,"story_text":"Hey HN
I\u2019m one of the founders of DailyStack.
Like many of you, my workday used to start with a "tab crawl." I\u2019d open Gmail, then Outlook for the corporate stuff, then scan Todoist, check the Linear board for dev tickets, and finally peek at Asana for the marketing syncs. By the time I actually knew what my day looked like, I\u2019d already context-switched five times and lost the "deep work" window of my morning.
We built DailyStack to solve this. It\u2019s a single, high-signal brief that aggregates your day before you dive into the noise.
How it works
We currently support Gmail, Google Calendar, Outlook, Todoist, Linear, and Asana. Instead of just giving you a long list of notifications, we pull the "delta" from the last 24 hours:
Email: Highlights threads that actually need a reply vs. newsletters.
Tasks: Correlates what you finished yesterday in Linear/Asana with what\u2019s actually due today in Todoist.
Calendar: A unified view across Google and Outlook so you don't double-book your life.
The "No-Storage" Architecture
We know that asking for access to your email and task managers is a massive request. We decided early on to build this with a zero-persistence mindset for your private content:
Ephemeral Processing: We don't save your email bodies or task descriptions to a database.
On-the-go Summaries: When you request your brief, we fetch the data via OAuth, process the summary in memory, and serve it. We don't "store and mine" your data to build a profile or train models.
Token Security: We only store the encrypted refresh tokens needed to communicate with the APIs.
Why we\u2019re doing this
There have been a hundred "all-in-one" inboxes that failed because they tried to replace the tools themselves. We aren't trying to be a new email client or a new task manager. We just want to be the 5-minute summary you read before you open those tools.
We\u2019d love your brutal feedback:
The Trust Gap: If you see a summary of a Linear ticket or a Gmail thread, do you feel an immediate urge to go verify the "real" version? How can we make the summary feel authoritative enough to trust?
Missing Pieces: What is the one tool that, if missing, makes an aggregator like this useless for you? (We're looking at GitHub and Notion next).
The Workflow: Does a "Morning Brief" actually fit your routine, or do you prefer to live in the raw feeds all day?
We\u2019re pre-revenue and still figuring out the best way to make this indispensable. I\u2019ll be in the comments all day to talk about the ETL challenges, API rate-limiting nightmares, or anything else.
Thanks!","title":"Show HN: DailyStack \u2013 Aggregate your work tools into a 5-minute morning brief","updated_at":"2026-03-05T23:41:25Z","url":"https://dailystack.ai/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"enraged_camel"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"I'd like to provide a different perspective. This is anecdotal, but I have \"before and after\" experiences that directly relate to the topic.
I work as a Presales Engineer for a software company. At the beginning of this year, we switched from a 90s-style cubicle setup with dividers to an open-office setup. When the change was announced last Fall, everyone on my team voiced heavy skepticism. We thought that it would greatly reduce our productivity as well as the already-limited privacy we had in an office setting. We had systems in place to limit the interruptions coming from the sales and marketing teams, and an open-office plan would practically nullify them. But we were the minority, so our concerns were swept under the rug. Fortunately, things ended up well.
For the sales and marketing folks, things have improved greatly since we made the switch six months ago. They now sit with us in the same \"pods,\" which are collections of IKEA desks. Each pod has several sales and marketing people and one or two Presales Engineers. They can ask us any question at any time. And unlike with email, which we could previously put on a queue to answer later, or instant message, which we could ignore or temporarily block (DND mode), we now have to provide the answer right away. They can in turn relay that answer to the sales channel or the customer with a much shorter turnaround, which helps to advance and close sales faster.
As for us Presales Engineers, I cannot tell if the net result has been a positive or a negative. On the one hand, we now have a lot more distractions. We see people walking around and we hear their conversations. I personally have memorized the phone scripts that my pod-mates use when they call customers. Another negative has been team cohesion. In the previous setup, my team used to sit together on one side of the floor and we could have conversations much more easily. Now we're spread out all over the place, and most of our interaction occurs via group chat (Google Hangout).
Collectively, everyone's morale has improved quite a bit. It's very refreshing to be able to walk out of the elevator into an open space, as opposed to a claustrophobic, never-ending group of cubicles. And all the pods are right in front of the windows, which means everyone can now enjoy the Southern California sun and the great view of mountains we have from our office. I purchased a nice set of noise-canceling headphones (company paid for it) that I put on whenever I need to get in \"the zone\" to work on things that need deep concentration, and I trained my pod-mates to not interrupt me when I have them on. It works really well. Other pods have also come up with systems that work for them.
Another collective benefit has been social cohesion. When the teams were separate last year, there was an \"us vs. them\" mentality. The sales folks saw us engineers as unapproachable, and we saw the sales folks as needy and disruptive. Now though, each pod has become a team, and people are much more willing to help each other and collaborate. This has eliminated a lot of the tension in the office.
It is worth noting that the above occurred within the context of a sales team and the engineers that support that team. That said, I'm pretty sure it can also apply to developers. We actually had one of the developer teams move to our floor a couple of months ago (the A/C unit on their floor broke). At first they had the same fears as my team of engineers had. But it ended up working out really well. Sales people never interrupt them, and communication flows from sales to Presales (my team), and from there to this group of developers. Being able to walk over to their desks to show the problem we're having and walking through it in person, as opposed to trying to do it over email or IM, has been a great boon for both parties.
Bottom line: open-offices have their pros and cons. The vast majority of Hacker News users are technical people and it seems most of them are adamantly against open-office plans. But as someone who has a bigger picture view (since I work with everyone in the company), I can tell you that there is a chance the net result can be a positive if the plan is implemented well."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Open-plan offices make employees less productive, less happy, and more sick"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"http://qz.com/85400/moving-to-open-plan-offices-makes-employees-less-productive-less-happy-and-more-likely-to-get-sick/#"}},"_tags":["comment","author_enraged_camel","story_5767414"],"author":"enraged_camel","comment_text":"I'd like to provide a different perspective. This is anecdotal, but I have \"before and after\" experiences that directly relate to the topic.
I work as a Presales Engineer for a software company. At the beginning of this year, we switched from a 90s-style cubicle setup with dividers to an open-office setup. When the change was announced last Fall, everyone on my team voiced heavy skepticism. We thought that it would greatly reduce our productivity as well as the already-limited privacy we had in an office setting. We had systems in place to limit the interruptions coming from the sales and marketing teams, and an open-office plan would practically nullify them. But we were the minority, so our concerns were swept under the rug. Fortunately, things ended up well.
For the sales and marketing folks, things have improved greatly since we made the switch six months ago. They now sit with us in the same \"pods,\" which are collections of IKEA desks. Each pod has several sales and marketing people and one or two Presales Engineers. They can ask us any question at any time. And unlike with email, which we could previously put on a queue to answer later, or instant message, which we could ignore or temporarily block (DND mode), we now have to provide the answer right away. They can in turn relay that answer to the sales channel or the customer with a much shorter turnaround, which helps to advance and close sales faster.
As for us Presales Engineers, I cannot tell if the net result has been a positive or a negative. On the one hand, we now have a lot more distractions. We see people walking around and we hear their conversations. I personally have memorized the phone scripts that my pod-mates use when they call customers. Another negative has been team cohesion. In the previous setup, my team used to sit together on one side of the floor and we could have conversations much more easily. Now we're spread out all over the place, and most of our interaction occurs via group chat (Google Hangout).
Collectively, everyone's morale has improved quite a bit. It's very refreshing to be able to walk out of the elevator into an open space, as opposed to a claustrophobic, never-ending group of cubicles. And all the pods are right in front of the windows, which means everyone can now enjoy the Southern California sun and the great view of mountains we have from our office. I purchased a nice set of noise-canceling headphones (company paid for it) that I put on whenever I need to get in \"the zone\" to work on things that need deep concentration, and I trained my pod-mates to not interrupt me when I have them on. It works really well. Other pods have also come up with systems that work for them.
Another collective benefit has been social cohesion. When the teams were separate last year, there was an \"us vs. them\" mentality. The sales folks saw us engineers as unapproachable, and we saw the sales folks as needy and disruptive. Now though, each pod has become a team, and people are much more willing to help each other and collaborate. This has eliminated a lot of the tension in the office.
It is worth noting that the above occurred within the context of a sales team and the engineers that support that team. That said, I'm pretty sure it can also apply to developers. We actually had one of the developer teams move to our floor a couple of months ago (the A/C unit on their floor broke). At first they had the same fears as my team of engineers had. But it ended up working out really well. Sales people never interrupt them, and communication flows from sales to Presales (my team), and from there to this group of developers. Being able to walk over to their desks to show the problem we're having and walking through it in person, as opposed to trying to do it over email or IM, has been a great boon for both parties.
Bottom line: open-offices have their pros and cons. The vast majority of Hacker News users are technical people and it seems most of them are adamantly against open-office plans. But as someone who has a bigger picture view (since I work with everyone in the company), I can tell you that there is a chance the net result can be a positive if the plan is implemented well.","created_at":"2013-05-25T23:13:58Z","created_at_i":1369523638,"objectID":"5769244","parent_id":5767414,"points":null,"story_id":5767414,"story_title":"Open-plan offices make employees less productive, less happy, and more sick","story_url":"http://qz.com/85400/moving-to-open-plan-offices-makes-employees-less-productive-less-happy-and-more-likely-to-get-sick/#","updated_at":"2023-09-06T21:35:59Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"olliej"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"This was going to be an addendum to the above comment, but I took to long trying hunt down old marketing material for Virtual PC, anyway here is the intended addendum.
[edit: Giant addendum starts here, in response to comments in replies, rather than saying variations on the same things over and over again. Nothing preceding this comment has been changed or edited from my original post. As I've said elsewhere, I really wish HN provided edit history on comments]
First off, for people saying I'm talking about containers, I was not considering them at all, I consider them as essentially tangential to the topic virtual machines and virtualization. I haven't looked into modern container infrastructure to really understand the full nuances, my exceptionally vague understanding of the current state of the art is the original full-vm-per-container model docker, et al introduced has been improved somewhat to allow better resource sharing between clients and the host hardware than a full-vm provides but is still using some degree of virtualization provide better security boundaries than just basic chroot containers could ever do. I'm curious about exactly how much of a kernel modern container VMs have based on the comments in this thread, and if I ever have time between my job and long winded HN comments I'll try to look into it - I\u2019d love good references on exactly how kernel level operation is split and shared in modern container implementation .
Anyway, as commonly used virtualization means "code in the VM runs directly of the host CPU\u201d, and has done for more than two decades now. An academic definition of a virtual machine may include emulation, but if you see any company or person talking about supporting virtual machines, virtual hosts, or virtualized X in any medium - press, marketing, article (tech or non-tech press) - you will know that they are not talking about emulation. The reason is simply that the technical characteristics of an emulated machine are so drastically different that any use of emulation has to be explicitly called out. Hence absent any qualifier virtualization means the client code executes directly on the the host hardware. The introduction of hypervisors in the CPU simply meant that more things could be done directly on the host hardware without requiring expensive/slow runtime support from the VM runtime, it did not change the semantics of what \u201cvirtual machine\u201d meant vs emulation even at the time CPUs with direct support for virtualization entered the general market.
Back when VMWare first started out a big part of their marketing and performance messaging boiled down to "Virtual Machine != emulation" and that push was pretty much the death knell for a definition of \u201cvirtualization\u201d and \u201cvirtual machine\u201d including emulation. As that model took off, "hypervisor" was introduced to general industry as the term for the CPU mechanism to support virtualization more efficiently (I'm sure in specialized industries and academia it existed earlier) by allowing _more_ code to run directly, but for the most part there was no change to userspace code in the client machine. Most of the early \u201chypervisor\u201d/virtualization extensions (I believe on ARM they\u2019re explicitly called the \u201cvirtualization extensions\u201d, because virtualization does not mean emulation) were just making it easier for VM runtimes to avoid having to do anything to code running in kernel mode so that that code could be left to run directly on the host CPU as well.
The closest emulation ever got to "virtualization" in non-academic terminology that I recall is arguably "Virtual PC for Mac" (for young folk virtual pc was an x86 emulator for PPC macs that was eventually bought by MS IIRC), which said \u201cvirtual pc\u201d in the product name. It did not however use the term virtualization, and was only ever described as explicitly emulation in the tech press, I certainly have no recollection of it ever even being described as a virtual machine even back during its window of relevance. I'd love to find actual marketing material from the era because I'm genuinely curious what it actually said, but the product name seems to have been reused over time so google search results are fairly terrible and my attempts in the wayback machine are also fairly scattershot :-/
But if we look at the context, once apple moved to x86, from Day 1 the Parallels marketing that targeted the rapidly irrelevant "virtual pc for Mac" product talked about using virtualization rather than emulation to get better performance than virtual pc, but the rapid decline in the relevance of PPC meant that talking about not being emulation ceased being relevant because the meaning of a virtual machine in common language is native client running code directly on the host CPU.
So while an academic argument may have existed that virtualization included emulation in the past, the reality is that the meaning of virtualization in any non-academic context since basically the late 90s has been client code runs directly on the host CPU, not via emulation. Given that well established meaning, my statement that virtualization of a non-host-architecture OS is definitionally not possible is a reasonable statement, that is correct in the context of the modern use of the word virtualization (again we\u2019re talking a couple of decades here, not some change in the last few months).
If you really want to argue with this, I want you to ask yourself how you would respond if you had leased a hundred virtualized x86 systems, and then found half of them were running at 10% the speed of the rest because they were actually emulated hardware, and then if you think that a lawyer for that company would be able to successfully argue that the definition of \u201cvirtualization include emulation\u201d would pass muster when you could bring in reps from every other provider, and every commercial VM product and none of them involved emulation, and every article published for decades about how [cloud or otherwise] VMs work (none of which mention emulation). If you really think that your response would be \u201cah you got me\u201d, or that that argument would work in court, then fair play to you, you\u2019re ok with your definition and we\u2019ll have to agree to disagree, but I think the vast majority of people in tech would disagree."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Tart: VMs on macOS using Apple's native Virtualization.Framework"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://tart.run/"}},"_tags":["comment","author_olliej","story_39059100"],"author":"olliej","comment_text":"This was going to be an addendum to the above comment, but I took to long trying hunt down old marketing material for Virtual PC, anyway here is the intended addendum.
[edit: Giant addendum starts here, in response to comments in replies, rather than saying variations on the same things over and over again. Nothing preceding this comment has been changed or edited from my original post. As I've said elsewhere, I really wish HN provided edit history on comments]
First off, for people saying I'm talking about containers, I was not considering them at all, I consider them as essentially tangential to the topic virtual machines and virtualization. I haven't looked into modern container infrastructure to really understand the full nuances, my exceptionally vague understanding of the current state of the art is the original full-vm-per-container model docker, et al introduced has been improved somewhat to allow better resource sharing between clients and the host hardware than a full-vm provides but is still using some degree of virtualization provide better security boundaries than just basic chroot containers could ever do. I'm curious about exactly how much of a kernel modern container VMs have based on the comments in this thread, and if I ever have time between my job and long winded HN comments I'll try to look into it - I\u2019d love good references on exactly how kernel level operation is split and shared in modern container implementation .
Anyway, as commonly used virtualization means "code in the VM runs directly of the host CPU\u201d, and has done for more than two decades now. An academic definition of a virtual machine may include emulation, but if you see any company or person talking about supporting virtual machines, virtual hosts, or virtualized X in any medium - press, marketing, article (tech or non-tech press) - you will know that they are not talking about emulation. The reason is simply that the technical characteristics of an emulated machine are so drastically different that any use of emulation has to be explicitly called out. Hence absent any qualifier virtualization means the client code executes directly on the the host hardware. The introduction of hypervisors in the CPU simply meant that more things could be done directly on the host hardware without requiring expensive/slow runtime support from the VM runtime, it did not change the semantics of what \u201cvirtual machine\u201d meant vs emulation even at the time CPUs with direct support for virtualization entered the general market.
Back when VMWare first started out a big part of their marketing and performance messaging boiled down to "Virtual Machine != emulation" and that push was pretty much the death knell for a definition of \u201cvirtualization\u201d and \u201cvirtual machine\u201d including emulation. As that model took off, "hypervisor" was introduced to general industry as the term for the CPU mechanism to support virtualization more efficiently (I'm sure in specialized industries and academia it existed earlier) by allowing _more_ code to run directly, but for the most part there was no change to userspace code in the client machine. Most of the early \u201chypervisor\u201d/virtualization extensions (I believe on ARM they\u2019re explicitly called the \u201cvirtualization extensions\u201d, because virtualization does not mean emulation) were just making it easier for VM runtimes to avoid having to do anything to code running in kernel mode so that that code could be left to run directly on the host CPU as well.
The closest emulation ever got to "virtualization" in non-academic terminology that I recall is arguably "Virtual PC for Mac" (for young folk virtual pc was an x86 emulator for PPC macs that was eventually bought by MS IIRC), which said \u201cvirtual pc\u201d in the product name. It did not however use the term virtualization, and was only ever described as explicitly emulation in the tech press, I certainly have no recollection of it ever even being described as a virtual machine even back during its window of relevance. I'd love to find actual marketing material from the era because I'm genuinely curious what it actually said, but the product name seems to have been reused over time so google search results are fairly terrible and my attempts in the wayback machine are also fairly scattershot :-/
But if we look at the context, once apple moved to x86, from Day 1 the Parallels marketing that targeted the rapidly irrelevant "virtual pc for Mac" product talked about using virtualization rather than emulation to get better performance than virtual pc, but the rapid decline in the relevance of PPC meant that talking about not being emulation ceased being relevant because the meaning of a virtual machine in common language is native client running code directly on the host CPU.
So while an academic argument may have existed that virtualization included emulation in the past, the reality is that the meaning of virtualization in any non-academic context since basically the late 90s has been client code runs directly on the host CPU, not via emulation. Given that well established meaning, my statement that virtualization of a non-host-architecture OS is definitionally not possible is a reasonable statement, that is correct in the context of the modern use of the word virtualization (again we\u2019re talking a couple of decades here, not some change in the last few months).
If you really want to argue with this, I want you to ask yourself how you would respond if you had leased a hundred virtualized x86 systems, and then found half of them were running at 10% the speed of the rest because they were actually emulated hardware, and then if you think that a lawyer for that company would be able to successfully argue that the definition of \u201cvirtualization include emulation\u201d would pass muster when you could bring in reps from every other provider, and every commercial VM product and none of them involved emulation, and every article published for decades about how [cloud or otherwise] VMs work (none of which mention emulation). If you really think that your response would be \u201cah you got me\u201d, or that that argument would work in court, then fair play to you, you\u2019re ok with your definition and we\u2019ll have to agree to disagree, but I think the vast majority of people in tech would disagree.","created_at":"2024-01-19T21:34:20Z","created_at_i":1705700060,"objectID":"39061507","parent_id":39059531,"story_id":39059100,"story_title":"Tart: VMs on macOS using Apple's native Virtualization.Framework","story_url":"https://tart.run/","updated_at":"2024-09-20T16:14:45Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"mkromberg"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["context","window","marketing","vs","actual"],"value":"Thanks for your interest in the future of Dyalog! You are absolutely right that 2019 marks a kind of watershed moment for Dyalog. The original two-man development team who built version 1.0 of the interpreter (released in 1983) recently celebrated their 70th birthdays. At the beginning of this year, both of them had reduced working hours to about half time. Geoff Streeter remains in good health, but sadly John Scholes passed away in February.
Before Dyalog was acquired in 2005 and Gitte and I came in as CEO and CTO, the team working on Dyalog APL consisted of 5 people. Today that number is heading towards 25, several of whom were hired over the past decade to be ready to take over the work of Scholes and Streeter.
Gitte's comment about "not enough" young people signing up needs some context. The problem was actually caused by significantly increased interest in APL, which made us realise that our "classical" registration process was putting potential new users off. It was often taking too long to get people a copy of Dyalog APL because of the manual processing that was required, people were confused by the licensing terms and afraid of using the software \u2013 and many young people are just allergic to providing any information about themselves online. Now, APL is available for Windows, Linux (including the Pi) and macOS with no questions asked \u2013 for non-commercial use.
Losing Jay as CTO was a bit of a blow, but I think we are on the way to recovery. Now that he has completed his PhD on the subject of a parallelizing compiler (research that Dyalog has funded for the last 5 years), Aaron Hsu will join young guns Marshall Lochbaum and Adam Brudzewsky at Dyalog, and we have one more C developer joining the team in the UK in January. We hired two fresh APL consultants in the USA in 2019, and will be looking to hire two more in 2020 to support both existing and new business. I've been in the APL business for 40 years now, and my opinion is that the "kids" at Dyalog are every bit as impressive as Scholes and Streeter were at the same age; the shoes will be filled. There is as much young talent at Dyalog as there has ever been working on any APL interpreter, throughout the 50+ year history of the language.
As the team grows, we are able to afford having one or two team members focusing most of their efforts on performance. These efforts have accelerated over time, as first Nic Delcros, then Roger Hui and now Marshall have spent significant time rewriting primitive functions to take advantage of vector instructions and new hashing, sorting and other algorithms that have been evolved over the last four decades. Hardware has evolved in ways which mean that many of the old algorithms are sub-optimal on modern chips where the relative speed of CPU cycles vs memory access is completely different from the Z8000. Yes, Marshall is very good indeed, but I can't see a problem there . Performance has improved consistently in most of the last ten versions of Dyalog APL, and I hope we may see even more spectacular improvements in the next decade, both in the interpreter and in GPU-based parallel compilers.
We have much work to do: In addition to language and performance work, we expect Aaron to work with Richard Park, another new recruit who was added to the team last year, to work on training materials and documentation \u2013 and with Marshall, Roger and myself on quote evangelism unquote; talks at Lambdaconf, Functionalconf and perhaps some new conferences in 2020 and beyond (invitations welcome!).
For decades, Dyalog was a company that made a very comfortable living providing a better APL interpreter to clients who converted to Dyalog APL after initially purchasing an APL system from one of the companies that did serious marketing of APL interpreters: companies like IBM, STSC and I.P.Sharp Associates. Thanks to our recent growth, and the fact that Dyalog APL now has decent tooling not only under Microsoft Windows, but Linux and macOS too, we are now starting to focus on developing new business and attracting the next generation of APL developers.
I'm sorry to hear that we appear "directionless" to you. I will admit that it is an interesting challenge to keep existing customers satisfied (which should always remain the first priority for any organisation \u2013 put on your oxygen mask before helping others) while also working on attracting completely new groups of users. The rate of development of new language features, development tools and libraries for Dyalog APL is as high as it has been for any APL interpreter in history, at the same time as we are making significant performance improvements. Is there anything in particular that you miss?
Aaron's work on using APL as a high-performance tool for manipulating tree structures demonstrates that APL is more relevant than ever before, as a programming language that has a natural mechanical sympathy with modern hardware, and allows relatively unskilled developers to write extremely efficient solutions without using complex tricks. I recently had the pleasure of sharing a podium with Aaron in Mumbai as part of the JioTalks series, where we covered some of the reasons why APL is a tool worth taking a look at in 2020, even though the core of the language is more than 50 years old: https://jiotalks.com/watch/204/home/Morten_Kromberg_&_Aaron_...
Thanks for asking!"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Getting Started with APL (2017)"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.sacrideo.us/getting-started-with-apl/"}},"_tags":["comment","author_mkromberg","story_21642670"],"author":"mkromberg","children":[21739582,21766619],"comment_text":"Thanks for your interest in the future of Dyalog! You are absolutely right that 2019 marks a kind of watershed moment for Dyalog. The original two-man development team who built version 1.0 of the interpreter (released in 1983) recently celebrated their 70th birthdays. At the beginning of this year, both of them had reduced working hours to about half time. Geoff Streeter remains in good health, but sadly John Scholes passed away in February.
Before Dyalog was acquired in 2005 and Gitte and I came in as CEO and CTO, the team working on Dyalog APL consisted of 5 people. Today that number is heading towards 25, several of whom were hired over the past decade to be ready to take over the work of Scholes and Streeter.
Gitte's comment about "not enough" young people signing up needs some context. The problem was actually caused by significantly increased interest in APL, which made us realise that our "classical" registration process was putting potential new users off. It was often taking too long to get people a copy of Dyalog APL because of the manual processing that was required, people were confused by the licensing terms and afraid of using the software \u2013 and many young people are just allergic to providing any information about themselves online. Now, APL is available for Windows, Linux (including the Pi) and macOS with no questions asked \u2013 for non-commercial use.
Losing Jay as CTO was a bit of a blow, but I think we are on the way to recovery. Now that he has completed his PhD on the subject of a parallelizing compiler (research that Dyalog has funded for the last 5 years), Aaron Hsu will join young guns Marshall Lochbaum and Adam Brudzewsky at Dyalog, and we have one more C developer joining the team in the UK in January. We hired two fresh APL consultants in the USA in 2019, and will be looking to hire two more in 2020 to support both existing and new business. I've been in the APL business for 40 years now, and my opinion is that the "kids" at Dyalog are every bit as impressive as Scholes and Streeter were at the same age; the shoes will be filled. There is as much young talent at Dyalog as there has ever been working on any APL interpreter, throughout the 50+ year history of the language.
As the team grows, we are able to afford having one or two team members focusing most of their efforts on performance. These efforts have accelerated over time, as first Nic Delcros, then Roger Hui and now Marshall have spent significant time rewriting primitive functions to take advantage of vector instructions and new hashing, sorting and other algorithms that have been evolved over the last four decades. Hardware has evolved in ways which mean that many of the old algorithms are sub-optimal on modern chips where the relative speed of CPU cycles vs memory access is completely different from the Z8000. Yes, Marshall is very good indeed, but I can't see a problem there . Performance has improved consistently in most of the last ten versions of Dyalog APL, and I hope we may see even more spectacular improvements in the next decade, both in the interpreter and in GPU-based parallel compilers.
We have much work to do: In addition to language and performance work, we expect Aaron to work with Richard Park, another new recruit who was added to the team last year, to work on training materials and documentation \u2013 and with Marshall, Roger and myself on quote evangelism unquote; talks at Lambdaconf, Functionalconf and perhaps some new conferences in 2020 and beyond (invitations welcome!).
For decades, Dyalog was a company that made a very comfortable living providing a better APL interpreter to clients who converted to Dyalog APL after initially purchasing an APL system from one of the companies that did serious marketing of APL interpreters: companies like IBM, STSC and I.P.Sharp Associates. Thanks to our recent growth, and the fact that Dyalog APL now has decent tooling not only under Microsoft Windows, but Linux and macOS too, we are now starting to focus on developing new business and attracting the next generation of APL developers.
I'm sorry to hear that we appear "directionless" to you. I will admit that it is an interesting challenge to keep existing customers satisfied (which should always remain the first priority for any organisation \u2013 put on your oxygen mask before helping others) while also working on attracting completely new groups of users. The rate of development of new language features, development tools and libraries for Dyalog APL is as high as it has been for any APL interpreter in history, at the same time as we are making significant performance improvements. Is there anything in particular that you miss?
Aaron's work on using APL as a high-performance tool for manipulating tree structures demonstrates that APL is more relevant than ever before, as a programming language that has a natural mechanical sympathy with modern hardware, and allows relatively unskilled developers to write extremely efficient solutions without using complex tricks. I recently had the pleasure of sharing a podium with Aaron in Mumbai as part of the JioTalks series, where we covered some of the reasons why APL is a tool worth taking a look at in 2020, even though the core of the language is more than 50 years old: https://jiotalks.com/watch/204/home/Morten_Kromberg_&_Aaron_...
Thanks for asking!","created_at":"2019-12-03T10:40:20Z","created_at_i":1575369620,"objectID":"21691319","parent_id":21655482,"story_id":21642670,"story_title":"Getting Started with APL (2017)","story_url":"https://www.sacrideo.us/getting-started-with-apl/","updated_at":"2024-09-20T05:24:15Z"}],"hitsPerPage":20,"nbHits":8,"nbPages":1,"page":0,"params":"query=context+window+marketing+vs+actual&advancedSyntax=true&analyticsTags=backend","processingTimeMS":24,"processingTimingsMS":{"_request":{"queue":38,"roundTrip":14},"afterFetch":{"format":{"highlighting":2,"total":2},"merge":{"mergeLoop":{"prepareNextHit":1,"total":1},"total":2},"total":2},"fetch":{"query":9,"scanning":10,"total":20},"total":24},"query":"context window marketing vs actual","serverTimeMS":65}