> Okay. But Fredric Jameson establishes that in postmodernism we have experienced a weakening sense of historisity such that what is, what was, and what will be all exist as presents in time. 1970, 1991, 1992, and 2017 all happen simultaneously.
Okay with the postmodernism, but relying on a memory unsafe language to implement a server-side web framework in 1970, 1991, 1992, and 2017 is equally anachronistic. That being said much love to Forth! – Or, as the post-modern philosopher Slavoj Žižek is used to say: "and so on and so Forth".
That's the implementation thing, not the language. You can implement an ANSI Forth standard like GForth in a memory safe way without a lot of issues. Even the memory allocation words[0] are easily implemented in a garbage collected language. Of course that makes it useless for embedded purposes which is where Forth usually works well, but that's not an issue as you are not doing that here.
Half correct. It's true that you can improve the safety that way, but what proponents of memory safety consider a no-go is pointer arithmetic and crafting - basically not what C allows.
You can forbid yourself to do these things and implement a "safety layer" for string handling, array handling with bound checking etc. but at the end of the day, it's more a a cultural thing than a technical thing. IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.
Well, you see the result: smartphones that can't make emergency calls when you need it etc. But hey, it's written in a memory safe language and our bus factor is 0.00004 !
You can do fake pointer arithmetic which won't hurt this use case (server-side web framework); if you implement Gforth as an interpreter on the JVM/CLR or running it with Emscripten, there is no issue for server-side web frameworks like this while being safe.
That's been done for C a few times (this [0] and there are a few others); if you don't depend on the actual physical memory addresses you are using (which, in embedded, you often are counting on, but not in a server-side framework).
> it's more a a cultural thing than a technical thing.
I agree with that
> IMO this era wants to build reliability from lots of unreliable parts, and that include developers; cowboy programmers who could make reliable things by themselves have been retired.
I will not hold my breath. I tested the first (admittedly rudimentary) HMDs in the mid 1990s. VR was f-ing hot back in the days among those of us interested in "computer graphics". According to commentators, VR would have disrupted our lives over the next a few years. Here we are.
The key thing missing at that point was a half-trillion market surrounding the hardware comprising the VR devices. The cellphone industry is going to continue to plow ahead no matter what happens with the popularity of VR so no matter what displays are going to get better, mobile processors more powerful, energy efficient and smaller, networking will speed up, and hand-face-eye tracking will get better.
The only necessary tech that isn't driven by a large existing market are lenses. That's a pretty good deal for VR hardware, you just have to focus R&D money on one area while getting the rest practically for free (yes I know a lot of work goes into integrating those other components but it's nowhere near the same as having to develop the tech in the first place).
Sure. Publishing means having your name listed among the authors. This does not necessarily translate in the production of results, or in the active participation in the writing process.
An interesting statistic would be the number of scientists who are able to publish a paper every five days or so, while going solo in their work. Essentially nobody, I suppose, for so many reasons I will not list here.
There is a line of research according to which social media create addiction [0]. When we are addicted to social media, we have less and less time for tinkering and pushing the envelope, because a sizeable part of our time is claimed by such media.
[0] Griffiths, M. D. (2012). Facebook addiction: Concerns, criticism, and recommendations: A response to Andreassen and colleagues. Psychological Reports, 110, 518–520. https://doi.org/10.2466/01.07.18.PR0.110.2.518-520
Sun Microsystems could not have a more special place in my hacker heart. In my youth Sun was all over the place; I was dreaming working for them – as I would eventually did later in my life – and, admittedly, I would have done so even only on the basis of their uber cool logo. I remember working on their Sun Ray thin clients for a military contract. Good times. Thanks for sharing this video.
In my opinion this could turn in a top seller – and I wish you so – if only you could add the means to sync Hyperpaper Planner to other calendars, such as Apple's and Google's ones.
I would typically need to quickly import calendar files related to the various online events I have to take part. And the planner should account for the differences in time zones, so that I do not have to.
Your point is? Various methods exist for running OCR on PDFs and then parsing the data and transforming it for structured input into other systems. Could be a periodic sync to the middleware; i.e. daily or at user's preference via emailing the doc.
The only option we are left with is to operate under the assumption that, indeed, our machines are permanently compromised.