607 karma · joined April 30, 2013
[0] autocorrect lol of the day: "I'm a vi[rgin]"
That said, Scheme is probably a good example. Lisps in general are a funny case for functional programming: historically they were described as "functional" but the word had a different meaning we would now call "procedural"; I think Lisp may have predated Algol so the concept of having functions at all was fairly notable. However, Lisps generally support functional programming and Scheme has embraced it more fully than the others. Note, for example, that Scheme doesn't actually have loops as a fundamental concept in the language; it emulates them with obligatory TCO and convenience macros.
This is known as point-free style. I think point-free style implies functional programming (at least locally; i.e., a point-free function will by definition be functional, although it can call imperative functions) but functional certainly does not imply point-free.
Of course the article shows its bias more clearly here:
> Whether in the US, UK or elsewhere, the more dissatisfied and afraid people become, Homer-Dixon says, the more of a tendency they have to cling to their in-group identity – whether religious, racial or national. Denial, including of the emerging prospect of societal collapse itself, will be widespread, as will rejection of evidence-based fact. If people admit that problems exist at all, they will assign blame for those problems to everyone outside of their in-group, building up resentment.
This is using a lot of loaded language to suggest that it's primarily the right guilty of these things, but identity politics is a mainstay of the left, at least in the US. Could it be that eliminating identity politics is more important than redistributing wealth?
This is bullshit, but it's very pernicious bullshit because while it only takes one person to pull this out of their ass, no one person can refute it. No one person can articulate where all the stuff in an iPhone came from; abstraction is one of the true marvels of technology today
One choice, for example, would be to rely on the bootloader's handling of .bss sections to allocate a temporary 'heap'. Haven't tried it, but it probably gets the job done well enough to bootstrap a real dynamic allocator. The point is, though, you can't just say "throw lazy-static and a custom allocator at the problem". Note, for example, my proposed solution requires writing the custom allocator entirely outside of Rust, since it can't access any Rust statics. It also requires two implementations of the custom allocator - one for bootstrapping, and the other after bootstrapping. These will have to be dynamically selected between at runtime since (AFAIK) Rust is hardly going to support static switching between them. Then you have to consider interoperability between them.
Finally, not all kernel designs are prepared to do any kind of dynamic allocation at all: microkernels which hand all available physical memory to userspace for management there cannot dynamically allocate (except, perhaps, for O(1) of allocation in a small, static heap - but at that point, what's the point?).