To me this raises the question of whether this is a growing trend, or whether it's simply that languages staying closed source tends to be a death sentence for them in the long term.
I've never been a [traditional] artist, but I reckon that those working in the arts, and even areas of the programming world where experimentation is more fundamental (indie game development, perhaps?), would intuit the importance of discovery coding.
Even when you're writing code for hairy business problems with huge numbers of constraints and edge cases, it's entirely possible to support programmers that prefer discovery coding. The key is fast iteration loops. The ability to run the entire application, and all of its dependencies, locally on your own machine. In my opinion, that's the biggest line in the sand. Once your program has to be deployed to a testing environment in order to be tested, it becomes an order of magnitude harder to use a debugger, or intercept network traffic, or inspect profilers, or do test driven development. It's like sketching someone with a pencil and eraser, but there are 5-10 second delays between when you remove your pencil and when the line appears.
Unfortunately, it seems like many big tech companies, even that would seem to use very modern development tooling otherwise, still tend to make local development a second class citizen. And so, discovery coders are second class citizens as well.
Yea, TIL, I'm a discovery coder. Always found planning early in Greenfield projects kind a pointless. Planning is almost step 3 or 4. I almost always prototype the most difficult/opaque parts, build operations around testing and revising (how do you something is good enough?), and then plan out the rest.
Hard agree on local development. I always make apps run locally and include a readme that describes all the steps for someone else to run it locally as well.
Ideally that should be as simple as adding a local app settings file (described in readme so people don't have to start reading the code to figure out what to put in it) for secrets and other local stuff (make sure the app isn't trying to send emails locally etc), and running Docker compose up. If there are significantly more steps than that there better be good reasons for them.
I had a similar idea a few months ago about whether it's possible to achieve some form of comptime with TypeScript. I didn't get too far unfortunately, but I think the implementation would need to interact with the TypeScript compiler API in some way.
Going off of the example on the home page, the language reminds me a lot of Alloy, a model checking language. Alloy lets you describe facts about some discrete system and check for the existence (or nonexistence) of properties within those systems. If you expect some property to hold and it doesn't, Alloy will automatically produce a counter-example for you. Here's an example of a program modeling a file system:
sig FSObject { parent: lone Dir }
sig Dir extends FSObject { contents: set FSObject }
sig File extends FSObject { }
// A directory is the parent of its contents
fact { all d: Dir, o: d.contents | o.parent = d }
// All file system objects are either files or directories
fact { File + Dir = FSObject }
// There exists a root
one sig Root extends Dir { } { no parent }
// File system is connected
fact { FSObject in Root.*contents }
// Every fs object is in at most one directory
assert oneLocation { all o: FSObject | lone d: Dir | o in d.contents }
I initially thought these model checking languages were purely academic in nature. But then a curious problem came up when I was working at AWS where folks were complaining that IAM policies generated by our library were sometimes growing to be too large in size (usually the limit was a few KB) - often due to redundant statements.
To solve this, a coworker implemented some code for merging IAM policies -- though the merging processe wasn't trivial because IAM policies can have both "Resources" and "NotResources", "Actions" and "NotActions", "Principals" and "NotPrincipals" etc. So to prove the algorithm was correct, he wrote up a short Alloy specification[1] (roughly mapping to the library code) that proved if two policy statements were merged, it wouldn't change the security posture. As a new engineer to the team, I'll just say that it blew my mind that this was possible -- actually using proofs to achieve goals in industry.
Needless to say, I'm curious to dive into Quint's differences and what kinds of models/specifications it excels with.
(a.resource in b.resource and a.action in b.action and a.principal in b.principal) or
You can write
{
a.resource in b.resource
a.action in b.action
a.principle in b.principle
} or // ...
(Also instead of `(some principal) iff not (some notPrincipal)` you can write `some principle <=> no notPrinciple`. Alloy has a lot of cool syntactic sugar!)
Yes, but the implementation is very different. These model checkers aren't turing complete, and because of that they can give some strong guarantees about what they can and cannot do.
Prolog? Shift some things around and watch your program suddenly run forever or so slowly as to be useless.
If you want to mess around with something very prolog like but using similar kinds of underlying tech to these model checkers, try playing around with ASP solvers like Clingo/Clasp or DLV
Totally fair. The choice to name it "bring" instead of "import" or "use" was mainly to add some flavor to the language, and make it easier to distinguish from the top of the file that "ah, this is a Wing code snippet, not a Zig/TypeScript/Python code snippet".
I was curious if the words could be used to form any sentences -- here's the corpus organized by part-of-speech. (Many words are missing due to gaps in the corpus I used):
How did they end up out of alphabetical order? It might be worth alphabetizing and collecting singular+plural into single entries; s and es are available, so you can pluralize most nouns (or singularize most verbs). The list has some pairs but not all, for no particular reason.
I’d suggest dropping the capitalization too, it adds duplicates, and can often be used in both senses, e.g., bill, bell, hill, hiss…
Also note there are plenty of nouns here that can be used as verbs and verbs than can be used as nouns.
Now a bonus round: Can anybody possibly do a long work of fiction only using calculator words? Just this post was difficult after losing just a unitary sound!
"Great, thanks for providing the words. Here’s a paragraph and a long sentence using only the words from your list."
Paragraph:
Ellie and Gil see high hills and lush soils as they sell eggs. Bessie, Lizzie, and Billie giggle at the blissful scene, while Bob, with his big bellies, sees sole lilies by the lake. Hobbes and Zoe bless the giggles and sighs from the hill. Ellie, high on glee, sees Leslie and Ellie loose on the hill.
Long Sentence:
Ellie, Gil, and Bobbie, with their big, glib egos, hobble to the hill, see high geese and geese solos, sell blissful lilies and lilies, see his giggles and giggles, sees solos, sees shell solos, sell loose, high eggshells, sell soles, sell high heels, lose high heels, lose loose lilies, and see highs, high on high hills.
Numeric Equivalent:
Ellie (371173), Gil (617), and Bobbie (860778), with their big (618), glib (6178), egos (3760), hobble (4607713) to the hill (411), see (335) high (4614) geese (63335) and geese (63335) solos (50505), sell (7735) blissful (817557981) lilies (511173) and lilies (511173), see (335) his (517) giggles (61977619) and giggles (61977619), sees (3355) solos (50505), sees (3355) shell (53477) solos (50505), sell (7735) loose (53350), high (4614) eggshells (355435517), sell (7735) soles (50535), sell (7735) high (4614) heels (43735), lose (3505) high (4614) heels (43735), lose (3505) loose (53350) lilies (511173), and see (335) highs (46145), high (4614) on high (4614) hills (4115).
Also, fun note: ChatGPT will go into Mr. Burns mode if you emote Simpsons...
This is blatant conservatism, and it's a mentality which leads to dead players. The job of an executive is to make good decisions; it's in the name: execut-ive. To decide always in the direction of the existent culture is a very peculiar bias which is only successful in certain situations.
To me this raises the question of whether this is a growing trend, or whether it's simply that languages staying closed source tends to be a death sentence for them in the long term.