Hacker News Reader

Comment by breck | Hacker News Reader

> Fuzzing instead of traditional types. In Candy, functions have to specify their needs exactly. As you type, the tooling automatically tests your code with many inputs to see if one breaks the code

This is a neat idea and the screenshots make it look fun. There are a few features that once you've gotten used to, become hard to live without (syntax highlighting, autocomplete, unit tests, etc). I could see how this real-time fuzzing approach might be one of those. Would be fun to try.

View on HN

I don't see how this is different from any other dynamically- and strongly- typed programming language with some kind of "contract" framework, like Clojure or Python.

Fewer types:

  Values are at the center of your computations. Only a handful of predefined types of values exist:

  3                   # int
  "Candy"             # text
  Green               # symbol (uppercase)
  (Foo, Bar)          # list
  [Name: "Candy"]     # struct
  { it -> add it 2 }  # function

Not having a Hash/Dict type is very oldschool lisp-y.

I assume a struct is a Hash/Dict type. Since you have no type checking all fields can be considered dynamic.

Exactly, structs are also used as maps/dictionaries, and the current implementation of them in our VM is as hash maps. (We have optimizations planned for this.) You'd create a struct with tags (symbols) as keys to create a typical struct/class, and can use arbitrary keys if you want to use it as a more general map:

  # A struct with two tags as keys mapping to functions
  httpServerStruct = [GetNextRequest: { … }, Close: { … }]
  
  # A map with text keys
  capitalCitiesMap = ["Germany": "Berlin", "France": "Paris"]

Even ancient Lisp was not without hash/dict processing. It was disguised in the interning of symbols, and symbol property lists.

If structs are just tables by another name, this sounds a lot like Lua to me. Not that there's anything wrong with Candy here, but I don't know that it's much of a departure from what we already have.

The real-time, nicely designed view of it as shown in the screenshots looks interesting.

What contract framework would you recommend in Python?

I've been dissatisfied with all of them actually!

But both Deal (https://pypi.org/project/deal/) and icontract (https://pypi.org/project/icontract/) have merit.

I can't remember where I saw it, but the author of deal seemed a bit annoyed at the existence of icontract, maybe on a mailing list.

I've played around with CrossHair (https://pypi.org/project/crosshair-tool/) as well a bit, and that supports both deal and icontract.

icontract also seems to integrate with hypothesis (https://pypi.org/project/hypothesis/) , which deal does not do explicitly.

deal actually has a far better integration with hypothesis as its testing strategies are built on that library! https://deal.readthedocs.io/details/tests.html#mixing-with-h...

Thanks a lot!

> I've been dissatisfied with all of them actually!

What are some of your dissatisfaction points? Do you know of better alternatives in other languages ?

Reply on news.ycombinator.com