# Include InteractiveCodeSearch by default

**URL:** <https://discourse.julialang.org/t/include-interactivecodesearch-by-default/104026>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [September 19, 2023, 1:53pm UTC](https://discourse.julialang.org/t/include-interactivecodesearch-by-default/104026 "2023-09-19T13:53:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [September 19, 2023, 1:53pm UTC](https://discourse.julialang.org/t/include-interactivecodesearch-by-default/104026/1 "2023-09-19T13:53:41Z")

</div>

In the wake of the recent discussion of [making Revise the default](https://discourse.julialang.org/t/making-revise-the-default/103506), I suggest another tool, that looks like it could be included in every Julia release:

> **[GitHub - tkf/InteractiveCodeSearch.jl: Interactively search Julia code from...](https://github.com/tkf/InteractiveCodeSearch.jl/)**
>
> Interactively search Julia code from terminal. Contribute to tkf/InteractiveCodeSearch.jl development by creating an account on GitHub.

I actually discovered this, as [this topic](https://news.ycombinator.com/item?id=31650898) on Hacker news came up.

A person, allegedly programming for a very long time, found it difficult to navigate in Julia, since multiple dispatch made it hard for the person, to ‘guess’ the method, that is going to get executed.

Aside from the obvious point, that the person didn’t understand that it’s valuable to accustom one self with a different environment, and not succeed to program as you are used to, is it surely helpful, to prevent such behavior in the first place, by putting the tools and practices that are unique to the language, front and center.

So people cant miss it.

What do you think about this?

Is it sensible, to include InteractiveCodeSearch in the default distribution?  
And make it eventually be named in the documentation?

---

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [September 19, 2023, 5:36pm UTC](https://discourse.julialang.org/t/include-interactivecodesearch-by-default/104026/2 "2023-09-19T17:36:40Z")

</div>

> [@OpinionatedJulia Package?](https://discourse.julialang.org/t/opinionatedjulia-package/103522):
>
> I’ve read a lot of opinions about what should be default for Julia to make it more accessible. Some conflicting but a lot of it is in alignment. Some of it is breaking to be in Base. Some of it is a matter of network/community issues (re: too many Chaining packages). Has anyone attempted to make an OpinionatedJulia.jl that installs things in the global env (Revise, Infiltrator…), adds nice things to startup.jl, has its own version of Pkg.generate()/PkgTemplates for fleshing out how the sensible…

I think this is a better candidate for something like what I pondered here. I think the efforts to trim down the things that come with Julia are important because they are prerequisite to small binaries and other goals. At the very least, it doesn’t make sense to require an interactive code search tool be installed in a server that is just running Julia scripts.

However, I think we should make “distributions” of Julia where we can roll up useful tools for specific workflows. I haven’t had time to start working on this, but I think it would be great if teachers, companies, etc. could say “Here are the sensible defaults for our use case. I’ve done the work to make sure they are get installed in the right way.”

---

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [September 19, 2023, 5:45pm UTC](https://discourse.julialang.org/t/include-interactivecodesearch-by-default/104026/3 "2023-09-19T17:45:30Z")

</div>

> [@mrufsvold](#):
>
> I think we should make “distributions” of Julia where we can roll up useful tools for specific workflows.

100%

Particularly one with a complete setup for newbies, to try out the language. Ideally with [Notebooks](https://julialang.org/learning/notebooks/). 😉

Sadly, it seems like the VSCode extension doesn’t work fine with Jupyter Notebook in VSCode.  
But, I am sure, we can solve this eventually. It can be a pain, to set up a new language and all its shenanigans, as I tried a lot of smaller languages, and that is rarely a super smooth process.

Julia is no different here, and only reproducible environments, that comes as a simple executable, can really fulfill the quality, that we all strife for, I think.

It seems like dev environments are quite sensitive to individual setups.  
And I am still uncertain, with which technology we should make that.

Habitat is the best solution, that I could find, given we need it cross-platform.