| 08:37 | <Ms2ger> | https://drafts.csswg.org/indexes/ |
| 08:50 | <Ms2ger> | What's about:unicorn? |
| 08:58 | <jgraham> | A joke in the fetch spec |
| 08:59 | <jgraham> | https://fetch.spec.whatwg.org/#concept-basic-fetch |
| 09:02 | <Ms2ger> | I found that, but why |
| 10:06 | <jgraham> | Same reason Excel used to contain a flight simulator I guess |
| 13:23 | <bblfish> | I just committed 1200 lines of code to wrap the JS Fetch and Stream API for Scala-JS. https://github.com/scala-js/scala-js-dom/pull/177/files |
| 13:23 | <bblfish> | It's an interesting example of how Scala.js essentially just makes the types in the JS APIs explicit. It even allows one to make functions and classes that contain generics explicit. |
| 13:24 | <caitp> | you did it |
| 13:24 | <caitp> | good job |
| 13:39 | <bblfish> | @caitp in a way the above commit just shows that JS is a type language that does not quite know it is :-) |
| 13:39 | <bblfish> | s/type/typed/ |
| 13:47 | <caitp> | oh it knows |
| 13:47 | <caitp> | it's still trying to find its place as a typed language |
| 13:48 | <caitp> | while also still trying to faciliate the dynamic programming styles at the same time |
| 13:48 | <caitp> | tricky balance |
| 13:49 | <bblfish> | Actually if one reads up on Homotopy Type Theory ( http://homotopytypetheory.org/ ) then types are a mathematical necessity. |
| 13:50 | <bblfish> | mathematical/logical |
| 13:51 | <caitp> | but, on the other hand, it's also necessary to not break the web, and to not break peoples expectations |
| 13:51 | <caitp> | still, work is being done on that |
| 13:53 | <caitp> | pragmatism and idealism have at it regularly |
| 13:57 | <bblfish> | There is an american philosopher who is showing how to merge analytic and pragmatic thinking http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-444/ |
| 13:57 | <bblfish> | Robert Brandom |
| 13:57 | <bblfish> | In fact in his book on meaning he shows how one can build more complex/experssive languages out of simpler ones. That's perhaps quite relevant here. |
| 13:58 | <bblfish> | "Making It Explicit: Reasoning, Representing, and Discursive Commitment" |
| 13:59 | <nox> | JS is a typed language. |
| 13:59 | <nox> | With only one type. |
| 13:59 | <caitp> | that's not usually what people mean when they talk about making JS a typed language, though =) |
| 14:00 | <nox> | caitp: Sure but then it's not JS. |
| 14:01 | <bblfish> | nox, actually its an implcitly typed language. Scala-JS just makes the implicit types explicit, and helps with compiler support in veryfing the types |
| 14:01 | <nox> | bblfish: No it's not. |
| 14:01 | <caitp> | under the hood, you've got maps/hidden classes, and you have values that aren't objects at all (small integers, etc), and those underlying types play a big role in how the compiler works --- but the runtime also cares about these to a degree, and there are efforts to make those types more explicit in the language itself |
| 14:01 | <nox> | If you write down the judgment rules etc of JS, you see there is only one type. |
| 14:02 | <bblfish> | I agree nox, but pragmatically it is typed |
| 14:02 | <bblfish> | just not explicity |
| 14:02 | <nox> | No. |
| 14:02 | <nox> | It's like saying Ok(_) and Err(_) in Rust's Result enum are two different types. |
| 14:03 | <nox> | The only type in JS is a huge enum with one variant for float, one variant for string, one variant for object, etc. |
| 14:03 | <caitp> | a type isn't strictly how something is represented in memory |
| 14:03 | <nox> | "A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute." There is no syntactic method in JS that automatically checks the absence of certain erroneous behaviours. |
| 14:03 | <nox> | I didn't mention anything about memory. |
| 14:03 | <caitp> | you seem to be arguing that in JS, everything is one type, but with different values/properties |
| 14:03 | <bblfish> | nox I am 100% with you. |
| 14:04 | <caitp> | which isn't really related to what a type is |
| 14:04 | <bblfish> | I am arguing that in fact you know that well defined functions return certain types of objects |
| 14:04 | <nox> | bblfish: All functions take all kind of values. |
| 14:04 | <bblfish> | when code is well written such as the Fetch or Streams API you can then make the types explicit |
| 14:04 | <jgraham> | ink nox's point of view makes sense |
| 14:05 | <nox> | They may crash with an exception, but there is still a judgment rule that means that you can evaluate the code. |
| 14:05 | <bblfish> | Here I made the types of the Streams API explicit https://github.com/scala-js/scala-js-dom/blob/master/src/main/scala/org/scalajs/dom/experimental/Stream.scala |
| 14:05 | <nox> | No matter how broken the code you write is, there is still a possible evaluation, no syntactic method will reject your code. |
| 14:05 | <caitp> | sure, but if you had static rules about what types you could pass to functions, well |
| 14:05 | <caitp> | that wouldn't work very well on the web |
| 14:05 | <nox> | So? That still doesn't mean JS has multiple types. |
| 14:05 | <bblfish> | and furthermore I discovered that Streams are in fact generic classes :-) |
| 14:06 | <caitp> | it doesn't have static typing |
| 14:06 | <nox> | Every dynamically-typed language is statically-typed. |
| 14:06 | <nox> | With a single static type. |
| 14:06 | <nox> | "Dynamically-typed" is a misnomer. |
| 14:06 | <bblfish> | caitp: it does not have explicit static typing, but pragmatically you could not write code if you were not able to expect certain datastructures |
| 14:07 | <nox> | https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ |
| 14:07 | <caitp> | when you only look at the static behaviour, you're missing the point |
| 14:07 | <caitp> | you can't make static guarantees about something that pulls in new code dynamically |
| 14:08 | <nox> | I'm not missing any point, this isn't a criticism of "dynamic" types. |
| 14:08 | <caitp> | and you sure as heck can't wait for all the code on every webserver in the universe to be preprocessed and compiled before running anything :p |
| 14:08 | <nox> | Both have their uses, but we shouldn't call the things that are in JS "types", IMO. |
| 14:08 | <nox> | caitp: I come from Erlang, I have nothing against unityped languages. |
| 14:08 | <caitp> | right, but that's not the point |
| 14:08 | <caitp> | whether it's static or runtime, types are about guarantees |
| 14:08 | <jgraham> | standard js barely even has runtime types |
| 14:09 | <nox> | And there are no guarantees in JS. |
| 14:09 | <caitp> | there absolutely are |
| 14:09 | <nox> | Types are about rejecting 3.length(). |
| 14:09 | <caitp> | and more all the time |
| 14:09 | <bblfish> | Well I program a lot in RDF and that is an interesting example of a datastructure that is fluid yet typed. |
| 14:09 | <caitp> | well 3.length() is a syntax error ,but |
| 14:10 | <caitp> | there's no intrinsic reason why you can't have 3..length() |
| 14:10 | <caitp> | if the type permits it |
| 14:10 | <caitp> | which it might! |
| 14:10 | <caitp> | but it probably won't be the same length() as something which requires a particular internal slot |
| 14:10 | <nox> | Of course the type permits it, because there is only one in JS. |
| 14:10 | <nox> | 3 and "foo" are of the same enumeration type, with different constructors. |
| 14:11 | <caitp> | you can easily have a 3..length() which is specific to floats and smis |
| 14:11 | <caitp> | there's nothing forbidding this |
| 14:11 | <caitp> | and it could even be encoded in the grammar of the language at some point |
| 14:11 | <nox> | You are the one missing my point. Type theory has a massive literature, and never in it you will find types framed as you do in JavaScript. |
| 14:12 | <caitp> | the literature is all about guarantees, and guarantees are certainly possible in dynamic languages |
| 14:12 | <caitp> | you just can't necessarily have static guarantees |
| 14:12 | <nox> | Saying that JS has multiple types is a pet peeve of mine, like "isomorphic" JS, |
| 14:12 | <nox> | or Julia claiming it has dependent types. |
| 14:12 | <caitp> | but that was a non-starter for scripting from the beginning |
| 14:12 | <bblfish> | flexible typing is pretty cool too. RDF is more along those lines: you can merge data structures from around the web, and infer types on the fly. And since every thing has a global identifier URI you avoid the duck-typing problem, that JS still has. |
| 14:14 | <caitp> | `for (x of { [Symbol.iterator]() { return null; } });` <<< you have a guarantee which forbids this --- it's a runtime guarantee, but there is still a guarantee |
| 14:14 | <nox> | Anyway, the link has posted pretty much explains my stance, I have nothing more to say that Harper didn't already write in it. :) |
| 14:14 | <nox> | I posted* |
| 14:14 | <caitp> | worrying too much about whether it's static or dynamic is a waste of effort |
| 14:14 | <nox> | Type system are a syntactic effort. |
| 14:14 | <bblfish> | Ideally you'd have a language that could have such just in time typing... that's what would be needed for a real web language ( RDF is just a datastructure not a programming language ) |
| 14:14 | <nox> | What is a huge waste of effort is conflating different things under the same monicker, but YMMV. |
| 14:15 | <caitp> | the syntactic effort can also arm the runtime and compiler with more information for aggressively making assertions and guarantees |
| 14:15 | <caitp> | which leads to the same thing (with not quite as elegant machine code) |
| 14:15 | <caitp> | arguably safer machine code, but whatever |
| 14:16 | <nox> | Having a syntactic method refusing to attribute any meaning to a piece of invalid code does not lead to the same thing as a unityped language where any function can take values of any shapes. |
| 14:17 | <caitp> | they're different things, but they lead to the same thing |
| 14:17 | <bblfish> | I agree that there are different notions of types at play. But still, the fact that I can translate Fetch API into Scala.JS typed Fetch.API does say something interesting. :-) |
| 14:17 | <nox> | bblfish: Sure. |
| 14:17 | <nox> | caitp: To me, that isn't true, cf. above link. |
| 14:19 | <caitp> | that's why I think you're missing the point, it doesn't really matter if the guarantees are static or not |
| 14:19 | <caitp> | if X will never work, will you still write X? |
| 14:19 | <caitp> | you make your own static guarantee |
| 14:19 | <caitp> | and if someone sneaks X into your program dynamically, it will fail elegantly |
| 14:19 | <nox> | How do you know X will never work? |
| 14:19 | <nox> | "Elegantly", hah. |
| 14:20 | <nox> | Anyway, I'm out of this conversation since you didn't even read the link. |
| 14:20 | <bblfish> | btw on duck typing I once wrote this https://blogs.oracle.com/bblfish/entry/duck_typing_done_right ( image is hidden because of http/https move ) |
| 14:20 | <bblfish> | Have a look at "Dynamic Languages are Static Languages" https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ |
| 14:20 | <bblfish> | s/Have/Having/ |
| 14:20 | <caitp> | you know X will never work, because you enforce that it never works =) |
| 14:20 | <nox> | bblfish: Will read yours. |
| 14:21 | <nox> | bblfish: The second is the one I linked. :) |
| 14:22 | <bblfish> | nox: you'll find the work by Brandom interesting - if you have a bit of an analytical philosophical bent. |
| 14:23 | <nox> | bblfish: Where is that? |
| 14:23 | <nox> | bblfish: RDF always kind of interested me, even though I never did anything with it. |
| 14:24 | <bblfish> | http://www.pitt.edu/~rbrandom/ his books: http://www.pitt.edu/~rbrandom/publist.html But perhaps most of all "Making it explicit" . |
| 14:24 | <nox> | That's one long beard. |
| 14:25 | <bblfish> | Or more recently " Between Saying and Doing: Towards an Analytic Pragmatism" |
| 14:25 | <nox> | I'm sure he strokes it when he thinks about types. |
| 14:25 | <bblfish> | there he even uses a bit of category theory - though I read that before I really knew about those |
| 14:25 | <nox> | bblfish: Will try to find the one about explicitness. |
| 14:26 | <bblfish> | He's a student of David Lewis https://philosophy.princeton.edu/about/past-faculty/david-k-lewis who also had a long beard. |
| 14:28 | <nox> | bblfish: Ah ah. |
| 16:48 | <smaug____> | there is convention that interfaces should start with uppercase letter |
| 16:48 | <smaug____> | is that documented somewhere |
| 16:49 | <Ms2ger> | I doubt it |
| 19:32 | <roc> | any research whose title contains the word "Towards" is very likely to be bogus |
| 19:37 | <tantek> | roc, how about "Toward", that too? |
| 19:37 | <roc> | sure |
| 19:37 | <tantek> | ok I'll offer a couple of posts for you to shoot down http://tantek.com/2015/068/b1/security-towards-minimum-viable-web-platform and http://tantek.com/2013/338/b1/people-focused-mobile-communication-experience ;) |
| 19:37 | <roc> | actually I should say "is even more likely to be bogus than average" |
| 19:38 | <roc> | tantek: ok, I stand by my claim :-) |
| 19:39 | <tantek> | I look forward to your thoughtful critiques :) |
| 19:42 | <roc> | I think the people-focused thing was a pretty good idea. "Towards" didn't belong in the title :-) |
| 19:42 | <tantek> | roc - indeed. it makes me cringe now admittedly |
| 19:43 | <miketaylr> | Toward essays considered harmful? |
| 19:44 | <roc> | "Toward(s)" is a weasel word |
| 19:44 | <tantek> | Towards a Consideration of the Harmfulness of Toward Essays |
| 19:44 | <roc> | similar to headlines that end in a question mark |
| 19:44 | <tantek> | roc - that's a dilution of "weasel word" |
| 19:44 | <tantek> | which is much more specifically about the "Some say", "One could say", "People say", "It is considered" patterns |
| 19:45 | <tantek> | https://indiewebcamp.com/it_is_considered |
| 21:06 | <TabAtkins> | The maxim is that if a headline ends in a question, the answer is always "no". |
| 22:22 | <Domenic> | smaug____: casing rules at https://w3ctag.github.io/design-principles/#casing-rules |
| 22:25 | <Domenic> | Is there no way to search the source in https://trac.webkit.org/browser ? |
| 22:45 | <smaug____> | Domenic: ok, this came when looking at FIDO U2F where Chrome is shipping something totally proprietary and the spec doesn't properly spec what is the API entry point. It does have an interface with name 'u2f', which feels odd |
| 22:45 | <Domenic> | smaug____: whole API seems bad, I am sad about it. |
| 22:45 | <smaug____> | yeah, it is horrible |
| 22:45 | <smaug____> | there is some new version coming, and that spec looks at least a bit saner |
| 22:47 | smaug____ | is rather sad that Chrome ships this kinds of APIs without standardization under some random .chrome prefixes |
| 22:51 | smaug____ | wonders if blink folks have considered removing window.chrome |
| 23:09 | <miketaylr> | Domenic: i just search https://github.com/WebKit/webkit/ |
| 23:17 | <jgraham> | It seems unlikely we need to copy the Chrome U2F thing, to me. It's only being used on a handful of sites and they are theoretically capable of moving to a new API that doesn't suck; particularly if Microsoft are only implementing the new version too |
| 23:17 | <jgraham> | smaug____: ^ |
| 23:19 | <smaug____> | jgraham: yeah, hopefully. dev.platform has the discussion |
| 23:19 | <smaug____> | apparently the new version is still rather early draft though |