Idle thoughts of a fellow developer

Understand centering

Thu, 23 Jan 2025 00:00:00 +0000

Once in a while, you stumble upon an article like this. Hardest Problem in Computer Science: Centering Things - Tonsky.

It contains all you need to know to realize that, centering things is much, much harder than you thought. There are so many moving pieces, it’s no wonder no-one seems to get it right.

Anyway. I regularly refer to this article, so I figured I’d keep a link to it somewhere.

TypeScript is lying to you (part III)

Mon, 26 Aug 2024 00:00:00 +0000

Context

See the previous post for a bit of context. In a nutshell, TypeScript pretends to be typed, but falls short in many cases.

What is `this`?

this is a reserved keyword in JavaScript and TypeScript that refers to a few different things. In most cases, the expected behavior is that this is the object that contains or owns the function you’re calling.

Typically:

class Library {
  books: string[] = [];
  add(book: string) {
    this.books.push(book);
  }
  print() {
    for (const book of this.books) {
      console.log(book);
    }
  }
}

In the print function, this is expected to be an instance of Library.

The issue with `this`

I write “this is expected to be” because that’s the issue we’re exploring today. Coming from many other languages, like Java, Python, even PHP, this looks like a familiar staple of OOP: the current instance.

The expectation is strong enough that any IDE will happily tell you that this is a Library, and that even the compiler will insist that it is a Library.

However, that’s not always the case (!).

this really is either:

the object this function is bound to (using fn.bind)
the object this function is called from (using object.fn())
(undefined or window, depending on the strict mode. Let’s assume we’re all reasonable and running in strict mode from now on.)

Example

A common pattern in, e.g. Java since Java 8, is to store function references to call them later, for example as a callback.

function grabABook(callback: (book: string) => void) {
  const book = "foobar";
  callback(book);
}
// ...
const library = new Library();
// Grab a book, and add it to the library
grabABook(library.add);

Let’s remember that library.add is simply this.books.append(book). The result is an Error: this is undefined (because this is undefined!).

But why?

As we’ve seen, this is not really just the instance on which the function is being called. It depends on binding, and on how the function is called. Like the actual syntax used to call the function.

When calling callback(book):

The function is not bound
There is no object. before the function name
Therefore, this is undefined

How to fix it

The second way of finding this, related to the calling syntax, is, in my opinion, ridiculous (see here if you still want to know). Instead let’s focus on binding the function so that it belongs correctly to its object.

Explicit bind

grabABook(library.add.bind(library));

I find this verbose, confusing, and easy to miss. It’s also possible to do this in the class constructor: manually bind all the function to this.

Note that if you bind a function, you can also re-bind it later. Which is even more confusing. If you think of binding a function, please think again.

Auto bind

This is a little more interesting: use the arrow notation for a function

  add = (book: string) => {
    this.books.push(book);
  }

Arrow functions are always auto-bound to their object, and so the ambiguity is removed

Why does it matter

The compiler, any smart IDE, and common sense expects a certain behaviour (but one should now know not to rely on common sense when it comes to JS or anything related to it). This sort of error is surprising and highly confusing.

At the very least, the type verification in the TypeScript compiler should not lie.

References

https://www.typescriptlang.org/docs/handbook/2/classes.html#this-at-runtime-in-classes
https://github.com/Microsoft/TypeScript/wiki/’this’-in-TypeScript

TypeScript is lying to you (part II)

Thu, 19 Oct 2023 00:00:00 +0000

Context

See the previous post for a bit of context. In a nutshell, TypeScript pretends to be typed, but falls short in many cases.

The issue with indexable types

TypeScript supports a few indexable types. By indexable, I mean that we can use [index] notation to get a value.

Those types are, well, typed, and the type of the value returned by the index notation is known.

But it is not correct, in many cases.

Examples

`Record<string, string>`

A very common thing to see:

const material: Record<string, string> = {
    "Fifer": "Straw",
    "Fiddler": "Wood",
    "Practical": "Bricks",
}

const other = material["Wolf"];

Here, other is of type string. But its value is actually undefined. Its correct type is string | undefined.

In other languages, requesting an invalid index throws an error.

Note that it’s not the case when using finite types for the keys:

type Pigs = "Fifer" | "Fiddler" | "Practical";

// This is invalid because the record is missing 2 keys
const material: Record<Pigs, string> = {
    "Fifer": "Straw",
}

// This is invalid because "Wolf" is not part of the record key type
const other = material["Wolf"];

`[]`

Arrays suffer the same problem. Consider:

const materials = ["Straw", "Wood", "Bricks"];

const mat = materials[42];

Here as well, mat is of type string, but really is undefined. An error indicating that the index is out of bound would make this error easier to debug.

Note that when using constants, TypeScript is more strict about the inferred type, and can detect index issues:

const materials = ["Straw", "Wood", "Bricks"] as const;

// This is invalid, because `materials` is now a tuple of size 3
const mat = materials[42];

What about `.at()`?

Arrays have .at() function, which types the output as string | undefined. (The function also has other uses, such as negative indices). That’s a little more honest, but arguably a little less practical.

Records don’t have such a thing.

How to fix it

TypeScript has lots of options in tsconfig. The one relevant for this case is --noUncheckedIndexedAccess.

Enabling this option will make indexed access return optional values. I wish TypeScript would just have this enabled by default.

Why does it matter

For Record, it matters because depending on the type of the key, it behaves differently.

For limited types, like unions of literals, it strictly enforces that the Record can only have those keys, but must have all of them.

For unlimited types, like string or number, any number of keys is ok, and all values are assumed to have the right type.

It’s confusing.

Next time: this is not always what you think this is.

TypeScript is lying to you (part I)

Tue, 17 Oct 2023 00:00:00 +0000

Context

TypeScript is presented, by the authors, as “a strongly typed programming language”.

For anyone who has worked with other strongly typed languages, like Java, Kotlin, C#, this normally means that types are checked before runtime, and guaranteed, unless the users explicitely tries something dangerous like casting.

In TypeScript however, there are several ways of ending, without being warned, with completely wrong types at runtime.

This article presents one. There are more, which will be the subjects of more articles in the near future.

The issue with `any`

There are a few ways to break the type system in TypeScript, but for ńow, I’m focussing on the fact that any can be implicitely casted into anything else.

No-one in their right mind would, on purpose and for anything other than a throw-away script, write something like this:

const double = (value: any) => {
    return 2 * value
}

It doesn’t however, need to be that basic.

Examples

A couple of example to illustrate slightly less obvious cases that can go un-noticed.

`JSON.parse`

JSON.parse is a built-in function that returns any:

type MyType = {
    key: string;
}

const parsed: MyType = JSON.parse('{"value": "key"}')
// parsed is actually { value: string }

There are libraries that do things like generating JSON schema, validating an input, and inferring a type, but out of the box, any is what you get.

`Array(n).fill("value")`

Array(n) returns an array of n undefined values, typed any[]. fill(value) fills the array with the given value, without changing its type.

const array: string[] = Array(5).fill(42);
// array is actually a number[]

What about `unknown`?

TypeScript has another type that is used when the specific type is not known: unknown. It is equivalent to Java’s Object. And it requires an explicit cast to be assigned to another type:

const value: unknown = 42;

const casted: string = value as string;
// This cast is necessary

Why does it matter

This confuses people (e.g. this question on StackOverflow). There are a few lint directive to restrict the usage of any, but it is still fairly easy to miss one.

Once any is somewhere, the error will only show up at runtime, making the whole point of a typed system moot.

To be honest, I don’t fully understand why we need to have any in typescript, and why unknown is not sufficient.

Next time: how indexed types lie about what they return.

More bipartite graphs

Tue, 01 Mar 2016 00:00:00 +0000

Yesterday, on CodeFights, against a company bot, I was confronted to an interesting problem. I will try as much as possible to avoid revealing which company that was and what problem that was.

It can be formulated like this:

Let U be a set of intervals
Let V be a set of intervals, each intervals being associated with a length
An element of V can be matched with an element of U if and only if the intersection of the 2 intervals is longer than or equal to the length associated with the element in V
Determine if it is possible to match each element of V with an element of U

For example:

u = [1, 4] is not compatible with v = [3, 5], length = 2
u = [1, 6] is compatible with v = [3, 5], length = 1

From this formulation, it appears rapidly that this describes a bipartite graph. The condition of matching indicates if there is an edge between a vertex in U and V, and U and V are disjoint sets.

This starts to look a lot like cat vs dogs, a problem from Spotify I solved a few years ago.

And indeed it does. The problem asked is simply to find if a maximum matching: a maximum matching matches exactly n distinct elements from U to n distinct elements from V using n edges.

The solution is therefore to measure is the cardinal of the maximum matching is the same as the cardinal of the set V.

A link to an implementation of the Hopcroft-Karp algorithm, which computes the maximum matching of a bipartite graph can be found at the end of the Cat vs Dog problem article.

