kgr

This short video / simulation, explains why, IMO, Unix surpassed Multics: https://www.youtube.com/watch?v=3Ea3pkTCYx4

For those feeling nostalgic (or curious), you can run my BASIC to JS compiler in your browser:

https://codepen.io/kgr/full/yLQyLjR

Unlike previous OSes, UNIX provided the pipe facility to allow you to combine the functionality of many small programs. Ex. ls | grep ... | sort ... | more Before that every command-line program had to support the full suite of additional functionality like search, filtering, paging, etc. This UNIX/Pipe approach allowed for greater reuse and much less code. This is explained and simulated in this video: https://www.youtube.com/watch?v=3Ea3pkTCYx4

If we analyze the computational complexity of software architectures the way we do regular algorithms, we see that UNIX was much more efficient than previous OSes/approaches.

It's demonstrated in this short video: https://www.youtube.com/watch?v=3Ea3pkTCYx4

I wrote a BASIC to JS compiler/transpiler that includes all of the programs from "BASIC Computer Games" as examples.

You can try it out in your browser at: https://codepen.io/kgr/full/yLQyLjR

Just select the game you want to to run from the top-left list box, then press the "Compile" button and you'll see the translated JS source in the right text-area. Then press the "Run" button to run it.

The source code for the compiler is available at: https://github.com/kgrgreer/foam3/tree/429f2fd2b4cef0e37996a...

I worked at Google on a project called the Chrome App Builder which would let you create simple Kiosk apps which ran on these kind of devices. It wasn't uncommon for companies to buy these 5 thousand to 20 thousand at a time to run the displays in fast food restaurants, casinos, department stores, race tracks, etc.

I would say that the best programmers don't change the multiplier, but the exponent, so that the factor by which they're better than the average increases with the size of the problem. This is why you might not see as much of a big difference with a test lasting a few hours, as you would with one lasting weeks, months or years.

I explain this a bit by means of a simulation in this video: https://www.youtube.com/watch?v=3Ea3pkTCYx4

I think FOAM does most of what the author is asking for.

A quick explanation is provided in this video: https://www.youtube.com/watch?v=S4LbUv5FsGQ

And more details can be found at: https://github.com/kgrgreer/foam3#videos

FOAM is a modelling framework that generates cross-language boilerplate for you, but it takes a much broader view of what constitutes boilerplate than most systems. Typically, it can generate between 95-98% of a working cross-language cross-tier system.

FOAM helps you create features for modelled data. Features include things like a Java/Javascript/Swift classes to hold your modelled data, code to marshall to/from JSON/XML/CSV/etc., various GUI Views, and support for storing your data in various databases or file formats. However, FOAM models are themselves modelled, meaning they're afforded all of the above benefits as well. This lets you apply the MVC technique of having multiple views work against the same underlying data-model concurrently (say a grid and a pie-chart in a spreadsheet), so that you can choose the best view or views for your current need. When treated this way, your code is no longer text (but it can be, if that's one of your views), and you can easily view and store it in many different ways and more easily programmatically manipulate it.

This short fun video demonstrates how FRP is related/similar to spreadsheets:

https://www.youtube.com/watch?v=-fbq-_H6Lf4

The Wikipedia article on AA-Trees is good: https://en.wikipedia.org/wiki/AA_tree

If you eat low-pesticide fruits and vegetables, you're less likely to die. If you eat high-pesticide fruits and vegetables, your chances of dying are unaffected, which is surprising because you would expect that increased fruit and vegetable consumption would decrease your chances of dying. So, it seems that the potential health benefits of eating fruits and vegetables is negated if they contain high levels of pesticide.

of being a lightweight, platform agnostic target

A little late for that. I see that my Chrome browser is currently using 2.66GB of RAM (for about 40 tabs, or about 65M per tab). I remember when I first started using Java, my whole computer only had 8M of RAM, and while it has gotten larger, I think it is still considerably lighter weight than a web app, despite also giving much richer APIs and multi-threading. The advantage of web apps isn't that they're lighter weight from a systems resource point of view, but lighter weight from a user's effort in installing and using the app, point of view (now that Applets are gone).

I don't think it's because of the milk lobby (which didn't exist until early 1900s according to other posts) because I once browsed a cookbook from the 1800s and noticed that many of the recipes called for an amazing quantity of butter. The recipe for bread, which made two loaves at once, called for 1 pound of butter. Pound Cake also uses a pound of butter.

This short video demonstrates why pipes were crucial for UNIX's success:

https://www.youtube.com/watch?v=3Ea3pkTCYx4

I wonder if this is the reason for the recent Ontario license plate fiasco. The new design for license plates had a blue background but they were very difficult to read.

https://toronto.ctvnews.ca/premier-doug-ford-to-hold-first-n...

When we designed to UI library for FOAM in 2011 at Google, we did extensive benchmarking, and discovered that DOM calls were very slow and that we could greatly improve performance by batching them. Yes, in the end, you still need to make DOM calls to update the DOM, but you were better off forming all of your DOM's html on the JS side and then just make one call to element.innerHTML = myHTML and then hookup listeners if necessary. The JS to C++ bridge was very slow, and so you were better off to make one large call and then have C++ parse your HTML and build all of the DOM itself than you were to make many small DOM calls adding each element and attribute value individually. However, I was recently writing a document on the performance advantages of FOAM's virtual DOM, but rather than just assert the fact without proof, I wrote some benchmarks to demonstrate... that it is in fact no longer faster. As a result, we're replacing FOAM's UI library, called U2, with a new non-virtual DOM library called U3.

Correct, no single interface does what the UNIX pipe did for command-line text-based IO-stream processing programs. In FOAM, we have about 20 standard interfaces, which correspond to your different glue types. Things like DAO (Data Access Object), Model, View, Factory, Parser, Adapter, Authenticator, Outputter, Validator, ... and as long as everything that does a certain thing, implements the corresponding interface, then everything can be piped together. Again, see: https://www.youtube.com/watch?v=S4LbUv5FsGQ or the longer more complete version: https://www.youtube.com/watch?v=PsFLlgrzn2E

To continue your analogy, if 95% of your house were made of glue, and 85% of the cost of your house was to buy glue, then that would be some cause for concern. That is pretty close to the truth for software.

I'm not advocating a closed system. Just like UNIX doesn't lock you in to any hardware or CPU vendor. FOAM is open source and most of the functionality is provided by existing languages, libraries and databases.A universal adapter, not a universal provider. https://www.youtube.com/watch?v=PsFLlgrzn2E

Both the video from the article and the one I posted above are from this longer talk of mine: https://www.youtube.com/watch?v=PsFLlgrzn2E

I think this the most important problem in software development to be given the least amount of attention, or even awareness. Another new MVC framework, build tool, or even programming language, isn't going to solve this problem. First we need to acknowledge the problem.

https://www.youtube.com/watch?v=S4LbUv5FsGQ covers this topic. As I say in the video, no point solution (ie. some new API) can solve the problem, when the need to integrate (glue) between so many point solutions, is the problem.

Seems to be heavily influenced by the Smalltalk language and VM. I find it interesting that people will say that embedded microcontrollers are too resource constrained for this type of system, despite many being significantly more powerful than the original Xerox workstations that ran Smalltalk. And those machines were considered mini-computer-class machines at the time.

The article seems to claim that if we did as he says and rewrote all of our code to be data-oriented instead of object-oriented, then our code would run ~2X faster and all of our performance problems would be solved. However, I got my first 64 thread server CPU 15 years ago and my first 64 thread desktop CPU six years ago, so I could get a much larger increase by instead keeping my OO code and making it concurrent (64X > 2X). Also, if being 2X faster would make everything better, we could just wait 18 months and let Moore's law take care of the 2X savings, rather than the much longer period of time it would take to redesign our languages and rewrite all of our code.

This video shows the kind of things you can do if you embed the spreadsheet concept in a general purpose programming language (Javascript):

https://www.youtube.com/watch?v=-fbq-_H6Lf4

I'm known as a strong proponent for keeping code DRY (see: https://www.youtube.com/watch?v=S4LbUv5FsGQ), but even I sometimes advocate just copying and modifying code. Sometimes two simple pieces of code are less work/maintenance/mental-burden than one overly generalized/parameterized/complicated piece of code. As the number of copies grows, then the balance of the trade off shifts.

This video explains why UNIX was a moonshot, and why it could be developed by a small number of people because of it: https://www.youtube.com/watch?v=3Ea3pkTCYx4

When I worked at Google, we made a prototype of a non-grid spreadsheet-type thing. More graphical than tree-like, but the same underlying engine could be used for other purposes.

Videos:

1. The FLOW Shell: https://drive.google.com/file/d/0B6Qg3A0fSZHoNk5EX3ZkREEwbUk...

2. FLOW 2D Turtle Graphics: https://www.youtube.com/watch?v=4wO_RrftJTE

3. Background: https://www.youtube.com/watch?v=-fbq-_H6Lf4

I made a simulation and video which shows why the pipe is so powerful: https://www.youtube.com/watch?v=3Ea3pkTCYx4 I showed it to Doug McIlroy, and while he thought there was more to the story, he didn't disagree with it.

According to the link you provided, most white rices are in the high-glycemic category. According to the "International table of glycemic index and glycemic load"[1], Jasmine Rice has a Glycemic Index of 109, which is actually higher than even pure glucose, which has an index of 100. Milo, on the other hand, depending on where you buy it and what you mix it with, has a GI of between 36 and 55.

[1] http://ajcn.nutrition.org/content/76/1/5.full.pdf

The results are compatible with "risk homeostasis" or "risk compensation" theory. People who use unit tests have an increased sense of safety, so are more comfortable living with less-safe designs and code-bases.

"Risk compensation is a theory which suggests that people typically adjust their behavior in response to the perceived level of risk, becoming more careful where they sense greater risk and less careful if they feel more protected. Although usually small in comparison to the fundamental benefits of safety interventions, it may result in a lower net benefit than expected" -- https://en.wikipedia.org/wiki/Risk_compensation

http://injuryprevention.bmj.com/content/4/2/89

The 7-GUIs suite looks better, but so far only one JS framework implements it. The problem with more realistic benchmark apps (or suites) is that they require more effort to implement, so you have a selection bias towards easy-to-implement yet too-small-to-be-useful demonstrations like TodoMVC.

Something like a GmailMVC would be better.

https://github.com/eugenkiss/7guis/wiki