Example-Driven Development
wilfred.me.uk
wilfred.me.uk
Keyword: program synthesis
[0]: http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht...
(1) My original post is just a statement of fact about how abstraction skills shape one's testing strategies. Suggesting that this has anything to do with functional programming is a total non-sequitur.
In any case, the issue is less with pure functional languages themselves, and much more with some of the people who use some of the more popular ones. You don't usually find people who enjoy programming primarily in Rust or C++ or even F# looking down on others and telling people who might potentially be interested in learning more about some feature or other that they'd be too stupid to understand, at least not to the same degree.
When people try to explain Rust's lifetime system, they don't start off by telling people that garbage collectors are for people too stupid to define data structures which manage memory properly. When they talk about static typing, they don't tell people that they're idiots if they enjoy Python's duck typing. Instead, they lay out problems that their solutions solve. Simple as that.
It's not terribly difficult to talk about ideas in a positive manner without tearing apart people who hold other ideas, either through ignorance or simply different experiences, most of the time.
Nope, I don't. I don't even use or like Haskell, though I happen to know it relatively well.
> In any case, the issue is less with pure functional languages themselves, and much more with some of the people who use some of the more popular ones.
I'd have no idea, since I evaluate technologies solely on the basis of their technical merits. In any case, in response to your earlier “weeding out” comment, I'm not really a member of any particular community to begin with, so it would be difficult (“only somewhat impossible”) to “weed me out” of anywhere.
> Instead, they lay out problems that their solutions solve. Simple as that.
The problem (yes, singular) solved by Rust's lifetime system admits a clear, concise, one-sentence even, description, which, as a matter of fact, is about half as long as this sentence. The benefits are immediately clear to anyone who has had to program defensively to mitigate that very same problem.
> It's not terribly difficult to talk about ideas in a positive manner without tearing apart people who hold other ideas,
Yes, but I deliberately chose not to. I'm expressing frustration because on a daily basis I have to fix code written by people who don't have the analytical skills necessary to determine what their code does in the general case. I see example-oriented programming as a very dangerous paradigm to adopt, since it would exacerbate the problems I already face.
Yes, though I think C++ might have gone through that phase when it was younger? (I am too young myself to say for sure, and wasn't really online in the much smaller communities back then nor working.)
Like, I'm a fan of the language, I do stuff with it, I worked with in professionally, I chose my school specifically to pursue it in 2005... sometimes I discuss topics related to it on the internet... but I don't really see myself as a "community member," I don't represent a community when I discuss, and the comments you're reacting to have nothing to do with me or my values.
So if stuff I say is taken as representing some "community", that's ascribing a false belonging and imagining a society where there's mostly just a loose association of different individual nerds who sometimes collaborate in different constellations.
Unless there's something systemically and blatantly wrong with some actual existing community project, I think it makes more sense to criticize individuals. There's no way to "weed out" people from the internet just because their tone is annoying.
If you don't get along with dudebros, you're going to avoid languages where the IRC channels and forums and random online discussion about the language is populated by dudebros - if you don't get along with people who speak aggressively, you're going to avoid languages which you see people speaking aggressively in support of - if you're really not a fan of active community management a la codes of conduct, you're going to avoid languages where their users speak in favour of such things.
Rinse and repeat a bunch of cycles, and whether there's a formal community or not, there's a type of person who permeates discussion of the language and its ecosystem, and is generally accepted by users of the language. Attempting to avoid them is difficult, because the existing language users see no problem, so you're stuck with a very limited number of places to learn, interact, and ask questions without coming across them.
I don't think the people in question represent the community as a whole, but they do represent what I'm signing up for when I need to communicate about the language with others - in Haskell's case, there's a higher chance than with most languages that I'm going to come across people who will proclaim I'm stupid if I don't immediately and from birth know why XYZ abstraction is amazing and universally good. And god forbid I disagree.
It's terribly sad if this is true because it wasn't the case before. Haskellers used to be very welcoming and very tolerant of beginners struggling with the language, because we had all been through the same struggles ourselves. I hope I'm correct when I say that the two public Haskell fora that I participate in (Haskell Reddit and haskell-cafe) would never proclaim anyone as stupid.
I imagine this would be much easier to implement in a language with strong typing since the vast majority of possible matches could be ruled out with a simple signature check instead of evaluation.
Having a feature like this would be very useful when teaching people how to program since it would help answer a lot of the basic questions that get asked.
You could use the p-adic norm. But that will probably not be the right notion for most applications.
This searches through a list of predefined (built-in?) functions and finds one that can match the given inputs and outputs. That sounds pretty cool and rather handy and although it's a form of machine learning (or function approximation in any case) it's not trying to sell itself off as anything it isn't, which was my initial concern. My bad for overreacting.
;; Inputs (one per line):
'(a b c d)
;; Desired output:
'(1 2 3 4)
;; Suggestions:
;; No matches found.
;; Inputs (one per line):
'(a b c d)
;; Desired output:
'(a b)
;; Suggestions:
;; No matches found.In terms of computational cost, this makes sense: removing the last element of a list in lisp takes linear time with the size of the list, while removing the first element takes constant time. (If you're returning a copy this is moot, but if you're modifying in-place this could be a problem.)
"I'll pass your feedback on to the devs" by any other name would sound as sweet.
Similarly for pseudocode rather than only ins/outs.
Maybe code analysis for similar implementations to (or optimizations of) what you're in the middle of developing.
Have long wondered about this, but never got around to dinking with it at all. Cool to see things along these lines.
Go back to your cubicle, grab a piece of paper, clarify your thoughts, describe what you want in the general case, provide at least 3 examples, possibly more of there are lots of tricky corner cases. And only then come back. Thanks.