Maximal matchings are very useful to solve optimization problem where you have to find the better arrangement for a set of elements to another set.

Publishing for Java (and Android)

Sat, 27 Feb 2016 00:00:00 +0000

As mentioned in a previous article, writing and publishing an open-source library is good for a lot of reasons.

There are a few things to do in order to make sure the publication of your library makes sense, here is how to do that in Java.

Open sourcing

My library is here. The issues are public and anyone can add one.

The shields on the readme page also indicate the public status of the testing, code coverage, and publication.

Testing

For testing, I use JUnit. It is the most common testing framework for plain Java.

To ensure that the tests are always run, I integrated the project with a continuous integration server. I chose Travis CI because it integrates easily with GitHub. All is required is the .travis.yml file with the language declaration and the which JDK to use.

language: java
jdk: oraclejdk8

Whenever a commit is pushed on a branch, Travis pulls it, compiles it, runs the tests, and reports the result to GitHub. It ensures that you always know immediately when a branch does not compiles, or fails any test.

Coverage

JaCoCo is a code coverage library for Java. It generates XML and HTML reports based on the tests integrated in your project. It has a Gradle plugin, which adds a jacocoTestReport task. I add this task as a dependency of the check task, which already encompasses the test task, and is run by the CI server.

apply plugin: 'jacoco'

jacocoTestReport {
    reports {
        xml.enabled = true
        html.enabled = true
    }
}
check.dependsOn jacocoTestReports

To make sense of the report, and to automatize the validation, I integrate Codecov. Again, pretty easy, just send the result of the tests to Codecov using their provided script.

