[HN Gopher] Show HN: ScrapScript - A tiny functional language fo...
___________________________________________________________________
Show HN: ScrapScript - A tiny functional language for sharable
software
Hi friends, I started casually working on scrapscript in 2015. I
built a few compilers over the years to test out various
ideas/implementations, and I think I'm finally happy with the
overall design. The code is not public yet. Email me at
hello@taylor.town if you're interested in joining the core team
later this year. Let me know if you have any questions or feedback
:)
Author : surprisetalk
Score : 389 points
Date : 2023-04-26 11:45 UTC (2 days ago)
(HTM) web link (scrapscript.org)
(TXT) w3m dump (scrapscript.org)
| chrismorgan wrote:
| In your styles:
|
| > _pre { overflow-x: scroll; }_
|
| `overflow: scroll` is very poorly named, and practically never
| the right tool. You want `overflow: auto` instead, which only
| renders scrollbars if they're needed.
|
| (Long ago, there were two potentially valid scenarios for it: for
| avoiding reflow when changing the document's length, and for
| unbreaking viewport units so that 100vw includes the viewport's
| vertical scrollbar. The former was only exceedingly rarely
| useful, and can be achieved better now on all but Safari with the
| _scrollbar-gutter_ property. The latter only Firefox ever
| implemented, and no one else wanted to, so they eventually
| removed it from the spec and from Firefox, so now viewport units
| are just stupidly broken by design. I myself have not found a
| single place I wanted to use `overflow: scroll` or where it would
| have been reasonable in the past decade. Stylesheet linters
| should include a default rule that complains about `overflow:
| scroll` because it's so temptingly-named but so thoroughly not
| what you want.)
| layer8 wrote:
| It's the right tool when you prefer scrollbars to always be
| rendered, which is a valid preference. For example, in the "not
| needed" case, the scrollbar being rendered tells you at a
| glance that there's no scrollable content with a hidden "only
| appears upon movement" scrollbar, an information which would
| otherwise be missing.
| chrismorgan wrote:
| I'm completely confused by what you write, because it seems
| back-to-front. You seem to be speaking of platforms with
| overlay scrollbars that are invisible until you try
| scrolling; how does `overflow: scroll` behave differently
| from `overflow: auto` on such platforms? I would expect it to
| either be no different, or possibly to briefly show a
| _completely misleading_ scrollbar briefly when the content
| appears. I think I must be missing something. Can you explain
| more what you mean?
| [deleted]
| al2o3cr wrote:
| Since each function is independently versioned, how does
| ScrapScript deal with functions that need to upgrade together?
|
| For instance, suppose "foo" produces a structure and "bar"
| consumes it - what happens if the user passes the output of "foo
| version 10" to "bar version 1"?
| dllthomas wrote:
| If you have any measure of success, you are 100% going to wind up
| with a thing in your ecosystem called "scrappy do"
| andybak wrote:
| It's late and I'm tired but this is one of the most interesting
| things I've seen in a while.
| mftb wrote:
| Surprised, none of the more functionally minded have jumped in.
| Looks interesting, I'll be taking a look, when it ships.
| dangoodmanUT wrote:
| Super cool!!
| thomasfromcdnjs wrote:
| This looks like a fun thing!
|
| It makes me feel like some hacker dweebs in the future would be
| communicating through this platform.
| azubinski wrote:
| This is perhaps too bright for the gloom of recent months here.
|
| Thanks to the author, this is a very exciting thing.
|
| Of course, ligatures without the "disable ligature under a
| cursor" extension are slightly weird, but it even adds charm,
| we're on a site "for hackers" (laughing).
|
| So, well, what kind of a ChatGPT can come up with something like
| that? :)
| sagebird wrote:
| This is lovely. I've had a vague notion that I wanted something
| like this... but never quite solidified my understanding of what
| is necessary. This is a super minimal-maximal example. Bravo.
|
| Do equivalent programs produce the same hash?
|
| Ie: a = 1 + 1 Return a
|
| Vs
|
| a = 2 Return a
|
| What if local internal variable names change?
|
| Ie
|
| b = 2 Return b
| xigoi wrote:
| Due to the halting problem, it's not possible to tell in
| general if two programs are equivalent.
| sagebird wrote:
| Thinking a bit more:
|
| A-If a program is a thing that produces a result for a given
| input, these programs are the same.
|
| B-You can't generally know if two programs are the same without
| solving halting problems, reducing polynomial algos to linear
| time or having infinite time and space computing resources,
| etc.
|
| C-The best you can do is ask if two compilers produce the same
| output, or a linting/refactoring/canonicalization/formatting
| operation results in same source.
|
| D-If a program is a thing that interactive debuggers use to
| create explorations next to source code while computing, these
| programs are different.
|
| I agree with your approach of starting with these programs as
| being different, and allowing custom scraps to become a higher
| layer hash resolver. The reason is that compilers change over
| time, and it is only under the lens of a compiler(or linter,
| etc) that comparisons can be made. To bake a holy compiler in
| today would be arbitrary and quickly outdated.
| surprisetalk wrote:
| This is one great question I've wrestled with over the years.
|
| Right now, all three programs would result in a different hash.
| I decided that the scrapyard publication process should do as
| little "magic" as possible.
|
| As the tooling evolves, we can provide a canonicalizer scrap
| that renames variables and simplifies the code. I think
| eventually we would make this the default process to encourage
| more reuse.
| alephaleph wrote:
| You might want to look into the way Unison does things: [1],
| they've got a lot of similar ideas and IIRC the way their
| hash system works avoids that ambiguity.
|
| [1]: https://www.unison-lang.org/learn/the-big-idea/
| surprisetalk wrote:
| Wow, that's a great guide!
|
| I didn't read it in-depth yet, but I think I had a previous
| implementation that worked very similarly to theirs.
|
| The problem with variable names is that they actually
| matter for some of the collaborative editor features I hope
| to implement in the future. There are certain assumptions I
| can't make quite yet, and so am keeping my options open :)
| pcl wrote:
| Have you thought about using type aliases or higher order
| types of some sort for that instead of relying on the
| variable name?
|
| I could define that a familyname and a givenname are
| strings, and then a function argument of type familyname
| would be differentiated from a function argument of type
| givenname, but still the argument names themselves could
| be dropped from the hash.
| thrrwy007 wrote:
| everyone says this is cool, but I didn't understand it at all, so
| embarrassing :(( please eli5, honestly, want to understand this,
| what is this and how is it useful?
| zubairq wrote:
| Author of a framework that also stores it's code in IPFS for easy
| sharing (https://github.com/yazz/yazz). ScrapScript is a really
| nice concept with how it stores code. I originally got the idea
| for storing the code as a hash of the contents from Unison, and
| it looks like the idea is really starting to catch on with more
| and more languages now. Well done!
| verdverm wrote:
| Would the IPFS-ness of this make updating all the programs that
| suffer from an exploit or error a difficult thing? Kind of like
| smart contracts, once it is published, there is no changing it?
| So the chain of dependencies containing the exploit or error,
| make updating all of the consumers a pain.
| surprisetalk wrote:
| This is a great observation.
|
| By default, using a name like `janedoe91/fibonacci` pulls the
| latest version of that particular scrap from the scrapyard. But
| all of its references are baked-in unless the author updates
| them.
|
| The way around this is that consumers are empowered to use
| whatever forcing upgrade strategies they want. All scraps are
| transparent, so you can pipe everything through an "upgrader"
| scrap before execution, which replaces dependencies all the way
| down the stack with their latest versions. I'm sure many of
| these upgraders will exist depending on what types of tradeoffs
| you're looking for.
| verdverm wrote:
| Can scraps be versioned? Is it possible to see the available
| versions of a scrap? Could you add support for dependency
| management?
|
| MVS is a nice and easy algo: https://research.swtch.com/vgo-
| mvs
| surprisetalk wrote:
| Yes, scraps can be versioned: user/my-
| scrap@99
|
| And you can check the available versions of the scrap by
| querying the scrapyard directly. But omitting the version
| will just use the latest: user/my-scrap
|
| Each scrap contains a full list of its own dependencies, so
| there is no need for external dependency management.
|
| All scraps are transparent, so you can create your own
| tools to manually tweak/replace dependencies before
| execution: $ cat my-scrap.ss \ |
| scrap apply my-dependency-helper \ | scrap eval
| verdverm wrote:
| This fixer would have to walk the dependency tree. What
| if something breaks contract in the middle, something I
| do not control? That sounds like a huge burden on
| developers with lots of risk.
|
| Why opt out of proper dependency management?
| surprisetalk wrote:
| You can emulate traditional dependency management by
| pinning the versions of all your scraps, and updating
| them selectively: user/my-scrap@414
|
| _> This fixer would have to walk the dependency tree._
|
| Remember that the language itself works like a merkle
| tree and every scrap can be cached anywhere. To keep the
| language and tooling extremely simple, I think this works
| well enough.
|
| _> What if something breaks contract in the middle,
| something I do not control?_
|
| Everything is strongly typed, so there are certain
| guarantees about how things can break and update. You can
| easily make tooling that never makes breaking changes.
|
| People can always introduce implementation bugs into
| their code though, but that's inevitable even with
| dependency management.
|
| _> That sounds like a huge burden on developers with
| lots of risk._
|
| I will try my hardest to reduce that burden. I think I
| can put some sane defaults in the tooling surrounding the
| language to obviate the need for traditional dependency
| management.
| quickthrower2 wrote:
| One question. If you reference a package by hash. Is there
| semantic versioning? Can you get security updates?
| surprisetalk wrote:
| I'm currently planning non-semantic versioning (next versions
| just increment by 1), but I'm open to changing if I can figure
| out how to make semver efficient.
|
| I mention it here[1], but security updates can be performed by
| both authors and consumers.
|
| [1] https://news.ycombinator.com/item?id=35739161
| quickthrower2 wrote:
| I am not a super fan of semantic versioning (but it is "OK").
|
| What I like is you can flag "breaking" vs "enhancement" vs
| "no api change". And "no api change" is usually always what
| you get with a security patch.
|
| Really you only need 2 versions in semantic version (my
| opinion): breaking.non-braking
|
| "next versions just increment by 1" might be good where you
| have a non-breaking change, and that would allow security
| patches to flow down.
| eggy wrote:
| I like the unique hash thing like Unison, but it also has an
| Urbit/Nock/Hoon vibe aside from IPFS one you mentioned. I'll
| check it out tomorrow. Ilike the examples and syntax. Types -
| yay!
| carapace wrote:
| Neat!
|
| Maybe check out the Joy programming language? It seems well-
| suited to this domain.
| ivoras wrote:
| Neat but... Someone will make a crummier version of this in a
| language which doesn't feature parts looking like Unicode white
| noise and the original authors will be frustrated why the
| crummier vetsion took off and their project didn't.
|
| Not every idea deserves to have an esoteric language attached to
| it to work.
| fernmyth wrote:
| The funny Unicode symbols are actually ASCII `->` and `|>`
| rendered in a font with ligatures. I agree it's a bit jarring
| to see, but you wouldn't need a special keyboard.
| surprisetalk wrote:
| The font is Fira Code for anybody interested!
| beeburrt wrote:
| JetBrains Mono does that ligature `|>` in my Elixir code. I
| like it :)
| detrites wrote:
| This really should be mentioned on the page. My first
| impression was: "well, however cool this is, I will never use
| it because I can't just type it in any terminal without
| creating some stupid bespoke environment for it".
|
| EDIT: I just copied and pasted a code example into a text
| window and the raw typed text is exposed. Maybe something
| like a suggestion to do that could be included for anyone
| flummoxed by the symbols?
| andyferris wrote:
| Ohh... totally missed that!
| alwillis wrote:
| I've been using fonts with ligatures for esoteric languages
| like CSS and HTML for years. ;-)
|
| Seriously, fonts that coders tend to use have included
| ligatures for quite a few years. For me, it's less visual noise
| and a cleaner look.
|
| I use Vim/Neovim and WezTerm but there are many combinations of
| editors and terminal emulators that support ligatures.
|
| And many programmers fonts: https://github.com/ryanoasis/nerd-
| fonts
| runlaszlorun wrote:
| I've been working on a crummier version. So crummy it will
| likely never make it to a v0.1... :)
| unwind wrote:
| Yeah, the language and ideas are so cool they're nearly a
| whoosh for my old brain. But I will never understand why anyone
| would go out of their way to present a programming language
| while obscuring how you actually type it.
|
| I had to copy-paste the "weird-looking play-symbol" (|>) into a
| text editor to see if it really was what I thought it was [1],
| after noticing that selecting it with the mouse split it in
| half. That is highly distracting from the message, at least to
| me.
|
| [1]: It was.
| TeeMassive wrote:
| This is fantastic. I can't count the number of hours I've wasted
| hacking away broken CI pipelines to fix broken links, passing
| data around through environment variables sorcery, runners and
| artifacts wizardry.
| aktuel wrote:
| What a funny hoax.
| replwoacause wrote:
| What does this even mean?
| offlinehacker wrote:
| Reminds me of what unison already does, I just wonder what will
| be license and scope
|
| https://www.unison-lang.org/
| surprisetalk wrote:
| I'm still not sure about the exact license yet, but everything
| will definitely be free and open :)
| noduerme wrote:
| I'm trying to wrap my head around the "magic compression" bit. So
| literally _every_ namespace lives in a repo somewhere? And even
| files referenced are just automatically committed to that
| repository? What am I missing?
|
| Also how does this not create either an enormous tangle of
| circular references or a huge pile of unused... scrap?
| andyferris wrote:
| It's content addressed, so circular references can't naturally
| arise. You kind of need to create an ID of some sort and
| reference that and create some way of looking that up. I didn't
| check if they allow for recursive function calls, etc.
|
| The repository/scrap pile of content could be stored in lots of
| ways that you could choose. I imagine if everyone pushed
| directly to a global "scrap pile" like IPFS it would end up as
| a huge pile of unused scrap. Like unison, they'd need to
| provide some kind of default development environment, but
| anyone could build additional tooling (kind of like anyone
| could write a git clone).
| VTimofeenko wrote:
| Looks extremely fun. Coming from nix background, content
| addressability of stuff is a huge win. Looking forward to be able
| to play with this.
| nightowl_games wrote:
| I don't get it. Can someone use an example to demonstrate the
| value of this?
| surprisetalk wrote:
| Just think of it as more powerful JSON :)
|
| You can send things around without converting everything into
| strings and objects that don't quite fit your use-case. Plus
| you have the added benefit of strong typing AND the ability to
| send those types to other systems.
|
| Most of the other features exist to make it nicer to use as a
| full programming language.
| haolez wrote:
| Looks fun, but doesn't look like it will be open source. That's a
| shame, since it considerably raises the risk of adopting such a
| platform.
|
| EDIT: the author claims that it will be open sourced soon :)
| surprisetalk wrote:
| Author here! It will be open sourced soon, but I'm embarrassed
| about my messy code :)
|
| Email me at hello@taylor.town if you're interested in joining
| the team
| elbear wrote:
| What are you building it in?
| surprisetalk wrote:
| My latest iteration uses a bootstrapped compiler written in
| scrapscript :)
|
| The bootstrapper was written in Elm, because its parsing
| combinator library is by far the nicest to use.
|
| I wrote a rust bootstrapper in ~2019, but it was much too
| heavy for my experimentation phase. I think rust would be a
| good candidate going forward for the bootstrapper going
| forward though.
|
| I'm open to suggestions!
| crowdhailer wrote:
| What is the plan for 2024 and what are the goals for the core
| team right now. I would potentially be interested in joining.
| surprisetalk wrote:
| My next step is to release an airtight spec and roadmap to
| all the people that are interested in contributing. I'm
| receiving a ton of emails from devs who want to contribute
| but don't have experience in compilers, so I'd like to find
| a way to evolve the system in a way that works for
| everybody.
|
| I think first steps with the core team would be to source
| feedback on some of my design and architecture decisions.
| It'll be much easier to build everything if everybody
| shares the same vision and we're aware of all the
| tradeoffs.
| teaearlgraycold wrote:
| Fuck It Ship It
| quickthrower2 wrote:
| No one really checks out old commits though. And any employee
| who cares about anything open source being "bad" isn't worth
| working for.
| Bjartr wrote:
| A rule of thumb is that if you're not embarrassed when you
| launch, you've waited too long.
| amitlzkpa wrote:
| This is awesome. I had a shell of an idea like this that never
| got anywhere. Wasn't even sure if it were feasible. Really neat!
| quaintdev wrote:
| Not 100% sure but there is another project with similar ideas
| https://www.unison-lang.org/
| noman-land wrote:
| This is nuts and incredibly cool.
| snthpy wrote:
| I like the high level ideas and goals. I still have to get my
| head around the syntax and how it works in practice but will
| definitely keep an eye on this!
| robinsord wrote:
| Is this meant to be understood by geniuses or something? I'm
| halfway through reading about it and I still have absolutely no
| idea what any of this remotely means. Is the target audience for
| this genius hipsters who have 10,000 years of boilerplate context
| to even grok what the author is saying?
| alwillis wrote:
| > Is this meant to be understood by geniuses or something?
|
| Nope; 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
|
| [3]: https://brave.com/brave-integrates-ipfs/
|
| [4]: https://en.wikipedia.org/wiki/Homoiconicity
| jmholla wrote:
| I agree. This whole page reads like nonsense to me. One easy
| example to point out: > # 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.
|
| What does the title, example, and text have to do with each
| other? None of them seem to be talking about the same thing.
| What does AI have to do with this? How are these single
| character variable enable autocomplete? What does wishful
| thinking have to do with anything here?
|
| I feel like I took crazy pills. Or maybe this is what having a
| stroke feels like.
|
| [0]: https://wiki.c2.com/?WishfulThinking
| surprisetalk wrote:
| Yeah, I'm hoping to put out a more readable guide soon! I
| didn't have the time/energy to put much of the necessary
| explanations and groundwork in there.
|
| For this specific example, many languages have constructs
| like this: let x = 1 in f x
|
| Scrapscript flips things around: f x . x = 1
|
| I stole the phrase "wishful thinking" from the SICP lectures,
| where Sussman encourages writing the important parts first as
| if the details existed. I think this syntax encourages
| writing the big-picture ideas first.
|
| 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!
| robinsord wrote:
| [dead]
| tromp wrote:
| Haskell uses keyword "where" for that. So the example
| corresponds to the following Haskell code:
| f a b where f = \x -> \y -> x * y -- or
| f = (*) a = 1 b = 2
| jmholla wrote:
| This comment here cleared up a lot of things and I'm
| beginning to understand what you are doing here. Let me be
| upfront about one thing, I do not think I am your target
| audience. But, I am happy to provide some feedback as I
| procrastinate on other things.
|
| With 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 }
|
| Why am I setting these values in the config? Admittedly I
| know what they can be, but not why our how they are used.
| That, to me, is the documentation that is most important
| and I don't see how scrapscript solves that.
|
| 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!
| surprisetalk wrote:
| This is incredible feedback! Thank you for taking the
| time to write it out.
|
| 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 :)
| [deleted]
| jbritton wrote:
| > . f = | x -> y -> x \* y
|
| What do these symbols mean "|" "\\*"
| surprisetalk wrote:
| The `|` operator indicates that you're starting a
| function. And `*` is basic multiplication.
|
| Scrapscript: | x -> y -> x * y
|
| Javascript: x => y => x * y
|
| It also works as a pattern-matching statement.
| | true -> true -> 2 | true -> false -> 1 |
| false -> true -> 1 | false -> false -> 0
| alephaleph wrote:
| I'm pretty sure that this is demonstrating that you can (have
| to?) write your definitions after the main expression, then
| suggesting that this encourages a development style in which
| you first write what you want the main output to be, then
| later write implementations for everything. It then further
| suggests that this style can work well with intelligent
| tooling, presumably by having autocomplete automatically
| infer definitions for the types you used or by having AI
| write implementations.
| motohagiography wrote:
| This is significant. There's so much I want to add, but I will
| wait until I can implement the things I needed this for in the
| actual code.
| panphora wrote:
| So it's like a social network with every type of relationship
| imaginable built into a low level programming language?
|
| That's wildly cool.
|
| This and Val Town [0] feel like they were made for each other. If
| you added them together with a nice front-end like mmm.page [1] I
| bet a million devs would sign up.
|
| I'm working on something in a similar space that I'm hoping mihht
| develop into that [2]
|
| It makes sense that the next step for the web is a more low-level
| social platform that works more like an agnostic API than a
| walled garden.
|
| [0] https://www.val.town/
|
| [1] https://build.mmm.page/
|
| [2] https://hyperspace.so/
| surprisetalk wrote:
| Wow, you totally get my vision!
|
| This is pretty much my plan for the next few years, with some
| added surprises :)
|
| I really want to rekindle the days of geocities and flash. I
| call this "the cheap web" haha
|
| I've also been working on open standards for authentication and
| payments within the ecosystem, but I'm not quite happy with the
| results yet. I don't like this world where we have to use
| companies like Auth0 and Stripe to build something worthwhile.
| I'm open to ideas!
| ilaksh wrote:
| Use some type of cryptocurrency for payments, or maybe a
| unified interface to different cryptocurrencies.
|
| Or maybe you can come up with something similar to a
| cryptocurrency that integrates with your data structure and
| has core things like digital signatures for secure
| transactions and public distributed ledger(s). It seems like
| there could be a way to adapt some underlying features of
| ScrapScript for this stuff. Maybe as part of the "lab" thing.
|
| Just don't call it a cryptocurrency. Lol.
| CodexArcana wrote:
| You should look into https://small-tech.org/. I don't know if
| they're still active (I discovered them a few months ago, and
| they seemed active.) But they definitely have a similar point
| of view.
| dangoodmanUT wrote:
| Thank you I've been trying to find the build.mmm.page link
| again for a year but I couldn't remember the name of the site
| XD
| mstade wrote:
| The signal to noise ratio in your comment is off-the-charts
| awesome - thank you for the amazing links!!
| depingus wrote:
| Thanks for these links. Looks like I have a new rabbit hole to
| explore!
|
| Side note: I was just watching the val.town video and at the
| end he mentions that "you are an object" and other people can
| access your properties. It immediately made me think of playing
| hackmud. Not sure if that's a good thing or bad!
| xhfloz wrote:
| Heyyo. Creator of mmm.page here. Fun to see it mentioned. In
| case it's of interest, I've been coming at this from a more GUI
| perspective: scriptable objects (like paper) [1] and social
| primitives [2].
|
| Excited to see where this project goes.
|
| [1] https://paper.mmm.dev/
|
| [2] https://twitter.com/xhfloz/status/1611094168981458981
| zephraph wrote:
| This is incredible. I've been thinking a lot about personal
| software systems and a hypothesis that I have is that simpler
| code sharing/versioning mechanisms is key to greater agency in
| programming environments. I'm already a huge fan of unison (we
| had Runar on devtoolsfm) so I'm eager to explore scrap further.
| crowdhailer wrote:
| This is very cool. I have similar goals with my own language.
| Though I am developing only and AST and no syntax because I would
| like to be able to embed the same language into visual
| programming environments.
|
| https://petersaxton.uk/log/
| leke wrote:
| Did I miss the reference to the license?
|
| Looks interesting though. Would like play with this when it's
| released.
| substation13 wrote:
| Hello!
|
| This looks really interesting to me.
|
| There is a feature I would like that I have never seen in a
| scripting language, and I wonder if Scrap might support it:
|
| > Monadic bind points and applicative join points in the script
| language
|
| Hopefully an example can convey what I mean.
|
| Bind: do { let! x =
| some_value_in_a_monad x + 1 }
|
| Applicative: do { let! x =
| some_value_in_a_monad and! y = another_value_in_a_monad
| (x + y) * y }
|
| Now when I embed this script, I would like my runtime interpreter
| to provide implementations of `let!` and `and!`. The script
| author defines the bind points and the runtime defines the
| effects.
|
| Is this possible in Scrap?
| andreypopp wrote:
| OCaml has a similar thing but purely on syntactic level --
| http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-...
| debugnik wrote:
| Stricly speaking, F# can be used in scripts too, which is where
| I think you've taken that syntax from. Ionide however is quite
| broken when writing scripts (or anything else) though.
| surprisetalk wrote:
| Wow, I really like that syntax!
|
| Juggling lots of monads can be annoying. But to keep
| scrapscript small like json, this is something I would try to
| solve with editor tools rather than the language itself.
| substation13 wrote:
| How should users write async, futures, option, result, etc.
| in Scrap?
|
| My hunch is that if you do not put the syntax into the
| language, then it will be hard for the community to
| standardize on one preprocessing tool.
|
| OCaml (which I am a fan of!) struggles with fragmentation
| here.
| surprisetalk wrote:
| With managed effects, all of the async stuff gets pushed
| over to the platform.
|
| I suspect that everybody will settle on a reusable `task`
| type, but each platform can determine its own async
| scheduling system.
|
| Consider this example: | "/home" -> q ->
| res:success <| "<p>howdy " ++ name ++ "</p>" , name
| = q |> dict/get "name" |> maybe/default "partner" |
| "/contact" -> _ -> res:success "<a
| href="mailto:hello@example.com">email</a>" | _ -> _
| -> res:notfound "<p>not found</p>" . res = : success
| text : notfound text
|
| In this case, the platform creates a simple web server from
| the following type: text => query => res
| . res = : success text : notfound text
|
| Because scrapscript stays out of the scheduling game, the
| platform is free to run this code on as many cores and
| servers as it wants in parallel.
|
| But I 100% agree that community standardization is
| incredibly important! I just don't have a solution yet :) I
| will try my best to get everybody to work together though
| haha
___________________________________________________________________
(page generated 2023-04-28 23:01 UTC)