I really hope that is somehow Microsoft’s gameplan. Otherwise how on earth did they justify abandoning mobile phones. I mean some of their stuff was amazing (zune), and usually I am not a fan.
> Otherwise how on earth did they justify abandoning mobile phones.
No one was buying Windows Phones, and no one was making apps for Windows Phones, and this had gone on for many years, and not for lack of trying on Microsoft's part.
How could they not abandon mobile? What options were left to them?
Buy a bunch of third-party apps (like Sunrise and SwiftKey) and slowly but surely integrate them into your own products (like Bing and Outlook) to gather more data?
I'm entirely used to one of them (SwiftKey) and I've tried several others as well. They've all offered amazing user experience, but I'm just not comfortable using Microsoft's Launcher for example.
Which is what Microsoft is doing. So if we're considering this part of their mobile strategy (which is fair), Microsoft hasn't actually abandoned mobile at all.
I recently found out that you can’t easily spawn a shell and then send commands to it. It’s doable with tmux commands, but you’d think it would be easier. I just wanted to write something that locates npm/virtualenv stuff in bash, nothing fancy.
A distinction you may be having trouble with, because it's kind of hidden from the user, is the difference between a shell and a "pty" (pseudo teletype). You certainly can spawn a shell and send it commands, but because it doesn't have a pty the input is treated very differently.
That's what you get setup for you by running tmux, screen, expect, xterm, ssh etc.
"expect" was mentioned, but what are you actually trying to do that cannot be solved with a shell script, either executed the normal way or sourced in at the start of a new shell?
It even seems to work with named pipes, although in my first test it exited after the first command (I suspect I'm accidentally sending a EOF when I echo the command in).
mkfifo testpipe1
<testpipe1 bash # in separate window
echo ls > testpipe1
"Each dimension of the cube corresponds to a new way of making objects depend on other objects"
Is it normal to refer to data structures as objects? Just to my knowledge most typed languages abhor the awesome potential of object-oriented programming, like the CLOS.
In this context I think it refers to mathematical objects, since the dependencies can be between either values or types in either direction (values to values, types to types, types to values, values to types).
Also, lexical closures in a functional language are "classes" from the OO setting, so it is natural to implement classes if you want them; see e.g. OCaml. What you rarely see in the functional setting are common OO design patterns, because many of those patterns are unnecessary or awkward in functional languages.
I don't think you meant to imply this, but for anyone else - please note that the reverse can also be said - closures from an FP setting are objects from an OO setting, and it is natural to implement closures if you want them; see e.g. C++ "functors".
That is, objects and closures can both be implemented in terms of the other, if your language doesn't happen to offer both.
I think Scala does a good job of unifying OO and FP. And because of everything being first class, you get to eliminate all the ridiculeous design patterns and end up with a very nice FP system based upon objects and traits or typeclasses
Define a set of functions that close over their lexical environment, then treat the closed-over variables as internal/private state, and treat those functions as you would methods in OOP (reading/mutating the aforementioned variables).
Classes are a combination of member variables, methods, and method dispatch (which is important for inheritance). So let's emulate that combination with a closure in Lisp:
(defun constructor (x y)
(list (lambda (a) (+ x a)) (lambda (a) (* y a))))
This is essentially a "v-table" as you would have in C++. Inheritance would be exactly what you expect: replacing v-table methods in child class constructors. Lisp is untyped but if you wanted to do this in a typed language then a class type would just be the types of the methods that can be applied and what index in the v-table each method type has, similar to duck typing (except that the methods are "named" by v-table index). Note that members are private, and can only be accessed if the interface (v-table type) allows it, and that in a pure implementation you would have immutable objects so "setters" would have to recursively call the constructor.
It's type theory, so the `objects' in question are either systems of terms and/or types. See where it says:
terms allowed to depend on types, corresponding to polymorphism.
types depending on terms, corresponding to dependent types.
types depending on types, corresponding to type operators.
So I think they're using the word `objects' either loosely (as in, they could have said `things' but maybe that's too informal?) or they're using it as a shorthand for `type-theoretic objects', in which case they're talking about languages of a certain constrained expressive power: the language which features polymorphism, the language which features dependent types, the language which features type operator.
`object' here refers neither to the objects of object-oriented programming nor to object in common lisp object system.
I think this is the mathematical/logical distinction between "object level" and "meta level".
The meta level is about lambda terms, involving things like variable names, abstractions, judgements, derivations, equivalences, reductions, substitutions, etc.
The object level is what lambda terms are about, involving things like values, types, variable contents, etc.
The level of productivity we could have would enormous if we just focused on cutting out inessential tasks at the source instead of the periphery. I have been trying to promote the idea of neural ablation in company forever, but my boss just keeps moving me to darker parts of the building.
