> # Optimized for AI & Autocomplete
> ```
> f a b
> . f = | x -> y -> x \* y
> . a = 1
> . b = 2
> ```
> Scrapscript encourages wishful thinking[0].
>
> Declare your goal up-front, and let your tooling make educated guesses about how to get there.
I feel like I took crazy pills. Or maybe this is what having a stroke feels like.
For this specific example, many languages have constructs like this:
let x = 1 in f x
f x . x = 1
For AI/autocomplete, tools like Github Copilot currently have to guess what you want from all the parts (e.g. variable names) you put on the table. By putting the variables last, the editor tooling can create boilerplate for your variables as you type.
Let me know if there's anything else that might need extra explanation!
> . f = | x -> y -> x \* y
Scrapscript:
| x -> y -> x * y
x => y => x * y
| true -> true -> 2
| true -> false -> 1
| false -> true -> 1
| false -> false -> 0With regards to AI, I think focusing on the fancy auto-complete isn't really a great idea. This seems designed around AI as it is now, not where it will be. But, I see your point, especially where your approach solves other issues. I think the page would be better served if you mentioned AI/auto-complete more as a side-effect than intent.
---
A small nit before I dive into my main point: the page is a pain to copy and paste from. Things like title capitalization should not be lost when doing so.
---
My biggest issue with this page is that it says it solves several issues but handwaves critical details and doesn't demonstrate the value proposition of scrapscript when claiming to solve them. You make a very big claim at the beginning that you are solving all of these problems:
> APIs diverge, packages crumble, configs ossify, serialization corrupts, git tangles, dependencies break, documentation dies, vulnerabilities surface, etc.
but the page is very lacking in the details of what parts of those problems scrapscript are solving (many of these have multiple vectors), and in places where it does, it often leaves out critical details, uses very simplistic examples that feel trivially solvable in many languages, or provides only example code that is difficult for newcomers to relate to its section.
For instance, I assume the APIs diverge claim is addressed under the section `Typecheck Across Network Bounds`:
> The scrapscript compiler tells you when remote APIs differ from the code. And if the API changes while the code is running, scrapscript offers a series of graceful handling options.
What are these graceful handling options? (Separately, is the compiler reaching out to these scrapyards every time it runs?)
I'm also not convinced some of these problems are solved. For example, documentation dies. I am guessing this is addressed by the `Self-Documenting Typed Configs` section. From that, I'm guessing the documentation referenced is auto-generated. But, the most important part of documentation is intent, which is usually not captured by code. In your example:
my-org:my-config
{ name = "my-server-001"
, cpus = :4
, mem = :16
}
. my-org = : my-config
{ name = text
, cpus = : 1 : 2 : 4 : 8
, mem = : 1 : 2 : 4 : 8 : 16 : 32
}
Overall, I think you should be very explicit about which presented issue each section of document is addressing. More details about how they are being solved need to be shared. And better examples should be used to demonstrate why scrapscript is the superior choice to solving these issues rather than other languages and their libraries.
All in all, there's a lot of cool stuff in here, and I bet this is just a result of you not having the time to spend on this page. But right now, this page comes across as a lot of empty marketing (and there are a lot of buzzwords).
I do have other, language-specific concerns (e.g. time != versioning, scrapscript assurances that all programs are safe to send around, `echo "'err red'"`), but I don't feel like there's enough information on this page for me to intelligently raise them.
Good luck!
My best friend gave me much of the same advice before I published the page, but I became too impatient.
I've bookmarked your comment, and will make sure to include deeper explanations in the near future
Thank you :)
f a b where
f = \x -> \y -> x * y -- or f = (*)
a = 1
b = 2Nope; anyone who has some basic programming knowledge and perhaps a high level understanding about how different programming languages work. And the ability to connect some dots together. I'm old enough to have learned BASIC programming on an Apple II and took Pascal in college, which is the extent of my formal programming training.
> “it’s JSON with types and functions and hashed references”
Another way to say this: it's executable YAML, which is a strict superset of JSON [1]. I like YAML, so that's what came to mind when looking at ScrapScript code. I also like clean, minimal syntax when I can get it, like YAML, CoffeeScript or Haml.
> “it’s a language with a weird IPFS thing”
I’ve been playing with IPFS [2] since its early days in 2015, though not much recently, though this will probably get me back into it. Content addressing solves a lot of problems that I won’t get into here but it’s certainly not that hard to grasp. IPFS is available for pretty much every browser these days and is integrated into the Brave browser [3].
> all programs are data
This concept has been around since the creation of Lisp in the 1950's. This enables all kinds of cool features the computer science types get excited about. I've known about this concept since the 80's when I used to teach kids Logo (which is a Lisp). The term used nowadays is homoiconicity [4] but that term wasn't in widespread use until fairly recently.
Bottom line: ScrapScript sounds very interesting and I'm looking forward to checking it out.
[1]: https://yaml.org/spec/1.2.2/#12-yaml-history
[2]: https://ipfs.tech