I feel this is the single most important causative factor for language popularity.
Javascript may have much more bad parts to the language than say Haskell but it's far easier for a programmer to learn all the bad parts of javascript and avoid those bad parts then for him to learn all the good parts of haskell and use those good parts.
I think the migration out of the bay will make it a more reasonable place to live. We do have some of the best weather in the world. I'm going to gamble on staying.
> We do have some of the best weather in the world.
Certainly some of the sunniest in the English-speaking world. Personally (as an ex-Londoner), I overheat a lot and actually miss a good rainstorm from time-to-time - but your evaluation does line up with most people's, I think.
Let's just gloss over the increasingly-common smoke from wildfires... :)
>Let's just gloss over the increasingly-common smoke from wildfires... :)
Yeah that part is bad. Not sure how to rate CA in general when you account for this as the wild fires only started getting crazy recently. For most of my life overall the fires weren't a problem.
>Certainly some of the sunniest in the English-speaking world. Personally (as an ex-Londoner), I overheat a lot and actually miss a good rainstorm from time-to-time - but your evaluation does line up with most people's, I think.
Scientifically it is actually rated as some of the best in terms of closest to something like room temperature throughout the year. It's a climate zone called the mediterranean climate zone. It exists in a few places in the world.
I think it's unlikely to turn out like Detroit, and I say that as someone who wants to leave the region.
The region will continue to have many of its best qualities: good weather, (relatively) diverse culture, access to nature, and good employment prospects. The biggest issue with the region is the high cost of living, but any relief in housing costs will only make the area more appealing again. There's a high floor.
San Diego is right in the range that you are describing. Average highs in August are ~75. I'm biased though since I lived in San Diego for a couple of years and have never lived in or near San Francisco. Inland is much hotter in San Diego though.
We're talking about the same SF from this summer where the heat waves were just as bad as SoCal? California climate change now means you're going to get heat waves pretty much everywhere.
I'm inclined to agree, if you can be near enough to the ocean to tame the summer heat.
SFBA winters are kinda miserable IMHO. It's not rust belt snow bad, but consistently cold and wet for months isn't exactly ideal.
And SF-proper regularly being fogged in renders too many nights useless WRT enjoying the outdoors, year-round. It's almost pointless to have something like a rooftop deck or outdoor patio. It'll all corrode and rot before you get sufficient use of it.
San Mateo manages to escape most of the negative fog effects though, I enjoyed living on the hill by 92 and Hillsdale Blvd. We'd regularly watch the apocalyptic fog stall @ Skyline while enjoying dinner outside on our deck.
For the south bay it's not 3 months of the year, 100F lasts for like 2-3 weeks at most (actually realistically it's more like 95-100). It's the same for socal. Socal has about 2-3 weeks in the summer where the temps become sweltering.
Even within LA the temperatures vary, the closer you are to the coastline the better the weather.
I know because I grew up in the south bay, I lived in SF for 2 years and lived in LA for 10 years.
What's overall better in socal is that the winters are much more mild. In the south bay the worst you can get is ice in the morning and really cold nights. Socal winters just has a very slightly lower temperature than spring.
Not trying to say NorCal has better weather than Socal. I'm saying NorCal has some of the best weather in the world despite it not having the "perfect" weather that Socal has. The entire CA coast line is afterall still in the mediterranean climate zone.
Not all aspects of programming can be described by math.
Mutations and IO are very critical parts of programming and the two areas where FP breaks down. Even the IO Monad leaks the imperative nature of the program over to the programmer.
The only way pure FP can sort of work is if there are heavy frameworks abstracting IO and mutation away from the programmer. If you're not doing IO or mutating something then your caching framework, database or Haskell runtime is doing it for you. Additionally like I said earlier, Even if your database is handling mutation for you, you still end up embedding mutation commands into the strings of your pure FP function. Updating a database in haskell still necitates the haskell user to place the mutation command in a SQL string.
My point is, that math is not the complete solution to the programming problem. What FP allows the programmer to do is to use the framework to segregate combinatorial logic away from mutation and IO. Your combinators will always be more composeable and modular but your IO and mutation functions will be less modular but they still have to exist.
>Not all aspects of programming can be described by math.
This is completely untrue. You may not be familiar with the math, but that doesn't mean it doesn't exist. If you can model something well enough to understand it, then you can model it mathematically. There really isn't any domain of knowledge that math is unsuitable for, excepting if you don't know any relevant math to do.
Technically everything in the universe can be modelled by math. If it isn't modelled yet we can make something up to model it. Math is just axioms and theorems so yeah, you're not wrong.
I'm speaking in less technical terms. For example in general mathematical equations or axioms represent immutable concepts. In programming, variables mutate and change... very different from what math traditionally represents. Haskell is an attempt to segregate the immutability (the math part) away from the less "mathy" part (the mutations/IO).
Maybe math is too broad of a term. I probably meant to say "algebra" can't model all of programming, or whatever more suitable word that may or may not exist.
Mathematicians have no trouble modeling change. There are many ways to do so. Some are algebraic, some are not. There is nothing wrong with modelling mutability using immutable structures: that is how you probably think about history, after all.
Either way, it is unclear what you're actually trying to say. Haskell has methods for modelling change of state through pure objects, but you're talking about that as though it were an inherently flawed or invalid approach, rather than one of many equally valid approaches to modelling state transformations.
>but you're talking about that as though it were an inherently flawed or invalid approach,
This is just your bias. I never said this. I feel some people worship a paradigm so much that they see everything as an attack. FP is great however it is not a one size fits all solution. There are limitations. This is literally what I said.
>Mathematicians have no trouble modeling change. There are many ways to do so. Some are algebraic, some are not. There is nothing wrong with modelling mutability using immutable structures: that is how you probably think about history, after all.
You can model change with purity but the program in the end actually has to conduct the change without the modelling. The application has to eventually perform real world actions and the purity of your program cannot protect you from potentials pitfalls of imperative style errors/mistakes.
You have a database. The purity of haskell does not remove the necessity of mutating data in that database.
What you can do is segregate dealing with mutation/IO to a framework or external service. This is what haskell does, but you see this is just shifting the problem to somewhere else. Someone somewhere still had to deal with the issue of mutation. Modelling mutation with purity does not eliminate the problem it only moves the problem to another location.
Segregation of mutation/IO into a framework is a good thing. It makes it so that the problem can be solved one time, rather then a problem solved many times. However the main point of my post is to say that "math" or "algebra" is not a one size fits all solution. You cannot model everything this way, moving the problem into a framework does not make the problem disappear. Someone still had to use imperative primitives to deal with the issue. Think about the complexity of a SQL database.
You said FP "breaks down" when handling mutability, and you attributed that to some vague sense in which "mathematics" is the cause of it.
I have no bias for FP. I just don't understand what you're getting at.
>the purity of haskell does not remove the necessity of mutating data in that database.
That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context.
>Modelling mutation with purity does not eliminate the problem it only moves the problem to another location.
Location? What is a location? It's like you're saying you can't truly add 3 + 3, because someone still has to add 1s under the hood. It's just a different model of the same problem.
Honestly, it sounds to me like you've never used the language, and your criticisms come off a bit like standing on an aircraft carrier shouting about how iron boats will never float.
>That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context.
Haskell does inhibit mutability within your haskell program. Your haskell program does not mutate. What it does is it that it does IO operations and the mutations happen externally. It can also model mutation without doing actual mutation but in the end there's no point in a program modelling mutation if the program can't actually do mutation or IO.
>Location? What is a location? It's like you're saying you can't truly add 3 + 3, because someone still has to add 1s under the hood. It's just a different model of the same problem.
Location meaning outside of haskell. Like your database. I'm saying within haskell you have a variable.
x = 3
You can never mutate that variable in haskell. However you can mutate the state of the console without ever mutating any state within haskell.
print "hello"
The above triggers no mutation in haskell. A runtime outside of the haskell universe analyzes the IO instructions and mutates the console. What I am saying is that the thing that mutates the console has to do mutation. Whoever wrote that thing HAS to write imperative primitives. They are moving the imperative nature of programming INTO a framework. They are not eliminating the problem.
This is the same thing as a database string. UPDATE. You are moving all the imperative errors that have to deal with threading and mutations to the database. But your haskell sql string is still pure.
Again my argument is just saying that this thing that is doing the UPDATE or mutating the console cannot be built using haskell style code or immutable algebraic concepts. Imperative primitives need to exist and someone needs to use those primitives to do the actual mutations.
The OP is basically saying algebra is the future and it can replace everything. I'm saying it CAN'T.
>Honestly, it sounds to me like you've never used the language, and your criticisms come off a bit like standing on an aircraft carrier shouting about how iron boats will never float.
And honestly you sound like the guy standing on the iron boat. The person I'm shouting at is you, but you're just dismissing me.
>You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.
Why the heck would I run such a long expose and troll you and be mistaken at the same time.
>How does this Haskell program write to stdout if it doesn't mutate memory?
Let's not be stupid here. Every program on the face of the earth must mutate memory because that's how computers work. Assembly instructions mutate things. We're not even talking about that. We're talking about application level programming where we only deal with primitives that the application programmer is aware about. I am saying that at the application level within the category of Hask nothing is mutated.
In your example tell me what haskell primitive.... What variable or data was mutated within haskell? That is what I'm referring to.
Try to implement IO or ST in another lang using only purely functional primitives. Use your algebra to make it work. You'll find it's impossible. What this means is that imperative primitives must exist for any programming to work.
>Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur.
Obviously I'm operating on a certain layer of abstraction here. In X = 6, X is obviously immutable in haskell. A runtime is obviously executing your haskell program and mutating the console but your haskell code itself is pure. But you know this. It's quite obvious you're the one that's trolling.
>What variable or data was mutated within haskell?
The stdout buffer.
Just because mutation isn't explicit doesn't mean it isn't there. Programming languages are not syntax devoid of meaning: they have semantics. What happens at runtime is part of what a programming language does. (Arguably, that is the most important part of what they do.)
>What this means is that imperative primitives must exist for any programming to work.
That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa. Again, they're just different models. No language can do anything if it isn't implemented in a machine. A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction. You absolutely could implement a pure functional assembly language. The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].
Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.
> Use your algebra to make it work. You'll find it's impossible.
Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.
The stdout buffer is not part of the haskell language, it is part of the OS. The haskell runtime reads the haskell language and accesses the buffer. Neither the runtime or the buffer is part of the haskell language, get it? That's why haskell is called "pure" Category Hask: https://wiki.haskell.org/Hask#:~:text=Hask%20is%20the%20cate....
>Just because mutation isn't explicit doesn't mean it isn't there.
So? I never said it wasn't there. I'm basically saying as far as the programmer is concerned when operating within the haskell language no haskell language primitive is mutating. stdout buffer is not a haskell primitive... it is an OS primitive.
>That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa.
This is true theoretically, but physically but you can't actually build a functional machine. Lisp isn't actually a functional language and you'll see from the instruction primitives that the lisp machine is more or less a turing machine that mutates memory.
>No language can do anything if it isn't implemented in a machine.
So? Never said this wasn't true.
>A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction.
The machine you build is limited by what you build it with. You have a limited set of atoms. Therefore you can only build a machine with limited amount of state. In order to use the state efficiently the state must be mutable. Mutable state means imperative instructions. You can imitate functional programming with such a machine and you can sort of solve the memory problem with garbage collection. But with what paradigm do you implement the garbage collector? Imperative primitives.
> The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].
No the real reason is also because it's physically impossible. A physical translation of a actual lambda machine cannot be realized. What they can make is register based machine that are more efficient at compiling certain functional languages that's it. All machines we build have some sort of state that changes.
>Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.
Sure I can prove what I said. But you're changing the problem from IO and ST to a computable function which I assume is algebraic. So of course all of algebra can be used to create all algebraic functions. I'll just prove what I said rather than what you changed it to.
Assuming mutation is an axiomatic operation that cannot be built from immutable operations, you will see that no mutation operation exists in algebra indicating that mutation cannot ever exist in any theorem of algebra:
You will see that no algebraic operation involving mutation exists in the above document.
>Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.
No but I can implement volatile with imperative primitives from other languages. All I am saying is you cannot implement ST and IO with functional primitives.
Personal attacks are against site rules on HN. You are clearly across the line here. Moderators ban people for repeated violations, so if you want to continue here, you should stop posting abuse.
You can do better, then. Read nendroids latest reply to me, and help them understand that it's the "use of statements" that makes a language imperative, not the "modification of state."
I won't be responding, and they seem to think they're quite the expert in this sort of thing.
"In computer science, imperative programming is a programming paradigm that uses statements that change a program's state."
The above quote is ripped straight out of wikipedia's definition of imperative programming showing that what I said wasn't a misunderstanding but an official definition.
The definition of imperative programming must include mutation otherwise it's isomorphic to functional programming. Because functional programming is simply statements without mutation.
Case in point, This guy turned what was just fact checking into something personal. See, it's not about being civil. That's just the way people like to think they are. The reality is most people can't accept being wrong and they can't accept opinions they disagree with and the irony is everyone believes they're above this base behavior.
"In computer science, imperative programming is a programming paradigm that uses statements that change a program's state."
You will see from the quotation above. The very act of changing state is an imperative style by definition. The purpose of mutable state is for it to change. So mutable state = imperative instructions.
>You don't have to listen to me, but you should seek out a second opinion from a competent person who can get through to you.
I'll throw that advice back at you. But you don't need to find that person. I'm right here in front of you telling you how it is.
>Everything I said in my last post is basic, well-understood computing knowledge. If you want me to disagree with it, you need to find yourself a competent computer scientist to aid you in framing your ideas in a way that is comprehensible with respect to the subject matter.
Yeah but you didn't account for the practical parts of computing. The theoretical parts often deal with machines that can't be realized in reality. It's pretty much common sense. How do you represent a function call without mutable state? How can you have a machine do an algebraic operation without mutable state? The very act of holding that information in state requires a state change meaning to even load a lambda machine with a program requires an imperative instruction.
We're also in a corner of computer science that isn't formally well defined. A language can be formally defined as pure but there's no formal theory for systems design and how the system overall influences the content of a pure SQL string in Haskell.
I define a haskell sql string to have syntactically correct SQL. The external requirements of my database are forcing me to define a string this way, is that a side effect? There's no formal rules in literature so it's just raw talking points... you won't be able to find an official source stating who's right or who's wrong.
The interpretation of the io monad? That's another story.
Once you realize that mutation itself is a side effect then why not use the single most powerful idiom we have for abstraction over side effects? (Monads with do notation; for blocks in f#)
For the record io is st with an opaque realworld type. And st is fully pure with a neat type trick to prevent leaking of st references.
I never said it's not pure. Just like how a SQL string in haskell is fully pure. Doesn't change the fact that you're using pure primitives to control a process that is fundamentally unpure. The concept leaks across the boundary.
It does. You're completely and utterly wrong. You don't understand.
I'll reiterate my example a SQL string is pure. Just like the IO monad is pure. However when you're coding the sql string in your "pure" haskell program you have to account for imperative side effects related to the SQL itself.
sqlString = "UPDATE X SET X.Y=2 WHERE X.Z = 1"
sqlString is technically "pure" but that doesn't mean you can treat the UPDATE command in the string as a pure concept.
It doesn't matter how "pure" your language or sqlString is... the concept of a mutation leaks over into the language and the programmer still has to deal with the concept.
Like you're original post said. The interpretation of the monad is different, and the programmer still needs to account for this in how he composes things together. The concept leaks across boundaries.
edit>>this whole karma thing is unfair. Posters can't vote down responses. I simply state my opinion the person responds then votes me down because he disagrees. What's the point of even having a discussion?
This is a philosophical distinction, not an objective fact.
I do not consider sqlString to be impure. It’s a perfectly valid string. I consider `executeQuery sqlString :: IO Result` to be an indication of impurity, since I can do `let x = executeQuery sqlString in “bar”` as a valid bit of Haskell but it’s clearly 100% pure.
If you want to think that sqlString is “impure” outside of the context of execution (i.o.w. a Monad...) then sure, that’s valid, but so is my assertion that it is pure since it is referentially transparent. It exists in the void as just another string until the programmer decides to make it into an IO value that’s executed for its impure side effects (the only reason we do anything in computing, right?)
I think you’re getting downvoted (I can’t) because of your first statement.
>I think you’re getting downvoted (I can’t) because of your first statement.
nobody is reading this stuff anymore. It's just you and me. You have over 800 karma. You CAN downvote and you ARE. There is no theatrics, you're just voting me down, stop.
>I do not consider sqlString to be impure.
It's not "impure." But it doesn't change the fact the way you you write your SQL has imperative side effects within the database. You can trigger a deadlock in the database from within your pure haskell code if you wanted to.
It's not a philosophical thing. You absolutely have to consider imperative side effects even in your pure program.
That is reality. The philosophical part is whether you can call it "pure" or "impure."
>If you want to think that sqlString is “impure” outside of the context of execution (i.o.w. a Monad...) then sure, that’s valid, but so is my assertion that it is pure since it is referentially transparent. It exists in the void as just another string until the programmer decides to make it into an IO value that’s executed for its impure side effects (the only reason we do anything in computing, right?)
Yeah so? I never said your assertion was wrong. I never said that it was "impure." But I did say that you have to account for side effects in your program. Example:
Is a valid "pure" string, but will trigger a syntax error in your database. You have to account for all of this within your "pure" program. Haskell eliminates side effects in the category Hask but does not actually eliminate the need for YOU to deal with those side effects. This part is an objective fact.
Here's a better way to put it. For this specific example, the impurity of the real world leaks into your pure haskell program by affecting the contents of the string. The type itself can be seperate from the real world but the contents of the string reflects knowledge and impurity from the real world.
I have over 14,000 karma. I can't downvote (direct) replies to my posts. So as far as HN mechanics go, you are falsely accusing nimish.
Other people - not nimish - are downvoting you. And they're doing so because you're starting to cross the line from "disagreeing" to "aggressive and rude".
Now for what it's worth, I'm kind of on your side of the actual dispute. I just think you're pushing the line in trying to be more, um, "expressive".
No it's not that. Even in posts where I just state logical reasons for disagreement I get voted down in this thread.
People vote down what they disagree with, if they agreed with me, most peoples' biases would usually find my attitude appropriate.
If I said something like logically I feel a certain race is inferior genetically. People will vote that statement down purely out of disagreement and misinterpret it as an emotionally charged statement and illogical.
It's just a statement with no logic behind it. It's dead pan with nothing. You can't even find erroneous logic with it because the logic wasn't even spelled out. You can only technically disagree with the statement. But people will subconsciously add all sorts of embellishment.
That's how people work. Maybe Nimish didn't vote me down, but they certainly aren't voting me down because I'm crossing some sort of line. They're voting me down because they disagree. That's the majority of it.
You'll find that more than anything the majority of what I write are just dead pan responses with like 5% of the sentences being "expressive." In fact a great number of stuff that I write that gets voted down is just dead pan responses with zero "expressiveness."
It's because people can't tell the difference between someone disagreeing with them and an actual attack. That's human nature. We all think we're above it, but basically none of us are. You'll find that even you are like this.
The reason why I get voted down is because my opinions tend to be different than most people. So people interpret this disagreement as an attack.
I've been here for over 10. I've had accounts with lots of karma generated by simply agreeing with everything I read or just commenting with useless side suggestions. T
I've experimented a lot. Without changing tone just disagreeing with a popular opinion is all that you need to get voted down. I've even experimented with emotionally charged impolite popular opinions. People will vote you up just because they agree.
If I wanted a shitload of karma. I know how to get it. Removing one or two of the more "expressive" sentences above will in my experience not do much for a thread that is very very biasedly supporting FP. FP is great, I prefer it but most people cannot maintain such neutrality for their favorite paradigm. Or favorite anything for that matter.
Not to mention if you recall a while back someone posted a GPT-3 AI generated story that got voted to the front page. Most commenters didn't realize it was AI generated. A select few were able to figure it out and they posted comments that were vehemently voted down for not being in agreement with the general sentiment. HN is a technical crowd but they are not above common mob behavior.
Scroll down to the picture. The person stated facts but his facts were misinterpreted to be attacks and he was told to be civil by someone who thought of himself as level headed. The reality is that the levelheaded person is as biased as one can get.
You think you're helping me. You think I'm putting up stubborn resistance to your help. Is that the case or am I just simply describing to you some of the insight I've gotten from messing around with HN for over a decade? Did I in fact put up stubborn resistance or am I just conversing with you and stating a disagreement? Hard to say.
Your immediate assumptions are no different than the "levelheaded" dude from earlier. Let's just be clear, I'm fully aware of the "expressive" areas in my posts.
You will also note that many of the posters assumed I'm attacking FP and that I don't have much experience with FP. All wrong assumptions. I have lots of experience and I prefer FP over other paradigms. I am simply stating that I disagree with the fact that algebra is the future of programming and can replace all imperative programming.
You've been here for over 10 years, under various accounts, but you don't know that people can't downvote direct replies? Not quite sure I believe that.
I disagree with the higher order functions thing. Writing functions that receive other functions as input can lead to over complicated code that's really hard to read. It's literally the same thing as dependency injection just with functions instead of objects.
Use sparingly. I would avoid altogether except for common ones like map, reduce and filter.
Functional programming promotes the idea of composition of morphisms and point free programming. I would use this in place of Object composition/dependency injection/higher order functions or whatever you want to call it.
If I have a "known" function, map() for instance, and I pass a function into it, that's fine, because I already know what map() does. But if I have a function foo() that takes another function bar(), and I don't know what either one does, then I have to look at both foo() and bar() to understand what is going on. I have to look at two places, not just one.
But this is not unique to FP. If I'm using OOP, I can do the same thing with virtual functions. In UI frameworks I can do the same thing with callbacks.
So you like writing functions that take 3 functions as input parameters and returns a new function that also takes a function as an input parameter and returns another function? In general excessive use of this at great depth leads to code that is not only less readable but less modular.
The complexity of higher order functions can easily be reasoned about by looking at the cardinality of the type. Sum types and product types are standard and easy to reason about.
However an exponential type that takes in an exponential type and returns another exponential type leads to cardinalities and possibilities that are much harder to reason about.
Composition of combinators is a pattern promoted by point free programming that leads not only to higher readability but greater modularity due to the reduced cardinality. Additionally cardinality of the entire type can he reduced to only analyzing the the final result of the composition.
F = A . B . C
The cardinality of F is all that needs to be known. The cardinality of the individual components can be ignored and you don't have to reason about this. This is not the case for higher order functions.
In general business problems that we deal with do not Require higher order functions. Higher order functions share isomorphisms with two concepts we are already familiar with: frameworks and metaprogramming.
Frameworks are programs that call your code and metaprogramming is code that writes and calls code. These things are no different then a function that takes another function in as a parameter and calls it. All three concepts are aspects of the same thing.
Therefore all the downsides of metaprogramming and all the downsides of frameworks are applicable to higher order functions.
Most of the programming problems we solve in the real world do not require metaprogramming. It can easily be avoided and solved with much more composition of combinators. Again, not saying to avoid the usage completely but the usage of higher order functions like metaprogramming should be minimal and used sparingly.
> In general business problems that we deal with do not Require higher order functions.
I cannot agree here, being currently involved in modeling and simulation work that would heavily benefit from more advanced type systems. A user would usually prefer to interact with a system with basic elements, but the interactions of the underlying domain concepts really do want to be captured with a richer set of tools.
And, to head off the "in general", there is a long tail of unique problem domains. Each individually doesn't get as much press as, say, a CRUD app, but that doesn't mean that simpler problem domains are necessarily in the majority.
I agree to some extent. When I see this in imperative code-bases, it can be used as a way to reduce lines of code and save having to define a new class. But when debugging or trying to make sense of the code it can be awful. However it's not the passing functions to functions that is the problem, it is the division of responsibility not being though through while doing so.
As a silly made up example, you pass a callback to an XML parser to tell you when a node has been parsed, so you can pass in a callback to call an API to let it know. Doing something like that just pollutes the XML parser code for no good reason, and you then debug and find you get a 400 error when trying to parse something and 'wtf' and you have to untangle the callbacks.
I'm having a hard time summing it up right now, but I think if you try to "libraritize" "specific code", i.e. make something that does a very specific job, too generic it causes confusion.
That example has 1 callback but believe me some developers want to stack 'em high.
> Writing functions that receive other functions as input can lead to over complicated code that's really hard to read.
Although your opinion is more extreme than I can get behind, I don't entirely disagree. I find monads and applicative functors are far easier to understand when presented in their non-higher-order formulation -- that is, "flatten" instead of "bind", and "merge" instead of "ap". You still need to understand "map", but that's an incredibly common pattern that you can get a lot out of for putting in just a little.
I wrote a little comment on this earlier this week.
I also agree with your opinion elsewhere about preferring combinators instead of directly passing higher-order functions, but I suspect that's much more of a style and design issue than a language feature distinction. You still need higher-order functions (and I'm frustrated weekly by Java's lack of higher-kinded types or pleasant existential types) as the basement layer to expose a beautiful API in more natural terms.
>I can’t help but feel like articles like this are an attempt to racialize Asians and make them identify as a marginalized minority group, instead of as individuals who are in the process of achieving upward mobility. Calling the long-standing economic trends a “myth” is borderline deceptive and risky. Clearly something is working. But if you make people think that it isn’t working, you might inadvertently break it.
Economically us asians are doing quite well but that's not the only aspect of racism that exists. We're marginalized in different ways. It's hard to put into words what this is exactly. Quantitatively you can see an aspect of this in low asian representation in Hollywood but it's much more deeper than that. See here: https://www.youtube.com/watch?v=KsWTFeP1hno&t=3s
As you can see from the video it's not even about economics. It's something else that's deeper because the most insidious thing about it is that huge amount of Asian women sort of have this attitude against their own race as well. It's a subtle sentiment that no one really talks about so it comes out in different ways.
The examples are related to dating but I'm not talking about dating specifically. There is something going on terms of class divide and perspective that is influencing the dating game as a side effect. We talk about class in terms of money but clearly something else is going on with class here that is seperate from money.
It's really something that's hard to pinpoint and as a result I feel a lot of articles like this are written in place of the actual problem.
I'm Asian, the guy didn't ask for a scientific study. He just asked for clarification which you did give in the second paragraph. Give him a break.
Yeah asians are victims of racism, but that doesn't preclude other races from criticising a statement for being unclear.
I would say to the parent parent poster that next time you can ask those questions without directly stating that the comment was: "extremely vague, charged, and lacking in nuance." Even though I agree that what you said is true, most humans are incapable of ingesting those words in an unbiased way and will likely misinterpret it as an insult. Ironically, the comment itself was "lacking in nuance."
It's just a nomenclature thing. Genetically your people are more similar to people from Europe then the "asians" the article refers to. The article uses the word "asian" but technically the article is just referring to people who have certain facial features that are similar to people from China, Japan, Korea, Vietnam... etc. You are asian yes, but in terms of facial features you are in a very separate category than the previous countries I mentioned.
I'm not sure what is the proper term here. I've seen the terms "mongoloid" and "oriental" used to refer to my people but I've also seen things written about how these terms are dated and considered to be insulting. I have found no other word to refer to "asians" the way the article refers to "asians."
It's strange that it's so hard to find a term here as there is a very clear cut category here. Whatever... it's just words.
I would respond to your query and say that "mongoloids" have a very different experience with racism in the US than Indian people due to a multitude of factors one of them being that most Indians already know English.
Qualitatively speaking, in the software world Indians are easily dominating that arena over "mongoloids" so it's a completely different experience.
Whatever hardships Indian people are going through would imho warrant a completely separate article to cover that topic.
I think you’ll find that’s strictly an American definition of “Asian”.
In the UK “Asian” definitely includes people from the Indian sub-continent. See the BBC Asian Network for the example.
Also your claims about genetic similarities and differences between races will need some supporting evidence as they sounds very much like personal opinion.
>I think you’ll find that’s strictly an American definition of “Asian”.
No, that's just colloquial usage of the term "Asian" in America. The official definition we use in America is the same as the UK version.
>Also your claims about genetic similarities and differences between races will need some supporting evidence as they sounds very much like personal opinion.
This is pretty common knowledge. "Mongoloids" branched off on a different ancestral line somewhere during the migration out of Africa. It happened roughly around the middle east with "mongoloids" migrating east on the north side of the himalayas and Indian people moving east to the south. The genetic markers when sampled from populations actually display this genetic separation geographically. In fact the grouping of Indians and "mongoloids" is far more natural and appropriate than the term "Asian"
This is pretty common knowledge from different facial features between Indians and Asian people. But if you want to get technical there are actually genetic markers that correlate geographically with racial physical features. The marker for "mongoloids" is called Haplogroup C-M217, also known as C2 (and previously as C3). It is a Y-chromosome DNA haplogroup. It is the most frequently occurring branch of the wider Haplogroup C (M130). It is found mostly in Central Asia, Eastern Siberia and significant frequencies in parts of East Asia and Southeast Asia including some populations in the Caucasus and Middle East.
The haplogroup C-M217 is now found at high frequencies among Central Asian peoples, indigenous Siberians, and some Native peoples of North America. In particular, males belonging to peoples such as the Buryats, Evens, Evenks, Itelmens, Kalmyks, Kazakhs, Koryaks, Mongolians, Negidals, Nivkhs, Udege, and Ulchi have high levels of M217.
The picture represents the frequency of the historic appearance of Haplogroup C-M217 among native populations with white representing very very low frequencies and the legend in the picture representing higher frequencies.
You will note that C-M217 is basically almost never shows up in India and is highly correlated with the geographic distribution of "mongoloid" facial features found from China going all the way to Native Americans in North America.
Now examine Haplogroup L-M20. Haplogroup L-M20 is also a human Y-DNA haplogroup, which is defined by SNPs M11, M20, M61 and M185. As a secondary descendant of haplogroup K and a primary branch of haplogroup LT, haplogroup L currently has the alternative phylogenetic name of K1a, and is a sibling of haplogroup T (a.k.a. K1b).
The presence of L-M20 has been observed at varying levels throughout South Asia, peaking in populations native to Balochistan (28%), Northern Afghanistan (25%) and Southern India (19%). The clade also occurs in Tajikistan and Anatolia, as well as at lower frequencies in Iran. It has also been present for millennia at very low levels in the Caucasus, Europe and Central Asia. The subclade L2 (L-L595) has been found in Europe and Western Asia, but is extremely rare.
The picture of the haplogroup linking Europe and India is illustrated here:
You will note that this haplogroup extends from India across the middle east into Europe which is consistent with the ancestral migrations of prehistoric humans and also with the caucasian features that Indians and Europeans share.
The story is more complex than this however. These Haplogroups only represent frequencies of two genetic markers. In reality what we interpret as race is an amalgamation of many many genetic and physical features. An individual needs to only have an average amount of these features for our visual cortex to recognize someone as "mongoloid" or "indian."
Because I chose to use a singular genetic marker to show the correlation between physical features, genetic features and geographic distribution you can actually find a flaw that arises from the use of a single genetic marker: Although japanese people and chinese people look alike, they do not share Haplogroup C-M127. Go ahead and look at the picture again above... you will see that japan is white, indicating a very low frequency of haplogroup C-M127 despite physical similarity. The reason for this is outside of the scope of this topic.
That being said it is still possible to find correlation between genetic similarities, physical features and geographic distribution with just two haplogroups because the correlations are very very high. This response serves as proof to show that what I said isn't my opinion. It is more representative of your lack of knowledge misleading you to believe that I am stating my opinion rather than a commonly known fact.
Most people know how use vision and sight to identify these genetic similarities just by looking at faces. It's totally obvious to normal people. However,some people get so politically correct that they lose the ability to to use common sense to see these similarities. People like you... For these people we need to use raw science to show you just how misguided your thought process is.
>My flawed argument was based on India and China sharing a land border and that shared genetic markers are found on both sides of it.
This is not flawed reasoning. Despite Indians and Chinese people possessing unique genetic markers, people in India and China do still share genetic markers from earlier haplogroups. If you go far enough back into human ancestry we can find a markers arising out of Africa that all humans in Asia and Europe share.
>I’m not sure there’s any need to cheapen your point by making personal attacks.
It's not a personal attack. I assume your conclusions are irrationally influenced by the current "woke" trend that's taking over America today. I say this because my conclusion can be arrived at trivially with zero technical jargon.
The same conclusion can be derived from just looking at people. The similarity in facial features between Indians and Europeans and the marked contrast between Chinese and Indians makes my expose into the genetics quite unnecessarily pedantic. It hinders conversation by forcing me to go into details in order to state the obvious.
Correct conclusions can be arrived at in significantly less time if people utilized a combination of common sense and scientific evidence where it is deemed necessary. If I didn't choose to troll this thread with a mile long document of terminal evidence then very likely this conversation would have ended without a real conclusion despite the obvious fact that Indians and Chinese look different enough to be classified as following different branches in the ancestral tree.
> I think you’ll find that’s strictly an American definition of “Asian”.
Well, yes, American media are going to use the American definition of "Asian". This is an article on Vox, not the BBC.
> In the UK “Asian” definitely includes people from the Indian sub-continent.
It is my understanding that the UK term isn't more inclusive, it just refers to subcontinentals instead of orientals, since for historical reasons that's who's present in England.
> Also your claims about genetic similarities and differences between races will need some supporting evidence as they sounds very much like personal opinion.
Don't be ridiculous. Yes, Indians are much more closely related to whites than Asians are. You don't need to support basic well-known facts.
Recall that Indians were usually "white" under US law (there are some exceptions) until pressure from Indian activists in the Nixon administration got them reclassified.
> Don't be ridiculous. Yes, Indians are much more closely related to whites than Asians are. You don't need to support basic well-known facts.
Recall that Indians were usually "white" under US law...
I’m sorry but that is not a “basic well-known fact” that is just conjecture.
Dubious, now repealed, racial laws are not a sound basis on which to hang an argument.
If you want to make that claim stick you’d need to do a peer reviewed comparison of DNA and prove it.
If you really want to play this game consider that China and India share a border.
Where do the people 20 miles on either side of that border fit in your racial hierarchy?
I guess you can keep resorting to ad hominem or you can admit this is not settled and India is a genetically diverse place.
If you pick a different haplogroup such as O-M122, which is believed to have originated in China, you’ll see that is highly present in northern India showing that that border is porous, Himalayas or not.
Notice how the modal component in Indian groups is the "Europe" component. Notice how the East Asian groups share almost nothing with the European groups.
And the next time you want to have an argument in public, please try to make sure you know at least a little bit about the topic. Come on.
Then that person might be the US Census Bureau, which defines (or, rather, has had defined for it) the following racial categories (and more, but these two are relevant to the discussion):
“White – A person having origins in any of the original peoples of Europe, the Middle East, or North Africa.
⋮
“Asian – A person having origins in any of the original peoples of the Far East, Southeast Asia, or the Indian subcontinent including, for example, Cambodia, China, India, Japan, Korea, Malaysia, Pakistan, the Philippine Islands, Thailand, and Vietnam.”
This also basically reflects the general use of the terms in the US, except that a lot of people would would consider Semitic people to be two additional separate races and not part of White, and/or would separate out those from the subcontinent as distinct from “Asians”. It's important to understand that while some of the racial terms have names of continent, they are about a particular model of racial identities, not continental boundaries.
Yea, the US has shown great historical leadership in naming people accurately. Thank God they just called the people there Indians and didn't go all the way and called the place India as well.
So the world has much more sense than to take it's cues from the US, in these matters atleast.
That's because JS is not a functional language. You are enforcing a functional style by discipline. Additionally a huge portion of benefits of the functional style are lost on untyped languages. If you're not using typescript you're dealing with a lot of unnecessary bugs.
If you guys moved to a fully functional paradigm where the language enforces the functional style you will see greater benefits.
Unfortunately for the front end the ecosystem for functional languages outside of TS/JS is not that great. But an easy one to try out to actually see the benefits I recommend writing a little app with ELM. With something like ELM, the functional style is enforced by the compiler. You will see that 90% of the bugs you typically deal with in JS/TS will disappear. One type of bug that will disappear is runtime errors. Runtime errors are not possible in ELM.
I find a lot of JS programmers haven't fully grokked the functional style. Example: You'll find JS programmers who talk about how much they like functional programming but don't understand why for loops don't exist in functional programming.
It's not just pure functions. Two things break modularity: Free variables and mutation.
The problem with OOP is that no method is truly pure, no method is a combinator.
class Thing
var memberVar
def addOne():
return memberVar+1;
The above is an example of your typical class. AddOne is not modular because it cannot be used outside of the context of Thing.
You can use static functions but the static keyword defeats the purpose of a class and makes the class equivalent to a namespace containing functions.
class Thing
static def add(x):
return x + 1;
the above is pointless. Just do the below:
namespace Thing:
def add(x):
return x + 1;
The point of OOP is for methods to operate on internal state. If you remove this feature from OOP you're left with something that is identical to namespaces and functions.
Use namespaces and functions when all you have are pure functions and use classes when you need internal state... there is literally no point for OOP if you aren't using internal state with your classes.
.png){kind=link}