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

The Build is Always Broken

gbracha.blogspot.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: The Build is Always Broken

#41

Post by dragonwriter »

mishoo wrote: post #32
skrebbel wrote: post #13

People love to complain about Webpack, but it pretty much does all of this out of box, all the way down to hot-reloading UI components. In that sense it's way ahead of all C++, C#, Java, etc build systems I know. Doing an `npm run dev` type of command in a reasonably set up JS project is very much this staged execution model the author talks about. Everything gets cached, on disk and in memory, only changes are recom…

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to…

> You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it.

Erlang provides this as well, as do many dynamic languages. However, aside from certain Lisps and Smalltalk that are image based, and a few others, liveness and source persistence are typically traded off for each other. I can make a live change to a Ruby system if it is set up to provide a REPL, but unlike a live Smalltalk change I won't then have the source code for the changed but available the same way it is for the rest of the system. As a result, in many languages live coding features are mostly a tool for experimentation (usually in nonproduction environment!) on code that will eventually be incorporated into traditional source tree for a from-scratch build.

Re: The Build is Always Broken

#42

Post by kohlerm »

I do not really see the point of this article. If you want modular software you need to somehow declare dependencies to existing (maybe open source) software components. If you only want to do this via import statements then you would have to use some long URLs pointing to the exact version. You would have to include some GIT commit hash in case the component is hosted on GIT. That doesn't look like a practical approach to me.

If you don't need modularity then as others point out Smalltalk solved this long time ago.

Also as others pointed out, gradle, bazel etc solve most of the issues mentioned (incremental builds, distributed (!) caching of build resources).

Re: The Build is Always Broken

#43

Post by toolslive »

mishoo wrote: post #32
skrebbel wrote: post #13

People love to complain about Webpack, but it pretty much does all of this out of box, all the way down to hot-reloading UI components. In that sense it's way ahead of all C++, C#, Java, etc build systems I know. Doing an `npm run dev` type of command in a reasonably set up JS project is very much this staged execution model the author talks about. Everything gets cached, on disk and in memory, only changes are recom…

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to…

- IBM's visual age for java provided most of this for Java too. (yes, it was modeled to the smalltalk env with the same name)

- Zope (python app server) had a feature where you could debug a web application (in production) in a private session, so all code modifications you did in your session were private until you committed the code.

Re: The Build is Always Broken

#45

Post by javajosh »

toolslive wrote: post #43
mishoo wrote: post #32

Earlier quoted context omitted.

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to…

- IBM's visual age for java provided most of this for Java too. (yes, it was modeled to the smalltalk env with the same name) - Zope (python app server) had a feature where you could debug a web application (in production) in a private session, so all code modifications you did in your session were private until you committed the code.

- Jrebel is a commercial tool that also lets you replace bytecode in a running program without loss of state.

Re: The Build is Always Broken

#46

Post by imtringued »

skrebbel wrote: post #13

People love to complain about Webpack, but it pretty much does all of this out of box, all the way down to hot-reloading UI components. In that sense it's way ahead of all C++, C#, Java, etc build systems I know. Doing an `npm run dev` type of command in a reasonably set up JS project is very much this staged execution model the author talks about. Everything gets cached, on disk and in memory, only changes are recom…

Webpack has 600 transitive dependencies. There is no way you can use that in a serious business if you care about security.

Re: The Build is Always Broken

#47

Post by jcrites »

mishoo wrote: post #32
skrebbel wrote: post #13

People love to complain about Webpack, but it pretty much does all of this out of box, all the way down to hot-reloading UI components. In that sense it's way ahead of all C++, C#, Java, etc build systems I know. Doing an `npm run dev` type of command in a reasonably set up JS project is very much this staged execution model the author talks about. Everything gets cached, on disk and in memory, only changes are recom…

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to…

> You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it

This can be done in a number of other common languages today such as Java (JVM languages) and C# (probably all .NET languages). Most IDEs I've seen for those platforms support it.

Substantial enough changes to the code can require an application restart, but most changes you might make like changing the implementation of a function, adding new functions to a class, etc., will not. Hot Code Replacement (HCR) has been supported since Java 1.4: https://wiki.eclipse.org/FAQ_What_is_hot_code_replace%3F

Fully dynamic languages like Lisp and Smalltalk permit a greater degree of this than statically typed languages do, however, since they don't have types and a type system to wrangle with. When I've used it, hot code replacement supported most of the changes that conceptually make sense to support.

Re: The Build is Always Broken

#48

Post by hibbelig »

dbmikus wrote: post #2

This is what Bazel, Pants, etc (and I'm sure a bunch of other build tools) do for you. You define a dependency graph, then per commit you can see what targets have been modified and then you can run commands on only targets dependent on the modified ones. I'm not sure why this blog post is written like these things don't exist. EDIT: on a re read, I'm a bit off the mark. The author seems to want the compiler or inter…

> This is what Bazel, Pants, etc (and I'm sure a bunch of other build tools) do for you. You define a dependency graph, then per commit you can see what targets have been modified and then you can run commands on only targets dependent on the modified ones.

This is way less live than the author hints at. Let's take Emacs as an example -- it can be extended using Emacs Lisp. If I write such an extension in Emacs Lisp, and I find that one of the functions isn't right, I go to the function and hit Ctrl-Meta-x and then the function is redefined in the running Emacs, and so I can try again to see if it works now.

Or take the Fish shell as an example. It provides a method to define a function that is automatically saved. So you write a shell function "foo" and you try it out (in your interactive shell) and you see it's not right. You go "funcedit foo" which pops up an editor with the function in it. You make your change and save and exit the editor. You run the function again to see if it now does what you wanted.

A similar experience can be had, I guess, using a Java IDE when working on a web application, if your stack supports hot reload (with JRebel?). You run the application in the debugger, you find it's incorrect, you make a change to the affected method, you save and the IDE hot-reloads the new method into the existing web application and you just try again.

But for all of the above examples, it is still the case that there are two processes -- one redefines things while developing, and the other process kicks in when you turn off your computer and then turn it on again.

I think in Smalltalk, you make code changes using something like the "hot reload" thing, but the new code is automatically saved to "the image". And when you want to run the system, you open "the image".

Re: The Build is Always Broken

#49

Post by LandR »

skrebbel wrote: post #34
mishoo wrote: post #32

Earlier quoted context omitted.

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to…

FWIW hot reloading React/Vue components come quite close to this.

So does ClojureScript and Figwheel.

Re: The Build is Always Broken

#50

Post by Kinrany »

dbmikus wrote: post #19
benschulz wrote: post #12

I believe many posts here miss the core point. The article is talking about _liveness_, i.e. modifying the program while it is running. One example of this would be Squeak[1]. Another perhaps more relatable one is modifying your HTML5 app from the browser console. [1]: https://squeak.org/

In Smalltalk, does anyone actually modify the production application live? I would think you'd want to modify the live application in devel, and then copy it over. At this point, you can either copy over the difference or just replace the whole production application. I'm not sure which would be faster. I don't think liveness is important for a production system. I prefer production to evolve in discrete chunks. Live…

I barely touched Smalltalk, but I think people value liveness as a feature for the user, not the developer. This is basically ultimate customization: you can change the source code of your local copy.
Post reply on HN