Hacker News Reader

I definitely see the benefit of a separate code search engine and would use it. Google has, as you have notice, gotten way less useful. A big part of that is trying to target the wider market to the exclusion of less popular searches, like developers'. A dedicated engine would help with that.

I'm more than willing to open another tab to not have a search result page full of YouTube videos.

To each their own. I have 1 flow for search which I don't plan on changing and I personally have no issues with google search (for code, technical, or otherwise). I still consider it to be one of the best and I don't agree with the "google search is getting worse" crowd. Maybe at some point I'll use some kind of "search hydra" that hits multiple engines and either combines the results or shows me the results based on the type of search it thinks I'm doing but I don't imagine I'll ever want to consciously switch engines based on task.

Also I've never seen a "search result page full of YouTube videos" no matter what the query was. Sometimes there will be 3 or a carousel of them near the top but I can easily ignore that (assuming they aren't relevant or useful to me). I can't remember the last time I got a video for a code/technical query on google, I just did some testing and only a few queries showed videos, always 3, always partway down the page so that the search results at the top answered what I needed before I even got to the videos.

In your first comment, you say you want high information density. In this one, you say if there are irrelevant results on Google, you'll just ignore them and scroll past.

I get that there's always a high bar to switch to a new tool, and Google obviously has certain advantages that are tough to replicate, but it seems like you're applying a bit of a double standard. If Google shows me a bunch of ads and irrelevant results that I have to parse through to find what I'm looking for, that's not high information density; it's quite the opposite.

Both things can be true and you are omitting/ignoring part of my comment about irrelevant results. Higher density of information means I can scan faster and see more with less/no scrolling. As for irrelevant results I called out that the relevant results were above the videos (irrelevant, to me in this context, content). Lastly, I very rarely get ads when doing technical searches so that doesn't really factor in here. I'd wager I get what I want within the first 3-4 results on google reliably (at least when it comes to technical/programming-related searches) and when I don't it's normally super niche (it also rarely has videos or other stuff in the results, think: error messages).

Right, but you still have to click on those links manually and potentially scan lots of text yourself for relevancy. Our goal is to automate that.

I understand that, unfortunately your goal is still in the future (be it a week, month, year, or decade I can't tell you but it's not there today). In the interim (and if you want users while you refine) your search results should at least be on par with Google/Bing/etc. That way the "happy path" is your ML spits out the right answer and no links need to be clicked but if your logic can't come up with an answer or if it comes up with the wrong one you need the results to be a viable fallback.

EDIT: Building on what I said:

I use Github CoPilot and have been very happy with it. It's far from perfect and even when it spits out good code I have to do minor cleanup but it does save me time and "sparks joy" when it works. When it doesn't work it doesn't really get in my way. If CP required I change my entire method of programing, IDE, or if I had to go into a "special mode" to use it then it would be next to worthless to me.

As it stands you don't have a good fallback (regular results). Your product should be additive to what currently exists in the space. Not "a step forward if we guess the correct answer and a massive step backwards if we don't". I 100% believe you can make changes such that the results function as a perfect fallback (I've outlined them in various places of this thread).

Not the parent poster, but I think there is an important distinction between information density and information relevancy. Google is information dense (compared to this), but not all of it is relevant. This search engine aims for higher relevancy, but the density suffers from the stylistic choices of the creators.

This is exactly what we think. And yes, we definitely plan to do better with space efficiency

With one dominant search provider, we are constantly conditioned to parse the results from Google. It is very easy to ignore certain parts of the page and mentally process which parts of the page your brain is interested in.

So, while it’s not necessarily “information dense”, finding the information you need is comparatively “cognitively light”. Or at least predictable…

The devil you know…

You're right -- we are all conditioned by Google. Yet, using Hello for my own technical searches these past few weeks, higher signal and lower noise is much better for me personally. At the end of the day, Justin and I are making the search engine that we want to use ourselves as developers.

Fair point, but I think the technical term for that is "Stockholm Syndrome". Or perhaps in this case, we should call it "Mountain View Syndrome".

