3 ms·
> Fuzzing instead of traditional types. In Candy, functions have to specify their needs exactly. As you type, the tooling automatically tests your code with man
by breck 3y ago
> 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.
- nerdponx 3y agoI 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.
- sdeframond 3y agoWhat contract framework would you recommend in Python?
- nerdponx 3y agoI've been dissatisfied with all of them actually! But both Deal (https://pypi.org/project/deal/ https://pypi.org/project/deal/) and icontract (https://pypi.org/project/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/ 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/ https://pypi.org/project/hypothesis/) , which deal does not do explicitly.
- sdeframond 3y agoThanks 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 ?
- growthwtf 3y agodeal 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-hypothesis https://deal.readthedocs.io/details/tests.html#mixing-with-h...
- breck 3y agoThe real-time, nicely designed view of it as shown in the screenshots looks interesting.
- karmakaze 3y agoFewer 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.
- nerdponx 3y agoIf 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.
- rowanG077 3y agoI assume a struct is a Hash/Dict type. Since you have no type checking all fields can be considered dynamic.
- JonasWanke 3y agoExactly, 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"]
- kazinator 3y agoEven ancient Lisp was not without hash/dict processing. It was disguised in the interning of symbols, and symbol property lists.