#strangeloop2022

Libby Horacek

POSITION DEVELOPMENT

@horrorcheck

What is the Kisekae Set System: It is a system to make digital dress up dolls!

Created in 1991 by MIO.H for use in a Japanese BBS. Pre-web!!! By separating the system from the assets of the dolls, you can make the systems much smaller

CEL image format. They have a transparent background and indexed colors like GIFs!

There is also the KCF Palette Format. Each GUF stores its own palette, with CELs there is a shared KCF palette file. Which is a file size cost savings. You do not have to repeat your color info per file.

Having your palette in another file makes palette swapping really easy! Just swap the KCF file!

CNF configuration files dictate layering, grouping, setting, and positions!

KiSS dolls have a lot of files, so they used LhA, the most popular compression format in Japan at the time.

In 1994, KLS (a user) created the KiSS General Specification

1995 FKiSS is born by Dov Sherman and Yav, which adds sounds, and animation!

FKiSS 2, 3, 4, two versions of FKiSS 5! So much innovation!

1995-2005 huge growth in KiSS! Increase of access, mainstreaming of anime, younger and more female audience.

2007-2012: KiSS declined due to it being much harder to make. All the old tutorials were written for older systems, English-speaking KiSS-making died out by 2010

The Sims, and other doll making was more accessible.

But, why KiSS? If I can make dolls in other places. They are great snapshots of the pre-internet world, and how play online evolved early on.

Lots of fun dolls were available, and it would be cool to save it.

Picrew is a modern thing people use to make dolls.

Tagi Academy is a tamagochi game within KiSS. Impressive!

KiSS has an open specification!!!! That is super cool! That means anyone can make your own viewer, as opposed to a closed system in The Sims.

So, why NOT make a KiSS interpreter?!!

Libby made Smooch, a KiSS renderer written in Haskell, which at the Recurse Center!

Smooch used a web framework called Fn (fnhaskell.com)

Had to make a CNF file parser using Parsec library that uses parsing combinators.

She created a data type that houses everything that can be in a CNF file, and parses it correctly in priority order.

Parsing is a great candidate for test-driven development. You can write a test with a bad CNF file, and then make sure your parser handles it.

The parser translates CNF lines into JSON. Uses the ASON library to translate into JSON.

First tried cel2pnm, coded with help from Mark Dominus at Recurse Center Made a C program that converted cels to portable bitmaps, which could be translated into PNGs.

Then JuicyPixels was created to translate palette files directly in Haskell

Now it is converted to JavaScript! No libraries, just JS!

Using PNGs in JS, thought, made it hard to click on parts of the clothing! Since it is squares.

So, you use ghost canvases! You use tow canvases, one on top of the other, to find the color of the pixel you clicked on, If you clicked on a scarf color, it will pick the scarf, and if you pick the sweater, you get the sweater!

Libby just added FKiSS 1 to Smooch! So we have animations now! The animations are basically event-based scripting the CEL files.

Smooch translates FKiSS to JSON, then the interpreter translates the JSON to JavaScript!

An action in FKiSS is translated into a function in JS. To do this you have to use bind in JS.

The events become CustomEvents in JS! So it looks like a regular event on the DOM.

What is the future of KiSS? Let's get more people making KiSS dolls!!! So why not make it easy to make dolls using PNGs.

How can we make people interested in building KiSS dolls and KiSS tooling.

Smooch need contributors!

Africa Periañez

BENSHI.AI, CEO

Focusing on bringing AI to the most underserved countries in the world.

40% countries have fewer than 10 medical doctors per 10,000 people!

HIV/AIDS is the leading cause of death across the world, especially in Africa.

There are many cheap, easy-to-implement technologies that can improve health outcomes across the world.

Most of the problem isn't getting the supply out there, it is getting people to understand, and trust, that the medicine is safe and trustworthy.

The name of the game, then, is engagement. We need to engage folx that do not know what is safe or not.

A great way do this is through games!

Benshi's were people that would describe silent movies to illiterate people in Japan. Origin of the name benshi.ai

They want to democratize medical knowledge through mobile phones. Mobile phone penetration is widespread. 80% of people in Africa have smart phones connected to the Internet.

Global health is a messy field that is not remotely organized globally, so there is a lot of communication needed at the local level to bring people together.

They focus on experimentation and machine learning to forecast health trends

The goal is to predict and nudge behavior towards improved health decisions.

They work to gamify and personalize interventions and predictions for each client.

It is not enough to have data, you need to have organized data to mine the value out of it.

Benshi uses data labeling to to organize data and build data sets, which feed back to client nudges

Benshi is n opinionated system. They want to guide clients towards decisions that will save their lives.

A Nigerian doctor can visit about 100 patients a day. In Ethiopia, there is 1 midwife per 10,500 people.

How can we use AI to optimize the limited resources of medical professionals to triage the highest need cases in within these constraints?

Malaria is 100% preventable, treatable, and curable, but we still see 200,000 deaths every year. We want to nudge people to take their malaria medication through gamification.

If a person goes to a pharmacy, and they do not have the drugs they need right away, there is a 29.4% chance that person will never return to get their medicine in developing countries.

Part of what we can do is predict the medicine needs per area using AI modelling.

ML helps us discover and predict actual demand and needs per area. That can kickstart the supply chain ahead of the resource needs

Big Pharma is not incentivized to participate in these improvements right now. So another problem is how do we encourage and incentivize Big Pharma to lean in as well?

There are very few people working in this field, despite this being a very large problem for the world

M. Kramer, E. Duflo, and A. Banejee got the Nobel prize for work in this field, and much more is needed in experimentation in low income countries and global health

Check out Milind Tambe's Field Study in Deploying Restless Multi-Armed Bandit in India

Tracking out of stock medicines over the world help s drive preemptive resource management

The more people that feed data into ML model apps, the better refines the predictions have gotten in Indonesia.

The team is largely woman-driven, 83% in leadership, 55% in engineering

John Romero

ROMERO GAMES

