juan_gandhi: (VP)
on one page

1. Idea

The theory of objects is the logical theory whose models in a category 𝒞 are precisely the objects of 𝒞.

2. Definition

The theory of objects 𝕆 is the theory with no axioms over the signature with a single type and no primitive symbols except equality.


===================

The classifying topos 𝒮[𝕆] for the theory of objects 𝕆, or the object classifier, as it is also called, is the presheaf topos [FinSet,Set] on the opposite category of FinSet.

What motivates the terminology, is that for any topos E, geometric morphisms E→𝒮[𝕆] correspond to objects of E.
juan_gandhi: (VP)
So, I just bumped into this problem being mentioned. "For performance", bounds are not being checked by c programmers, who mostly don't care about any cases except the ones they like.

But well, what's the point in these checkings?

I know three cases.

1. We know during compile time the size of the vector we need, and we should not accept the smaller ones; we should rather not accept the larger ones, but mostly we don't care. This is the case for tuples. It's not an array. If someone wants to pass into the code an array pretending to be a tuple, this fact should be checked at the border. Ok, yes, there are no tuples in C or C++. Well, bad luck, and say hi to the three morons interesting people that provided you with such a language.

2. We don't specify the size, but we have some constraints, like the height of one matrix should be equal to the width of another; or maybe that a vector must contain not less than so many members. Ok, why not have it all in a specialized class? Once the class is instantiated (optionally, with all the checks), there's no way the sizes will change, right? So we don't have to check the bounds.

3. A loose collection of ancient libraries with loose, frequently unknown, requirements. I guess these libraries should be wrapped and hidden from the eyes of a modern human. It's like a slaughterhouse, hardly any modern city dweller wants to see what's going on there.
juan_gandhi: (VP)
...is that nobody cares whether subtyping is monomorphic.

I mean, if we only say that A is a subtype of B when we have a canonical inclusion A ↣ B, may things would make more sense.

But for some reason, any canonical function A → B is accepted as a subtyping relationship, and I wonder why. Or rather not, I don't. Liskov etc. Projections.
juan_gandhi: (VP)
Every time you write
val myName = props.get("Name") orElse ""
you are introducing an algebra over Option monad.
Even if you have no clue what an algebra or a monad is.

Same goes for catching exceptions and returning a "default value". Now you have a category of algebras over the exception monad.

This category is called Eilenberg-Moore category for the monad. There's a couple of adjunctions of course.

Kleisli also provides a couple of adjunctions.

All possible adjunctions make a category, where Kleisli is an initial object and Eilenberg-Moore is a terminal object.

Nlab says that Kleisli can actually be embedded into Eilenberg-Moore.

Meaning, guys, you don't need to invent "default values"; just use Option[T]. Whatever. Probably hard to explain to people that are thinking in terms of saving computer memory on string instantiation.

apple swift

Jun. 2nd, 2014 04:22 pm
juan_gandhi: (VP)
So, with the new "Apple language", object-oriented Java people are going to do what?
There must be some deep philosophy, explaining why they are so retarded.
I think.

I mean, I kind of heard an explanation from Josh; in my translation it sounds like this: "Java programmers are not very smart anyway, let's not overload them with closures and all that stuff."

The correlation I was writing about lately kind of shows itself again.
Weird.

Well, it's not Scala, of course; but it's a nice step in the right direction, I think.
juan_gandhi: (VP)
here

I'd say it's more of oop bashing.
juan_gandhi: (Default)
Subclassing errors, OPP, and practically checkable rules to prevent them

P.S. I believe the problem is that with stateful objects, we do not know exactly which category are we dealing with; roughly speaking, for class A subclassing class B, there are actually two monads, with a natural transformation from one to another; and we think we have a functor from, not sure yet, one Kleisli category to another, or from one Eilenberg-Moore category to another, or even an interesting relationship between two categories of adjoints generated by the monads.

Have to look closer; maybe this explains the problem with "Liskov substitution".
juan_gandhi: (Default)
It's a known puzzle from the depths of object-oriented teaching: is Circle a subclass or Ellipse. From school we know it is; but as we read in books, for programmers, it is not. How come? Oh, "Liskov principle". They use Liskov principle to scare kids.

Actually we know that a circle is an ellipse with both axes being the same length.

But in programming, an ellipse is something different. It is at least stretchable. And it is also moveable. Somehow it is not rotatable, but we can skip it for simplicity.

An ellipse in programming is (almost) always horizontal; it can be moved (by changing coordinates of its center) and it can be stretched/compressed by changing its height and width. Sure a stretchable ellipse is neither an ellipse nor a circle, not even a stretchable circle. A stretchable circle stretches equally in all directions.

That's it, no? Questions? Objections?

Profile

juan_gandhi: (Default)
juan_gandhi

June 2017

S M T W T F S
     1 2 3
4 5 67 8 9 10
11 12 13 14 15 16 17
18 19 20 21 222324
252627282930 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 22nd, 2017 06:20 pm
Powered by Dreamwidth Studios