The mental model distance between dev tools and user tools is simply too large. Dev tools are still too anchored in the 50's model of source-code >> compilation >> runtime code, when consumer products have a much more healthy mixture of active content and tool palletes working on the content. Heck, even the guy in the article asks about "Programming Languages Startups" when he means "Integrated development startups".
This difference is shrinking in the web, both client (DevTools run like an app inside the browser, with live changes to the code reflected instantly in the page) and the cloud (the entry point interface is a collection of collections, where you can inspect and operate on any component running in the system, and even create some kinds of workflows in the live environment).
But the lowest level for designing components relies on specifying a fully formed program in formal code, and having to run a build-deploy-test cycle without errors before seeing whether it works, instead of having code and data run side by side to see how the code behaves.
I put my hopes in online notebooks, but these are used mainly for data analysis, and "true developers" seem determined to ignore them.
The gap from an "online notebook" to "here's the script to run the monthly report" or "here's the model complete with training and inference that anybody can retrain" is wide.
Yet it's the difference between a data scientist making an occasional report to putting their expertise on wheels that makes it worth paying for.
Notebooks don't need to be online. You can run a local notebook same way as you run a local IDE.
The most significant difference is that the notebook always has runtime information about how the available information is being processed, while the IDE only has this information available while it's in debug mode. The first model provides much more information about the system behaviour, easier to access.
> I put my hopes in online notebooks, but these are used mainly for data analysis, and "true developers" seem determined to ignore them.
This is merely my own personal preference, not an assertion that my stance is correct or common.
For development, it's important to me that I can put the toolchain into version control along with the code. This ensures that I can check out a build that is years old and be able to build it without issue.
SaaS solutions break this for me, so I avoid them to the greatest extent that I can. If it's cloudy, then it can change without warning or recourse. That's a problem.
For that reason, I would never seriously entertain using something like a netbook for development.
You can use toolchains with notebook software, provided
a) the notebook has an internal text representation that can be version-controlled, and
b) the notebook follows a spreadsheet-loke paradigm with incremental non-mutable data structures, so that all state is represented consistently at all times (no dependence on what order you've run the cells in the current session).
This difference is shrinking in the web, both client (DevTools run like an app inside the browser, with live changes to the code reflected instantly in the page) and the cloud (the entry point interface is a collection of collections, where you can inspect and operate on any component running in the system, and even create some kinds of workflows in the live environment).
But the lowest level for designing components relies on specifying a fully formed program in formal code, and having to run a build-deploy-test cycle without errors before seeing whether it works, instead of having code and data run side by side to see how the code behaves.
I put my hopes in online notebooks, but these are used mainly for data analysis, and "true developers" seem determined to ignore them.
reply