It's well known that less power leads to less opportunities to shoot yourself in the foot. The article talks about "less" power from a qualitative perspective like how "Go" is less "powerful" than "C++" because the language primitives are less dense. It also talks about turing completeness as well but still from a qualitative perspective.
There is actual benefits in removing fundamental core features of programming. You can remove iteration to make something not turing complete but before that you can maintain turing completeness while removing certain core programming features.
In fact There is an entire style of programming that removes these core features and is "less" powerful and "less" expressive as well. It is called functional programming.
Functional Programming is simply the same thing as imperative programming only without the power of mutability. No variable reassignment. No looping.
The strange thing is I always hear people talk about things how functional languages like say... Haskell are more expressive and more powerful than imperative languages. They are technically wrong. These languages are LESS powerful.
So yeah the author is really talking more about cognitive overload of say something like C++ but at a more fundamental level making our core programming model less powerful actually has some interesting benefits outside of just "cognitive overload"
Modules in functional programs (called combinators) are the most modular primitives available in all of programming and FP pushes the programmer into encapsulating his logic into these primitives leading to actually more modular and better constructed programs. The structure of programs changes for the better when things are made less powerful.
> The strange thing is I always hear people talk about things how functional languages like say... Haskell are more expressive and more powerful than imperative languages. They are technically wrong. These languages are LESS powerful.
You're just arguing from different definitions, here. In fact, it's worth checking whether your definitions match up whenever you find yourself saying "technically" since it suggests you're applying a particular definition.
So tell me what do people mean when they say Haskell is more "powerful"? Tell me the definition. I don't think there is a different definition. I think it's just that most people aren't sure why Haskell is "better" than say C++.... They know it's "better" but they can't put their finger on "why" and they mistakenly attribute it to a more powerful language without thinking that Haskell is actually less powerful in every possible way.
The set of all things you can do to your computer with Haskell is less than the things you can do to it with C++. If you look at it from every possible angle you will see that either you do less with Haskell or Haskell makes it Much harder to do certain things. There's really no angle where you can say Haskell is more powerful than C++ unless you really stretch the definition which I'm sure your subsequent reply (if you reply at all) will be doing.
Let's assume you're right and there isn't a different definition. Still: by focusing on the use of the term, you're driving the conversation away from the substance of what the other person is saying and toward a linguistic discussion.
In other words, if you recognize that someone is using a term incorrectly, first take the time to understand what they're trying to communicate. Maybe start talking about that concept using words you think are a better fit, but stay on the territory. Responding that "powerful" isn't the right word doesn't address their claim that Haskell is more <whatever they mean by powerful>.
This charitable approach shifts the conversation away from scoring points (as would leaving out asides like "(if you reply at all)") and toward collaborating on developing each other's understanding, which is more valuable for everyone involved.
You're the one that put focus on the term. I didn't do that. I'm defining powerful in the same sense the article defines it.
My argument in response to your reply is to say there is no reasonable alternate definition and people people are using the term because of an incorrect notion that haskell has more expressive power then say c++ when in fact it has much less expressive power.
I put "if you reply at all" to acknowledge the fact that I could've went into a long expose into something and you could just ignore it as an optional retort. My reply is anticipating all possible logical counters. I also wanted to emphasize the fact that I do not believe an alternate definition is reasonable but I am aware that it is the most likely reasoning you will be using in your response. I am letting you know that I am already aware of it. It saves the discussion from going down an avenue of things we already are aware of.
I did not anticipate you to go meta and talk about the discussion itself but maybe I should've as I sort of boxed you out of all other alternative paths. I personally think it's unnecessary to go here still. If you disagree stay on topic and propose why you think an alternate definition is reasonable. If you agree you can still stay on topic by conceding I'm right... but human nature prevents 99 percent of all people from ever conceding as conceding is subconsciously perceived to be a form of weakness. By probability, I am hypothesizing that you are within this 99 percent and that you will likely never take this path as an option in your next reply, if you reply at all.
I concede as often as I can, actually. Partly it's because I view being wrong as a temporary state of affairs, that doesn't reflect poorly on me as a human, and that I can grow from. Partly it's tactical: by conceding, I can focus on more substantive territory, make the conversation less adversarial, and build credibility with others both in the conversation and observing it. I've found it works better than arrogance or insistence.
I chose the sentence I responded to because I thought you were putting focus on the term, specifically where you say people are "technically wrong" because functional languages are "less powerful." My mistake. I was trying to encourage you to consider that the people saying that may be correct in what they mean, even if what they mean doesn't correctly align with the use of "powerful."
Just to point out, as well: you have also had the opportunity to acknowledge that I'm right. If these people are arguing from an incorrect definition of "powerful," as you say, then they are indeed arguing from a different definition of "powerful" than you are. That fulfills what my original comment set out, which is that you and these people are arguing from different definitions.
Perhaps you should have anticipated my focusing on the conversation itself, not because you had boxed me out, but because that was the substance of my comment in the first place.
>Perhaps you should have anticipated my focusing on the conversation itself, not because you had boxed me out, but because that was the substance of my comment in the first place.
Not only do I often fail to anticipate this. I find the whole thing pointless. I'm uninterested in personal details or meta aspects of the conversation. I am only interested in the topic.
Your initial comment was on the definition of the word "powerful" your subsequent comment was on meta aspects of the discussion which I find very tangential.
Haskell has fully-featured generics and Go does not. In this sense Haskell is more powerful than Go. However, Go has mutability and (mostly) Haskell does not. In this other sense, Go is more powerful than Haskell.
Kind of but if you think about it generics and parametric polymorphism in general is a restriction on the types that a function can take as parameters. It is a feature that allows you to restrict how a function is used. In a sense you are using generics to deliberately make a function less powerful.
Golang doesn't have parametric polymorphism as a restrictive option . Instead you can use interface {} which removes all restrictions makes go as unrestrictive as python. Type checking and any feature related to it in general exists to make languages less "expressive"
Types in Haskell are not just restriction, they're also used to generate code automatically for you using typeclasses. Something like [traversable](https://wiki.haskell.org/Foldable_and_Traversable) provides behavior just based on types, and is far too powerful to be expressible in Go (or in most typed languages anyway).
This isn't code generation. This exists in other typed languages including Go. It's called interfaces or polymorphism. It's done via interfaces or inheritance in other languages.
This is still a restriction. A function that operates only on a "traversable" type is still a function that is restricted to that type class.
Haskell is substantially more powerful when it comes to features like enforcing compile time guarantees about properties of your program, as well as writing highly polymorphic functions.
I would say python/javascript is more powerful with polymorphism as it defines polymorphism over everything.
Saying Haskell is more powerful when it comes to compile time guarantees is like saying Haskell is more powerful because it is more restrictive. The guarantee exists because Haskell is not expressive enough allow you to break that guarantee.
I mean yeah. An obese person is more powerful than an olympic athlete because the obese person is better at weighing more.
I honestly don't think most people are using the word in the way you define it. They think Haskell is less restrictive than python/javascript because really they haven't thought about why Haskell is better. Haskell is more restrictive and less expressive and less "powerful" and that is why it is "better."
Case in point your example of highly polymorphic functions as a unique feature.... Completely mistaken given that polymorphism is available on most typed programming languages and that all data structures in untyped languages are polymorphic to each other.
There is actual benefits in removing fundamental core features of programming. You can remove iteration to make something not turing complete but before that you can maintain turing completeness while removing certain core programming features.
In fact There is an entire style of programming that removes these core features and is "less" powerful and "less" expressive as well. It is called functional programming.
Functional Programming is simply the same thing as imperative programming only without the power of mutability. No variable reassignment. No looping.
The strange thing is I always hear people talk about things how functional languages like say... Haskell are more expressive and more powerful than imperative languages. They are technically wrong. These languages are LESS powerful.
So yeah the author is really talking more about cognitive overload of say something like C++ but at a more fundamental level making our core programming model less powerful actually has some interesting benefits outside of just "cognitive overload"
Modules in functional programs (called combinators) are the most modular primitives available in all of programming and FP pushes the programmer into encapsulating his logic into these primitives leading to actually more modular and better constructed programs. The structure of programs changes for the better when things are made less powerful.