[HN Gopher] Launch HN: Haystack (YC S24) - Visualize and edit co...
___________________________________________________________________
Launch HN: Haystack (YC S24) - Visualize and edit code on an
infinite canvas
Hi HN, we're Akshay and Jake from Haystack
(https://haystackeditor.com/). Haystack re-imagines the IDE by
putting it on a 2D digital whiteboard that automatically draws
connections between code as you navigate and edit files. We
designed it to match our mental model of how code works - as a
graph of connected components. Here's a demo of what it looks like:
https://www.youtube.com/watch?v=5XADctpWNNs. You can download
Haystack from https://haystackeditor.com/. We used to work as
software engineers at big companies, and when the explosion in AI
code-generation tools started we were really excited about them.
They gave us a huge speed boost in our day-to-day work. But
something was missing: writing code had become easier, but
navigating codebases remained painful. We found that we were
spending more time on the latter than the former! Our vision of
Haystack is an IDE that helps you navigate your codebase at speed.
You should be able to type a vague description of the code you're
looking for ("Show me the code flow that triggers after we click
the submit button") and immediately see the right result. But we
don't think the traditional split-panel interface is the best fit
for this type of rapid navigation. Inspired by the fluidity of
design tools like Figma (Akshay used to work there!) and Miro, we
realized that the canvas layout is a perfect way to represent and
operate on code flows, and a great base for all the AI and
collaborative tooling we want to build! This is how Haystack was
born. You might have seen our original Show HN
(https://news.ycombinator.com/item?id=41068719) about two months
ago. Since then, a ton of our users have told us that they'd love
to contribute. We've made the decision to make the editor source-
available so that folks can make contributions and so that they can
examine the code to make sure they can trust it. Our repo is at
https://github.com/haystackeditor/haystack-editor. If you're
wondering why we're going source-available rather than proper open-
source: as a startup, we're going to eventually monetize and it's
too early for us to make the decision on whether going fully open-
source is the right move. We want to own the distribution of
Haystack until we can better understand the ramifications that
open-sourcing would have, and whether it's sustainable business-
wise. We'd love to find a way to make proper open-source work, but
it's a one-way door, so we want to take our time to make sure we're
making an informed decision. We would love to hear about what you
think about having a canvas in your IDE and the role visualizations
have to play in software development!
Author : akshaysg
Score : 156 points
Date : 2024-09-25 15:31 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bhy wrote:
| This looks quite useful! However could Haystack be made an VSCode
| extension instead of a fork? So I could use this in Cursor, which
| is also a VSCode fork.
| akshaysg wrote:
| We're going to make a "Haystack-lite" extension in the future!
| I understand the pain here. We chose to go with a VS-code fork
| so we could maximize the canvas features. I am curious if you
| would find the "canvas" view distracting when it's on a sidebar
| as opposed to the main editor?
| bhy wrote:
| Thinking about it, a sidebar "canvas" could be more useful
| comparing to the main editor to me:
|
| * when reading code, I found I jump back and forth the call
| stack quite often, a visualization of this could help with
| this navigation, especially with some properly designed
| shortcut keys.
|
| * I mostly code on MacBook so screen real estate is precious.
| The canvas as main editor looks like waste a lot of screen
| space. But the canvas in a sidebar do not have this issue.
| akshaysg wrote:
| 1. You can hop back and forth using the "backward/forward"
| buttons in the top bar, similar to VS Code. Not sure if I
| misunderstood here. 2. That's fair. You can "pin" editors
| on the canvas, which allows you to fullscreen editors.
| fragmede wrote:
| I think part of what makes this work is that
| ultrawidescreen monitors aren't as impossibly expensive as
| they once were, so screen real estate can be spent and your
| spacial reasoning can take over. It might just not work
| well on a laptop screen.
| candiddevmike wrote:
| So many YC folks are forking VSCode for various reasons that
| mostly revolve around "can't monetize extensions, want to own
| the platform".
|
| I don't think any of them will be successful, IMO. You want to
| be an extension because getting software approved is _hard_ at
| bigcos, it's much easier to trojan horse on an existing tool.
| akshaysg wrote:
| I could be wrong but I don't believe it's difficult to
| monetize an extension.
|
| The reason I think there has been an explosion of VS Code
| forks (e.g. Supermaven, a very successful extension) is that
| being an extension in VS Code is limiting insofar as what
| you're able to change in terms of the UI and UX.
|
| You are right about the difficulty of getting into big
| companies. However, we developed a standalone editor because
| it's easier to build on top of, and we eventually want to
| build a very portable browser-based editor that utilizes the
| canvas view for pull requests, arbitrary code, etc.
| chairmansteve wrote:
| Bigcos not that hard to get into. It's just an entirely
| different process. You would need to hire someone with that
| kind of experience.
| jitl wrote:
| I think Cursor is already looking successful. Most VS Code
| people I know (including myself) have switched over. I love
| the idea of Haystack (I was a fan of Light Table back in the
| day) but if I have to pick between a better UI and an
| assistant who perform most simple code transforms by English
| language request, saving hour(s) per day, I'm picking the
| assistant.
| akshaysg wrote:
| Yeah the productivity optimization here makes sense. We
| intend to add generative AI features unique to the canvas
| UI as well to ensure our users don't lose productivity.
|
| I am curious what features you like about Cursor the most?
| For me it's the CMD/CTRL+K -- I've had mixed experiences
| with the chat window and Composer.
| williamcotton wrote:
| I could be wrong but one of the main reasons to fork VS Code
| is because extensions have a limited UI.
|
| This was at least the motivation for Positron, AFAIK.
| ocean_moist wrote:
| This feels helpful as I have to hold less stuff in my mind, but
| the UI is way too mouse dependent right now. You guys should make
| some shortcuts and somehow make it "tiling" like a window manager
| (dwm), so you don't have to manually resize windows.
| akshaysg wrote:
| We actually do try to make the canvas as keyboard navigable as
| possible. There are a list of keyboard bindings in the
| "Keybindings and Help" button on the bottom right.
|
| In terms of manually resizing, we actually do try to tile in
| the viewport. May I know what's causing you to resize it so I
| can fix it?
| graerg wrote:
| In this vein, do you know what the experience has been like
| for users that use the vim vscode plugin? I see that it's
| trivial to carry over extensions and whatnot, but is the
| experience still "good" trying to use both?
| akshaysg wrote:
| I use the Vim VS Code plugin! It mostly works, but I'm not
| going to lie: there are a couple of bugs e.g. when you go
| to definition the Vim selection gets confused because in
| most cases you get placed into a symbol editor.
|
| I am happy to fix any bugs here. I am the only person I
| know who uses the Vim plugin in Haystack, so I haven't
| prioritized fixing the bugs I encounter.
| ocean_moist wrote:
| Sorry, I was just going off the demo. Maybe demo the keybinds
| briefly.
|
| If you get a demo of someone editing stuff super quickly
| using only keybinds I think it would look pretty cool.
|
| Right now I don't know if the value prop is strong enough for
| me to switch editors and remodel/relearn all my keybinds.
| This is like a 10-15% improvement not a 1.5x or 2x
| improvement.
|
| An extension would probably help onboard users.
| ivanjermakov wrote:
| Interesting, for me this is exactly the opposite of efficient
| code navigation.
|
| LSP + keyboard-driven interface is miles ahead in terms of
| efficiency and speed.
|
| I respect the effort of breaking into less researched lands
| though. Congrats on the launch, I'm sure some will find this tool
| useful.
| akshaysg wrote:
| This is fair! Not sure if you're a VS Code user, but our goal
| is to maintain a parity between the keyboard experience in VS
| Code and the keyboard experience in Haystack. All the keyboard
| shortcuts in VS Code still live in Haystack.
|
| If you're a Vim user then this is an entirely different story
| haha.
| scrozier wrote:
| To give you (Haystack authors) another datapoint, I'm a +1 to
| this comment. I can't think of a time when a canvas UI solved a
| problem I had. Usually it made navigation more difficult.
|
| But also agree that it's great that you're innovating in this
| space! Good luck!
| necovek wrote:
| I actually like keyboard-driven interface + spatial layout, I
| just don't have a large enough monitor (I've been hoping for
| 40"+ 8k monitors for years). But having multiple files open
| that smartly refocus and rearrange as you ESC-. (Emacs shortcut
| to jump to implementation of a thing under cursor) would be
| wonderful: if smart "arrows" are drawn between file boxes,
| that'd be sweet as well.
|
| The hard bit is making that to be "smart" and not annoying with
| things moving that you still need.
| chirau wrote:
| Is this a YC backed company?
| akshaysg wrote:
| Yes (all launch HNs are YC-backed)
| xixixao wrote:
| Congrats on the launch. It is an "obvious" idea, in a good way.
| Agree that minimizing the effort in constructing the workspace
| will be key. I'd also love to try a sort-of 3D stack for
| caller/callee relationship, zooming in and out. The code really
| is a graph (not acyclic though), and I think visualizing it that
| way can be helpful.
| akshaysg wrote:
| I'd love to learn more about what you're envisioning for the
| caller/callee relationship here! Do you mean recursively show
| callers/callees as you zoom out?
| sohzm wrote:
| hey love the concept (though Im not sure if its for me).
|
| btw you should add a (small) gif or video in the github readme
| cuz that makes it really clear of what exactly its about.
| akshaysg wrote:
| Good idea. Will add!
| valianter wrote:
| I get that this is a completely new idea so adoption is going to
| be slow but I'm curious to see how your user interviews and user
| research is going. I'm a young dev but I'm not even sure if I
| would use this because the way I've learned to code is already so
| ingrained into the traditional IDE. Nevertheless, congrats on the
| launch!
| yatvij wrote:
| Jake from Haystack here! Thanks for the interest. We've been
| doing a lot of user interviews with folks on our discord (and
| folks we know in real life) to understand issues in the
| onboarding process, find problems that make people churn off,
| etc with the long-term goal of increasing retention. A lot of
| our time lately has been spent on fixing these bugs and
| improving the new-user experience. As a result of this we found
| that retention on later launches got much better!
| verdverm wrote:
| Have you done user research outside your fan base to show
| this experience is something developers want?
|
| Is it desirable enough to get them to switch IDEs?
| akshaysg wrote:
| Yeah just to add onto what Jake said -- in our user interviews
| we found that folks, even those who are pretty used to old
| IDEs, do get the hang of Haystack pretty fast. However,
| developers are very idiosyncratic, so we frequently get pain
| points that are real problems but are also highly unique to
| each developer, which is interesting!
| necovek wrote:
| Totally: I couldn't stop thinking about actually generalizing
| this to a workspace/desktop so I could apply similar
| principles with multi-windowed Emacs -- a window manager that
| also connects windows ;)
|
| Looks really intriguing, but Emacs is really hard to leave
| behind.
|
| But I do believe this pattern applies to more things than
| just IDEs, and might even replace multi-workspace setup. Keep
| at it and hopefully you are successful and this pattern keeps
| evolving!
| btown wrote:
| This is really, really cool!
|
| On the licensing side, though:
|
| > We've made the decision to make the editor source-available so
| that folks can make contributions and so that they can examine
| the code to make sure they can trust it.
|
| This is a very reasonable intent, and it absolutely makes sense
| to preserve your options to monetize, but Polyform Strict
| https://polyformproject.org/licenses/strict/1.0.0/ , which you
| link to from your readme, seems to be far stronger than this
| intent.
|
| The way I read that license, I cannot "make changes" even if I do
| not distribute those changes, not even changing a line of code on
| a version I'm running on my own computer, whether I'm using it
| for a commercial project or not. So contributors, it seems, would
| be limited to raising issues but not PRs? And it's unclear what
| applies as commercial use - if I'm using Haystack on a commercial
| codebase, and I encounter a bug that triggers on that codebase,
| and want to use the Haystack source code to understand what's
| going on to further my commercial purpose, would that be an
| unlicensed use of the source code?
|
| Now, make no mistake - this is in no ways worse than the prior
| status quo of Haystack being closed-source. And I think you as a
| company should focus on building, with the certainty and comfort
| that this license, if anything, does err on the side of being
| restrictive. But some users, given this license, will be
| uncomfortable referring to the repository at all. I'll be one of
| those, but will still be excited to experiment with Haystack as a
| binary distribution nonetheless!
|
| (Not a lawyer, this is not legal advice!)
| akshaysg wrote:
| Hmm I'll take a look at other licenses to see if there's one
| that expresses our intent in clearer language.
|
| The intent is that you should be able to make PRs, examine the
| source code, but not distribute Haystack for commercial
| reasons.
|
| I believe the license should allow you make PRs and examine
| code (even in commercial settings), but I'll take a more in-
| depth look.
|
| Thank you for raising this to my attention!
| faramarz wrote:
| Very cool. I imagined my organizations entire codebase being
| mapped like this and across different frameworks and languages.
|
| I don't know if I missed this in the video or if it's not yet
| possible, but that's a lot of manual work, so instead of
| connecting the nodes, give a simple bot to run in the repo folder
| to automate the visualization.
|
| It's super cool and I'm adding to my watch list.
|
| If I were you, i'd target enterprise organizations or local
| municipalities IT groups who are going through or planning their
| digital transformations. They have a need for way-finding and
| sense making across legacy and new work.
|
| If you play your cards right, Salesforce will come knocking in
| under a year. I see a lot of compatibility with their vision and
| product offerings.
| akshaysg wrote:
| It automatically adds connections as you traverse through
| files/symbols. Not super sure if this is what you mean, but we
| intend to serve the users "flows" based on queries in the
| natural language e.g. "what happens when you click the
| subscribe button from the mouse down all the way to the
| backend".
| faramarz wrote:
| That's awesome! Generally when I find tools that can improve
| our work culture and output velocity and quality, I try and
| get it on front of teams ahead of a an internal hackathon
| where the cost of on-boarding and prototyping is already
| factored in. This feels like a good candidate.
| hansonkd wrote:
| that would be interesting if you could "link" across API calls
| to different services.
| akshaysg wrote:
| Most likely we would either have to get the user to do this
| (we plan to add this as a feature) or use AI to understand
| when disconnected code (from the LSP standpoint) is indeed
| connected.
|
| This is a top user request though!
| matsemann wrote:
| I like the concept so far in the video. I just want more, even
| bigger, more panes, all connected! If it's usable in such a
| state I don't know, but would be fun to try. Like a UML
| diagrams of the whole code base with thousands of arrows.
|
| Ane I can then tell my coworker that the file needing change is
| in the upper right corners somewhere.
|
| And git diffs being visual, can just zoom in on the changes
| here and there.
| aappleby wrote:
| What happens when I have 10,000 or so editors open at once?
| aappleby wrote:
| Proof of concept of mine from years ago - every file from the
| Linux kernel open in a browser window at once
|
| https://github.com/aappleby/wideboard
| randomcatuser wrote:
| wow that's pretty next level
| akshaysg wrote:
| I've actually never tried this (it'll probably take awhile to
| get to this point). Feel free to try it out and report back the
| results -- I'm curious as well!
| tracyhenry wrote:
| This has been a great idea for decades. I want Haystack to be
| successful just like many other attempts. The early execution
| seems promising. And I suspect there will be many challenges
| (e.g. when it's hard to figure out caller/callee,, inconsistent
| UX preferences across developers, etc). Kudos for taking this on!
|
| Btw I've always thought that this is even more powerful when the
| screen estate is more infinite than a 2D screen (like in a VR
| headset).
| akshaysg wrote:
| I love the idea of a Haystack VR world! It's a shame that VR
| software is in a tenuous state due to the biological factors,
| but I believe it's the future "one day".
| dangerlibrary wrote:
| "In a tenuous state due to the biological factors" is easily
| the funniest SV euphemism for "can't be used by humans."
| IgorPartola wrote:
| It's ok after they deliver the MVP there will be a wetware
| update.
| akshaysg wrote:
| Who knows, one day it may be possible (hopefully without
| any dystopian updates to human biology)!
| doctorhandshake wrote:
| Check out SoftSpace https://soft.space ... not an IDE but
| similar idea for knowledge mapping
| akshaysg wrote:
| This is actually really cool!
| williamstein wrote:
| Is most development of Haystack done using Haystack?
| yatvij wrote:
| Yes! Both of us prefer Haystack to other IDEs; for me it feels
| a lot less "restricting" than VSCode. Developing in Haystack
| also helps us find issues early.
| hyggetrold wrote:
| Does this project take any inspiration from Light Table?
|
| Potential feature request - take the visualization beyond 2D.
| Really complex systems are usually an intricate graph (polite way
| of saying ball of yarn) and just visualizing in the 2D plane
| doesn't seem to cut it in my experience.
|
| I would love to have something like concentric spheres of
| visualization - boundary services on the outer layer, core/domain
| services in the inner layer.
| akshaysg wrote:
| A lot of people mentioned Light Table, but I didn't know about
| it until post-launch!
|
| It's interesting that you mention a more 3D view. We were
| ideating on this, but it's really hard to get right in a way
| that the user can understand. This is definitely part of our
| vision for the future though!
|
| EDIT: Deleted the bit about my speculation regarding Light
| Table since it's false.
| hyggetrold wrote:
| Light Table was getting lift and traction but didn't make it.
| There was a ton of conversation on it back in the day on HN,
| including great presentations by the creator (who had been a
| PM on Visual Studio as MSFT!). Definitely check it out.
|
| There's definitely demand for this tool but it looks like
| it's hard to get it off the ground. Wishing you the best of
| luck!
| eep_social wrote:
| For 3D I'd run a clustering algo across the graph and use the
| Z axis to background "far" clusters.
|
| I'm imagining a typical graph might end up looking a bit like
| this: https://upload.wikimedia.org/wikipedia/commons/thumb/8/
| 81/07... in which case I'd want to have whatever
| cluster/file/method/object I'm focused on front and center
| with some visual cues like low-contrast and z-axis
| perspective that preserves edges to show the "far" clusters
| that interact with the focal point.
|
| edit to add: as per usual, naming the clusters automatically
| might be hard.
| hyggetrold wrote:
| Interesting idea and curious - because when I look at that
| visualization, the first thing it reminds me of is gource.
| 999900000999 wrote:
| Very awesome!
|
| I want this for C# and Python! Are their any technical challenges
| there? I would love to use this with Unity.
| akshaysg wrote:
| For C# unfortunately we're missing a lot of features because
| the VS Code ecosystem itself lacks them (I think this is due to
| them being unique to Visual Studio). In most cases, except
| grabbing incoming/outgoing calls, Haystack should just work.
|
| For Python, it should work just fine!
| 999900000999 wrote:
| Can I still do the cool visualization ?
|
| I'll experiment with this over the weekend and I might share
| it with my game dev friends!
| akshaysg wrote:
| Yes the visualization should work!
| neonsunset wrote:
| There are multiple ways to go about this in .NET - the
| instrumentation for the networking stack is not missing:
|
| https://learn.microsoft.com/en-
| us/dotnet/fundamentals/networ...
|
| https://learn.microsoft.com/en-
| us/dotnet/fundamentals/networ...
|
| It is, however, not dependent on VS Code and exists
| standalone, so it requires integration work if there's custom
| tooling at play. It is what most vendor SDKs that offer
| observability do.
|
| There are CLI tools which consume the EventSource events and
| the EventPipe itself which can be used to access them in and
| out of process: https://learn.microsoft.com/en-
| us/dotnet/core/diagnostics/ev...
|
| EventPipe/EventSource and DiagnosticPort are very powerful
| APIs however that cover much deeper instrumentation
| scenarios, so they are going to require writing a connector
| for the product that wants to integrate with them. There is
| already an implementation in shared code that is used by e.g.
| dotnet-trace which can be found here https://github.com/dotne
| t/diagnostics/tree/main/src/Microsof... but it can be a bit
| convoluted to read through.
| jecel wrote:
| This reminds me of the "Kansas" environment in the Self
| programming language. Here is a video about it from Sun in 1995:
|
| https://www.youtube.com/watch?v=Ox5P7QyL774
|
| More interesting search features were added after this video was
| made.
| gavmor wrote:
| > Haystack takes care of the tedious confusing parts of coding
|
| Tedious, yes, but confusing? Yikes!
|
| My job as a coder is to resolve ambiguity favorably. Every day, I
| strive to leave the world less confusing than I found it. I would
| no more rely on an IDE to "take care" of confusion than I would
| outsource my firm's core competencies.
|
| But the main conceit is cool, and I'm sure the dependency graph
| is helpful. I'm just picking nits with marketing copy. Can't wait
| to check it out! (Although my first instinct is to check for a
| canvas plugin for VScode).
|
| Edit: I should say that I think this UI paradigm will
| fundamentally improve coder understanding by exploiting our
| visual cortex and "sixth sense" of proprioception, at least as
| far as I understand it via _Supersizing the Mind_ (Andy Clark,
| 2008).
| akshaysg wrote:
| Hmm I think someone else has voiced a similar opinion on the
| wording here, and I actually do agree with you.
|
| What was meant by this statement is really just taking care of
| plumbing and the visualization of how code relates to one
| another.
|
| To give you a very basic/silly example of plumbing, if I add a
| parameter in a function used in 100s of places, doing the
| manual work to figure out what edits I need to make to those
| callers is pretty annoying and in most cases mechanical.
|
| If you're lucky, you can do a grep + replace (or just use a
| default param), but in most cases I find it requires more
| manual intervention than that.
| gavmor wrote:
| Adding a parameter to the function signature, and then
| passing an additional value at each call site is done...
| automatically in Haystack? Impossible!
|
| Edit: And "to figure out what edits I need to make" is done
| by any ol' compiler, no?
| akshaysg wrote:
| Not yet -- it's our vision to automate stuff like that!
|
| > Edit: And "to figure out what edits I need to make" is
| done by any ol' compiler, no?
|
| Kinda? There are cases where you have to drill data down
| into the callstack (i.e. pass data from above). There are
| folks who have gone down this path before: https://www.jetb
| rains.com/help/resharper/Refactorings__Chang... but we
| intend to automate it even more and show it to the user in
| an organized way for them to handle large-scale
| "refactors".
| hathawsh wrote:
| I strive for the same thing, but every time surprising new
| requirements arrive, there's a good chance that the elegant
| architecture my team created is in conflict with the design we
| now want. At that point, there is a three step process:
|
| 1. Design the new architecture.
|
| 2. Gain a full understanding of the existing architecture and
| all of its trade-offs.
|
| 3. Design a way to convert the old architecture into the new
| architecture.
|
| This happens surprisingly often and it's quite unavoidable. In
| the past, I tried to avoid redesigning by building things that
| could be expanded in every conceivable way, but I discovered
| that over-engineering actually makes it harder to redesign.
| YAGNI wins!
|
| I've been thinking for a while that a canvas-type editor might
| help a lot in the process of redesigning. It should help by
| taking better advantage of spatial memory.
| closetkantian wrote:
| So this is a major side question, but is there a go-to open
| source infinite canvas? I'm building a card game and I need a
| multiplayer infinite canvas for it. I'd appreciate any
| recommendations.
| akshaysg wrote:
| Does tldraw work for you? We use Pixi JS, which comes with
| graphics as well.
| zharknado wrote:
| Ooh I see PixiJs can make content available to the
| screenreader for a11y. That's always a big question mark for
| me when people start cramming a content tree into a canvas.
| Onavo wrote:
| https://retejs.org
| joshdavham wrote:
| > we're going to eventually monetize
|
| How do you plan on monetizing?
| akshaysg wrote:
| Collaborative and generative AI features. E.g. sharing Haystack
| workspaces, searching your codebase in the natural language,
| making edits to multiple files, etc.
| rrr_oh_man wrote:
| _> Monetization_
|
| All right
|
| _> Collaborative_
|
| OH! YES!
|
| _> and generative AI features_
|
| Oh no.
| akshaysg wrote:
| Since it's opt-in, the generative AI features won't ever
| bug you unless you want to use them!
| belowm wrote:
| Why can't this be an extension? I love the idea and can perfectly
| imagine this inside a tab of the editor area. This would allow
| for multiple haystack tabs as well, so switching contexts would
| be seven easier. Having to install another IDE (even if it is
| based on vscode) is a bit of a bummer for me. None the less, keep
| it up!
| btown wrote:
| VS Code extensions are pretty limited - you can override the
| renderer for an editor tab, but if you want multiple things
| within a custom interface to be treated as first-class editor
| tabs by the larger environment (and by the larger extension
| ecosystem), that's not really possible. Forks are a reasonable
| step as long as they don't fall behind!
| akshaysg wrote:
| I understand the frustration here! As the other commenter
| noted, it's quite bit tougher to make Haystack as good in the
| form of an extension, but we do plan to eventually explore this
| path!
| calderwoodra wrote:
| If you structure your directories sensibly, you can get the same
| effect/value prop in every IDE and dev env.
|
| Or is there a deeper experience/knowledge that gets unlocked
| coding in this paradigm?
| akshaysg wrote:
| Not sure if I completely grasp what you're saying, but you're
| saying that if you plan the codebase well then dependencies
| between files/bits of code are more easily followed?
|
| For our users, Haystack has been helpful to understand how code
| works together, from simple React components to legacy C
| codebases that are a decade or older. I think the value prop
| shines when you're trying to understand how multiple pieces of
| code together, and this will become more useful as folks
| increasingly lean on AI tools to modify/create/delete multiple
| files.
| Tepix wrote:
| Did you really have to pick the same name as the Haystack open
| source AI framework? https://haystack.deepset.ai/
| https://github.com/deepset-ai/haystack
|
| It's a very active project and it's confusing to have two
| projects with the same name. Besides, I don't understand why
| you'd give a _" 2D digital whiteboard that automatically draws
| connections between code as you navigate and edit files"_ the
| name haystack.
| akshaysg wrote:
| This is an unfortunate name collision, but in our defense the
| concept of a "needle in a haystack" is hardly unique and I
| believe a code editor is different enough from the AI framework
| that it's OK.
|
| The idea is that a codebase is much like a haystack and finding
| the relevant portions of it for a task or specific flow would
| be equivalent to finding needles.
| drawnwren wrote:
| Is this just a pretty picture of the AST that I"m already
| navigating with go-to definition, fuzzy search, and harpoon in
| 2024?
| akshaysg wrote:
| Harpoon is kind of like a bookmarking tool right? I think the
| value prop is that you have to do less manual window
| management, can see connections between code better, and can
| context switch between tasks.
|
| Reposting this from another comment: For our users, Haystack
| has been helpful to understand how code works together, from
| simple React components to legacy C codebases that are a decade
| or older. I think the value prop shines when you're trying to
| understand how multiple pieces of code together, and this will
| become more useful as folks increasingly lean on AI tools to
| modify/create/delete multiple files.
| rrr_oh_man wrote:
| This is so. fucking. sexy.
|
| Wow.
|
| Thank you for sharing your work.
|
| Please don't go down the GenAI bullshit bingo VC route.
| theideaofcoffee wrote:
| Oh, this is great. And pretty much the process of what I do when
| I look at larger codebases, except not as clean and organized. I
| would normally have a half dozen terminals open into various
| source files at once trying to build the map in my head. Though
| it eventually clicks and happens, it's laborious, but it seems
| like something like this would help immensely. Now, the only
| thing left is to combine it with an ultrawide monitor.
| bitbasher wrote:
| A gulpfile... has been while since I've seen one of those.
| akshaysg wrote:
| Yeah VS Code is built on top of some older frameworks and ideas
| unfortunately.
| observationist wrote:
| Screenshots. Show - don't tell, _especially_ if you 're making
| claims about visualization!
| akshaysg wrote:
| Do you mean in the GitHub repo? Happy to add more images/gifs
| to the repo! It's a fairly recent addition and the website does
| a much better job of showcasing the product!
| nicktikhonov wrote:
| I would try it if it was a VSCode extension. I'd like to use it,
| but I live inside cursor these days.
| threecheese wrote:
| This is great and I can't wait to try it. I've been coding for a
| few decades, and have always been good at "keeping the program in
| my head". However, in life I am very bad at this and have failed
| at just about everything that's not programming, and based on a
| recent diagnosis I've learned a lot about ADHD, autism, and
| "visual learners" for whom abstract mental models are difficult
| to internalize without some visual anchor. Anyway, this has led
| me to use more visual tools - like Miro and Heptabase - and the
| lessened cognitive load is nothing less than stunning. I hope
| this model of human/machine interface is beneficial to everyone,
| and not just those who are broken, but coming from one of the
| latter I appreciate what you are doing here.
| jahewson wrote:
| Diagrams can certainly be helpful but do be aware that "visual
| learners" is a myth that has been debunked for 15 years now:
|
| https://www.theatlantic.com/science/archive/2018/04/the-myth...
| threecheese wrote:
| Interesting, thanks for the reference. The chance that my
| doctor's info is out of date is definitely nonzero. I am
| however interested in why this nugget of info has been so
| life-changing, and so off I go to figure out if this is
| placebo or something else. Appreciate you not being a dick,
| but then again this isn't reddit.
| ElFitz wrote:
| Oh. That would be fun on the Vision Pro.
|
| Don't know wether or not it would be productive, that remains to
| be seen, but it certainly would be fun.
| waingake wrote:
| Is there a way to move the canvas via mac track pad which works
| the same way the middle mouse button does? I.e. always drags even
| if I'm looking at an editor
| nodelessness wrote:
| Press ctrl while panning with trackpad. Creates tiny artifacts
| but works.
| akshaysg wrote:
| This is to zoom correct? You can also pinch/unpinch!
| waingake wrote:
| Holding down option seems to do what I want here
| akshaysg wrote:
| Ope sorry for the late reply but OPT/ALT is the intended way
| for you to do this.
| jacobsenscott wrote:
| Interesting - though it probably just soft of devolves to using
| hot keys (hopefully those exist) to jump between files after a
| few editors are open. Panning around with even half a dozen files
| open would get tedious.
| akshaysg wrote:
| What I do personally is I try to keep all relevant code in my
| viewport and jump around using shortcuts (are hotkeys a gaming
| term? I used to say hotkeys all the time!). The visualization
| is still really helpful for me so that I can quickly orient
| myself with which functions/classes relate to each other.
| g19fanatic wrote:
| I've needed something this from the first days of learning to
| program. I've been able to recreate this (kinda) with vim panes
| and tabs in addition to tmux panes and sessions.
|
| I'll keep my code in a left pane in vim, <C-w v> to duplicate the
| buffer in a new pane and then use tags to goto a definition and
| if needed to go deeper, do it again. I don't usually kill this
| unless no longer needed and If i need to go down some other
| branch, will just <C-w v> then <C-w T> to start that pane in a
| new tab and do it again. Easily keeping the different contexts in
| different panes and tabs inside of vim. all managed by <C-w |>
| and <C-w => to make it easier to read... Tmux panes and sessions
| for entire project contexts so on and so forth.
|
| Having it graphical looks really really nice and I'd love to have
| something like this for presentations/debugging over zoom
| sessions.
| haolez wrote:
| If this is supposed to be a next step from text files, what would
| be the previous step? Forth blocks? :)
| ksksksko wrote:
| Winsnw
| azhenley wrote:
| Beware, canvas-based code editors (like Code Bubbles) have
| problems. A 1d carousel/ribbon performed better in some initial
| user studies:
|
| https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf
| akshaysg wrote:
| Thank you for the flag! Our intention is to try to "tile" the
| viewport so that it resembles this grid format (i.e. the
| carousel/ribbon), but we've found the canvas is still useful
| folks who want to go that extra mile to organize their editors.
| jderick wrote:
| It doesn't make sense unless zooming out shows some higher level
| representation of the code.
| akshaysg wrote:
| We certainly intend to add semantic zoom levels, but for now I
| think zooming out is just helpful in navigating the canvas when
| you have multiple connected components on the canvas at once
| and need to pan to an area in the canvas.
___________________________________________________________________
(page generated 2024-09-25 23:00 UTC)