Nothing prevents code from accessing .paint in the case that type is CLICK. At all times, every possible field in event is visible to the programmer.
And that's the way it damn well should be. All this masturbatory academic bullshit for "safety", causing programmers to become even more idiotic and making their brains turn into mush.
What does that Benjamin Franklin quote say...?
Name:
Anonymous2017-02-02 12:04
>>2 Amnesiac programming. What if window was already checked for null before close_window got called? Then the check inside close_window would be superfluous, hurting performance with no need.
Name:
Anonymous2017-02-02 12:55
>>4 If you want performance, sum types take more memory and require more handling code than a NULL/Nil check. All this OOP polymorphism doesn't come for free.
Name:
Anonymous2017-02-02 13:06
>>5 They don't take any more memory than a tagged union in C, sometimes (in case of Option) even less as the None can be represented as simply a null pointer. They don't require any more handling code either, it's just better structured. What requires more handling code is your imperative amnesiac programming where you check everything for null a hundred times because the type system is too stupid to remember what is nullable and what isn't.
Oh and sum types don't have anything to do with OOP polymorphism unless you're trapped in Scala.
Name:
Anonymous2017-02-02 13:34
A minor point, perhaps, but Java’s Optional is not free. Due to Java lacking ‘value types’, essentially just stack allocation, you must allocate on the heap to wrap a type in Optional. And, due to that lack of value types, you can not wrap a primitive type in an Optional - so you’re again forced to make use of the heap when it may not be necessary. These are minor annoyances, but coming from lower level languages I definitely find it irksome to be forced to use the heap in places where the stack is obviously acceptable.
Our Rust OptionString type actually has the same overhead as a check for null. There is 0 memory overhead, 0 allocation performed. Because ‘null’ (0) is not a valid address for our String type, we can use that to represent the Absent variant under the hood.
Whenever I had to use the Option type I felt like I was wearing a chastity cage.
Name:
Anonymous2017-02-02 14:17
>>8 You'll get used to it. Sum types change the way you think just like feminism and Marxism. Soon you will be indignant at the null pointer macho programming patriarchy.
Its checked when its needed, and often function have special "default behavior" with null. If you afraid of NULL so much you can force get_focused_window to return Default_Window dummy object instead of NULL.
sum types don't have anything to do with OOP polymorphism
This is OOP polymorphism with syntax sugar, the case is the static method dispatch on overload of window - which is exactly the same as close_window(Window) C code. window <- get_focused_window case window of p Nothing -> return () Just w -> close_window w
you can force get_focused_window to return Default_Window dummy
More bloat.
This is OOP polymorphism with syntax sugar
No, this is category theory. Sum types are dual to product types.
Name:
Anonymous2017-02-02 14:37
>>10 to Clarify, C code equivalent side-by-side: window <- get_focused_window <---> Window* window=get_focused_window(); case window of p <---> void close_window(Window* window){ Nothing -> return () <---> if(NULL==window)return; Just w -> close_window w <-----> /*handle window*/ }
Name:
Anonymous2017-02-02 14:44
Sum types come from imperative programming and imperative languages. FP scammers are stillstealing from the goyim decades later.
Name:
Anonymous2017-02-02 14:54
0 is the billion dollar mistake Why use 0 when you can just use sum types?
Name:
Anonymous2017-02-02 15:05
>>14 Yeah, Imagine no more Division by Zero errors.
Does C++ implement category theory? case window of p Nothing -> return () <---> void close_window(nullptr){;} Just w -> close_window w <-----> void close_window(Window* window){ /*handle window*/ }
Name:
Anonymous2017-02-02 15:10
>>13,16 Imperative languages like C++(not including the modern ones here, of course) have no sum types, only product types, which is strange but easily explainable by the fact their creators didn't know jack shit about mathematics. The closest thing OOP has to sum types is Scala's case classes which are a hack to overcome JVM's limitations.
Of course imperative languages don't need that OOP garbage everywhere, as most cases can be answered by: https://en.wikipedia.org/wiki/Tagged_pointer And NULL pointer is simply replacement of tag with a special value 0, which is the Nothing of Datatype pointer.
Name:
Anonymous2017-02-02 18:07
>>18 What's that article supposed to prove? That Ada and Modula-2 have sum types? C, C++, Java, C#, Python etc still do not.
Unfortunately, C compilers do not verify that the null case is always handled, and this is a particularly prevalent source of errors in C code, since there is a tendency to ignore exceptional cases.
Hahaha C is shit.
>>19 You're totally clueless, aren't you? Don't even understand what the thread is about? Tagged pointer is an implementation detail only, and yes, genius, tagged pointers are actually used in languages with sum types to implement the T + 1 types like Option or Maybe, so they bring no performance overhead.
This usage of Option to create safe nullable pointers is so common that Rust does special optimizations to make the representation of Option<Box<T>> a single pointer. Optional pointers in Rust are stored as efficiently as any other pointer type.
🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳 DUBS FOR DA PEOPLE 🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳🇨🇳
Name:
Anonymous2017-02-02 20:33
>>21 This is crap, not a real sum type. I'll remember from now on that "tagged unions" are just codephrase for "we've got a bunch of tacked on crap joined with sushi sticks where our sum types should have been". a) no pattern matching b) no exhaustiveness checks c) ugly functions with asserts instead of the neat, structured, convenient pattern matching. d) no pattern matching - seriously, in the XXI century?
Pattern matching works with nested sum types and allows quick & intuitive bindings. In imperative crap you would have to build whole unreadable forests of ugly nested ifs and switches:
Pattern matching makes deconstruction of values syntactically and structurally intrinsically tied to their construction. To deconstruct something, you describe how it was constructed. Simultaneous addition of bindings where you want em (and _ where you don't care) just adds concision to beauty. Add to that the fact you can never forget to check the tag as in C, and sum types are the biggest win since sliced bread. Only vacuously skulled imperative simians couldn't understand that and cling to their ugly, prehistoric nested ifs and ``accessor'' functions.
A tagged union is just a union with a tag field, which is trivial in any language sufficiently powerful to have unions in the first place. And ``pattern matching" is FP turdware that real programmers don't need, anyway.
Name:
ser2017-02-02 21:22
setr
Name:
Anonymous2017-02-02 21:30
>>27 Enjoy your caveman sticks and spears, Chimps.
Name:
Anonymous2017-02-02 21:45
What's curious is that the languages with sum types totally allow accessor functions and even C-like tagged union. But no one uses them, it's considered bad style and so unidiomatic. I've yet to see someone who prefers not to use pattern matching when it's available.
Name:
Anonymous2017-02-02 21:51
https://github.com/solodon4/Mach7 (note that imperative code is always faster:C switch is in the lead, and computed goto will be even faster for many cases) If safety is needed, tagged unions in C are perfectly safe to use and don't require handling NULLs.
Name:
Anonymous2017-02-02 22:12
>>30 Thought experiment: implement sum types in C and describe their difference from C tagged unions. Pseudocode is allowed.
Name:
Anonymous2017-02-02 23:44
>>29 Hey, at least I know how my sticks and spears work. FP fags can't code their way out of a paper bag without a bloated compiler to hold their hand and protect them from having to touch pointers and memory addresses.
Name:
Anonymous2017-02-03 7:31
Hey, at least I know how to survive as a nomad herding horses in Inner Mongolia. Civilization fags can't eat their way out of starvation without a bloated agriculture industry and ``malls'' to hold their hand and protect them from having to clean up horse manure and wear rags made of horseskin.
>>32 The differences have been expounded in lots of places, including this thread. Basically, a sum type is a tagged union where
a) you cannot get the payload without checking tag; the type of payload is guaranteed to be what was declared for that particular tag;
b) the compiler can check that everywhere you inspect the payload of such a tagged union, you include code branches for every possible value of the tag; this is called exhaustiveness checks;
c) with sum types, you get pattern matching which is like Common Lisp's DESTRUCTURING-BIND on steroids: handles nested types, creates bindings concisely, handles conditions on payload (for example, Some(5) may be a separate branch than Some(x), with the second one handling all values of payload x except 5), makes deconstruction of values correspond syntactically and structurally to their construction.
window <- get_focused_window <---> Window* window=get_focused_window(); case window of p <---> void close_window(Window* window){ Nothing -> return () <---> if(NULL==window)return;/* exhaustive enough as there are no other type*/ "advanced pattern matching"<---> if(5==window.type){Some(window);return;} Just w -> close_window w <-----> /*handle window*/ }
Name:
Anonymous2017-02-03 11:49
>>35 You got conned again. ML ``sum types'' were inl and inr. Pattern matching isn't from functional programming. ``[Y]ou cannot get the payload without checking tag'' is a normal property of a tagged union.
If you want to really unravel the scam, union is a set-theoretic union and tagged union means a union with a label. Neither of those have anything to do with C ``unions'' or ML ``sums''.
Name:
Anonymous2017-02-03 12:47
the first thing I do when picking up a new language is implement an Option/Maybe type if one doesn't already exist
Name:
Anonymous2017-02-03 20:53
>>31 OK I've read the slides. The switch on integers is faster because it's compared to Sepples reflection capabilities which is kind of a no-brainer. As for comparison with Haskell and OCaml, it's a hand-waving graph with a hand-waving note. There is no comparison of real pattern matchibg (eg. in Haskell) and imperative destructuring.
>>37 Sun types are the dual of product types, whoever said anything about ML? And maybe pattern matching isn't an FP thing, I don't know, but that's where it took root. And yes, C allows inspecting the payload of a tagged union without checking the tag - the result is undefined behaviour or some such crap.
And yes, C allows inspecting the payload of a tagged union without checking the tag
C doesn't have tagged unions or set-theoretic unions. They're a ``design pattern'', not a language feature.
the result is undefined behaviour or some such crap.
Why would you expect a compiler to check and understand design patterns? You might as well complain that the compiler doesn't understand your comments.
Name:
Anonymous2017-02-04 1:35
A minor point, perhaps, but Java’s Optional is not free. Due to Java lacking ‘value types’, essentially just stack allocation, you must allocate on the heap to wrap a type in Optional. And, due to that lack of value types, you can not wrap a primitive type in an Optional - so you’re again forced to make use of the heap when it may not be necessary. These are minor annoyances, but coming from lower level languages I definitely find it irksome to be forced to use the heap in places where the stack is obviously acceptable.
Rumor has it that Java will be getting some form of value types. All it took was them being shown up by C++, then C#, then Go, then Swift. Give them another 20 years and it will basically be an enterprise version of Haskell.
How come modern mathematics is so much like a cult? In universities you're forced to recite the correct incantations, which in most cases are just a layer of bullshit on top of the base ideas, for full credit.
Cult of the infinite set. Very focused on repackaging old ideas in a more abstract and harder to understand way.
Name:
Anonymous2017-02-04 13:32
more like lulpointers amiright
Name:
Anonymous2017-02-04 17:36
>>47 I (>>42) was wrong. Yes, unboxed types in Haskell are value types.
Name:
Anonymous2017-02-04 18:58
>>51 No! Javascript will rule them all! You'll see!
>>60 Your Javascript engine sucks because it doesn't support TCO or a decently sized stack. The Ackermann function is defined recursively, but it isn't primitive recursive, so you can't easily convert it into an iterative solution.
Name:
Anonymous2017-02-05 7:18
>>63 It probably doesn't support arbitrarily large integers out of the box either
They get a bit silly defining integer addition as recursive, then using a + symbol in their definition And it doesn't really work for non-integers (there's no smallest positive non-integer)