John started learning BASIC as an elementary school kid. Then got an Apple ][. He eventually learned 6502 Assembly.

Made software for the Air Force in High School, since his dad worked in the Air Force.

At 21, John was working porting games to the Commadore 64.

Made a tool to make games. Hired John Carmack, Adrian Carmack and Tom Hall to make games.

Carmack ad Hall made Dangerous Dave in Copyright Infringement, Sept. 20, 1990. The demo proved you can do smooth scrolling on a PC!!!!!

Commander Keen was the first PC game that could do smooth scrolling horizontally. The Commander Keen trilogy was made in three months. So popular people cosplay as commander keen.

Started licensing the Keen engine in 1994.

ID Software was started in Shreveport, Louisiana.

They played D&D on the weekends, Quake was inspired by one of there D&D sessions.

They made a SMB3 PC demo to pitch to Nintendo, but Nintendo (wisely) decided to only allow their software to run on their hardware.

They always were making two games at a time. No prototypes, always maintain contently shippable code. Only make games, not prototypes of games. It was a small team of four people.

They were making games 24/7, and they moved from Louisiana to Wisconsin.

Your game has to be able to be run by your team at all times. Bulletproof your engine by providing defaults upon load failure.

If you fail to load a sprite, load a bagel. If the sound fails, play an annoying sound.

Keep your code simple. Always make it simpler all the time.

After six months of snow, they went to Texas.

Great tools help make great games.

Wolfenstein 3D took 4 months for the first episode. 6 months for the rest.

Licensed the Wolfenstein engine for Shadowcaster.

We are our own best testing team. There is no throwing it over the fence. There is no QA, just you!

As soon as you see a bug, you fix it! If you don't fix your bug, new code will be built on buggy code.

Doom was based on their D&D campaign, Evil Dead, and Alien.

Use a development system that is superior to your game.

Doom was developed in NextStep systems.

Doom was a 5 person team. Then Tom Hall left, and they hired two more people.

In the middle of building Doom, they had to port Wolfenstein 3D for the Super Nintendo. It took them three weeks.

Doom was INSANELY popular.

The final day of Doom's creation the team worked 30 hours straight. On some computers, the game just froze. Carmack thought about the bug, and fixed it.

Doom II took them 8 months!

Then John made Heretic.

1995, they started working on Quake. With 9 developers/designers.

No code in Doom was used in Quake. Write this code for this game only, not for future games. You are going to be a better coder in the future.

They planned to make Quake on a Cray 64 super computer. Unfortunately Cray was bought by Silicon Graphics and the agreement fell through.

John then made Hexen, but Hexen II was not the same system.

Strife was the very first FPS RPG.

In 1995, 9 developers, released 2 new games.

Created Qtest around this time.

Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves times.

June 22, 1995, 5 pm CST Quake shareware was released in university FTP.

The Pentium FDIV bug was discovered with Quake.

Quake was the first internet multiplayer, Quakeworld was launched, first mouse driven FPS.

Try to code transparently. Coders are not black boxes. Coding is a creative art form based in logic.

They didn't have source control!!!

julia ferraioli

OPEN SOURCE TECHNICAL LEADER @ CISCO

amanda casari

OPEN SOURCE SCIENTIST @ GOOGLE

@juliaferraioli, @amcasari

There are times in our past when open source, or something like open source broke the internet. It is ALL interconnected!

In Open Source, you cannot restrict who uses your technology.

Complexity Theory: unpredictable systems that operate by independent rules. And the emergent system is more complex that its parts.

A sociotechnical system is a complex system that contains people as nodes in the system.

Open Source is a complex sociotechnical system. OSS is fundamentally a human-based system. We have to take in consideration how we as humans interact with each other

A "black swan" event is an evet that disrupts the status quo, causes systematic change, and seem inevitable in hindsight.

Context matters. You have to understand the history behind where systems have evolved over time. And where evolution happens as a disruption of norms.

<sing a long commencing now>

The Morris Worm 1988 - Created by Robert Tappan Morris at Cornell to attack MIT by exploiting transitive trust between sys admins and users.

Morris was the first arrest under the computer fraud act of 1986

We do not assume, now, that everyone is operating in everyone else's best interests. Morris himself helped spread the solution to the worm.

Super homogeneity is now though as a risk.

Heartbleed 2014 - Heartbleed was released is 2012, but publicly announced in 2014. Security flaw in OpenSSL (used EVERYWHERE is TLS). 66% of the internet used OpenSSL.

Heartbleed increased funding towards developers and maintainers of open source software.

Corporations start paying people to work on open source software.

left-pad 2016 - trademark disagreement over an npm package name. The maintainer deleted ALL his libraries, including left-pad, and broke a TON of services.

Npm published the left-pad package without permission of the main maintainer. It is "free to Fork" which should be OK.

Choose your license carefully.

This increased visibility of the cost on maintainer burnout.

New issues abound on maintainer rights.

Fauxpen 2018 - Licensing wars… Companies start using open source as a business strategy. OSS used to be counter culture, now it is corporate culture.

Companies developed OSS n order to monetize it. And at the same time the cloud was born.

The companies that made the OSS started reversing their licenses. Example: Akka.

A haiku:

A need for income

The actors have to get paid

My old friend, Akka

Open source waters are muddied: Open Core is being a thing, where the OSS is a core that is useless, but still open.

Exposed OSS as a business strategy. How can companies be a part of the ecosystem ethically.

Also, capitalism introduced into OSS is a sticky mess.

#TODO(everyone) https://todogroup.org/

OSS is a sociotechnical system. OSS is lost to walled gardens, private conversations, and an overindex on source code. OSS needs to be more transparent.

Glue work is critical, but not recognized. Feature work is given more visibility than glue work for systems, though it is the critical and essential work of OSS.

Our OSS narratives are not complete, they are overindexed by a cult of personality. As long as OSS is captured by hero engineers and cult of personality founders, the system will be broken and glue work will be undervalued.

This is a sustainability problem. We didn't light this fire, but we are here to fight it!

Philipp Haller

ASSOCIATE PROFESSOR AT KTH ROYAL INSTITUTE OF TECHNOLOGY, SWEDEN

@philippkhaller

Closures are essential in Scala. Map and reduce are example of functions that are based off of closures.

Closures are also important for concurrent programming in Java.

If you are using Futures in Scala, you are also using Closures.

BUT, it is also easy to get things wrong while using closures.

A distributed data set is set across multiple data nodes, and the closure has to be serialized across all nodes.

Safety issues stem from unrestricted variable capture within closures. So we could deeply clone an object before using it in the closure as a potential solution.

How do you spot unsafe closures?

Capturing vars (reassignable variables)

In Java, captured variables need to be final, but not in Scala

Mutable types in closures can be an issue

Types that are not serializable

How to write safer closures: verify the creation of the closure

What is the logical snapshot of the memory that the closure should be initialized in?

Verify the semantics of the closure's execution. Does it mutate? Is it transactional? (hint, it shouldn't be)

Introducing Spores3, a new Scala 3 library to prevent these pitfalls.

Spores3 provides a dropin abstraction for closures

Spores3 is a complete reimplementation of spores from Scala.

Macro usage is simple and robust. Designed to be portable from the beginning, as opposed to spores for Scala 2.

val s = Spore((x: Int) => x + 2)

The type is Spore[Int, Int] { type Env = Nothing }

Nothing is the bottom type in Scala. No type has a type of Nothing.

Spore types are subtypes:

sealed trait Spore[-T, +R] extends )t => R) { type Env }

The Env type member of the Spore trait expresses type-based constraints.

A spore parameter can only capture thread-safe types.

We need a flexible way of serializing closures to make them portable. Serialization needs to be determined statically for safety.

Serialization is used for communication, not storage.

Every node needs to be running the same code

We also don't want to pass byte code back and forth.

