Pluto.jl VS monorepo

I thought that notebook based development and package based development were diametrically opposed in the past, but Pluto.jl notebooks have changed my mind about this.

A Pluto.jl notebook is a human readable Julia source file. The Pluto.jl package is itself developed via Pluto.jl notebooks.

https://github.com/fonsp/Pluto.jl

Also, the VSCode Julia plugin tooling has really expanded in functionality and usability for me in the past year. The integrated debugging took some work to setup, but is fast enough to drop into a local frame.

https://code.visualstudio.com/docs/languages/julia

Julia is the first language I have achieved full life cycle integration between exploratory code to sharable package. It even runs quite well on my Android. 2023 is the first year I was able to solve a differential equation or render a 3D surface from a calculated mesh with the hardware in my pocket.

Re Julia there is also pluto.jl that is another notebook-like environment for julia. It's been a few years since I played with it but it looked cool, for example it handles state differently so you don't get into the same messes as with ipython notebooks. https://plutojl.org/

For this, Notebooks are often used. Julia offers a uniquely nice and interactive Pluto notebook for the web https://github.com/fonsp/Pluto.jl

I believe this is what Pluto sets out to do for Julia.

I used it as part of the “Computational Thinking” with Julia course a year or two back. Even then the beta software was very good and some of the demos the Pluto dev showed were nothing short of amazing

https://plutojl.org/

I think what you want is Pluto!

I like how Pluto.jl handles this:

> Pluto offers an environment where changed code takes effect instantly and where deleted code leaves no trace. Unlike Jupyter or Matlab, there is no mutable workspace, but rather, an important guarantee:

> At any instant, the program state is completely described by the code you see.

[1] https://github.com/fonsp/Pluto.jl

fixed the capitalization https://github.com/opral/monorepo/commit/6127c6899290b35442c...

Hey there! Have you ever heard about inlang (inlang.com)? Your approach goes in our direction. Great to see so many people fixing the i18n pain! :)

If you want to take a look, here is the website featuring our products: https://inlang.com/

Last time I posted on this Subreddit I was announcing my typesafe i18n library. As luck would have it some people at Inlang saw that post and my project and contacted me to work on ParaglideJS.

I'm from inlang and we have a fully configurable JavaScript i18n library with paraglide-js that might help you. There will be a dedicated adapter of the library for NextJS that is more integrated into the framework. Until then you can look at our NextJS example and set the library up this way.

i am on a 2 year long rabbit hole to solve many i18n problems that devs face https://github.com/inlang/inlang

we are in our third (major) refactor because the problem is so complex and new requirements emerge regularly :/

inlang: localization infrastructure for software and the next git (made by the inlang team and same author of the amazing typesafe-i18n library)

https://www.loom.com/share/85d77004aa4c4bea9752d959c229e577

The irony is that this is not needed anymore. The plugin API simplified the config interface so much that initializing configs only differs by the used plugins and their respective configs.

The only useful thing that chatgpt provides is deriving what files in a filesystem are translation files. But a hardcoded version might be faster and more resilient.

Learning: The GPT hype is ... well hype. The amount of work that went into this feature is insane. The work boils down to software engineering. Sure, tools will emerge that make prompt engineering easier but so does the previous ML hypetrain led to endless nocode machine learning tools. Yet, there is no "disruptive everyone builds ML models" (for GPT "everyone will become a developer") nocode machine learning tool in sight. Maybe signaling that the premise of ML NoCode/GPT of "this works for everything" is not true. Deriving what files are translation files, yep. Deriving an entire config file, maybe not.

[0] https://github.com/inlang/inlang/discussions/408#discussion-4914727

We faced the same issue and build a viscose extension too! https://github.com/inlang/inlang/tree/main/source-code/ide-extension