mastodon.ie

4 posts4 participants0 posts today

José A. AlonsoReadings shared June 30, 2025. <a href="https://jaalonso.github.io/vestigium/posts/2025/07/01-readings_shared_07-01-25" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://jaalonso.github.io/vestigium/posts/2025/07/01-readings_shared_07-01-25</a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CompSci</a> <a href="https://mathstodon.xyz/tags/FunctionalProgramming" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#FunctionalProgramming</a> <a href="https://mathstodon.xyz/tags/Haskell" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Haskell</a> <a href="https://mathstodon.xyz/tags/ITP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ITP</a> <a href="https://mathstodon.xyz/tags/IsabelleHOL" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#IsabelleHOL</a> <a href="https://mathstodon.xyz/tags/Logic" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Logic</a> <a href="https://mathstodon.xyz/tags/Maxima" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Maxima</a> <a href="https://mathstodon.xyz/tags/Teaching" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Teaching</a>

José A. AlonsoTeaching children thinking. ~ Seymour A. Papert (1971). <a href="https://citejournal.org/volume-5/issue-3-05/seminal-articles/teaching-children-thinking" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://citejournal.org/volume-5/issue-3-05/seminal-articles/teaching-children-thinking</a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CompSci</a> <a href="https://mathstodon.xyz/tags/Teaching" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Teaching</a>

Aether~Fedi, I have a <a href="https://plasmatrap.com/tags/ComputerScience" rel="nofollow noopener noreferrer" target="_blank">#ComputerScience</a> (maybe <a href="https://plasmatrap.com/tags/Linguistics" rel="nofollow noopener noreferrer" target="_blank">#Linguistics</a> ?) Question I need your lovely guidance for ❤️:boosts_ok_gay:💙 I have a design problem about grammar ambiguity ish stuff and want to find reading, resources or theory I can check out to get a good understanding of the problem space. Particularly, I'm trying to find different techniques to use when a given word can appear in multiple parts of the syntax, in order to reduce ambiguity. I'm being deliberately vague because I'm trying to think about generalisable heuristics here, but here's an example of the type of problems I'm thinking about. Sorry it's computery: You have two strings (or lists of tokens) you want to combine into a single string, separated by a delimiter, such that both strings can be retrieved again. But, that delimiter can show up in either of the two strings. What are the ways you can sanitize the input strings or format the final string to clarify where one string ends and the other begins, and how do various restrictions in the input strings affect those precautions? Possible techniques I've thought of are: - designate an escape token and prepend all instances of the delimiter within the strings with it (eg <code>\"</code>) (which is pretty universally used nowadays) - when the delimiter appears in the string, put a repeat copy of it to distinguish it from the delimiter. e.g. <code>"this string contains "" one quote mark"</code> - Another crazy option would be interlacing the two strings so all even tokens belong to string 1 and odd ones are string 2. You'd have length difference issues, but maybe there are other solutions taking a similar thought process. So yeah I'm looking for stuff like that so I can figure out good patterns for unambiguous yet elegant grammars. For a tad more context, I'm thinking about command line argument formats, trying to think of the most user friendly ways one can handle complex data as a list of arguments. Also please boost and let me know if there's hashtags I should include etc :ablobcatheart: <a href="https://plasmatrap.com/tags/CompSci" rel="nofollow noopener noreferrer" target="_blank">#CompSci</a> <a href="https://plasmatrap.com/tags/programming" rel="nofollow noopener noreferrer" target="_blank">#programming</a> <a href="https://plasmatrap.com/tags/askfedi" rel="nofollow noopener noreferrer" target="_blank">#askfedi</a> <a href="https://plasmatrap.com/tags/TechSupport" rel="nofollow noopener noreferrer" target="_blank">#TechSupport</a>

José A. AlonsoReadings shared June 27, 2025. <a href="https://jaalonso.github.io/vestigium/posts/2025/06/28-readings_shared_06-27-25" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://jaalonso.github.io/vestigium/posts/2025/06/28-readings_shared_06-27-25</a> <a href="https://mathstodon.xyz/tags/AI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#AI</a> <a href="https://mathstodon.xyz/tags/AI4Math" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#AI4Math</a> <a href="https://mathstodon.xyz/tags/Autoformalization" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Autoformalization</a> <a href="https://mathstodon.xyz/tags/CategoryTheory" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CategoryTheory</a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CompSci</a> <a href="https://mathstodon.xyz/tags/ITP" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#ITP</a> <a href="https://mathstodon.xyz/tags/LLMs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#LLMs</a> <a href="https://mathstodon.xyz/tags/LeanProver" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#LeanProver</a> <a href="https://mathstodon.xyz/tags/Math" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Math</a> <a href="https://mathstodon.xyz/tags/Mizar" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Mizar</a>

Papers We Love📜 A New Approach to Linear Filtering and Prediction Problems [2001]By: T. Başar📖 <a href="https://github.com/papers-we-love/papers-we-love/blob/master/data_fusion/a-new-approach-to-linear-filtering-and-prediction-problems.pdf" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/papers-we-love/papers-we-love/blob/master/data_fusion/a-new-approach-to-linear-filtering-and-prediction-problems.pdf</a> 🔍 <a href="https://www.semanticscholar.org/paper/d36a38125557764efb0fd2b3ef0a4cde515b3861" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.semanticscholar.org/paper/d36a38125557764efb0fd2b3ef0a4cde515b3861</a><a href="https://mstdn.io/tags/semanticScholar" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#semanticScholar</a> <a href="https://mstdn.io/tags/paperswelove" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#paperswelove</a> <a href="https://mstdn.io/tags/research" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#research</a> <a href="https://mstdn.io/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a>