In practice, we create a names Spore.Builder to create the spore to make a SporeData to "pickle" the spore (aka serialize it).

SporeData factory uses a macro to check for safety!

Bruce Eckel

AUTHOR/CONSULTANT

@BruceEckel

Bruce was studying at the oceanography school at UW!

Cfront was a type of C++ sent to schools on tapes that would generate code to run through a C compiler.

Cfront had virtual classes and dynamic binding.

Simula67 was the first OO language. The common thing you need to do is send messages to step simulations forward.

Smalltalk evolved from Simula to introduce code reuse through inheritance. But Smalltalk is inherently dynamic: it is part of its nature.

Alan Kay regrets not calling OOP Message-oriented Programming. Since OOP is really all about message passing.

C++ took the idea of inheritance and dynamic binding and expanded it. C++ was statically typed…for safety!

With C++, you don't have to use objects if you don't want to.

Then Java came along to say: if objects are good, then objects are the best. Everything is an object! And Static typing is also the best! But…inheritance was a mistake.

What is polymorphism? A type that represents multiple types. Usually as a function parameter. Why would you do this??!?

We are somehow fitting a group of types into a single type.

Ad-hoc polymorphism, aka Overloading. The same function taking different arguments. Under the hood, this is jus two different functions.

Kotlin by default makes all functions final, use the open keyword to make them open.

Overloading is in a lot of languages: Java, C++, Kotlin, etc.

Subtype Polymorphism: "Classic" inheritance. Follows the Liskov Substitution Principle.

Multiple Inheritance: forces an existing set of types into a hierarchy. This is useful if you are handed classes that you cannot change. But…it gets messy.

Multiple inheritance is really just composition in the guise of inheritance.

But true composition is much cleaner than multiple inheritance for code reuse and readability.

C++ is private by default, and it allows you to do private inheritance. It is not used very often.

Parametric Polymorphism: Generics in Java, Templates in C++

Now you have a parameter that creates a class of types instead of just one type. Mostly used for standard libraries for generic use cases.

