Looks interesting but here's what I don't understand. So many programming languages do not show example code on the homepage. That's like if Mazda didn't show cars on their homepage. Sure, you won't really know what it's like to drive it without getting your hands dirty but at least let me see the trim.
For starters, the first "test" was bogus: grantparent said "front page", but parent tried the naked domain (which Mazda doesn't intent to be the front page).
Do you work for Mazda, or else how do you know? Is this intent published on the real site somewhere, which is what the user is trying to find in the first place when they try mazda.com?
Maybe this is just some webmaster that needs to have their ass fired.
Trying "mazda.com" for Mazda is the obvious thing for a user to do. I just tried half a dozen multinational corporations that are associated with well-known consumer brands, they all have a page at <name>.com or redirect to one. It is not in any way "bogus" to try that.
The mazda.com page doesn't even provide a clue as to where the expected site actually is; that's what is "bogus". For a second I was wondering whether Mazda actually own the domain, or is that someone squatting (yet using a Mazda logo favicon).
Not to have a page there which redirects the user to the real one, and just a permission error, comes across as astonishingly unprofessional, especially for a company of the proportions of Mazda. (If it was Uncle Bob's Pizza down the street, I might not think so as much.)
There's this thing called common sense. Either they have a broken "naked domain" homepage for months and they didn't notice, or their homepage is www.mazda.com.
>Trying "mazda.com" for Mazda is the obvious thing for a user to do.
OK, fine, whatever.
>Not to have a page there which redirects the user to the real one, and just a permission error, comes across as astonishingly unprofessional
Which is neither here, nor there, to the actual question of this subthread: whether they have cars on their homepage.
That they have the naked domain not redirect to www, doesn't mean their homepage is that and not the one they actually present, fill-in, and treat as such.
> Trying "mazda.com" for Mazda is the obvious thing for a user to do.
That used to be the case, but I would argue strongly that it is no longer. Now the obvious and normal thing to do is type "Mazda" into a search engine. In the USA, mazdausa.com is the top hit. (And Wikipedia is second.)
I don't get your point. Plenty of sites have `www` (though most will forward to it from the non-`www` version. A company's homepage isn't defined as their first-level subdomain. On top of that, many companies have different homepages. Some are for their products, some are for their company.
The corporate and product sites you are talking about firstly (1) exist and (2) link to each other. "Hey, this is our corporate site; if you're looking for products, click here."
Can you find another company that has the same revenue figures as Mazda (multi-billion dollars), and that is a widely recognized consumer brand, which has a broken web page at their root domain that doesn't redirect or link to anything, or even greet the user in any way?
I'm not sure. If we're talking about turing complete languages, aside from performace, you can get all kinds of features in all kinds of languages. It's actually a matter of how expressive, safe, idiomatic and well designed they are for everyday usage.
When discussing a language which is defined by caching values, we sure do want to see how that looks like in practice.
I can only speak for myself, but this kind of abstract listing of features is absolutely meaningless to me. Why would I want to use it instead of others, how do the unique features make a difference at solving a frequent problem? After reading the page I know Skip does something with caching, but I still have no clue what difference it actually makes in a program.
In my opinion a programming language landing page without code example is like a game's Steam store page without screenshots - it's cool to know it's a "fast-paced racing game" but that could apply to everything between Tux Racer and Gran Turismo.
TypeScript's website shows right at the top in a few lines how it makes an easy mistake in JS impossible. Zig's site has a nice example that gives you an idea of some added features, how it differs from C but still feels similar.
Rust's website had an editable and runnable code snippet showing iterators and pattern matching (although for some reason they later replaced it with the phrase "blazingly fast" in the redesign).
> Just click "learn more" button and you'll see step by step examples of the language features.
I got bored after about 5 pages, everything presented there is the same as in any other language. I want to see what differentiates this language from others, not what's the same.
That is what a landing page of any new language must accomplish - sell the reader on the power of your unique features as fast as possible.
what's worse, even if you click on "more info" it goes to a tutorial that teaches you from zero. But I'm more eager to know killer features in this language.
If done right, SQLive is the sort of thing that could entirely change the way many applications are written. Solving the problem of real time collaboration at the database level has been a dream of mine for years. Unfortunately I'm doubtful that existing RDBMSs will be able to integrate such a thing, seeing how shoddy implementations of materialized views have been.
I really hope you are successful in tackling this problem and that you can share your work.
I did just that recently. They certainly seem to offer the most complete solution. Definitely worth keeping an eye on.
I had to pass because of its prohibitive license (for now) and the head-scratching bugs I ran into with the direct Postgres source. I also had some concerns about the complexity Materialize would add to architecture of the sort of small apps I typically build.
I know this is unappreciative of the complexity of the problems that Materialize solves, but it would be so nice if Postgres just had observable (with triggers), no-compromise incremental materialized views.
What sort of experiences have you had with Materialize, if any?
Thanks for trying Materialize, (I work there!) What bugs did you run into with the Postgres Source? If you put them in a reply here or an email to andy@materialize.com we would be very appreciative of your feedback.
"In Skip the = operator introduces a new variable, but unlike other languages the = operator alone can not modify an existing variable."
Using != to assign a value feels really strange to me. I know some languages use := but in those languages typically it's because = is an equality operator. I'm sure there are some exceptions but != just so universally means "not equal" to me.
It does make sense if you realize that it is also used for fields and that a.!b.c = d is different than a.b.!c = d. The first makes a copy of the object at a.b before assigning a new value to its field c.
What's stopped me from using this syntax in the past is that it means LTE in basically any language I can think of. One can certainly design a grammar where it's unambiguous, I have in fact, but it still doesn't look right to me.
Why is seeing the syntax of a programming language so interesting? I think that syntax is one of the least interesting aspects of a programming language.
I can't find any code that highlights the main feature of the language. Only example programs like hello world, arithmetic, etc. which are fairly useless.
This seems to be their main hook that differentiates the language: http://skiplang.com/docs/lvalues.html. Otherwise, it looks basically like TypeScript with some of the keywords renamed.
It's not about syntax, it's about quickly seeing language choices and verbosity of various constructs.
There is a lot more information in a good example rather than a front page feature list.
it's the user interface of a language. you could as well say that screenshots are the least interesting thing about a gui app and what it can do is more important, but people want to see the screenshots anyway!
It’s actually the opposite: one will be writing that syntax when using the language if it’s a chore to write then nobody will want to use the language. Also it’s easier to understand what a language is doing looking at code than a technical document.
Well, one particular thing we'd see if there were a meaningful example on the home page is that Skip doesn't use a keyword to declare new symbols, opting instead declaration being conflated with first-assignment.
Misspelled variable assignments will silently succeed, rather than error because the symbol doesn't exist. I think that's a massive mistake and it speaks to a relative lack of large project development on behalf of the Skip designers.
So, I guess, in a backwards way, it's better for them to hide their syntax away from the home page, because I wouldn't have spent as much time on the site if I had seen that right away. "Time on site" metric improved, but to no meaningful result.
Also, in the year 2022, the site does not have a TLS certificate.
It's nice to be able to see what a new language is able to express easily. Have you ever browsed Rosetta Code? I find syntax interesting because it shapes how a language is used.
It's like viewing the floorplan of a house vs a written description of the floorplan. The latter is verbose, long, wordy and ultimately cannot paint a picture as accurate as just showing the floorplan.
Syntax interesting I is a aspects think so the language. Is language the of why seeing programming of of programming a syntax one interesting? Least that
My first thought was wondering why this couldn't be partially implemented (i.e. the important bits like memoisation of idempotent, state-bound functions or contexts) in any other programming language.
Then I wondered if this was already implemented for some functional languages. Then I read your comment.
For context, this is the brainchild of Julien Verlaguet, one of the creators of the Hack language used at FB.
Skip was meant to gradually replace Hack, but the FB codebase turned out to be too tangled to gradually convert to the reactive paradigm, and a big rewrite was not possible, so FB pulled the plug, then Julien kept on pushing the project independently.
Looks very interesting, but the last blog entry was over three years ago, and there are no mailing lists/IRC/Slack/any community forums to indicate signs of life. A shame.
It gets complicated as soon as there’s a pointer involved
Do you compare the pointer for equality, or do you follow it and deep-compare what’s on the other side?
What about the next pointer jump? What if there’s a class instance? What if there’s a reference cycle?
Python lets you implement custom logic in __eq__() to manually bridge some of these gaps, but doing that for everything can get out of hand. Also, deeply-traversing large objects to check equality can get arbitrarily expensive. Immutable structures simplify these comparisons (just compare everything as a value, any change will mean a new pointer), but obviously introduce certain constraints.
By tracking observed properties of mutable structures at runtime, and then publishing cache invalidations only when they change, you can:
- Do no extra work to know whether or not a cache has been invalidated
- Automatically and perfectly track everything the function “cares about”
- Track only the things it cares about, so changes to properties it doesn’t actually use won’t invalidate the cache
I think some of the phrasing there ("the variable x is going to be updated to point to a new copy of the object pointed to by x where field1 has the value 0") would really benefit from some graphics. Nothing fancy, something similar to what the Rust book does for ownership would help.
I like the name. In 4th grade I presented the argument to my PE teacher that skipping was better exercise than running and he let me skip around the track while everyone else ran.
It seems the last blogpost was from Aug 2018 [1] and last commit in the repo from June 2021 [2], so it doesn't look very maintained at the moment of writing this comment (Feb 2022)
Whoa so - I had to kinda dig to get to the Lvalues section of the docs, but ya really bury the lede there! I love the concept of x.!o = 3 and !x.o = {copy of x, with o=whatever}. I didn't read far enough to understand whether this makes deep clones with sub-objects. (I'm guessing...not?) Still, that itself is very innovative.
> Thanks to Skip's tracking of side effects the garbage collector only has to scan memory reachable from the root of a computation
But any typical copying GC only has to scan memory reachable from the root(s) of a mutator. I suspect there are more interesting optimisations, but I am unable to discern them from this statement.
Well, imagine your type-system was able to tell you exactly what roots are mutable in what scope. Now you can run a garbage collection on a single scope.
That's not how it works, but in pseudo code:
collect {
// Some code
return ...;
}
Well, if you don't have a type-system that tells you what is mutable, you have to either scan all the mutable roots, or maintain a write-barrier to know what could have captured data in the scope.
The problem with write-barriers, which is the go-to solution for generational GCs. Is that it is a conservative approach. Meaning, it will promote garbage in the cases where the pointer that lived outside of the scope is dead.
If you use a write-barrier, what is going to happen is that [A, B, C] is going to be promoted, because the barrier is going to track the object myObject, and it doesn't realize that it's dead.
However, instead, imagine you have a type-system that tells you that in that scope, the only thing that can be mutated is myObject!
Well, now you can run that in a loop, without accumulating garbage!
So, myObject and the list are allocated in different generations/scopes/etc, and we'd typically trip the write barrier, if we kept the program as is. Right. I don't see how it follows after, that we can avoid the barrier based on just mutability information. It is true that we can only "capture" data with the involvement of mutable objects, but I am struggling to figure out what more we can derive from mutability information. It feels like I'm missing some inference step between "the only thing that can be mutated is myObject" and "now you can run that in a loop, without accumulating garbage" and I can't think of one.
I would be more tempted as a compiler writer to delete all the code, since nothing is ever read outside the loop; but such analysis again doesn't depend on mutability type information per se, rather on what mutations occur in the program.
I guess the vision is to have SQLive hooked up to Skip hooked up to React. Then your website is a pure function of your database, and clicks in the UI just mutate the DB, and all the views updates seamlessly.
I've been tempted to learn Rust just for Differential Dataflow, less sure I'd learn something even more esoteric for some similar functionality, but a very interesting space to see progress in.
This looks fascinating, I wish I had found it sooner.
Am I correct that the cache invalidation logic is akin to pull streams, unlike computations in projects like S.js/Surplus, Solid.js or Sinuous, that are push-based?
adopting a new language is such a huge task.
doesn't seem like a big enough feature for a whole entire new language.
glad people are trying new things though
