lukedegruchy

C-11 is about algorithms (more specifically, the requirements that govern algorithms) and discoverability.

The former CRTC commissioner as well as the senate confirmed that user generated content is within the scope of the bill:

https://www.michaelgeist.ca/2022/11/oops-he-did-again-crtc-c...

It is traditional broadcasters that lobbied for this bill.

The senate heard months of testimony from digital first creators who believe this bill will negatively impact them. That's why the added the UGC amendment that the government rejected.

It's not the source of the funding that makes the CBC biased.

It's all the exemptions and correspondence between the CBC and cabinet, the treasury board, and other arms of the government that is absolutely not made public in any way whatsoever:

https://frpc.net/wp-content/uploads/2023/04/2023-04-26-Hidde...

I'm a Canadian who's been following C-11 and before that C-10 for the 2 years the government has been working to pass this legislation.

Here is the best summary I've read so far:

https://allenmendelsohn.com/2023/04/welcome-to-the-online-st...

Digital first creators, Canadian YouTubers and TikTokers (ex Linus Tech Tips), stand to lose the most from this. Their livelihoods are under threat.

This is because of a clause in the bill that seeks to regulate user generated content. Months of senate testimony concluding that user generated content is in scope of the bill. The senate introduced an amendment to exclude user generated content, but the government rejected the amendment, while insisting this will not affect user generated content.

The heritage minister claimed in an interview that the only opposition to this bill came from YouTube. This is despite months of testimony from digital first creators expressing grave concerns about this bill.

Other facts to keep in mind about C-11:

1. The heritage minister gets to define Canadian content only after the bill has passed 2. Cabinet can overrule any decisions made by the CRTC, the Canadian equivalent of the FCC.

For Canada, Toronto and Vancouver are considered distinct from the rest of their provinces, but not Montreal from the rest of Quebec.

-reified generics: From what I've seen, the Ceylon guys have done a good job of implementing this and they make flow-sensitive typing possible. Without out, the benefits of union types don't fully materialize. See http://ceylon-lang.org/blog/2015/04/19/observable/

- problem of null: Ceylon uses union types to union between the class in question (ex String) and Null, which is a type separate from Object. Therefore, the typesystem enforces this. And yes, Ceylon has the exists operator, which means you can do if (exists stringOrNull) to instanceof/cast at the same time.

- elegant APIs - With regard to file I/O: https://modules.ceylon-lang.org/modules/ceylon.io/1.1.0/doc

- language spec - Ceylon's is much more detailed: http://ceylon-lang.org/documentation/1.1/spec/html_single/

Experimental support for higher order generics will be in 1.2 (JavaScript runtime only):

http://ceylon-lang.org/blog/2015/06/03/generic-function-refs... http://ceylon-lang.org/blog/2015/06/12/more-type-functions/

Optional (either JDK or Guava) is not perfect but is infinitely better than hand-checking for null. Among other things, it expresses the intent of the API writer that their method may or may not return an absent value and this is expressed via the type system. This is in stark contrast to using null as a primitive, which has no such transparency. For instance, there is no difference in Java's type system between a method that intends to always return a non-null String, and one that intends to return a null String under certain circumstances. Thus it is impossible for the user of the API to determine when to build conditional logic to check for null or when not to bother.

In any case, the concept of null as a primitive is fundamentally broken. Due to Java's backward compatibility requirements, it's too late to resolve this in that language. However, newer languages don't need to make this mistake. However, there are "interoperability" requirements for new languages interfaces with legacy runtimes that tempt language designers to build escape hatches. These escape hatches exist in Swift, Kotlin, Rust, etc even though they're not recommended and their usage presents edge cases.

Ceylon and Haskell seem to be the only two languages to get this completely right. Ceylon expresses optionality as the union between the present value type and null, which is an actual type separate from Object. An optional String is therefore a String|Null, or a String? Haskell accomplishes this with the Maybe type.

All this to say that null should not be a primitive but should be banished to its own corner of the type system with clear compile-time semantics for dealing with the absence of values.

What well-designed language doesn't do this?

Sorry, but I don't understand your point about instanceof/casting and how this relates to constructors. Please elaborate.

Gavin's looking for positive feedback on this since he wants the community to buy into this, so please give encouragement if you want this feature. It's currently experimental and only works on the JavaScript runtime, but they'll implement it for the JVM runtime as well if it's well received.

Java interop is way better with Ceylon 1.1. For example, use-site variance for generics was introduced and overloading bugs have been resolved. Ceylon 1.2 will have constructors (to support DI frameworks) and I believe Java EE integration. The Ceylon guys have been very careful about adding new features, considering the pros and cons. Strict Java interoperability would have resulted in a much less elegant language (ex public/protected/private instead of shared and allowing an escape hatch for null, as Swift and Kotlin have done).

What's wrong with Ceylon's type system? I find it incredibly well designed. For instance, the Ceylon compiler won't allow you to assign null to a non-optional variable. Also, there is a bottom type, which makes controvariance far more manageable. I could go on.

I disagree about the dots and parents. It impacts readability because the person reading the code, which most developers do 90% to 95%. If different developers on the team use different styles, it makes reasoning about the cod that much more difficult.

I can't say I've followed Kotlin all that closely, but it struck me as a less dense language. Ceylon is a language I've followed closely, and I find it very consistent.

I disagree. I think Scala suffers from Perlisms like being too succinct and more than one way of doing things (ex omitting dots and parens to invoke a method). There are newer alternative JVM languages that are more consistent and preferable to Java, so I disagree with your argument that those of us that prefer not to use Scala are Luddites.

Scala isn't the only alternative JVM language that has a superior generics implementation and that doesn't have primitives.

What neither Scala nor those languages have is support for value types (structs) at the JVM level. Generics over primitives and value types is a natural consequence of the introduction of value types to the JVM.