José A. AlonsoCategory theory and its implications in computer science. ~ Srinivasa Ramanujan, Mary Cartwright, Henri Poincaré. <a href="https://www.mathresearchjournal.com/uploads/archives/20250613123444_14.pdf" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://www.mathresearchjournal.com/uploads/archives/20250613123444_14.pdf</a> <a href="https://mathstodon.xyz/tags/CategoryTheory" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CategoryTheory</a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CompSci</a>

LobstersBitsets match regular expressions, compactly (2013) <a href="https://lobste.rs/s/u06sy7" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://lobste.rs/s/u06sy7</a> <a href="https://mastodon.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mastodon.social/tags/performance" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#performance</a> <a href="https://pvk.ca/Blog/2013/06/23/bitsets-match-regular-expressions/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://pvk.ca/Blog/2013/06/23/bitsets-match-regular-expressions/</a>

vruzDirect WASM→DOM access doesn't leave JavaScript behind - JS could use the same fast path! We could even build Fagnani's exact templating API as a reference implementation on top of it. But unlike a JS-only solution, the platform stays open for potentially superior approaches in ANY language. Rust might build something faster. Zig might build something smaller. That's the kind of competition through collaboration that drives innovation. Everybody wins wins wins. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#wasm</a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#javascript</a>

vruzWeb's superpower is its openness. Native JS templating makes JS more ergonomic. Direct WASM→DOM makes the web more OPEN. Which better serves the platform's future? The web shouldn't privilege one language. True platform evolution means equal access to core capabilities for all languages. That's how we get the next generation of web innovation. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/webstandards" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webstandards</a> <a href="https://mstdn.social/tags/opensource" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#opensource</a>

vruzInstead of standardizing one templating syntax (that'll be bikeshedded to death), give us the primitive: fast DOM access from any language. Let a thousand templating libraries bloom - in any language. Lower-level primitives enable more innovation than high-level APIs. That's the Unix philosophy. Simple, composable, powerful. Build the foundation right. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#wasm</a> <a href="https://mstdn.social/tags/frontend" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#frontend</a> <a href="https://mstdn.social/tags/unix" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#unix</a>

vruzFrameworks already solved templating. They're good at it! What they CAN'T solve is the JS monopoly on DOM access. Open that up and watch innovation explode across the entire ecosystem. React, Vue, Svelte - they all work great. But imagine what could be built if any language had direct DOM access. New paradigms, new approaches, new frameworks we can't even conceive of yet. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#javascript</a>

vruzThe performance argument for native templating is weak - we're talking 2% gains, max. But remove the JS bridge for WASM? That's where real performance wins live. Fix the actual bottleneck. Every DOM call through JS is overhead we don't need. Direct access would unlock true native speeds for web UIs. Imagine game engines manipulating DOM at 60fps without JS overhead. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/performance" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#performance</a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#wasm</a>

vruzThe Web's superpower is its openness. Native JS templating makes JS more ergonomic. Direct WASM→DOM makes the web more OPEN. Which better serves the platform's future? The web shouldn't privilege one language. True platform evolution means equal access to core capabilities for all languages. That's how we get the next generation of web innovation. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/webstandards" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webstandards</a> <a href="https://mstdn.social/tags/opensource" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#opensource</a>

vruzNative JS templating: helps JavaScript developers. Direct WASM→DOM: helps EVERY language. Rust, Go, C#, Zig, Swift, Kotlin... all get first-class web UI performance. That's real platform evolution. We shouldn't be adding more JS-specific APIs when we could be opening the web to all languages equally. The web platform should be language-agnostic at its core. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/webassembly" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webassembly</a> <a href="https://mstdn.social/tags/programming" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#programming</a>

vruzWhy add yet another JS templating API when WASM + direct DOM access solves the root problem? Every language could build efficient UIs without the JS bottleneck. More universal than blessing one syntax. Think beyond JavaScript - imagine Rust components with zero overhead, Go templates that actually perform, or C# Blazor without the bridge tax. That's true platform evolution. <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webdev</a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#wasm</a> <a href="https://mstdn.social/tags/webstandards" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#webstandards</a>

vruzSome people still weren't born, or came of age recently and are building the future, but never before had the luxury afforded to them and they have never known a world without React, or a world with non-stupidly complex technology so they keep reinventing things like Mustache.<a href="https://mstdn.social/tags/mustachejs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#mustachejs</a> <a href="https://mstdn.social/tags/mustache" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#mustache</a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#javascript</a> <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mstdn.social/tags/programming" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#programming</a> <a href="https://mstdn.social/tags/tech" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#tech</a> <a href="https://mstdn.social/tags/technology" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#technology</a>

LobstersInteractive Handbook on Data Structures and Algorithms <a href="https://lobste.rs/s/shxzwu" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://lobste.rs/s/shxzwu</a> <a href="https://mastodon.social/tags/compsci" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#compsci</a> <a href="https://mastodon.social/tags/education" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#education</a> <a href="https://mastodon.social/tags/visualization" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#visualization</a> <a href="https://cartesian.app/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://cartesian.app/</a>

Recent searches

Search options

Administered by:

Server stats:

#compsci