I think you missed the forest for the trees... it is a Q&A system not just a search engine. You can talk to it, you can refine your queries.

To the SayHello team: kudos for being faster than Google to release a Q&A+search system. I was expecting something like this for a couple of years wondering why Google was sleeping on its mountain of papers and not doing it.

Search was the first step in finding information, Q&A is the next logical step. Language models+search such as DeepMind RETRO have shown this approach to be very efficient: 25x reduction in model size for the same perplexity and verifiable correct answers with source document references.

In the future I expect search to become more like an assistant with context and language abilities. Retrieving a bunch of web pages is so 2000's. Q&A is especially relevant for mobile use with speech interface (hello Siri and Google Assistant).

> I think you missed the forest for the trees... it is a Q&A system not just a search engine. You can talk to it, you can refine your queries.

From the creators:

> We're building a better search engine for software developers.

Also no you can't "talk to it", I'm not sure where you got that idea. It has a "Ask a follow up" but that performs a new search with none of the context of your previous search (also this UI of sliding a modal up from the bottom and layering the results is terrible).

> Search was the first step in finding information, Q&A is the next logical step.

And we are clearly not there. Not only does this not allow you to ask follow-ups to refine but it doesn't give good results in my testing.

Could you post which examples you tried? It's not perfect, but the "Ask a followup" feature is usually smart enough to use existing context to refine.

I asked a question with "php" in the search then asked a follow up without including "php" in the search and it gave me python results. Also, and I'm sure this is a code formatting issue, the PHP code is invalid (newlines appear to be missing, the important one being after the opening tag) [0]

[0] https://cs.joshstrange.com/RP4B59

I don't see a followup in the screenshot you provided. Again, we're definitely not perfect with followups, but we generally do capture context. It would be very helpful if you could tell us your original search query, your followup, and your intent with this question.

That wasn't what I searched for and did a follow, here is a repeat of the original and follow up I tried (or as best as I can remember, I know it actually showed me python code last time, now it's showing SQL and python results).

Original (php get end of day timestamp): https://cs.joshstrange.com/50y9Pf

Follow up (end of month timestamp): https://cs.joshstrange.com/hStUEm

Sidenote: This slide over modal (that hides the results of the first query, you cannot get to them once you do a follow up) has got to be the worst of all worlds. It's very unintuitive, doesn't provide any value, makes your initial query only as useful as what you can see "before the fold". Just redirect to the new results or append them under. This modal is frustrating to work with, it's a weird parallax-type thing: https://cs.joshstrange.com/d6rhPZ

> * I won't use a different search engine for programmers stuff vs everything else.

I'd use this as a ddg bang[1]. I don't use them often, as ddg is a great search engine, but some search engines handle certain queries better and ddg lets you route queries efficiently.

https://duckduckgo.com/bang

Thanks for the feedback. We agree that speed is incredibly important, and we're working on making searches much faster. We'll be iterating on the UI/UX as well, as we think that we can definitely do better and be more efficient with space.

I'd love to hear more about what you mean by "informationally dense" -- some search engines simply show more information on the results page, but that doesn't make results inherently better in my opinion because it frequently simply increases noise relative to signal.

Our current approach is to provide only the most relevant answers/code snippets and nothing else (high signal with low noise) as opposed to cramming in every Stack Overflow answer we can find. We realize we still have a long way to go to make it magical for every search, but we're working on it.

Consistent, non-moving (as things load) UI is super important. Also something that bugged me but I didn't realize why until now: don't use the full width for the description under links (or the titles for that matter). We've known for some time now that if you make text too wide it becomes harder to read.

My suggestions:

* Kill the padding/margins, it's pretty for demos or certain cases but I want to be able to see more information, heavy padding/margins have no place in search results.

* Shrink the search bar to the upper left like every other search engine. Keeping it centered with tons of padding wastes space. Take your logo and put it to the left of the search field, take the buttons and put them to the right. On my screen you are burning a little over 500px of vertical space with things that don't matter, the results matter.