after_success:
  - bash <(curl -s https://codecov.io/bash)

You can then access other features, such as comparing the coverage from a branch to another, or rapidly see which parts of a pull request are not being tested. This is particularly important if you receive outside contributions to your project.

Publication

Gradle build system uses Maven dependency management system, and connects to any maven repository. The most common are Maven Central and jCenter. I use jCenter because it is included by default in Android Studio in new Android projects.

To publish on jCenter, here is how

Get an API key

Register on Bintray
Get your API key from your profile
Add your username and API key to a file that you add to your .gitignore. The key is obviously secret and should not be shared with anyone.

bintray.user=smaspe
bintray.apikey=API key goes here

Prepare the package

Publishing on jCenter requires that you include the JavaDoc and the source together with the build. There are a few things to add to your build file.

Include the maven and maven-publish plugins
To actually create the JavaDoc and the source bundle, define the javadocJar and sourcesJar tasks
Declare those tasks as being archives in the artifacts of the publication
Configure the group and version of your library

group 'com.example.group'
version 'X.Y.Z'

apply plugin: 'maven'
apply plugin: 'maven-publish'

task javadocJar(type: Jar, dependsOn: javadoc) {
    classifier = 'javadoc'
    from 'build/docs/javadoc'
}

task sourcesJar(type: Jar) {
    from sourceSets.main.allSource
    classifier = 'sources'
}

artifacts {
    archives javadocJar
    archives sourcesJar
}

Uploading

Get the jCenter plugin
Read the properties file with your API key
Configure the bintray task

plugins {
    id "com.jfrog.bintray" version "1.4"
}

Properties properties = new Properties()
try {
    properties.load(project.rootProject.file('local.properties').newDataInputStream())
} catch (Exception ignored) {}

bintray {
    user = properties.getProperty("bintray.user")
    key = properties.getProperty("bintray.apikey")

    configurations = ['archives']
    pkg {
        repo = "maven"
        name = "The name of your library"
        publish = true
        // There are other parameters you can set, but only those are mandatory
    }
}

You now only have to call the tasks whenever you want to publish a new version

./gradlew bintrayUpload

That’s about it. Refer to my complete Gradle file to see the complete configuration I use.

Publish an open-source library

Thu, 25 Feb 2016 00:00:00 +0000

So you want to publish a library?

There are a few questions you should be asking yourself.

What

What library. What does it do, why is it different/more relevant than existing libraries, how is it useful to other people. Jesse Wilson said during one of his presentations that you should not write yet another JSON parsing library. But then he presented moshi.

A new library can be a different approach to a known problem that suits you better. Or a totally new thing. Or an SDK to use another of your products. Or a bunch of things you often need in a project, and that you think fit together as a consistent entity.

Who

Everyone, really. Companies, individuals, hobbyist, students…

Why

Why are you writing a library? Here a few good reasons, that apply differently depending on who you are:

Better modularity and separation of concern in your code
Possibility of peer review
Open source is cool. It can be a part of your port-folio, or carry a positive image for a company.
Give back something to the community. You probably have dozens of open-source libraries in your own projects.
Make that part of your code a proper product so it gets the documentation and QA attention it deserves
Make it easier to reuse it in other projects

When

How do you know when it is time to write a library?

When there is a component that naturally emerges from your code, and it starts to look like it has a personality
When you architecture your project, and realize that one of the module is really independent from the rest

How

There are a few things to do in order to ensure your library is in good shape to put out there.

Open sourcing

That’s the obvious step. If you are not publishing the library itself, I don’t know what you are doing here, and if you are not open-sourcing it, you loose most of the benefits of the publication.

The current place to be is github, but it could also be sourceforge, bitbucket, or any mean you want.

Documenting

If you want people (including your future self who does not remember how you wrote this thing) to be able to use the library, well, obviously, you need to document it. Also, because it is now open-source, you are responsible for it.

Testing

A code that has tests is immediately perceived as more reliable.

Making sure you test it (coverage)

A single test that passes is not a very good guarantee. Try to aim for 100% coverage. Various tools can help you measure that, depending on your platform, and can help you identify the edge cases you may have missed.

Publish it

To help people use it (including yourself), as most modern build systems have dependency management integrated with publication systems. (npm for JavaScript, pip for Python, maven for Java…)

Example

I recently published a Java/Android library of higer-order functions for functional programming. It is a Java library, and uses Gradle as build system, so most of the information here are related to that. It is described in a separate article.

Functional Iterables

Tue, 23 Feb 2016 00:00:00 +0000

A few month ago, while working on an app, I realized Java was lacking higher-order functions.

Why

I realized this because of 2 reasons:

Around me a lot of people were using JavaScript, and discussing whether to use Ramda or Lodash, both being JavaScript libraries providing higer-order functions
I had been playing with retrolambda, which backports in particular lambdas and function references from Java 8

So, having functions close enough to being first-class objects, I was in need of higher-order functions to use them.

As a reminder, a few common higher-order functions:

map
filter
all
reduce (more on this one later, in a dedicated post) …

How

Because I like simple things, there was a few principles:

The library should be based on existing things. Less code to write, less bugs.
I need to be able to use it in code very easily. The library must be usable in an existing project, and must not shape the project.
It must be short and self-explanatory. This is a utility library, it should do what you think it should do, and you shouldn’t have to read the documentation.

Existing things

It revolves mostly around the the Iterable interface.

The Collection interface extends Iterable, so all collections, sets, lists,… could be used there. Iterable defines only one method, so it is easy and short to implement.

The FuncIter class is a decorator to Iterable, it adds features to an existing instance. Those features being, of course, the aforementioned higher-order functions.

Because of this, it takes very little code to write a function. As a simple example, here is the basic implementation of map:

public static <T, R> Iterable<R> map(Iterable<T> input, Func<T, R> func) {
  return () -> new Iterator<R>() {
      Iterator<T> iter = input.iterator();

      @Override
      public boolean hasNext() {
          return iter.hasNext();
      }

      @Override
      public R next() {
          return func.call(iter.next());
      }
  };
}

(The actual implementation includes a wrapping in the decorator, omitted here for clarity.)

It is a grand total of 5 instructions, and it does exactly what it should do. No ifs, no loop, no error.

Easily integrated

Integration of the library is easy, as it should be. It is published on jCenter, so it is a matter of one line in your Gradle file (or a few in your Maven file).

As per the code itself, all functions are instance methods and static methods (taking the Iterable as the first parameter). You can chain them or call them in one shot.

Because it is a decorator of one of the most common interfaces, and because it also come with a wrapper around T[], you can use it with most of your existing objects.

Now, Iterable is usually not the most useful output. This is why there are a few collect functions to collect the iterable in an ArrayList or a HashMap.

A quick note on collect. This method returns an ArrayList, rather than a List. I covered that in a previous article. By returning an ArrayList, I guarantee that the returned object is a mutable list, with, for example, a complexity for getting an arbitrary item of O(1). It also means that I am not allowed to change it, ever. But I am OK with that.

Short

The whole library fits in a single file, and has no dependency. It is compiled for Java 7 as it is what Android uses. If for some reason adding the Gradle dependency or including the jar file is not convenient, you can simply drop the unique source file in your project.

Each function itself is only a few lines long. Because of that, reading that piece of code will tell you more clearly what it does than the documentation could.

Because it is so short, I can guarantee that it is thoroughly tested, with the tests having 100% coverage (I am not just saying it, codecov attests to it).

Last word

So there you have it, a 300-line library (at the time of the writing), 100% tested, compatible with Java 7, containing the most common higher-order functions for your daily functional programming needs.

The Top 5 things I dislike about Java

Thu, 18 Feb 2016 00:00:00 +0000

I have been working with Java for about 12 years, starting with Java 2. I have been using other languages, Python, JavaScript, C, Swift,…

There are a few things that are frustrating when writing Java that are not present in other languages.

Here is my Top 5

`void` is special

void is only ever used to indicate that a method does not return anything. It also means that a method defined as public <T> T func(); must return something, and can never return a void.

There is even a Void type when you want a generic function to not really have a return value. It is just a placeholder, though, and your function still needs to return something. Usually null.

Primitives

int, long, char, bool, byte, float, double, short all have equivalent objects, and are auto-boxed and -unboxed. Still, it is a bit weird, and can lead to unexpected behavior:

Integer a = null;
int b = a;

causes a NullPointerException because you can’t assign null to an int.

Other surprise:

Integer.valueOf(500) != Integer.valueOf(500);
// But
Integer.valueOf(5) == Integer.valueOf(5);

Because of how small integers are cached and the same Integer objects are returned. Of course this is implementation specific.

Operators are special too!

Operators in Java work by combining one (for unary operators) or two (for binary operators) operands of compatible types into a result of the same type as one of the operand. Only primitives (and String for +) are usuable with operators, or their Object equivalent, through auto-unboxing.

This means you cannot use an operator with generic objects. Your operands have to be of the proper type, and they have to be so at compile time.

And also that means that you cannot refer to an operator, because it is not a function.

Functions as first-class objects

To access a function and learn things about it, like its return type and its arguments, you need to use reflexion, which is tedious.

With Java 8, there are function references, lambdas, and functional interfaces. It is much better, but still not perfect.

While Functional Interfaces provide a way to reference a function, they do not provide direct access to the function itself. You still need a functional interface that matches your function’s signature to create a variable that holds it.

`List` is broken

List is an interface for ordered collections. You can iterate on it, or access the elements based on their position.

But a List does not tell you if it is mutable or not. In other words, all the add and remove operations are marked (optional operation).

For example:

List<String> strings = Arrays.asList("one", "two", "three");
strings.add("four");

Throws an UnsupportedOperationException. Whenever you receive a List as a parameter, you do not know if you are capable of mutating it. What is worse, there are several implementations of mutable lists. ArrayList and LinkedList being the more famous. But there is no way to indicate in your method signature that you need a mutable list, short of choosing one of those.

List is also very generic in the sense that it does not give any indication of how is performing the underlying implementation. Every operation in a List has a complexity that ranges from O(1) to usually O(n) depending on what type of list it is. See Big-O notation for each type of list. Not knowing which list is used prevents from knowing the complexity of an algorithm.

This is why I always tend to try to accept the most generic interface I know I can work with (i.e., not List if I need to add to it), but return the most specific type I can commit to. My methods never return List, unless I really need to. (Typically returning the result from Arrays.asList). In which case, the returned List should not be considered mutable.

How other languages do it

As I mentionned, I have use other languages, because all languages have unique features that make them interesting, and it is by comparing languages that I get to see what is specific, what is good, and what I like less about a language.

Python

`void`

There is no such thing as a void type, nor as a return type. There is None, but it can be affected to any variable, and is simply a null pointer. It is implicitely returned by functions that have otherwise not returned anything.

Primitives

There is no such thing. There are literals, which allow you to express certain types (numbers, lists, dicts, strings, regex…), which is convenient, but all types are objects. Try (1).__doc__.

Operators

Operators are shorthand for functions. This is really neat. Because there are no primitives, all things are objects, and all objects have methods. And because Python ducktypes and does not need interfaces, all you need to do is implement the function matching your operator. For example the += operator (in-place addition) is implemented by the __iadd__ function.

Also, because operators are functions and are also defined in the operator module, you can refer to them, and use them in higher-order functions: functools.reduce(operator.iadd, [1,2,3])

Functions

Are a type in python. The have properties, and even functions.

List

list in python is an array-backed list. Other types of elements you may use are subscriptable (can be accessed by key or index) and iterable (can be iterated sequentially).

JavaScript

`void`

Return statement are not mandatory, and return types are not a thing, so nothing more to say here.

Primitives

Some types are represented by primitives similarly to Java. Fortunately, the dynamic typing prevents us from having to worry about it.

Operators

All types can be used with all operators. But watch your step. For fun, try things like

[] + []
[] + {}
{} + []
{} + {}

Functions

Every function in JavaScript is a Function object.

in Mozilla functions reference

`Array`

The basic list type in JavaScript is Array. To use other types, define it yourself, or use a library. There is no indication to the developer, however what type of list (or, come to that, of what type of variable at all) they are receiving in a function, but it is generally admitted that unless indicated otherwise, Array is used.

Quick note on Functional Programming

Tue, 09 Feb 2016 00:00:00 +0000

Functional Programming is nice.

It helps you avoid all those loop, removes lots of conditions, and gets the code clearer as it enables very good separation of concern.

This article presents quickly what functional programming is, and how it is useful, in order to introduce the functional programming library that I wrote for Java 7, and that I’ll present next time.

There are 2 important things you want to have for functional programming

First-class functions
Higher-order functions

First-class functions

First-class functions is when you can refer to a function.

A lot of languages have First-class functions. A few: JavaScript, Swift, Python, Go…

Here, a Python example:

def square(x):
  return x*x

func = square
func(42)
# 1764

func is a variable that references the function square

You can then pass it to another function, use it in cases like this trivial and pretty much useless example:

def apply(f, p):
  return f(p)

apply(square, 42)
# 1764

But since apply takes a functions as a parameter, it is a higher-order function, which is a perfect transition to the next section

Higher-order functions

In most cases, a higher-order function is a function that takes a function as one of its parameters, and apply it in various ways to the other parameter(s).

The best known example is map:

map(square, [1,2,3])
# 1, 4, 9

It replaces the more verbose

res = []
for i in [1, 2, 3]:
  res.append(square(i))

There are plenty other such functions.

In Java

First-class functions

Until Java 7, the way to reference a function is to create an interface that has one function, then create an anonymous implementation of that interface, then call the function on that object. Think about all those OnClickListener, for example.

In Java 8, 3 new things appeared:

Functional Interfaces. An interface with a single method. The function and the interface are synecdoches
Lambdas. The() -> {} notation basically allows you to implement a functional interface without the verbosity
Function reference. The :: notation allows you to refer directly to a function instead of implementing a functional interface.

Both lambdas and function references can be assigned to Functional Interfaces, provided that the signatures are compatible.

This is as close as it gets to First-class functions, as far as Java is concerned.

Higher-order functions

Java 8 has streams, which has a lot of higher-order functions. RxJava has a lot things too. And of course, my own Functional Iterables which leverages the Iterable interface to implement higher-order functions in Java 7, but that’s for another post.

Example

Here is a quick example of what first-class functions look like in Java

Before

view.setOnClickListener(new View.OnClickListener() {

    @Override
    public void onClick(View target) {
      anotherFunction(target);
    }
});

For every single listener.

After

The lambda:

view.setOnClickListener((target) -> anotherFunction(target));

or the function reference:

view.setOnClickListener(this::anotherFunction);

Much better.

Idle thoughts of a fellow developer

Understand centering

TypeScript is lying to you (part III)

Context

What is this?

The issue with this

Example

But why?

How to fix it

Explicit bind

Auto bind

Why does it matter

References

TypeScript is lying to you (part II)

Context

The issue with indexable types

Examples

Record<string, string>

[]

What about .at()?

How to fix it

Why does it matter

TypeScript is lying to you (part I)

Context

The issue with any

Examples

JSON.parse

Array(n).fill("value")

What about unknown?

Why does it matter

More bipartite graphs

Publishing for Java (and Android)

Open sourcing

Testing

Coverage

Publication

Get an API key

Prepare the package

Uploading

Publish an open-source library

What

Who

Why

When

How

Open sourcing

Documenting

Testing

Making sure you test it (coverage)

Publish it

Example

Functional Iterables

Why

How

Existing things

Easily integrated

Short

Last word

The Top 5 things I dislike about Java

Here is my Top 5

void is special

Primitives

Operators are special too!

Functions as first-class objects

List is broken

How other languages do it

Python

void

Primitives

Operators

Functions

List

JavaScript

void

Primitives

Operators

Functions

Array

Quick note on Functional Programming

First-class functions

What is `this`?

The issue with `this`

`Record<string, string>`

`[]`

What about `.at()`?

The issue with `any`

`JSON.parse`

`Array(n).fill("value")`

What about `unknown`?

`void` is special

`List` is broken

`void`

`void`

`Array`