Hacker News new | comments | ask | show | jobs | submit login
Example-Driven Development (wilfred.me.uk)
157 points by jsnell on July 30, 2016 | hide | past | web | favorite | 38 comments



There's also Magic Haskeller [0], which generates potential Haskell functions from predicates. It's surprisingly good.

[0]: http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht...


The difference in sophistication between supplying individual individual examples and supplying predicates is like that between unit testing and property-based testing. One method is brutish, being invented by and for the abstraction-challenged; the other at least tries to investigate general properties of the desired solution.


I do agree with you, though I'd suggest being nicer about it if not in general then at least outside of preaching to the choir.


This is, overall, a huge issue with much of the Haskell and pure functional programming community that puts people off - there's a minority of people who view what the vast, vast majority of the world's programmers do as beneath them, and the programmers in question as stupid. The community doesn't appear to do enough to weed these people out.


I think there's a mistake in imagining that there is a Haskell community or a pure functional programming community and that people you come across represent these communities.

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.


The thing is, people gravitate to languages where they can learn about the language and its ecosystem from people they can get along with. Many people avoid confrontation - especially when they're trying to learn about something.

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.


> 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

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.


(0) I don't even like Haskell that much: https://news.ycombinator.com/item?id=12177685

(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.


It was in response to a link to a Haskell library, so I assumed that you had some experience with said library.

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.


> It was in response to a link to a Haskell library, so I assumed that you had some experience with said library.

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.


> You don't usually find people who enjoy programming primarily in Rust or C++ or even F# looking down on others [...]

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.)


I know your name from many constructive and enlightening comments you've posted on HN. Clearly you're frustrated by something at the moment but please don't let it seep into the public sphere and diminish the high quality of your comments.


Hoogle[1] is also a pretty awesome example of this. It doesn't track the values themselves, but in Haskell there are usually only so many (sensible) functions for a given type which mitigates it a bit.

[1]: https://www.haskell.org/hoogle/


Parametricity actually cuts the number of possible functions at a given type much more effectively than any small number of examples: http://cstheory.stackexchange.com/questions/19548/how-can-re...


It's been posted before, but anyway: Flashfill from excel sdk: https://microsoft.github.io/prose/documentation/flashfill/us...

Keyword: program synthesis


This is pretty neat. I've definitely spent hours scribbling examples on a sheet of paper trying to come up with the correct math to go from my desired input to output for one or a few examples of input/output. Two drawbacks to this kind of solution, that I can think of: (1) the examples I'm thinking of are pretty complicated and I can't imagine this could solve them for me, and (2) playing with numbers on a sheet of paper is kind of fun, and jumping straight to the answer would remove that bit of fun from my life.


I watched the video of a Pharo demo linked in the article and it was amazing. I don't know how much of that capability comes from the way Smalltalk is built vs just a clever IDE feature.

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.


It feels strange saying this but finding a function from a set of inputs and a set of outputs is what machine learning is all about.


Not all function spaces are equally easy to search. If you're looking for a continuous, possibly even monotonic, real map that approximates a given data set, fine, just perform a regression. If you want to attach one of finitely many tags to every element of a data set, fine, just use a clustering algorithm or perform a correspondence analysis. But, can you find higher-order functions using these techniques? Or can you find arbitrary computable functions on the integers using these techniques? Note that the integers don't have a very good notion of “sufficiently near”, unlike the reals.


> Note that the integers don't have a very good notion of “sufficiently near”, unlike the reals.

You could use the p-adic norm. But that will probably not be the right notion for most applications.


My bad, I misunderstood the intent behind this project (and I mixed it up in my mind with Barliman, elsewhere on HN at the time).

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.


If you like this you should look at the demos for Pharo. It takes this concept to another level. Very cool project.


This seems to me like a less-formal (and consequently less powerful) implementation of type completion in dependent-type systems and theorem provers such as Agda or Coq.


I believe you are correct. The advantage, on the other hand, is that you don't have to first acquire a PhD in mathematics and then learn Coq/Agda. Seriously though, simpler interfaces can add a lot of value, but only if the increase in ease of use makes up for the decrease in expressiveness.


You don't need a PhD to use dependent types. I don't have a Bachelor's.


Oh cool!

  ;; Inputs (one per line):
  '(a b c d)

  ;; Desired output:
  '(1 2 3 4)

  ;; Suggestions:
  ;; No matches found.
Damn :(


On further inspection it seems severely limited:

  ;; Inputs (one per line):
  '(a b c d)
  
  ;; Desired output:
  '(a b)

  ;; Suggestions:
  ;; No matches found.


Interesting that this fails, since removing one element was an example they considered. Maybe they should include the length of the lists as "magic numbers" which they then use to generate functions. For example, here they might generate the functions take_the_first_2 and remove_the_last_(4-2) as candidates.


The example they considered was removing the first element of the list, while that example is removing the last element.

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.)


Perhaps this suggest thing could do with some kind of a genetic algorithm searching for new functions that seem to do the right thing..


Would you actually want to use software written like this? You submit a bug report or feature request, and the maintainer tells you: “Okay, let's see whether my AI can make sense of it...”


> “Okay, let's see whether my AI can make sense of it...”

"I'll pass your feedback on to the devs" by any other name would sound as sweet.


Connecting something like this to github and other large public repos would be fun.

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.


> “Hey $COLLEAGUE, is there any function that takes this list and returns a list like this?”

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.


Apple's Playground is another alternative

https://developer.apple.com/swift/playgrounds/


I've never had a problem tracking down the function or language construct I need with Google.


What if we combine this with AI?


I'm working on that! Long story short, it's hard. Most functions are big ones, and knowing where to look in the infinite set of functions is a big challenge. But it's a super fun problem :-)




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

Search: