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

61–70 of 75 posts

Re: The Build is Always Broken

#61

Post by iainmerrick »

alkonaut wrote: post #60
iainmerrick wrote: post #57

Earlier quoted context omitted.

The norm is: - Use an incremental build during development - If you hit weird errors, try a clean build - Always use a clean build for releases Make is vulnerable to weird errors, as are newer systems like Gradle. Better build systems work hard to be 100% correct. Bazel is the best example I've seen. I'd say working with an extremely reliable build system is just as eye-opening as working with a good live coding syst…

Incremental where you need to stop and restart running is still much slower than hot-edits (as in editing a dynamic/script language file) or hot-reloading statically compiled as C#). So clean build, incremental build+restart, incremental build while running I think is the 3 levels. I wonder if what the article is on about wrt. smalltalk is the last one.

That sounds about right.

You could maybe distinguish between "incremental build while running" and "no build, just interpret the code directly". But I don't think there's a major difference between those in practice, it's all just a question of how quickly code edits are picked up.

Re: The Build is Always Broken

#62

Post by partyboat1586 »

fenomas wrote: post #53
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…

Huh? I do procedural music in JS/web audio, and my projects are set up so that changes to the logic and instruments all happen live, while the music continues to play. How is that different from what you're describing? What specifically can't webpack/HMR do?

What tools do you use? Just web audio api? Or a higher level library?

Re: The Build is Always Broken

#63

Post by bzzzt »

javajosh wrote: post #45
toolslive wrote: post #43

Earlier quoted context omitted.

- 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.

"Hot code replacement" is a Java VM feature. What makes JRebel useful is support for live reconfiguration of a gazillion Java frameworks (e.g. Hibernate, CDI, Spring etc) so you don't have to restart your server after changing some configuration annotations. It's expensive though and slows down startup so it's a tradeoff.

Re: The Build is Always Broken

#64

Post by iainmerrick »

Kinrany wrote: post #50
dbmikus wrote: post #19

Earlier quoted context omitted.

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.

I think blurring the distinction between users and programmers is a big part of the SmallTalk philosophy, yeah.

Re: The Build is Always Broken

#65

Post by fenomas »

partyboat1586 wrote: post #62
fenomas wrote: post #53

Earlier quoted context omitted.

Huh? I do procedural music in JS/web audio, and my projects are set up so that changes to the logic and instruments all happen live, while the music continues to play. How is that different from what you're describing? What specifically can't webpack/HMR do?

What tools do you use? Just web audio api? Or a higher level library?

I first started out using Tone.js (and recommend it!), but later wound up rolling my own engine and so forth. So I'm just using WebAudio directly (or via libraries I wrote).

Re: The Build is Always Broken

#66

Post by specialist »

kstenerud wrote: post #40

The biggest problem I see with live systems is this: The longer you run without a restart, the more dependent you become on the current state. And the more dependent you become, the more likely it is that restarts will be catastrophic due to lost implicit state.

Keen point.

There was (is?) a live code editing capable browser which updates the source code. My failing memory seems to remember creating a project and mounting directories. Chrome? Great idea, but IIRC, also very brittle. And because it had it's own notions of "project", there was some impedance mismatch with the IDE.

Re: The Build is Always Broken

#67

Post by SamBam »

Cthulhu_ wrote: post #37
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…

I understand where Webpack et al came from, but the more I work with it the less I like it. There used to be a time when the JS I wrote was the exact same that was executed. Now, even in development mode, it gets pulled through several tools (webpack/babel and a heap of their plugins, a minifier, source maps get generated etc) before my changes are visible, even in an incremental / hot reloading build. It's not just…

Which is fine, if you have no need of any dependency management (stick everything in script tags and reference globals), your script is going to be made up of only a few individual .js files (every one has to go in the header), and you have no use for JSX or TypeScript.

For most people working on larger projects, though, the advantages of real dependency management (however broken NPM is) and transpiling JSX or TS is worth the compilation, which you get used to.

Re: The Build is Always Broken

#68

Post by [deleted] »

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…

[deleted]

Re: The Build is Always Broken

#69

Post by theamk »

Kinrany wrote: post #50
dbmikus wrote: post #19

Earlier quoted context omitted.

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.

That sounds insane -- how do versions updates work then? One of the best parts of only allowing customization at well-defined points is that you can upgrade software and it is likely to keep working.

Or is the Smalltalk idea that you never update your software?

Re: The Build is Always Broken

#70

Post by ratww »

Cthulhu_ wrote: post #37
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…

I understand where Webpack et al came from, but the more I work with it the less I like it. There used to be a time when the JS I wrote was the exact same that was executed. Now, even in development mode, it gets pulled through several tools (webpack/babel and a heap of their plugins, a minifier, source maps get generated etc) before my changes are visible, even in an incremental / hot reloading build. It's not just…

If you don't need backwards compatibility, you can use ES6 modules directly in the browser [1] and even load NPM packages in module format from Pika or Unpkg.

Living without a bundler was alright.

At my last job we checked Google Analytics and almost 100% of our users were on greenfield browsers, so we moved to that and had no issues.

[1] https://www.sitepoint.com/using-es-modules/

Post reply on HN