lectrick
Born on August 13, 2010•1393 Karma
Also false dichotomy. We do not know the percentage of successful marriages with undiscovered affairs.
If your mate is with you for your money and you are with them for their youth and looks, then assuming you stay with them long enough that after a divorce much of their youth and good looks are gone, why shouldn't they get some of your money? You got their most valuable assets.
But that's not true. Under United States laws, all women will take half your money when they divorce you. Doesn't matter that they're gold diggers or not.
And also, most women marries up (marry a guy who makes more than her), not down.
This whining about women taking "your money" in a divorce is absurd. Get a prenup or marry someone with as much or more money. If you marry someone with less money (i.e. someone "marrying up") then you are knowingly "marrying down". Don't whine about fairness. This isn't a problem with the courts being "unfair" so much as a problem with people being petty.
Always a pleasant conversation to start... ;)
> or marry someone with as much or more money.
This strategy works around an artificial limitation imposed by the law which limits your dating pool quite a bit, and overly penalizes the successful. Of 20-odd women I've dated, exactly one made more money than me.
> This whining about women taking "your money" in a divorce is absurd
In medicine, when we evaluate treatments, we base it on statistical efficacy. In law, when we evaluate guilt, we base it on evidence. When determining safe traffic laws (such as requiring seatbelts, we look at accident statistics. But for some reason, in marriage, a high failure rate is always "someone else's problem with commitment". (Along the same lines, I suppose fatality rates from accidents where seat belts weren't used are "someone else's problem with driving"!) No one stops to think "ok so maybe marriage itself may be the problem that needs some tweaking", and evaluates marriage changes/expectations based on empirical efficacy (lasting marriages). In the meantime, women profit off the pains of sorry men in failed relationships. Why is that?
She doesn't have to be a gold digger to take half your money because the laws still applies regardless of her gold-digging status.
The proper way to handle this is to marry some who makes the same or more than you.
I make more than my wife. If we got divorced, her getting half the assets would not be the biggest problem.
This also hints at the "qualia" mystery...
Page 3, point 4:
"Sightings of unexplained objects at great altitudes and traveling at high speeds in the vicinity of major U.S. defense installations are of such nature that they are not attributable to natural phenomenon or known types of aerial vehicles."
Also note the National Security Council directive on the last page.
From a semantic persopective I've found that I almost automatically understand Erlang just from working with Elixir. Some things like OTP are pretty much identical. Plus you get "real" macros :)
Now I personally prefer Erlang's syntax. I like that it is different because I know semantically stuff behaves differently. I would be more confused and disturbed by it if it looked like Java for example. I also like the immutable variables aspect..
However at the end of the day I am very happy to see Elixir grow. It really has one of the friendliest and most welcoming community. It will hopefully bring more people to the BEAM VM ecosystem.
Elixir has the same immutable variables. I don't know why this is such a misconception. Erlang conflates rebinding and reassignment, Elixir does not, and the tradeoffs seem to (overall) be better in Elixir's case. Here, read the language creators' explanation as to why that is, it's the best:
http://blog.plataformatec.com.br/2016/01/comparing-elixir-an...
Very succinct and (hopefully) puts this misconception to bed.
Thanks for that useful comment, man.
I personally hope Elixir helps thrust Erlang into ever more success. (But not so much success that it becomes a victim of it...)
What is not beautiful is that:
- the people who conceived the original idea of the 'Actor model' were not appreciated enough, and their work had to languish in obscurity, during the OO (object-oriented) hype era, before it was rediscovered and later the dots were connected.
- 'reinvention of wheels' is bad because it's inefficient.
- Not to mention original OO idea by Alan Kay, in Smalltalk, was actually the 'Actor model' but it ended up being very misunderstood when implemented in C++, Java, etc, with the term OO being hijacked.
Yap here it is right from the horse's mouth, so to speak:
https://computinged.wordpress.com/2010/09/11/moti-asks-objec... (see comments history)
---
If you are doing “simulated data structure programming” rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). “Real OOP” is much more about “requests”, and the more the requests invoke goals the object knows how to accomplish, the better. “Abstract Data Types” is not OOP!
...
Many of Carl Hewitt’s Actors ideas which got sparked by the original Smalltalk were more in the spirit of OOP than the subsequent Smalltalks. Significant parts of Erlang are more like a real OOP language the the current Smalltalk, and certainly the C based languages that have been painted with “OOP paint”."
---
There you have it folks, Erlang is more OO than C++/Java and C#. It is kind of a funny tidbit, good for sharing during meetups over beers.
One interesting response to that I heard from a developer was "Well, it doesn't matter what Kay thinks anymore. C++/Java/C# got so popular and that is OO now officially".
This comes across as strongly worded, but I'm going to let it stand, given the understanding that the C++ and Java style of 'Object Oriented' has value in a lot of situations and circumstances. Though I have leaned very heavily on Kay's 'Actor Model' over the years, C++ style OOP has also been useful from time to time.
I've been pointing OO people to these thoughts by John Carmack, who is pretty well-respected in the C++ OO community: http://gamasutra.com/view/news/169296/Indepth_Functional_pro...
Re: "I'm so sorry, man." Thanks, but I'm not sorry at all. The (what I call) Message Oriented Programming first approach has allowed me to have a highly successful career.
Re: Carmack. There's quite a few such highly respected and respectable articles out there, but I gave up advocacy a long, long time ago. I just let what I'm doing, and not doing, do the talking, for better and worse.
I'm actually working at a startup now that I found very interesting, mostly because it's based on flow-based programming paradigms:
i was kind of curious about this statement, so i looked up the history of programming languages (http://cdn.oreillystatic.com/news/graphics/prog_lang_poster....).
if you take a look, it would seem to _suggest_ that smalltalk borrows from both simula-67 and lisp. wikipedia page for simula-67 suggest that it (simula-67) "introduced objects, classes, inheritance and subclasses, virtual procedures, coroutines and discrete event simulation, and features garbage collection..."
now it might be just possible that simula-67 was the first language to incorporate those features in a language, and that alan-kay originally came up with that idea, waaay before simula-67 came into being.
How it happened is well chronicled in the history paper I was asked to write by the ACM in 1992-3 "The Early History of Smalltalk" (i.e. why speculate when most high res answers are available online?). Ivan Sutherland's Sketchpad was the big first hit for me in 1966, and I saw the first Simula a week later.
Some of the confusion here is explained in the above link I wrote explaining that what is called "O-O" is nothing like I had in mind. The term was "colonized" because what we had been doing at Parc was powerful and we called it "object-oriented". But the "low-pass filter of O-O" was that Bjarne Strousrup decided to "do to C what had been done to Algol to make Simula". This was a perfectly reasonable idea. We were quite a bit more radical at Parc because we needed enormous amounts of expressability to invent personal computing (and we could and did design and build hardware that was matched to the radical ideas).
An interesting historical note is that the two inventors of Simula had completely different views of what they were doing and how it should be used for programming. Dahl was brilliant and conservative, and later wrote papers about using class definitions to make Abstract Data Types (and that is how a lot of so-called OOP programming is done today). Nygaard on the other hand was quite a wonderful wild man and visionary -- beyond brilliant -- and was into the abstract "simulate the meaningful structures" idea. Dahl was trying to fix the past and Nygaard was trying to invent the future.
During the 1978 HOPL conference time, we were visited at Parc at two different times, first by Dahl and Tony Hoare, to whom I showed and tried to explain Smalltalk: they didn't get it, and this was very frustrating. A few days later Nygaard showed up, and it was completely different: he got everything, and was finishing my sentences after 5 minutes!
Back to the origins in '66: besides the biological metaphors I had under my belt, I was also interested in the "virtual machines" ideas that were being used to do multi-processes and time-sharing in a safe way via hardware memory protection schemes (none of which I had had any involvement with inventing). One of the things that popped into my head while contemplating Sketchpad and Simula was that it would be just incredibly good -- and a huge improvement in systems designs -- to be able to use protected processes as the sole building blocks communicating only by messages that were not commands, but only "suggestions".
I think I'd call this not an invention, but a "realization" -- that the recursive machine idea was already around, and what it lacked was scalability downwards, so that all entities could be "protected virtual machines". A lot of what I now have to call "real OOP" turned out to be some years of software engineering in order to create a practical systems material that could scale in all directions.
Still seems like something worth being proud of. It just got sideswiped by the personal computer industry (a lot of things did).
These days it's hard to argue for correcting the features that people label as OO. It's part of history at this point. It is still interesting to note that there was a slightly different intention when Alan Kay coined the term though. Perhaps we need a new label. Kay-OO or something.