Less is more: language features(blog.ploeh.dk)
blog.ploeh.dk
Less is more: language features
http://blog.ploeh.dk/2015/04/13/less-is-more-language-features/
16 comments
Which in turn allows more modular code. I translated an example from Why FP using Python here: http://satvikberi.com/2014/10/13/functional-programming-usin...
I take issue with the single-number-type thing. This guy is conflating two different reasons/ways to divide up number types - for transparency w.r.t. machine (optimization) and by conceptual types (integer vs natural number vs fractional, etc.). The first arguably doesn't belong in a high level language. The second arguably is _exactly_ what a truly high level language should have.
I agree. Just think of how often what you really want to express in your program is a function that takes a Positive Integer, and any other type of number is simply wrong.
I've often thought you could add that to your type system somehow? Sometimes you want to express that this variable can only take numeric values between 0-1 or this variable can only take string values with exactly three uppercase ASCII letters. Just like you don't need a special string type to handle three letter strings, you don't need a special number type to handle positive integers, you just need a way to represent subsets in your type systems.
On the other hand I'm decidedly old school and get very uncomfortable around languages that at least don't separate floats from ints.
On the other hand I'm decidedly old school and get very uncomfortable around languages that at least don't separate floats from ints.
Pascal had subrange types, which were quite nice in that regard. Although I don't remember using them that much.
Yet another article that misses the point of "goto considered harmful."
The way "goto" is used in modern C (named breaks and defined function escape routes) is perfectly acceptable. Newer languages include these features in the language, in much the same way that C encoded structured "goto"s as "while" loops and "if" statements.
Dijkstra was complaining about unstructured programming compared to structured programming.
The way "goto" is used in modern C (named breaks and defined function escape routes) is perfectly acceptable. Newer languages include these features in the language, in much the same way that C encoded structured "goto"s as "while" loops and "if" statements.
Dijkstra was complaining about unstructured programming compared to structured programming.
Yep. Things like while loops, break statements and if-else statements containing blocks are basically structured constructs over goto. Goto is the basic building block, it is not "entirely redundant", it is entirely foundational. It's just too low-level for everyday usage.
To me this is a weird list. It's a bit like removing the personality of a person and then claiming that made the person better.
Also a lot of the things he lists are not at all as clearly harmful as he makes them out to be.
GOTO: Used in some of the cleanest code bases. For example the lua programming language, redis db, and linux kernel OS. Yes the use is limited, but it's there not because of mistakes but rather because it is sometimes the most clean way.
Numbers: I don't understand this one. In the very least having different types of numbers seems to be a necessity for anything performance oriented such as graphics. JS not having them (they seem to have been added for WebGL as an extension, no?) is not a good reason for all new languages to do the same.
Mutations: I am personally of the view that mutation often simplifies the informal reasoning complexity of a program. There's a reason functional programming hasn't caught on and it likely never will. A hybrid approach of having both immutability and mutability like Rust seems most sensible.
Reference equality (Referential transparency?): If you have immutability do you not get this for free? How can you be sure about getting rid of mutations but not be sure you want objects to be equal based on data?
Each language has it's own quirks that make it special and that's part of the reason programming is fun. There's never a single right way.
Also a lot of the things he lists are not at all as clearly harmful as he makes them out to be.
GOTO: Used in some of the cleanest code bases. For example the lua programming language, redis db, and linux kernel OS. Yes the use is limited, but it's there not because of mistakes but rather because it is sometimes the most clean way.
Numbers: I don't understand this one. In the very least having different types of numbers seems to be a necessity for anything performance oriented such as graphics. JS not having them (they seem to have been added for WebGL as an extension, no?) is not a good reason for all new languages to do the same.
Mutations: I am personally of the view that mutation often simplifies the informal reasoning complexity of a program. There's a reason functional programming hasn't caught on and it likely never will. A hybrid approach of having both immutability and mutability like Rust seems most sensible.
Reference equality (Referential transparency?): If you have immutability do you not get this for free? How can you be sure about getting rid of mutations but not be sure you want objects to be equal based on data?
Each language has it's own quirks that make it special and that's part of the reason programming is fun. There's never a single right way.
GOTO: Agreed, it can be a very effective way of error handling in exception free languages.
GOTO, mutations, and side-effects break referential equality and equational reasoning, making it much harder to prove things about your program. I guess you can do that by endless permutations of tests or a stochastic testing system, but that sounds like a horrible way to spend your time.
A program that's harder to prove correct is not necessarily incorrect.
I'd actually argue that most of the software that runs our lives today is impossible to prove correct and yet seems to be doing quite alright overall.
You're setting up a similar false dichotomy as people who say that programs that ship without automated tests are worthless and broken.
I'd actually argue that most of the software that runs our lives today is impossible to prove correct and yet seems to be doing quite alright overall.
You're setting up a similar false dichotomy as people who say that programs that ship without automated tests are worthless and broken.
Nah, I am saying two things:
1. Mutability makes your program harder to reason about.
2. There are better ways to spend your time than writing tests for conditions that could not exist with pure functions.
You could totally extrapolate a ton of statements from those two statements though. But I'm not doing that now, and not here.
1. Mutability makes your program harder to reason about.
2. There are better ways to spend your time than writing tests for conditions that could not exist with pure functions.
You could totally extrapolate a ton of statements from those two statements though. But I'm not doing that now, and not here.
> 1. Mutability makes your program harder to reason about.
How so?
How so?
I give an example in a sibling (cousin?) comment here: https://news.ycombinator.com/item?id=9372280
You are conflating "proving correct", which is exceedingly rare and "reason about", which is extremely common.`
Functional languages may make the former easier (though from the proofs we did in University, I don't really see it), but they make the latter much harder in many cases.
Functional languages may make the former easier (though from the proofs we did in University, I don't really see it), but they make the latter much harder in many cases.
I disagree. I think reasoning in a programming language that limits effects with types and promotes partitioning them from the rest of your logic is dramatically simpler than in languages where mutation and effects can happen anywhere.
> mutation and effects can happen anywhere.
That's a red herring and a scare-story that FPers tell each other. They can't happen "anywhere". They happen where you tell them to happen.
Do you have any evidence that actual reasoning is simpler?
"At the end you usually get a tight loop that is easy to follow. It is also much more imperative/operational than before, which may bug Haskell-style people." -- Jonathan Blow
https://twitter.com/jonathan_blow/status/588007366618062848
"I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard.
Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops.
You shouldn't use it either." -- Rob Pike
https://github.com/robpike/filter
This matches my experience pretty well. When I first created Higher Order Messaging, I was also really into creating chained higher order ops. After a little while, I noticed that a small for-loop was actually more readable than the really cool filter-chains I had created. Less cool, but more readable, comprehensible, easier to reason about, not least because of named intermediate values, something that tends to get lost in point-free style (and trust me, having been a heavy user + implementor of Postscript, I know a little about point-free style).
That's a red herring and a scare-story that FPers tell each other. They can't happen "anywhere". They happen where you tell them to happen.
Do you have any evidence that actual reasoning is simpler?
"At the end you usually get a tight loop that is easy to follow. It is also much more imperative/operational than before, which may bug Haskell-style people." -- Jonathan Blow
https://twitter.com/jonathan_blow/status/588007366618062848
"I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard.
Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops.
You shouldn't use it either." -- Rob Pike
https://github.com/robpike/filter
This matches my experience pretty well. When I first created Higher Order Messaging, I was also really into creating chained higher order ops. After a little while, I noticed that a small for-loop was actually more readable than the really cool filter-chains I had created. Less cool, but more readable, comprehensible, easier to reason about, not least because of named intermediate values, something that tends to get lost in point-free style (and trust me, having been a heavy user + implementor of Postscript, I know a little about point-free style).
In a strongly typed functional program I can prove that side effects only happen in specific places that are designated by the types. I have no such assistance in say Java, or Python. That is what I mean that side effects can happen anywhere.
I would call referential transparency, which gives rise to equational reasoning, very strong evidence that reasoning becomes simpler.
I would call referential transparency, which gives rise to equational reasoning, very strong evidence that reasoning becomes simpler.
You're still conflating "prove" with "reason". I don't need to prove things about my code in order to reason about it. For example, I can just look at the code in question to know whether it has side effects, and most code doesn't.
In fact, most proofs I have seen don't particularly help me reason about the code in question. On the other hand, a simple imperative execution model does help me reason about the code.
In fact, most proofs I have seen don't particularly help me reason about the code in question. On the other hand, a simple imperative execution model does help me reason about the code.
I don't think I am doing any such conflating.
Being able to reason about things equationally makes my code easier to reason about. Having a type system and a compiler assist me makes my code easier to reason about. Having fewer variants makes my code easier to reason about. Not needing to know the order in which functions have been invoked to know their return values makes my code easier to reason about.
However, I will make the statement -- and this is indeed conflating! -- If I can prove something about my code, then it is easier to reason about. The proof can be simple or complex.
Being able to reason about things equationally makes my code easier to reason about. Having a type system and a compiler assist me makes my code easier to reason about. Having fewer variants makes my code easier to reason about. Not needing to know the order in which functions have been invoked to know their return values makes my code easier to reason about.
However, I will make the statement -- and this is indeed conflating! -- If I can prove something about my code, then it is easier to reason about. The proof can be simple or complex.
Again, you are just repeating your assertions and somehow think that simply asserting them makes them true. It does not, and I don't think I can make you understand the difference between assertions and evidence, so let's call it a day.
I think my assertions are pretty well accepted virtually ... everywhere, so it didn't really occur to me THOSE specifically were what you were calling into question. But if THAT is what we are arguing about, I agree, this is all rather cyclical and pointless.
They're not. Or rather, you have a very narrow definition of "everywhere". And even if they were, that doesn't make them true without evidence, quite the contrary, that makes them especially suspect (groupthink etc.). Also, if you're so sure they are universally accepted, why the need to argue them at all? And of course, if they are so universally true, it should be trivial to actually come up with actual evidence, which hasn't been the case.
Something to think about. Maybe.
Something to think about. Maybe.
[deleted]
"[They] break referential equality and equational reasoning"
Please explain?
Mutations can cause side-effects but don't have to. You seem to think that limiting program behavior _necessarily_ alleviates informal reasoning, but that's not the case. Your argument is also highly hyperbolic in terms of testing. A properly designed system with immutability needs to be tested no less than properly designed system with mutability.
Please explain?
Mutations can cause side-effects but don't have to. You seem to think that limiting program behavior _necessarily_ alleviates informal reasoning, but that's not the case. Your argument is also highly hyperbolic in terms of testing. A properly designed system with immutability needs to be tested no less than properly designed system with mutability.
Sure!
Mutations ARE side effects. Consider two situations with a function and a mutable variable:
First: Your function depends on a value that can mutate. Now you have a hidden parameter to your function. You have to test the function under all reasonable conditions by which the value can change. The function is not isolated from the rest of your program any more, and you have to check who has access to that value. That's a lot to keep track of.
Second: Your function mutates a value. Now you have to keep track of everyone who references that value, and everywhere your function is invoked.
In both situations, the number of scenarios you must test is greatly expanded compared to when you have a 'pure' function that does not operate on mutable memory.
Referential transparency means that for a fixed input value you can replace a function invocation with a static value. It's just a mapping that is always the same, whether it's computationally expensive or not. That means that you can always expect the same behavior when you compose that function. But even more important, you can assert that your function is equal to something else -- always, under all conditions.
This means that you can make a series of equational substitutions. And THAT means that you can use equational reasoning to prove things about your function.
And if your program is just a bunch of functions that are composed together, well then you can prove things about your program, too.
Programs are getting really complex. Really, really, really complex. Having the power to make more safe assertions about your programs is becoming more important. Being able to prove things about your programs using well known proving techniques, such as those borrowed from more formal maths like abstract algebra, is really useful.
You still need to test, but what you need to test becomes of much narrower scope and much less cumbersome. This is why functional programming is indeed becoming more popular.
Mutations ARE side effects. Consider two situations with a function and a mutable variable:
First: Your function depends on a value that can mutate. Now you have a hidden parameter to your function. You have to test the function under all reasonable conditions by which the value can change. The function is not isolated from the rest of your program any more, and you have to check who has access to that value. That's a lot to keep track of.
Second: Your function mutates a value. Now you have to keep track of everyone who references that value, and everywhere your function is invoked.
In both situations, the number of scenarios you must test is greatly expanded compared to when you have a 'pure' function that does not operate on mutable memory.
Referential transparency means that for a fixed input value you can replace a function invocation with a static value. It's just a mapping that is always the same, whether it's computationally expensive or not. That means that you can always expect the same behavior when you compose that function. But even more important, you can assert that your function is equal to something else -- always, under all conditions.
This means that you can make a series of equational substitutions. And THAT means that you can use equational reasoning to prove things about your function.
And if your program is just a bunch of functions that are composed together, well then you can prove things about your program, too.
Programs are getting really complex. Really, really, really complex. Having the power to make more safe assertions about your programs is becoming more important. Being able to prove things about your programs using well known proving techniques, such as those borrowed from more formal maths like abstract algebra, is really useful.
You still need to test, but what you need to test becomes of much narrower scope and much less cumbersome. This is why functional programming is indeed becoming more popular.
That's just handwaving. Assume for a second that your reader knows about referential integrity, has taken advanced FP in university, programmed in/with and implemented higher order mechanisms.
Assume that the reader also knows how substitutability makes some variants of FRP much, much harder to both implement and reason about, has Haskell code in production that only two people at the company claim to understand, knows about the Principle of Least Expressiveness": "When programming a component, the right computation model for the component is the least expressive model that results in a natural program." And also knows about how to interpret it, namely: "Note that it doesn't say to always use the least possible expressive model; that will result in unnatural (awkward, hard to write, hard to read) programs in at least some cases" (http://c2.com/cgi/wiki?PrincipleOfLeastPower)
Assume that the person has seen people be very productive with simple dataflow tools such as Quartz Composer, and then hit a wall because that simpler programming model doesn't just have a low threshold, it also has a low ceiling. And has read in a report on 15+ years of constraint programming that students consistently found it difficult to think ("reason") in a functional style. (see http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...)
So.
What evidence do you have for your assertions? Not arguments or logical inferences from your assumptions, but actual evidence?
Assume that the reader also knows how substitutability makes some variants of FRP much, much harder to both implement and reason about, has Haskell code in production that only two people at the company claim to understand, knows about the Principle of Least Expressiveness": "When programming a component, the right computation model for the component is the least expressive model that results in a natural program." And also knows about how to interpret it, namely: "Note that it doesn't say to always use the least possible expressive model; that will result in unnatural (awkward, hard to write, hard to read) programs in at least some cases" (http://c2.com/cgi/wiki?PrincipleOfLeastPower)
Assume that the person has seen people be very productive with simple dataflow tools such as Quartz Composer, and then hit a wall because that simpler programming model doesn't just have a low threshold, it also has a low ceiling. And has read in a report on 15+ years of constraint programming that students consistently found it difficult to think ("reason") in a functional style. (see http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...)
So.
What evidence do you have for your assertions? Not arguments or logical inferences from your assumptions, but actual evidence?
I disagree that it is just handwaving. I assert that I gave lots of evidence, namely that the scope of what you need to test to assure correct operation of your program is much narrower.
You can reason about that intuitively even, without trying to prove anything. The less stuff I need to test, the less stuff that my brain needs to think about.
I'm not quite sure what kind of evidence you're looking for. I'm not quite sure that you calling all of the evidence I provided as handwaving is valid, either!
But I can give you all kinds of anecdotal evidence if you like? I gave, I think, two pretty concrete but general examples.
You can reason about that intuitively even, without trying to prove anything. The less stuff I need to test, the less stuff that my brain needs to think about.
I'm not quite sure what kind of evidence you're looking for. I'm not quite sure that you calling all of the evidence I provided as handwaving is valid, either!
But I can give you all kinds of anecdotal evidence if you like? I gave, I think, two pretty concrete but general examples.
You are still confusing logical inferences from unproven assertions with evidence. You claim that what you need to test is narrower, and I understand your reasoning as to why you think that this is true, but there is no evidence that your claims are actually true.
On the other hand, there was a paper just recently (can't currently find it), with empirical evidence that surprisingly few tests were required to weed out large swathes of potential misbehavior, much fewer than could reasonably be expected.
Or there is Robert Smallshire's data mining of github errors that showed type errors in dynamically typed languages as being exceedingly rare (1-2%), when everyone just knows that they must be common and problematic.
On the other hand, there was a paper just recently (can't currently find it), with empirical evidence that surprisingly few tests were required to weed out large swathes of potential misbehavior, much fewer than could reasonably be expected.
Or there is Robert Smallshire's data mining of github errors that showed type errors in dynamically typed languages as being exceedingly rare (1-2%), when everyone just knows that they must be common and problematic.
We could both give each other empirical evidence all day.
I wouldn't really call my assertions unproven. Speaking of referential transparency and equational reasoning is kind of the core of a lot of computer science.
I'm not really sure what kind of evidence you are asking for.
I will say that I think some programming languages are more interesting than others, and some are a more productive, better use of time than others.
I wouldn't really call my assertions unproven. Speaking of referential transparency and equational reasoning is kind of the core of a lot of computer science.
I'm not really sure what kind of evidence you are asking for.
I will say that I think some programming languages are more interesting than others, and some are a more productive, better use of time than others.
If a function receives immutable state, returns immutable state, and does not depend or modify outside mutable state, then that function has no side effects. Mutating state within the function itself will not affect anything outside it and so mutations are not side effects, at least by default.
About your two situations, I am guessing you mean that the functions rely on state not being passed in, but rather on state referenced from the outer scope? I agree that that complicates both reasoning and testing, and so it should be avoided. In C/C++ this type of design (i.e. relying on static scope state) is practically always avoided as there's rarely any need for it.
If instead you mean that mutable references are being passed in as parameters then logic wise isn't this similar to assignment/binding in a functional language as long as you avoid propagating the side effect to other functions?
I am personally a great fan of immutability, just not functional languages. I can see the justification for limiting the tools at your disposable to guarantee certain things, it's just that in this case I think they are not sufficient.
---
For those downvoting, gee thanks. I see how trying to have a discussion is hurting your feelings.
About your two situations, I am guessing you mean that the functions rely on state not being passed in, but rather on state referenced from the outer scope? I agree that that complicates both reasoning and testing, and so it should be avoided. In C/C++ this type of design (i.e. relying on static scope state) is practically always avoided as there's rarely any need for it.
If instead you mean that mutable references are being passed in as parameters then logic wise isn't this similar to assignment/binding in a functional language as long as you avoid propagating the side effect to other functions?
I am personally a great fan of immutability, just not functional languages. I can see the justification for limiting the tools at your disposable to guarantee certain things, it's just that in this case I think they are not sufficient.
---
For those downvoting, gee thanks. I see how trying to have a discussion is hurting your feelings.
Yeah! If your mutability is completely limited to the scope of your function, then you should be fine.
If your programming language takes the power to mutate away from you then you have even less to worry about: You don't have to rely on self-discipline to not write a bad program, the compiler tells you it's not good.
Even in really small functions, with tiny scopes, I think reasoning about mutation takes a tidy mental toll. You can express about almost everything you need (well, I don't really know you or what you are programming) with maps and folds and recursion.
In object oriented languages the traditional belief has been that encapsulation with privacy modifiers and getters and setters is sufficient to make well behaved programs. I don't think that goes far enough. I think that to reason about programs effectively you need some sort of immutability guarantee.
If your programming language takes the power to mutate away from you then you have even less to worry about: You don't have to rely on self-discipline to not write a bad program, the compiler tells you it's not good.
Even in really small functions, with tiny scopes, I think reasoning about mutation takes a tidy mental toll. You can express about almost everything you need (well, I don't really know you or what you are programming) with maps and folds and recursion.
In object oriented languages the traditional belief has been that encapsulation with privacy modifiers and getters and setters is sufficient to make well behaved programs. I don't think that goes far enough. I think that to reason about programs effectively you need some sort of immutability guarantee.
I dispute the basic narrative here. If you have tail calls, you have GOTO. If you have closures, you have pointers. The story (so far) is not one of features disappearing, but of features being subsumed by other more general, abstract features.
Everything ultimately manifests as a restriction on the set of assembler instruction series you are permitted to execute. A GOTO that is restricted from leaping outside of its local scope is a limitation. A language with no GOTO is even more limited. A language that only permits tail calls is yet more limited. You don't have GOTO unless you have a full, unrestricted JMP, and if all your language has are tail calls, you do not have a full unrestricted JMP. If you have "pointers" but can't perform arithmetic on them, you don't really have "pointers".
All of these things are restrictions, as well as features. The idea that "features == more power" is not accurate... features and power have a complicated relationship, the moreso since there's more than one useful definition of power, but they are almost no matter what neither strictly in opposition, nor strictly working together. But pretty much every useful high level feature is some restriction on what code sequences you can cause to run with the language, together with something built on top of that restriction that would be either harder or less safe without the restriction.
All of these things are restrictions, as well as features. The idea that "features == more power" is not accurate... features and power have a complicated relationship, the moreso since there's more than one useful definition of power, but they are almost no matter what neither strictly in opposition, nor strictly working together. But pretty much every useful high level feature is some restriction on what code sequences you can cause to run with the language, together with something built on top of that restriction that would be either harder or less safe without the restriction.
If you have closures, you have pointers.
And if you have closures you generally have a garbage collector of some sort or another. But anyways, I don't think closures are more "general" than pointers. Closures form a proper subset of memory access vectors (to use a fairly simple definition of "pointer"), so there are things pointers can do that closures can't. But for that matter pointers themselves are an abstraction for memory addresses that the Real Programmers of Yore used before compilers came in and made us all wimps...
And if you have closures you generally have a garbage collector of some sort or another. But anyways, I don't think closures are more "general" than pointers. Closures form a proper subset of memory access vectors (to use a fairly simple definition of "pointer"), so there are things pointers can do that closures can't. But for that matter pointers themselves are an abstraction for memory addresses that the Real Programmers of Yore used before compilers came in and made us all wimps...
As long as they are not directly available to the programmer.
No you don't. A GOTO allows you to GOTO a location that isn't valid code—for example, the middle of a multibyte instruction. A tail call does not. That's what the article meant by "disallowing invalid code": a GOTO is strictly equivalent to a tail call, except for all the extra invalid things a GOTO also allows you to do.
Not really. Machine language jumps can do that sort of nasty stuff but usually gotos are restricted to more well-behaved labels.
That said, gotos are still much less structured than tail calls. You can make some much more spaghetti-like control flow patterns and you are also encouraged to use shared mutable variables instead of passing parameters by value.
That said, gotos are still much less structured than tail calls. You can make some much more spaghetti-like control flow patterns and you are also encouraged to use shared mutable variables instead of passing parameters by value.
It's interesting to see that recent languages are making strides towards this list.
* Golang does away with inheritance and exceptions.
* Rust does away with mutability, or at least makes it explicit.
I wonder if a convenient language with all of these taken out could exist. I'm skeptical about a single number-type.
Also, wouldn't reference equality simply be gone if you take away pointers?
Also, his point about interfaces is pretty narrow, not every interface's manipulation can be characterized by one or one set of manipulations. I think Golang is a fantastic example of a language that forces a role-based interface pattern.
* Golang does away with inheritance and exceptions.
* Rust does away with mutability, or at least makes it explicit.
I wonder if a convenient language with all of these taken out could exist. I'm skeptical about a single number-type.
Also, wouldn't reference equality simply be gone if you take away pointers?
Also, his point about interfaces is pretty narrow, not every interface's manipulation can be characterized by one or one set of manipulations. I think Golang is a fantastic example of a language that forces a role-based interface pattern.
Rust also lacks goto, "raw" pointers, null pointers, inheritance, general reflection, and cyclic dependencies. It also has very limited exceptions (as panic can only be caught at thread boundaries) and prefers structural equality syntactically to reference equality (although reference equality is possible).
Also, Go has exceptions as described here. Panic and recover allow the same semantic power, since every exception-based program can be easily transformed into the equivalent program with Go panic/recover, and vice-versa.
Also, Go has exceptions as described here. Panic and recover allow the same semantic power, since every exception-based program can be easily transformed into the equivalent program with Go panic/recover, and vice-versa.
> Also, wouldn't reference equality simply be gone if you take away pointers?
You don't need to expose a pointer datatype to offer a reference equality check operation. Java, JavaScript, C#, etc, all do reference equality by default for user-defined classes.
You don't need to expose a pointer datatype to offer a reference equality check operation. Java, JavaScript, C#, etc, all do reference equality by default for user-defined classes.
> * Golang does away with inheritance and exceptions.
Meh,regarding exceptions you still have errors that you bubble up by returning them. It's hardly different from exceptions.
On the other hand, Go went way too minimal with its type system so much that, you can opt out with inteface{} because it's not expressive enough. I would prefer no interface {} , no reflection ,but to allow types as parameters and value.Which they are not in go.
finally, go has GOTO ... I would have gotten rid of that at first place.
Meh,regarding exceptions you still have errors that you bubble up by returning them. It's hardly different from exceptions.
On the other hand, Go went way too minimal with its type system so much that, you can opt out with inteface{} because it's not expressive enough. I would prefer no interface {} , no reflection ,but to allow types as parameters and value.Which they are not in go.
finally, go has GOTO ... I would have gotten rid of that at first place.
> you still have errors that you bubble up by returning them. It's hardly different from exceptions.
It's completely different: you have to manually bubble them if you want them to bubble. You can perfectly not deal with them.
Yes, the initial reaction to seeing an err pop up is to return it. No, you don't have to return it.
It's completely different: you have to manually bubble them if you want them to bubble. You can perfectly not deal with them.
Yes, the initial reaction to seeing an err pop up is to return it. No, you don't have to return it.
I think it's worrying if language design ever becomes about having higher and higher level features 'protecting' the programmer from making mistakes, at the cost of losing access to lower level features that are considered harmful. Higher level features are much better than a GOTO 99% of the time, but there's always going to be 1% of the time when a GOTO might be better.
There's no need for the two things to be at odds. Look at Rust's unsafe blocks, for example—or C's asm blocks, for that matter. A language can let you have your cake (or safety), and eat it (or skirt it) too.
Protecting the programmer is a good sell to corporations though. Less chance of error prone production code, easier for people to develop with, etc.
The same corporations that use the Linux kernel, various database engines and various language runtimes, all of which contain C or C++, many platform specific byte manipulations and various other unsafe features?
Have you used Linux lately? It's always close to falling apart, in my experience. That the developers are doing a heroic job of keeping all the unsafe parts under control does not mean this is a good idea for the rest of us.
I use it daily, both personally, for development and in production. Performs better than commercial nix and Windows IMHO; cannot comment on BSDs or Mac.
This article is nearly its own reductio ad absurdum. By this line of reasoning, we would all be better off programming just with NAND gates – the most minimal programming model of all.
It seemed really unfair the way the "valid programs" was slightly out of bounds on C (meaning there are some things you can do in assembler, but not C, to which I agree); but then as he starts removing more and more features, the "valid programs" circle is wholly inside his imaginary language construct; and no matter how much is taken away, we're to believe all possible valid programs can still be represented? Nonsense.
I agree. I stopped taking him seriously when he wrote that Java didn't have pointers. (Java's references are pointers w/o arithmetic. But they're still pointers: they're occupying space and are allocated separately from the pointee.)
Also, in the summary list of features to be removed: in that case the diagrams of "Languages that disallow X" should all be mutually intersected, and I suspect that the resulting intersection would exclude too many valid programs (i.e., you'd end up with the graph "languages taking away the wrong features).
Also, in the summary list of features to be removed: in that case the diagrams of "Languages that disallow X" should all be mutually intersected, and I suspect that the resulting intersection would exclude too many valid programs (i.e., you'd end up with the graph "languages taking away the wrong features).
Nice post, although I think the author is cheating a little with his Venn diagrams. Most of the time, his language subset contains almost all the valid programs. I don't think it is true. I'd like to know how one can make hard real-time embedded programming with the only language features he offers, for instance, or anything that requires as much processing power as you can (cryptography, constraint solving, data mining, optimization, simulation, etc.) I am not talking about exotic niches here.
More generally, I'm still waiting for a massively successful piece of software made in a language that would involve no mutation, no null pointers, only one numeric type, etc. Even John Carmack has not yet delivered a revolutionary game engine programmed in Haskell.
More generally, I'm still waiting for a massively successful piece of software made in a language that would involve no mutation, no null pointers, only one numeric type, etc. Even John Carmack has not yet delivered a revolutionary game engine programmed in Haskell.
> More generally, I'm still waiting for a massively successful piece of software made in a language that would involve no mutation, no null pointers, only one numeric type, etc. Even John Carmack has not yet delivered a revolutionary game engine programmed in Haskell.
One can program with mutations in Haskell, and all the side-effects can be kept "sandboxed" at the same time; also I believe the side-effectful parts of a Haskell program can be compiled (in principle) in a way that results in very efficient code, as fast as e.g. C++, though I'm not sure how well current compilers are doing in this respect.
So in a way, Haskell (as a language) offers the best of both worlds.
One can program with mutations in Haskell, and all the side-effects can be kept "sandboxed" at the same time; also I believe the side-effectful parts of a Haskell program can be compiled (in principle) in a way that results in very efficient code, as fast as e.g. C++, though I'm not sure how well current compilers are doing in this respect.
So in a way, Haskell (as a language) offers the best of both worlds.
Unlambda [1] is completely functional and has only 2 built-in functions. According to the author, it's the perfect programming language, even though it's extremely inefficient and the code is almost impossible to understand. Many of the features he lists enhance either efficiency (number types) or readability. The languages that lack these things are bound to be slow and hard to understand at least in some cases.
[1] https://en.wikipedia.org/wiki/Unlambda
[1] https://en.wikipedia.org/wiki/Unlambda
> F# projects have fewer and smaller cycles than C# projects.
Sure, but maybe the reason is the people that choose to use F# and Caml like languages are a bit smarter that the regular coder. Or maybe F# projects have a different nature and people don't write "enterprise applications" in F#.
Sure, but maybe the reason is the people that choose to use F# and Caml like languages are a bit smarter that the regular coder. Or maybe F# projects have a different nature and people don't write "enterprise applications" in F#.
Whilst it is true that the absolute number of possible wrong programs grows as the number of features increases, I don't think that it implies that the proportion of wrong programs actually coded by people grows as well.
I do not like this article at all. I rebutted it extensively at https://lobste.rs/s/ipml3l/less_is_more_language_features/co....
I don't understand the point in removing cyclic references, coming from FORTH, Lisp, Smalltalk point of view those are required, if you split a big recursion into smaller factors. The recursion automatically becomes a cyclic reference between words, functions, methods or even classes, as classes are just closures.
Does he want to forbid factoring? His feature looks more like a deficit of the linker to me.
Does he want to forbid factoring? His feature looks more like a deficit of the linker to me.
I think Erlang hit everything?
Not sure about Cyclic dependencies and I don't think it have Reflection unless I'm wrong.
Not sure about Cyclic dependencies and I don't think it have Reflection unless I'm wrong.
If you install nightly builds on a production system you deserve to get bitten.
The paper gives laziness as an example. It’s made possible by idempotency. Which is made possible by the removal (or careful management) of side-effects. Which then allows certain otherwise impossible ways to express infinite data structures.
http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html