But what does it really mean? From scratch.. what? Lots of you claim to do everything from scratch, but then mention OpenGL, DirectX or even SDL.
.
I built a logic circuit that manipulated individual segments on a seven segment display without using any ICs ... does that count ?
I built a logic circuit that manipulated individual segments on a seven segment display without using any ICs ... does that count ?
Did you mine the materials for the logic circuit? 
It all becomes redundant. No-one builds anything from scratch.
"If you wish to make an apple pie from scratch, you must first invent the universe." - Carl Sagan
All we do is argue about the degree of others work we use.
You use tools. If the tools are inadequate, look for better tools. If you can't find better tools, you might have to become an expert and build your own tools. Basically always do the least amount of work you can, so you can focus on the parts that are important or interesting to you.
But what does it really mean? From scratch.. what? Lots of you claim to do everything from scratch, but then mention OpenGL, DirectX or even SDL.
.
I built a logic circuit that manipulated individual segments on a seven segment display without using any ICs ... does that count ?
I'm actually rather curious as to what that project looked like. Plain individual semi conductor logic gates? Valves, tubes, or something else?
I've been exploring clockwork and mechanical computing systems as a random hobby. There is something rather cool about turning gears that pop out numbers.
But what does it really mean? From scratch.. what? Lots of you claim to do everything from scratch, but then mention OpenGL, DirectX or even SDL.
.
I built a logic circuit that manipulated individual segments on a seven segment display without using any ICs ... does that count ?
No, unless you generated your own electricity
.
.
I built a logic circuit that manipulated individual segments on a seven segment display without using any ICs ... does that count ?
No, unless you generated your own electricity
.
I used transistors, resistors and a lot of solder.
As far as generating my own electricity .... just as soon as I figure out this whole cold fusion thing, I'll let you know.
Edit: HERE is a pure mechanical binary adder powered by gravity.
The actual fundamental question is this: why is composability* so poor in our current languages/technologies?
I agree that this is a very interesting take on the problem. While I could speculate a lot on the actual "why"s of how our composability has regressed over the past decades, I don't think it'd wind up being productive :-)
What I'm personally more interested in is how we recapture the ideas of live-swapping code, of building systems that can talk to arbitrary other systems sans the stupidity of most of the "universal protocol" attempts that have been made in the past, and so on.
OK, fuck it, I'm gonna speculate a tiny bit. I think the proliferation of languages without clean ABIs (C++, cough) and the erosion of clean platform-level composablility features (like Unix espouses, and Windows doesn't) is a big part of the problem.
Ah! Unix espouses a text-level composability in the userspace. Windows espoused an object-level composability at the API level (multiple times, from Win32 to OLE to .NET/PowerShell). Both require that applications on both ends of the communication pipe adhere to protocols in order to exchange data, but the Windows protocols are more complex because they are more complete. That complexity came at the cost of integration being more difficult, resulting in lower adoption, undermining the whole process. But don't forget that Unix's userspace text-level composability is brittle! If both ends don't expect exactly the same things in exactly the same order, then you have to interpose a utility like sed or awk to transform them…
It gets complicated quite quickly.
Here's why I say that: if you're running Smalltalk, you're an end-to-end Smalltalk system. You can compose arbitrarily because the whole system is self-contained and pieces you get from other sources use the same basic mechanisms to interact with each other. Same goes for the Unix philosophy of textual communication via piping; if the entire platform believes in the compositional abstraction, it works great. If it doesn't, you get PowerShell.
Contrast that with my current workstation: I run programs and scripts written in PowerShell, Python, Ruby, C, C++, C#, and probably a handful more. Aside from the C ABI, there's no clean way for all those to interact, and the C ABI is not first-class in many of those languages.
This leads to attempts at a lingua franca of code, which usually wind up looking like SOAP or something equally obnoxious.
So ever being the stubborn pragmatist: how do we move on from this situation?
The protocols and abstractions necessary for composition must be built right into the operating system layer, to the point that the application silo is completely discarded. Really, such a system has only two applications, or application "modes": composition and presentation. The composer has the inherent ability to display and edit text, images, video, audio and a timeline and/or event graph for interactivity. All "applications" are then specifications for how to combine those elements, and instructions for de/serialization.
Yeah, the fix is to move the Smalltalk layer right into the OS.
Also, really good to see you again, Seyi!
Thanks! Good to see you, too, Mike!
(Sorry to everyone else for drifting so far afield of the topic!)
