Joshua Grochow<p>Has anyone played around with encouraging (but not requiring) students to teach one another?</p><p>One way of demonstrating mastery of the material is teaching it to others. I feel like if student A says "Student B really helped me understand the material" that increases my Bayesian posterior that student B understood the material really well (and also that student A understood it, since presumably after student B explained it, student A understood it at least better than they did before).</p><p>I wouldn't do this as the only, or even major, part of their grade, but it seems like if the grade is to reflect learning, that teaching it to others certainly reflects on their learning.</p><p>(Additional context: this is for a university-level elective technical course in Comp Sci, for 3rd and 4th-years mostly. I generally do flipped classroom and alternative grading - some combo of ungrading, mastery-based, standards-based, but I'm open to ideas. The class has about 55 students, so whatever it is can take some time but not be *too* time-intensive on me & the one TA.)</p><p><a href="https://mathstodon.xyz/tags/AlternativeGrading" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AlternativeGrading</span></a> <a href="https://mathstodon.xyz/tags/grading" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>grading</span></a> <a href="https://mathstodon.xyz/tags/teaching" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>teaching</span></a> <a href="https://mathstodon.xyz/tags/education" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>education</span></a> <a href="https://mathstodon.xyz/tags/CSEd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CSEd</span></a> <a href="https://mathstodon.xyz/tags/ComputerScience" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ComputerScience</span></a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CompSci</span></a></p>
eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.
Administered by:
Server stats:
215active users
eupolicy.social: About · Profiles directory · Privacy policy
Mastodon: About · Get the app · Keyboard shortcuts · View source code · v4.4.1
#compsci
1 post · 1 participant · 0 posts today
Charo del Genio<p>New paper!<br>How can we detect the presence of communities in networks with higher-order interactions? For instance, by maximizing hypermodularity! Also, this formulation will allow you to leverage tensor spectral methods to do it. Additionally, the paper also argues that the "overfitting" of modularity methods is actually just people applying them where they are not supposed to be used. And, as a byproduct, there is an explanation of why higher-order SVD works so well in classification tasks in machine learning. Oh, the code is available to use in your own projects (link in the first comment). And moreover, the code includes an efficient data structure for higher-order networks that is independent from the community detection method and that you can also use in your own work. 😎</p><p><a href="https://journals.aps.org/prresearch/abstract/10.1103/58dr-wktc" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">journals.aps.org/prresearch/ab</span><span class="invisible">stract/10.1103/58dr-wktc</span></a></p><p><a href="https://mathstodon.xyz/tags/networks" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>networks</span></a> <a href="https://mathstodon.xyz/tags/complexity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>complexity</span></a> <a href="https://mathstodon.xyz/tags/physics" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>physics</span></a> <a href="https://mathstodon.xyz/tags/maths" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>maths</span></a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CompSci</span></a> <a href="https://mathstodon.xyz/tags/graphs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>graphs</span></a> <a href="https://mathstodon.xyz/tags/higherorder" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>higherorder</span></a> <a href="https://mathstodon.xyz/tags/hypergraphs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>hypergraphs</span></a> <a href="https://mathstodon.xyz/tags/community" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>community</span></a> <a href="https://mathstodon.xyz/tags/detection" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>detection</span></a> <a href="https://mathstodon.xyz/tags/algorithm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>algorithm</span></a> <a href="https://mathstodon.xyz/tags/communitystructure" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>communitystructure</span></a> <a href="https://mathstodon.xyz/tags/modularity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>modularity</span></a> <a href="https://mathstodon.xyz/tags/hypermodularity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>hypermodularity</span></a></p>
cst1<p><span class="h-card" translate="no"><a href="https://a.gup.pe/u/academicchatter" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>academicchatter</span></a></span> </p><p>Okay, what tools would you recommend using to help order, browse, visualize and expand your research library? </p><p>I'm using Zotero as the backing library manager + <a href="https://researchrabbitapp.com/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">researchrabbitapp.com/</span><span class="invisible"></span></a> for the visualization/discovery part but open to suggestions and tips!</p><p><a href="https://chaos.social/tags/academia" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>academia</span></a> <a href="https://chaos.social/tags/phd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>phd</span></a> <a href="https://chaos.social/tags/research" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>research</span></a> <a href="https://chaos.social/tags/compsci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compsci</span></a></p>
José A. Alonso<p><a href="https://mathstodon.xyz/tags/MULCIA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MULCIA</span></a>: Two postdoctoral positions in homotopy type theory at the University of Nottingham, UK. <a href="https://tinyurl.com/ysld3f5r" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">tinyurl.com/ysld3f5r</span><span class="invisible"></span></a> <a href="https://mathstodon.xyz/tags/PostDoc" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PostDoc</span></a> <a href="https://mathstodon.xyz/tags/CompSci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CompSci</span></a></p>
Papers We Love<p>📜 A Byzantine Fault Tolerant Distributed Commit Protocol [2007]</p><p>By: Wenbing Zhao</p><p>📖 <a href="https://github.com/papers-we-love/papers-we-love/blob/master/distributed_systems/byzantine-fault-tolerant-distributed-commit-protocol.pdf" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/papers-we-love/pape</span><span class="invisible">rs-we-love/blob/master/distributed_systems/byzantine-fault-tolerant-distributed-commit-protocol.pdf</span></a><br>🔍 <a href="https://www.semanticscholar.org/paper/ebb685399ffe65d1b3119ada60fdf002cfac66f9" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">semanticscholar.org/paper/ebb6</span><span class="invisible">85399ffe65d1b3119ada60fdf002cfac66f9</span></a></p><p><a href="https://mstdn.io/tags/semanticScholar" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>semanticScholar</span></a> <a href="https://mstdn.io/tags/paperswelove" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>paperswelove</span></a> <a href="https://mstdn.io/tags/research" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>research</span></a> <a href="https://mstdn.io/tags/compsci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compsci</span></a></p>
Aether~<p>Fedi, I have a <a href="https://plasmatrap.com/tags/ComputerScience" rel="nofollow noopener" target="_blank">#ComputerScience</a> (maybe <a href="https://plasmatrap.com/tags/Linguistics" rel="nofollow noopener" target="_blank">#Linguistics</a> ?) Question I need your lovely guidance for ❤️:boosts_ok_gay:💙<span><br><br>I have a design problem about grammar ambiguity ish stuff and want to find reading, resources or theory I can check out to come up with an elegant solution.<br><br>Particularly, I'm trying to find good alternatives to cases when a given word can appear in multiple parts of the syntax<br><br>An example problem (sorry it's very computery): I have two strings (or lists of tokens) I need 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. The standard way to deal with this is to designate an escape token and prepend all instances of the delimiter within the strings with it (eg </span><code>\"</code>). The issue there is now is that any instances of the escape token need escaping too (e.g. <code>\\</code><span>).<br><br>Slightly less work is inserting a repetition of the delimiter any non-delimiting instances of the token. If the delimiter appears twice, it's part of a string, and the only non-repeating delimiter must be the real one. This can look ugly if the delimiter is long though.<br><br>Another crazy option would be interlacing the two strings so all even tokens belong to string 1 and odd ones are string 2. This would obviously look horrible, but maybe there are other solutions taking a similar thought process.<br><br>That's just the most basic case I'm interested in, there might be heaps of other strategies when you have more restrictions and guarantees on what the tokens might contain.<br><br>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 to handle complex data as a list of arguments.<br><br>Also please boost and let me know if there's hashtags I should include etc </span>:ablobcatheart: <a href="https://plasmatrap.com/tags/CompSci" rel="nofollow noopener" target="_blank">#CompSci</a> <a href="https://plasmatrap.com/tags/programming" rel="nofollow noopener" target="_blank">#programming</a> <a href="https://plasmatrap.com/tags/askfedi" rel="nofollow noopener" target="_blank">#askfedi</a> <a href="https://plasmatrap.com/tags/TechSupport" rel="nofollow noopener" target="_blank">#TechSupport</a> <a href="https://plasmatrap.com/tags/CompSci" rel="nofollow noopener" target="_blank">#CompSci</a> <a href="https://plasmatrap.com/tags/programming" rel="nofollow noopener" target="_blank">#programming</a> <a href="https://plasmatrap.com/tags/askfedi" rel="nofollow noopener" target="_blank">#askfedi</a> <a href="https://plasmatrap.com/tags/TechSupport" rel="nofollow noopener" target="_blank">#TechSupport</a></p>
Papers We Love<p>📜 A New Approach to Linear Filtering and Prediction Problems [2001]</p><p>By: T. Başar</p><p>📖 <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" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/papers-we-love/pape</span><span class="invisible">rs-we-love/blob/master/data_fusion/a-new-approach-to-linear-filtering-and-prediction-problems.pdf</span></a><br>🔍 <a href="https://www.semanticscholar.org/paper/d36a38125557764efb0fd2b3ef0a4cde515b3861" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">semanticscholar.org/paper/d36a</span><span class="invisible">38125557764efb0fd2b3ef0a4cde515b3861</span></a></p><p><a href="https://mstdn.io/tags/semanticScholar" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>semanticScholar</span></a> <a href="https://mstdn.io/tags/paperswelove" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>paperswelove</span></a> <a href="https://mstdn.io/tags/research" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>research</span></a> <a href="https://mstdn.io/tags/compsci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compsci</span></a></p>
vruz<p>Direct 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wasm</span></a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>javascript</span></a></p>
vruz<p>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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/webstandards" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webstandards</span></a> <a href="https://mstdn.social/tags/opensource" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>opensource</span></a></p>
vruz<p>Instead 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wasm</span></a> <a href="https://mstdn.social/tags/frontend" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>frontend</span></a> <a href="https://mstdn.social/tags/unix" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>unix</span></a></p>
vruz<p>Frameworks 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>javascript</span></a></p>
vruz<p>The 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/performance" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>performance</span></a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wasm</span></a></p>
vruz<p>The 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/webstandards" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webstandards</span></a> <a href="https://mstdn.social/tags/opensource" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>opensource</span></a></p>
vruz<p>Instead 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wasm</span></a> <a href="https://mstdn.social/tags/frontend" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>frontend</span></a> <a href="https://mstdn.social/tags/unix" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>unix</span></a></p>
vruz<p>Frameworks 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>javascript</span></a></p>
vruz<p>The 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/performance" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>performance</span></a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wasm</span></a></p>
vruz<p>Native 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/webassembly" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webassembly</span></a> <a href="https://mstdn.social/tags/programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>programming</span></a></p>
vruz<p>Why 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" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webdev</span></a> <a href="https://mstdn.social/tags/wasm" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wasm</span></a> <a href="https://mstdn.social/tags/webstandards" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>webstandards</span></a></p>
vruz<p>Some 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.</p><p><a href="https://mstdn.social/tags/mustachejs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mustachejs</span></a> <a href="https://mstdn.social/tags/mustache" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mustache</span></a> <a href="https://mstdn.social/tags/javascript" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>javascript</span></a> <a href="https://mstdn.social/tags/compsci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compsci</span></a> <a href="https://mstdn.social/tags/programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>programming</span></a> <a href="https://mstdn.social/tags/tech" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tech</span></a> <a href="https://mstdn.social/tags/technology" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>technology</span></a></p>
Ele Willoughby, PhD<p>Happy birthday to Alan Turing, OBE, FRS (1912 – 1954), British <a href="https://spore.social/tags/mathematician" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mathematician</span></a>, <a href="https://spore.social/tags/cryptanalyst" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cryptanalyst</span></a>, computer scientist, prophet & hero. Turing foresaw not only that machines might quite likely develop the capacity to think (after all, our brains are only made of matter, and complex systems of neurons, which either fire or not, much like an electronic switch), but that we needed an objective, double-blind test to determine whether 🧵1/n</p><p><a href="https://spore.social/tags/sciart" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>sciart</span></a> <a href="https://spore.social/tags/printmaking" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>printmaking</span></a> <a href="https://spore.social/tags/linocut" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>linocut</span></a> <a href="https://spore.social/tags/compsci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>compsci</span></a> <a href="https://spore.social/tags/histsci" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>histsci</span></a> <a href="https://spore.social/tags/mastoart" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mastoart</span></a></p>
TrendingLive feeds
Mastodon is the best way to keep up with what's happening.
Follow anyone across the fediverse and see it all in chronological order. No algorithms, ads, or clickbait in sight.
Create accountLoginDrag & drop to upload