"The problem is that coding isn’t fun if all you can do is call things out of a
library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who’d want to go into that as a career?"
"In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job…".
The hardware industry didn't stop at mass-produced integrated circuits (IC) though. ASICs (Application-Specific Integrated Circuit) and SoCs (System on a Chip) are common now.
Similarly while IC-style libraries may be good enough for back end systems and native applications, front end can only tolerate the associated bloat to a point otherwise tree shaking wouldn't be a thing—and code has to be deliberately structured for tree shaking to work.
So apart from hand coding, in terms of automation, this suggests tooling that is capable generating exactly the functionality required but with the minimum amount of code. It doesn't take too much of a leap to imagine that "configuration" of such tooling is going to be some form of "programming"—though likely more declarative in nature.
Interesting point. I immediately thought of C# WASM. Whereby all Javascript can now be bypassed. No more bloat, because the C# IL and subsequent machine code don't have it. In fact I believe C# WASM also supports pre compiled machine code.
If the code supports DI using configuration options, then optimal low code solutions are workable.
No more bloat, because the C# IL and subsequent machine code don't have it.
I don't agree. The bloat exists in the form of the .NET CLR which isn't present on browser- the JavaScript runtime already exists on all browsers. And for the time being each isolate/thread/worker would need it's own copy of the runtime in memory which can add up pretty quickly especially on resource constrained devices.
WebAssembly is an attractive option for languages with minimal run times like C/C++, Rust and perhaps even AssemblyScript but due to their comparatively slow development cycles will most likely be optimizations rather than main application development (there will always be exceptional niche cases).
In many cases using JavaScript as a compilation target will still make more sense in order to take advantage of the existing capabilities rather than having to design some minimal purpose designed WebAssembly runtime (especially during product inception).
Some C# dialect to generate WebAssembly against some minimal Web API specific runtime via WASI perhaps but there is no advantage going through the CIL.
I don't agree with that either. C# is able to deliver code that's pre-compiled and fully optimized at the machine layer. Apart from a one time CLR load the bloat comparison holds no water. Javascript only goes to the IL layer which always interprets into machine code. Optimization with Jit are inferior, they don't have time to do the same thing as multipass compilers. Minus the one time CLR load WASM is super fast. It's ultimate niche is with those needing ultra secure run time.
I couldn't agree more. It's so sad that much of what seems to pass for "development" today is really little more than simple plumbing - connecting together premade parts in a defined manner, to accomplish things that have largely been done before.
Personally I cannot stand that, and derive no sense of achievement or enjoyment from it whatsoever. I much prefer building as much as I can from scratch. This is how I taught myself to code from age 7, and it's still the reason I love writing code.
Working in this way gives a far greater understanding of languages and programming concepts. I always found it interesting when doing this as a job (but coming from a totally self taught background) that concepts I'd worked out for myself and techniques I had used actually had formal names. These things had just come to me as emergent knowledge from writing a lot of code. That's where the joy is for me... in the discovery, driven by curiosity and experimentation. Interestingly, this lack of knowledge of the formal names for programming concepts was sometimes seen by interviewers as a lack of ability. I think this is testament to how bad a lot of interview techniques are.
Sadly there is too much "convenience culture" in development these days... resulting in diminishing amounts of real understanding, insight, and interesting work.
@jonrandy It depends what you consider fun. If you're taking a spreadsheet lib that you don't wish to re-invent and it satisfies the need you have in a bigger product or vision, you might find it more fun to build that bigger product or vision with the parts.
Fun is what YOU make of it.
Based on your logic above, you might want to go make a computer from scratch on an uninhabited island before writing an OS before writing a browser before writing a web app!
Good work @tato!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Coders At Work: Donald Knuth (2009):
"The problem is that coding isn’t fun if all you can do is call things out of a
library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who’d want to go into that as a career?"
international lisp conference -- day two (2009):
"In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job…".
Whatever happened to programming? (2010):
"Today, I mostly paste libraries together."
Perhaps that explains the proliferation of packages on npm - at some point it's just more fun to write libraries.
True, just like integrated circuits dominated the world, integrated software is finally getting there.
Why reinvent anything which already has a marketable solution?
BTW, a medium complex custom app. from scratch takes about 1.5 years.
The hardware industry didn't stop at mass-produced integrated circuits (IC) though. ASICs (Application-Specific Integrated Circuit) and SoCs (System on a Chip) are common now.
Similarly while IC-style libraries may be good enough for back end systems and native applications, front end can only tolerate the associated bloat to a point otherwise tree shaking wouldn't be a thing—and code has to be deliberately structured for tree shaking to work.
So apart from hand coding, in terms of automation, this suggests tooling that is capable generating exactly the functionality required but with the minimum amount of code. It doesn't take too much of a leap to imagine that "configuration" of such tooling is going to be some form of "programming"—though likely more declarative in nature.
Interesting point. I immediately thought of C# WASM. Whereby all Javascript can now be bypassed. No more bloat, because the C# IL and subsequent machine code don't have it. In fact I believe C# WASM also supports pre compiled machine code.
If the code supports DI using configuration options, then optimal low code solutions are workable.
I don't agree. The bloat exists in the form of the .NET CLR which isn't present on browser- the JavaScript runtime already exists on all browsers. And for the time being each isolate/thread/worker would need it's own copy of the runtime in memory which can add up pretty quickly especially on resource constrained devices.
WebAssembly is an attractive option for languages with minimal run times like C/C++, Rust and perhaps even AssemblyScript but due to their comparatively slow development cycles will most likely be optimizations rather than main application development (there will always be exceptional niche cases).
In many cases using JavaScript as a compilation target will still make more sense in order to take advantage of the existing capabilities rather than having to design some minimal purpose designed WebAssembly runtime (especially during product inception).
Some C# dialect to generate WebAssembly against some minimal Web API specific runtime via WASI perhaps but there is no advantage going through the CIL.
I don't agree with that either. C# is able to deliver code that's pre-compiled and fully optimized at the machine layer. Apart from a one time CLR load the bloat comparison holds no water. Javascript only goes to the IL layer which always interprets into machine code. Optimization with Jit are inferior, they don't have time to do the same thing as multipass compilers. Minus the one time CLR load WASM is super fast. It's ultimate niche is with those needing ultra secure run time.
I couldn't agree more. It's so sad that much of what seems to pass for "development" today is really little more than simple plumbing - connecting together premade parts in a defined manner, to accomplish things that have largely been done before.
Personally I cannot stand that, and derive no sense of achievement or enjoyment from it whatsoever. I much prefer building as much as I can from scratch. This is how I taught myself to code from age 7, and it's still the reason I love writing code.
Working in this way gives a far greater understanding of languages and programming concepts. I always found it interesting when doing this as a job (but coming from a totally self taught background) that concepts I'd worked out for myself and techniques I had used actually had formal names. These things had just come to me as emergent knowledge from writing a lot of code. That's where the joy is for me... in the discovery, driven by curiosity and experimentation. Interestingly, this lack of knowledge of the formal names for programming concepts was sometimes seen by interviewers as a lack of ability. I think this is testament to how bad a lot of interview techniques are.
Sadly there is too much "convenience culture" in development these days... resulting in diminishing amounts of real understanding, insight, and interesting work.
There's 2 concerns, both profitable 1) Selling software built from parts and 2) Building software parts for sale or use in an enterprise.
I've always done #2 but have often wondered about #1.
@jonrandy It depends what you consider fun. If you're taking a spreadsheet lib that you don't wish to re-invent and it satisfies the need you have in a bigger product or vision, you might find it more fun to build that bigger product or vision with the parts.
Fun is what YOU make of it.
Based on your logic above, you might want to go make a computer from scratch on an uninhabited island before writing an OS before writing a browser before writing a web app!
Good work @tato!