In Python, one can run a program by package name, file name, directory name or zip file name. Also, one can run commands from stdin (e.g. by pipelines) link
In Julia, we can run commands from stdin but it isn’t mentioned in docs! (I’m not sure! maybe somewhere else)
For example, this is working:
echo 'println(sinpi(1/2))' | julia
in Julia Version 1.3.0
Commit 46ce4d7933 (2019-11-26 06:09 UTC)
IMO, all that interfaces can be useful for some cases.
I looked for any discussion but not found anything, so thought it would be good to discuss and decide whether Julia shoulds have them or not. 
I am not sure what this means in the context of Julia packages, which usually contain type and method definitions, not toplevel code.
Look for julia -e, which is somewhat simpler for short snippets, or simply julia some_script.jl.
For example, youtube-dl is a python package. you can install it by python3 -m pip install youtube_dl and use it by python3 -m youtube_dl
Actually, python run __main__.py file that located in the root directory of the package.
youtube-dl’s __main__.py file.
pip’s __main__.py file
Most julia packages aren’t for end-user and i know that it’s a less popular feature but
julia -m <pkgname> <pkgarg1> <pkgarg2>
is nicer than
julia -e "using <pkgname>; main()" <pkgarg1> <pkgarg2>
For Julia, it doesn’t have to be a file, it can be a specified function in the main module. and in anyway, it’s optional and can’t break compatibility.
I agree with you they are better interfaces, using cat <file> | julia or echo <str> | julia are wrong indeed but if one has a program that generate some julia commands or want to run some online code, using pipelines could help. e.g. curl <link> | julia
Julia distinguishes projects and packages. Here you are talking about projects that contain an application.
That functionality is WIP, but if you are interested in delivering an “executable” like youtube-dl (which is usually deployed as a python script in binary format), look at
https://julialang.github.io/PackageCompiler.jl/dev/devdocs/binaries_part_2/
(incidentally, I moved the topic from internals to Usage)