* Shrink your "regular" search results to be half the width of the screen (on desktop, something like a max of 700, Google uses ~640 as does Ecosia). Use the space to the right to show your AI/ML results. This means no content will jump around and people can more easily read the results, full-width is very hard to read. Also shorten the "description" under the links. 2 lines max (at 640px width).

* Either don't ask "Was this answer helpful?" (use hints like: Did they click the link? Did they leave the site after seeing the results?) OR don't make it move the content (hold the space empty if you must animate it in, just don't let the content shift multiple times after doing a search).

Here is your default result for "this is a test" search query: https://cs.joshstrange.com/oKbz6G

Here it is with a bunch of padding/margins removed: https://cs.joshstrange.com/VEVXGh

Yes, I removed the logo/buttons because that was faster than moving them to the left/right of the search but the end result is the same. In my tightened up version you can fit 8+ result links where the initial version could only show 3, also all the results are easier to read.

Thank you, the cleaned up version is helpful. We definitely have a lot of UX work to do :)

> some search engines simply show more information on the results page, but that doesn't make results inherently better in my opinion because it frequently simply increases noise relative to signal.

But if the "automatic" answer fails and I need to skim results, as I'll often need to do, you put 3 result previews in a space DDG and Google fit 5. They also apply reasonable defaults for the max line length - a basic typography thing that improves quick readability a lot.

To comment on the dynamic DOM - we're displaying up to three answer types (text, code, links) for each question. We're loading them independently to get information to the user as fast as possible. The alternative (in this state) is to have all of them wait until the slowest component finishes. We're still in the early stages of development, so either way it's not going to be perfect. I can see how this can be a poor experience for some - we're working on it.

Side-by-side is the best way to handle this. Show results on the left and load in the ML stuff on the right after it loads. This prevents content-jump and makes the results less wide (you want to aim for <700px to be more readable).

Maybe not everyone understands that the Q&A responses have to go through a large language model before they are displayed. This takes time, showing something while the LM is churning away is a good idea.

Yep, the current loading bar attempts to do that (replaced by the slowest generated answer when available). Definitely looking into new ways to improve speed + loading experience if necessary.

A placeholder empty box that gets populated when the content arrives would be an improvement.

Also the scraped snippet appears at the top of the results a couple seconds after the results load and it causes all the results below it to suddenly jerk lower on the page

Lowest common denominator and "one click" is killing the internet for me. A lot of times I am the lowest common denominator and so that's fine. But when I am a specialist I want something that lets me be specific and gives me specific results.

How much more specific do you need than having the ability to refine your question iteratively? I think regular search engine only allow for a few special keywords. Here you can use natural language to refine.

Sorry, I meant this in response to the part of the parent's comment about not wanting a specific search engine for code. To make it clear - I could see myself using this engine.

UI: Feels overpadded to me, I'd like to be able to see more stuff without scrolling so far

a search for v8 gave me:

* juice

* v8 engine

* juice

* v8 engine

* juice

so definitely some non-programming searches showing up, unfortunately none of the documentation sources for v8.

Yep, I saw non-programming stuff but my worry is, if they are branding themselves as "better search engine for software developers", that programming-stuff will be weighted higher than non-programming stuff even if the search term has nothing to do with programming (or a tenuous link). Though your search examples seem to prove the exact opposite.

All that said the UI/UX is too frustrating to use (as-in) even if they don't promote programming content over non.

We learned many of these lessons at https://you.com/code:

* we also needed to build a strong "everything else" search engine and then

* have great results for coding with specific search apps like StackOverlfow, AI code complete, ++

* be very fast (we messed that up when we first launched)

* have great scores on Privacy Badger, be compatible with uBlock, etc.

Last week we've started opening up our platform to collaborate on results with outside developers and have gotten a lot of interest: https://about.you.com/developers/

Maybe we can collaborate also with you guys at sayhello. Ping me at hey@you.com if you want to compare notes.