Parametirc polymorphism allows you to introduce pattern matching! (Which we are getting with Java 19, LET'S GO!)

Kotlin has reified generics, Scala has that too.

Duck Typing: In dynamically typed languages, we can just throw a method at an object, and if it works, it works! "If it quacks like a duck, it is a duck!"

C++ has duck typing through templates. The templates do function overloading for you!

Union Types, aka Sum Types: creating anonymous types by combining multiple types (Type1 | Type2 | Type3)

Union types allow you to get errors at type check time instead of run or compile time (aka faster)

Go has a version of union types, but they are composed differently.

C++ has union types, too, but it is not pretty

Protocols: another way to mash your types together. Now you can have interfaces that invert the control of your inheritance.

Algebraic Data Types (ADTs). Martin was all about Enums in Scala 3. ADTs become case classes in Scala. The ADT makes sure the pattern match is exhaustive.

Type Classes: Type classes allow you to extend generic functions to, again, invert control of execution. A type class is an adapter that is taken care of at compile time.

Multiple Dispatching (need more info here)

Takeaways:

Why do we want to treat multiple types into a single type: capturing and reusing concepts.

Don’t do it without questioning!

Was OO a mistake? No, sometimes it is quite useful, just not ALL THE TIME.

Ad-hoc polymorphism is used all over the place: map, foldLeft, FoldRight, flatMap, etc.

Gjeta Gjyshinca

SOFTWARE DEVELOPER, MORGAN STANLEY

A monad is a container that abstracts away execution.

Today we will concentrate on Futures, which allow us to write sync and non-blocking code. But they invade our type system.

The problem with most systems is the bottleneck of sequential code. What is a solution: Futures!

Scala gives you a for/yield comprehension abstraction to fix this, BUT it is just syntactic sugar for map ad flatMap. But if you move executions out of the for comprehension, they can ne lazily evaluated async. But now your code is double the size, and much less clear than declarative styles of programming.

Execution concerns have leaked into our type systems! VERY NO!

We want to solve the business problem, but we have to build a lot of structure around it to get it to run the way we want it. That's annoying.

If you have a blocking call that makes async futures, the blocking call is STILL blocking, you have to wait still, the block issue isn't solved.

Where does composability and debugging comes in? I don't want a future of what I want, I just want what I want.

What if you want more than one thing, you have to get sequences of future,  now you need cancellable futures, now you can have Future[Seq[CancellableFuture[Metrics]]]. Now it is getting silly. But this is real code!

Type acrobatics are not fun! Why are we spending our mental energy playing with the type system.

A possible solution is 'free' Monads. Make all your code lazy, nothing runs until it is needed.

What about applicatives with effects, though? People don't want to deal with that. You cannot only hire phDs! It is hard enough hiring ANYBODY!

Multicore is here. Why isn't FP winning? IT is immutable! That solves thread safety! Referential transparency! That is repeatable execution: same input same output every time. Portability! Cacheable results! Purity! No side effects! Compossibility! You can map higher order functions to others.

FP is not doing well because it is not the code you want to write.

The problem is the platform. But category theory has provided a solution, but it is absurdly complicated, so 'free' monads really doesn't solve it.

If the solution requires a phD to understand, it is not a good solution.

Check out blog "What color is your function"

Does C++ solve memory management? NO! Does the JVM manage concurrency? NO!

What is a language that natively solves concurrency? SQL!!!!!! (shock!)

SQL solves for concurrency.

What is the runtime?

Garbage collectors allowed us to stop thinking about pointers. The runtime can give you a lot back. Can we make a runtime that makes it so you never hav to think about concurrency? Like SQL?

MorganStanley introduces the @node annotation to Scala. @node tells the runtime that the function is referentially transparent. The @node annotation turns the function into an async state machine. The developer doesn't have to think about futures, etc. anymore.

The @node annotation will behind the scenes batch data calls together if they re going to the same datastore. Since the reads on data stores are referentially transparent, the data is cacheable at a fixed point, so the @node automatically caches sequential call results.

The @node is a monad, but you as the developer do not have to THINK about it being a monad. And that is a HUGE win.

Marian Petre

CENTRE FOR RESEARCH IN COMPUTING, THE OPEN UNIVERSITY

Software errors are inevitable

Experts see errors as opportunities - to stumble onto insight.

They hold off swatting the bug, they say "Hold on, what is that?"

High performing teams: produce software on time, without bugs, and with no bad smells

What is the nature of high performing developers: what do they do, not what they SHOULD do.

Active Error: these are human errors during the task: typos, lack of attention, and mistakes. Faulty decisions.

For recovery, you have to see the error, understand how to fix it, and then fix it. But these can be missed.

What is it that experts do that give them better results? They reflect on the problem and the solution scope.

Experts don't just fix one bug, they see the others bugs coming out of it. They thing of dependencies, they see the deeper issues, like flaws and misconceptions.

Software developers do not work in an ideal world

We tolerate:

Software is like a lab. Apparatus: It is tested for standard operating procedures.

We, then tolerate bugs that are outside the standard operating procedure: e.g. You do not care if a system in the artic can withstand 100+ degree temperature.

We wrap code to prevent code from working outside the needed errors.

We defer:

Sometimes we defer the problem. Sometimes we have to walk away from the solution. Experts recognize they are thrashing, and stop to pause. The novice will continue to thrash.

We compromise:

Experts will make deliberate suboptimal choices to move the project forward.

Developers break down and create incremental solutions to get to the cognitive space they need to find a greater solution.

YAGNI: You ain't gonna need it. Delay the decisions that are not important. You focus on what needs to be addressed first. Focus on the essence

When you compromise on the unimportant, in the end you won't compromise anything.

There are good reasons to tolerate, defer, and compromise

Great programmers KEEP TRACK of when they do this and pay attention to the decisions they are making.

Experts mind the gaps: they examine where they are not focusing on right now.

Experts challenge confirmation bias. They are the skeptic in the corner. They try to figure out how it fails.

Experts make MORE errors and mistakes than novice developers, they just understand the safety nets.

Not just "How do I know this is right" but "how do I know this is wrong?" They KNOW that code is read by PEOPLE. So they write code and comments to explain why the code is written the way it is.

We gain understanding though breaking things and fixing them again.

We tend to fix familiar flaws. Experts think outside the familiar.

Experts reflect on their tools as well as their code. They play their methods against each other. They write code to test their test harnesses.

The selection of tools is not arbitrary. They try tools and play around. They discard what is not needed.

"Solving the problem is NOT the problem. Understanding the problem is the problem."

Most software errors are requirements errors.

Developers know they can step away from tools and methodologies to investigate issues.

Developers can distinguish between their tools and their goals.

Pair de-bugging is a powerful way to learn the codebase and growing expertise.

Experts don't expect to know everything. In fact, they deny their own expertise. To find the expert, ask everyone in the office and go to the person everyone is pointing to, and whom is pointing to someone else.

Experts reach out to other experts. You don't know everything, but there is probably someone that might. Experts know to ask others early.

Experts use systematic disciplined practices that are socially embedded and reinforced by their environment.

The team culture provides the safety net. The focus is on fixing the error not assigning the blame.