Hacker Newsnew | past | comments | ask | show | jobs | submit | youraverageuser's commentslogin

In the same manner that you're against the guys lumping the women into homogeneous group that abides by some rulebook (which it might), in the same manner you're grossly misunderstanding the motivation of the guys who have trouble finding a good relationship. There may be some crazy representatives, but normal people just want normal things.

At the end of the day, those people want to have an understanding of what is going on and reassuring that they are not a failure compared to their ancestors, but a "work-in-progress", especially when nobody actually encourages, pushes them on or provides guidance. Of course, one must still walk the journey, but you're not exactly helping.

I don't know where you are in life, but I hope you're in a good position, having achieved your goals. The problem is that you don't really want to understand the hardships that people are going through, even if you gone through them yourself at some point. I know I did become less empathetic to people until I got back into the same shoes.

Another problem is that no one really offers a good advice. "No more Mr.Nice guy" is a book that attempts to read too much into people's motivation and seems to see everyone as an entitled narcissist. The only good thing that came out of it is some small guidelines in which direction to move and some encouragement along the way. But I still hate the fact that it pushed me into becoming less kind and more cynical towards the others, something that I'm trying to fix in myself.

Anyhow, if the solution to the problem was easy, you'd expect that the world would have corrected itself. Maybe there is some underlying situation going on, that we are conveniently oblivious to?


No pun intended: this is called datatype, algebraic data types, ADT, etc. They are popular in many functional languages.

You can think of them as enumerators that can possibly hold extra data.

The first definition (data Exp) is indeed a grammar. Thus "Num", "Int", "If" are just the names we give to different cases we encounter in the grammar. As for what they are... you can think of them as functions that wrap some data inside a struct of the same name (function names and type names don't collide). As for the name, they are called data constructors.

As for what "data" means, we are defining a new type which can hold some data (again). You can think of it as a synonym for "enum". The reason word "data" used here is because there's something called type synonyms. For example one can write:

type Email = String

type Password = String

Here the underlying representation for both email and password is string, but compiler treats Email and Password as another name for string. But if you were to use data constructors:

data Email = Email String

data Password = Password String

We are creating entirely new types. Even though the internal representation is still string, if we were to supply password when an email is expected, we get a compile error.

Essentially a wrapper class can do the same. But using data constructors we get the same benefit + something called pattern matching + exhaustive error checks + cleaner syntax + additional low-level optimizations by compiler.


> The first definition (data Exp) is indeed a grammar

No, it isn't. It's an AST datatype. That definition does not at all cover the relationship between text and structure, as a grammar does.


Probably because it is very easy to mess up when using state incorrectly. It has been years since the last time my program run without bugs for the first time. If you're a genius, then sure, whatever tool you may be using, you'll do fine. But I noticed that many mainstream programming languages introduce concepts that are easy to misuse, even the same global variables. I recently wrote a small python script in 40-50, having concise and separate functions, etc. And I still was stuck on a bug that turned out be a consequence of shared state. The real issue was far from the location I was observing the bug. I think those kind of bugs is quite common.

What it boils down to in the end, is your priorities. If you want a program that works 90% of the time and you don't care about the last 10%, then sure, stating your way through is quite natural. If you're sick of the small bugs that is the consequence of the language semantics and not the logic or design, then you'll start nailing down the factors that contribute to the erroneous nature, with state being just one part of it.

Based on my experience in python and trying to teach other python developers some fp (spoiler, it didn't work)


Boldrin & Levine: Against Intellectual Monopoly.

The book opens up with a case of James Watt (after whom the Watt SI units are named), and that even though he came up with the steam engine, only after the patent for steam engine expired, was the world able to benefit from his invention. Most of the time while patent was active, he was busy fighting off others, trying to extract financial gain (AFAIK). Not only that, his initial design was subpar, and the improvement that was important was actually patented by somebody else.

I would like to finish the book someday though...


But if there was no patent, he'd have kept it under trade secret in perpetuity, and no one would have been able to make that improvement


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: