Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to Pluto.jl

juliafordatascience.com

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Introduction to Pluto.jl

#111

Post by lungben »

ChrisRackauckas wrote: post #66
KMag wrote: post #59

Earlier quoted context omitted.

It improves reproducibility, consistency, and sharing, but reduces convenience for some operations. It's a trade-off in favor of programming in the large. If you don't want to recompute dependent nodes, then use new names for your experiments rather than redefining old functions and variables. Yes, in some ways this is less convenient for you, but it's more convenient for people receiving your notebooks, that the not…

I think this is the interesting point though. Many people want to use Jupyter notebooks so that it looks reproducible. Not to make it actually reproducible. God forbid it actually has to be re-ran, it could have different results! I think that's my main notebook gripe: they make it look like if you run the code you'll get these results, but that's not even close to the case. Many people abuse this. At this point, I p…

Yes. A Jupyter notebook is only reproducible in my opinion if you can hit "Restart Kernell and execute all cells" and get the same result.

Otherwise, it should never been shared with other people or even contain relevant analysis you may need for yourself later.

But this is not enough - also the library dependencies need to be fixed. Pluto will make this very easy in the near-future: https://github.com/fonsp/Pluto.jl/pull/844

Re: Introduction to Pluto.jl

#112

Post by jakobnissen »

enriquto wrote: post #96
JustFinishedBSG wrote: post #19

Earlier quoted context omitted.

> I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces. What does it even mean? What is a CLI interface for a programming language if not a REPL ?

> > I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces. > What does it even mean? What is a CLI interface for a programming language if not a REPL ? I guess they mean that the julia interpreter should be a good unix citizen (which is quite not at the moment). For example, while you can in theory…

I think there needs to be a distinction between on one hand Julia's startup time, which is an inevitable consequence on its compilation model and unlikely to change, and on the other hand whether there is a lack of command line functionality in Julia, e.g. the package manager. The latter is much easier to amend.

Re: Introduction to Pluto.jl

#113

Post by enriquto »

jakobnissen wrote: post #112
enriquto wrote: post #96

Earlier quoted context omitted.

> > I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces. > What does it even mean? What is a CLI interface for a programming language if not a REPL ? I guess they mean that the julia interpreter should be a good unix citizen (which is quite not at the moment). For example, while you can in theory…

I think there needs to be a distinction between on one hand Julia's startup time, which is an inevitable consequence on its compilation model and unlikely to change, and on the other hand whether there is a lack of command line functionality in Julia, e.g. the package manager. The latter is much easier to amend.

but is this "compilation model" inherent to the language? It seems to be an implementation choice. It is conceivable an independent interpeter for the same Julia language but with fast startup.

Re: Introduction to Pluto.jl

#114

Post by simeonschaub »

enriquto wrote: post #113
jakobnissen wrote: post #112

Earlier quoted context omitted.

I think there needs to be a distinction between on one hand Julia's startup time, which is an inevitable consequence on its compilation model and unlikely to change, and on the other hand whether there is a lack of command line functionality in Julia, e.g. the package manager. The latter is much easier to amend.

but is this "compilation model" inherent to the language? It seems to be an implementation choice. It is conceivable an independent interpeter for the same Julia language but with fast startup.

Julia already comes with an interpreter, try starting your session with `julia --compile=min`.

One part of the ongoing effort to reduce latencies is to allow package authors to specify optimization levels on a per-module basis. This is great for plotting packages for example, since they usually don't benefit much from overly aggressive optimizations, so spending less time optimizing codes generally leads to a snappier experience. It is now even possible to opt into a module-specific fully interpreted mode, which can make a lot of sense for typical scripting tasks.

Re: Introduction to Pluto.jl

#116

Post by enriquto »

simeonschaub wrote: post #114
enriquto wrote: post #113

Earlier quoted context omitted.

but is this "compilation model" inherent to the language? It seems to be an implementation choice. It is conceivable an independent interpeter for the same Julia language but with fast startup.

Julia already comes with an interpreter, try starting your session with `julia --compile=min`. One part of the ongoing effort to reduce latencies is to allow package authors to specify optimization levels on a per-module basis. This is great for plotting packages for example, since they usually don't benefit much from overly aggressive optimizations, so spending less time optimizing codes generally leads to a snappie…

That's great! Hoping to see julia get snappier at every release! (as it seems to be going)

Re: Introduction to Pluto.jl

#117

Post by Iwan-Zotow »

jaegerpicker wrote: post #42
Iwan-Zotow wrote: post #18

Earlier quoted context omitted.

> Are there any plans to have a non-browser Jupyter? Sure. VSCode with python and Jupyter extensions

Is VSCode's Jupyter extension much better than PyCharm's? Just curious, I prefer PyCharm over VSCode for normal python dev work. By a lot but I get it's personal preference, so I'm curious.

can't compare with charm, but a lot better than web, I believe
Post reply on HN