Home
constants, orders
Gleam

Master Weather Ranking in Gleam: Complete Learning Path

Code is displayed on a computer screen.

Master Weather Ranking in Gleam: Complete Learning Path

Unlock the power of type-safe data manipulation in Gleam by mastering the Weather Ranking module. This guide provides a comprehensive walkthrough of parsing, sorting, and formatting structured text data, a fundamental skill for building robust applications, from data processing pipelines to dynamic leaderboard generation.

The Frustration of Unruly Data

Imagine you're building a sleek new weather dashboard. You've just connected to a third-party API that feeds you raw weather data as a multi-line string. Each line contains a city, its rainfall, and the current temperature, but it's all jumbled together. Your task seems simple: display a clean, ranked list of the cities from lowest to highest temperature. But as you start coding, the complexity mounts.

You find yourself wrestling with string splitting, type conversions that might fail, and sorting logic that feels brittle. A single malformed line from the API could crash your entire process. This is a common pain point for developers—taming messy, unstructured text data into a reliable, ordered format. It’s a challenge that demands precision, error handling, and clarity.

This is precisely where Gleam, with its powerful static type system and functional principles, truly shines. The kodikra.com Weather Ranking module is designed to guide you through this exact problem, transforming you from a data wrangler into a data maestro. You will learn not just how to solve the problem, but how to solve it elegantly and safely, writing code that is readable, maintainable, and resilient to errors.

What Exactly is the Weather Ranking Challenge?

At its core, the Weather Ranking problem is a classic data transformation task. The goal is to take a raw, multi-line string containing weather information for various cities and convert it into a single, beautifully formatted string. This output string must present the cities ranked by temperature in ascending order.

This process can be broken down into three primary stages:

  • Parsing: Reading the raw string input and converting each line into a structured data format that your program can understand. This involves splitting strings, converting text to numbers, and handling potential errors gracefully.
  • Sorting: Implementing the ranking logic. The primary sorting key is the temperature (lowest first). If two cities have the same temperature, a secondary sorting key—the city name in alphabetical order—is used to ensure a deterministic output.
  • Formatting: Taking the sorted, structured data and converting it back into a specific string format for display. This often involves padding, concatenation, and careful layout control.

This single challenge encapsulates a wide range of fundamental programming skills that are essential for any developer working with data, regardless of the language.

Why Use Gleam for Data Manipulation?

While you could solve this problem in many languages, Gleam offers a unique set of advantages that make it exceptionally well-suited for such tasks. Its design philosophy prioritizes clarity, correctness, and developer happiness, which directly addresses the common pitfalls of data processing.

Unbreakable Type Safety

In languages like Python or JavaScript, you might represent weather data as a dictionary or a plain object. This is flexible but dangerous. A typo in a key name (e.g., "temprature" instead of "temperature") would only be caught at runtime, potentially causing a crash in production. Gleam eliminates this entire class of errors with its custom types.

By defining a custom type, you create a contract with the compiler. It guarantees that every piece of weather data will always have the correct fields with the correct data types. This compile-time safety net is invaluable.

// In Gleam, we define a clear, unbreakable structure.
// The compiler enforces this everywhere.
pub type WeatherData {
  WeatherData(city: String, rainfall: Int, temperature: Int)
}

Expressive Pattern Matching

Extracting data from strings and lists is clean and declarative with Gleam's pattern matching. Instead of chaining multiple function calls and index accessors, you can destructure data in a way that mirrors its shape, making the code's intent immediately obvious.

This is especially powerful when parsing lines of text. You can match on the expected number of elements after a split and handle success and failure cases in one elegant expression.

Immutability and Pure Functions

Gleam encourages a functional style where data is immutable. You don't modify data in place; you create new data through transformations. This results in a predictable data flow that is easier to reason about, test, and debug. The entire Weather Ranking process can be modeled as a pipeline of pure functions, where each function takes data in and produces new data without any hidden side effects.

// A predictable pipeline: each step is a pure transformation.
raw_input
|> parse_input()
|> sort_data()
|> format_output()

How to Implement Weather Ranking: A Step-by-Step Guide

Let's dive into the practical implementation. We'll build the solution from the ground up, following the logical flow from raw input to formatted output. This structured approach is central to the kodikra learning path.

Step 1: Modeling the Data with Custom Types

The first and most crucial step is to define a robust data structure. A custom type is the perfect tool for this. It provides a named, structured container for our weather information, ensuring data integrity throughout our program.

import gleam/int
import gleam/string
import gleam/list
import gleam/result
import gleam/order.{Order}

// Define the shape of our data.
// This is the single source of truth for what weather data looks like.
pub type WeatherData {
  WeatherData(city: String, temperature: Int)
}

In this simplified model, we're focusing on the city and temperature, as they are the only fields required for sorting and formatting. This focused approach keeps our logic clean and relevant to the task.

Step 2: Parsing the Input String

Next, we need a function to convert a single line of the input string into our WeatherData type. This function must be resilient; it should handle valid lines correctly and gracefully report failure for malformed lines. Gleam's Result type is perfect for this.

The ASCII diagram below illustrates the parsing logic for each line.

    ● Start with a single line (String)
    │
    ▼
  ┌──────────────────┐
  │ string.split(",") │
  └─────────┬────────┘
            │ e.g., ["London", "10"]
            ▼
    ◆ Is it a list with 2 elements?
   ╱                ╲
 Yes                 No
  │                   │
  ▼                   ▼
┌─────────────────┐  ┌──────────────┐
│ Destructure list │  │ Return Error │
│ `[city, temp_str]`│  └──────────────┘
└─────────┬───────┘
          │
          ▼
    ┌──────────────────┐
    │ int.parse(temp_str) │
    └─────────┬─────────┘
              │
              ▼
        ◆ Is parse successful?
       ╱                ╲
     Ok(temp_int)        Error
      │                   │
      ▼                   ▼
┌───────────────────┐  ┌──────────────┐
│ Create WeatherData│  │ Return Error │
└───────────────────┘  └──────────────┘
          │
          ▼
    ● Return Ok(WeatherData)

Here is the Gleam code that implements this flow. Notice how pattern matching makes the destructuring step clean and safe.

// This function attempts to parse one line.
// It returns a Result, which forces the caller to handle success and failure.
fn parse_line(line: String) -> Result(WeatherData, Nil) {
  case string.split(line, on: ",") {
    [city_str, temp_str] -> {
      // Try to convert the temperature string to an integer
      case int.parse(temp_str) {
        Ok(temp_int) ->
          // Success! Wrap the new WeatherData in an Ok
          Ok(WeatherData(city: city_str, temperature: temp_int))
        Error(_) ->
          // The temperature part was not a valid integer
          Error(Nil)
      }
    }
    // The line did not split into exactly two parts
    _ -> Error(Nil)
  }
}

Step 3: Sorting the Data with a Custom Comparator

With our data parsed into a list of WeatherData records, the next step is sorting. Gleam's list.sort function is highly flexible; it accepts a custom comparison function that tells it how to order any two elements.

Our sorting rules are:

  1. First, compare by temperature in ascending order.
  2. If temperatures are equal, compare by city name in alphabetical (ascending) order.

This logic is encapsulated in a comparator function that returns an Order enum (Lt, Eq, or Gt).

This diagram shows the decision-making process inside the comparator.

    ● Comparator receives (A, B)
    │
    ▼
  ┌───────────────────────────┐
  │ temp_order = int.compare │
  │ (A.temperature, B.temperature) │
  └────────────┬──────────────┘
               │
               ▼
    ◆ Is temp_order == Eq?
   ╱                       ╲
 Yes (temps are equal)      No
  │                         │
  ▼                         ▼
┌──────────────────────┐  ┌──────────────────┐
│ city_order = string.compare │  │ Return temp_order │
│ (A.city, B.city)     │  └──────────────────┘
└────────────┬─────────┘
             │
             ▼
    ● Return city_order

And here is the corresponding Gleam function. The use of case makes the multi-level comparison logic explicit and easy to follow.

// A comparator function that defines our sorting rules.
// It takes two WeatherData records and returns an Order.
fn compare_weather_data(a: WeatherData, b: WeatherData) -> Order {
  // First, compare temperatures
  case int.compare(a.temperature, b.temperature) {
    // If temperatures are equal, then compare by city name
    order.Eq -> string.compare(a.city, b.city)
    // Otherwise, the temperature order is definitive
    other_order -> other_order
  }
}

// Example usage:
// let sorted_list = list.sort(weather_data_list, by: compare_weather_data)

Step 4: Formatting the Sorted Data

The final step in our pipeline is to convert the sorted list of WeatherData back into strings, formatted according to the specification. For this, gleam/string_builder is often more efficient than repeated string concatenation, especially for large lists.

import gleam/string_builder.{StringBuilder}

// Converts a single WeatherData record into its final string representation.
fn format_weather_data(data: WeatherData) -> String {
  let temp_str = int.to_string(data.temperature)
  
  // Example format: "City: XX"
  string_builder.from_strings([data.city, ": ", temp_str])
  |> string_builder.to_string()
}

Step 5: Orchestrating the Entire Pipeline

Now we combine all the pieces into a single public function. This function will serve as the entry point to our module. It takes the raw input string and performs all the steps in sequence. Using the pipe operator |> makes this data transformation pipeline incredibly readable.

pub fn rank_weather(input: String) -> String {
  input
  // 1. Split the raw input into individual lines
  |> string.split(on: "\n")
  // 2. Try to parse each line, keeping only the successful results
  |> list.filter_map(parse_line)
  // 3. Sort the list of WeatherData using our custom comparator
  |> list.sort(by: compare_weather_data)
  // 4. Convert each sorted WeatherData record back into a formatted string
  |> list.map(format_weather_data)
  // 5. Join all the formatted strings back together with newlines
  |> string.join(with: "\n")
}

This elegant pipeline demonstrates the power of functional composition in Gleam. Each step is a distinct, testable transformation, leading to a final result that is clear, concise, and correct by construction.

To test your solution from the command line within the kodikra learning environment, you would typically run:

gleam test

This command executes the test suite for the module, validating your implementation against a series of predefined test cases.

Real-World Applications of This Pattern

The "Parse, Sort, Format" pattern you learn in this module is not just an academic exercise; it's a fundamental building block used in countless real-world applications:

  • Leaderboard Systems: Ranking players in a game, first by score (descending), then by name (ascending).
  • Data Reporting: Generating financial reports that list transactions sorted by date, then by amount.
  • Log Processing: Parsing server logs, sorting them by timestamp, and formatting them for analysis.
  • E-commerce Platforms: Displaying products sorted by price, with a secondary sort by customer rating.
  • API Response Formatting: Taking raw data from a database and formatting it into a clean, sorted JSON or XML response.

Mastering this pattern in Gleam gives you a powerful tool for building reliable data processing systems.

Pros and Cons of Gleam's Approach

Every technical approach has trade-offs. Being an expert means understanding not just how to do something, but why it's a good (or bad) fit for the situation. Here's a comparison of Gleam's statically-typed, functional approach versus a more traditional dynamic approach for this task.

Aspect Gleam (Static & Functional) Dynamic Languages (e.g., Python/JS)
Data Integrity Pro: Guaranteed by the compiler via custom types. Impossible to have a record with a missing or misspelled field. Con: Relies on programmer discipline. Typos in dictionary keys or object properties are common runtime errors.
Error Handling Pro: Explicit and enforced. The Result type forces developers to handle parsing failures. Con: Often implicit. Can lead to unhandled exceptions (e.g., `TypeError`, `KeyError`) if not carefully managed with try/except blocks.
Readability Pro: The data pipeline (`|>`) and pattern matching make the code's intent very clear and declarative. Neutral: Can be readable, but imperative loops and nested conditionals can sometimes obscure the overall data flow.
Initial Development Speed Con: Requires more upfront thought to define types. Can feel slower for very simple, one-off scripts. Pro: Very fast for prototyping. No need to define schemas or types, allowing for rapid iteration.
Refactoring & Maintenance Pro: Extremely safe. The compiler acts as a refactoring guide, pointing out every location that needs to be updated if a data structure changes. Con: Can be risky. Changing a data key's name requires a project-wide search-and-replace, with no guarantee of catching everything.

Your Learning Path Forward

The Weather Ranking module is a fantastic way to solidify your understanding of core Gleam concepts. By completing it, you will gain hands-on experience with some of the language's most powerful features.

Progression Order

This module contains one core exercise that builds upon fundamental Gleam skills. To succeed, you should be comfortable with basic syntax, functions, and list operations before starting.

  1. Weather Ranking: This is the capstone exercise for this module. Apply your knowledge of custom types, pattern matching, list manipulation, and sorting to solve a practical data processing challenge.

After mastering this module, you will be well-prepared to tackle more complex data structures and algorithms. We encourage you to continue your journey through our comprehensive curriculum.

Explore the full Gleam Learning Roadmap to see what challenges lie ahead.

Frequently Asked Questions (FAQ)

Why is a custom type better than a Tuple for this problem?

While a tuple like #(String, Int) could work, a custom type WeatherData(city: String, temperature: Int) is far superior for readability and maintenance. With a custom type, you access fields by name (e.g., data.city), which is self-documenting. With a tuple, you use indices (e.g., tuple.0), which are opaque and error-prone, especially if the data structure changes later.

What is the purpose of `list.filter_map` in the final pipeline?

The list.filter_map function is a highly efficient combination of filter and map. Our parse_line function returns a Result(WeatherData, Nil). filter_map iterates through the list of results, unwrapping all the Ok(data) values into a new list and discarding all the Error(Nil) values in a single pass. This is the perfect tool for cleaning up a list after a parsing operation that might fail.

How does Gleam's sorting comparator differ from other languages?

The core concept is similar to many languages (e.g., Python's `functools.cmp_to_key` or Java's `Comparator`). However, Gleam's approach is more type-safe. The comparator function is required by the type system to return a specific order.Order enum (Lt, Eq, Gt). This prevents common bugs where a comparator might return incorrect values like `0`, `1`, `-1` in an inconsistent way. The compiler enforces correctness.

Could I use an external library for parsing, like for CSV?

Absolutely. For more complex, real-world scenarios involving standard formats like CSV or JSON, using a well-tested library from the Gleam ecosystem (like `gleam_csv` or `gleam_json`) is the recommended approach. This kodikra module, however, focuses on teaching you the fundamental principles by building the parser from scratch, so you understand exactly what those libraries are doing under the hood.

What is the performance implication of this functional pipeline approach?

For most datasets, the performance is excellent. The Gleam compiler and the underlying Erlang BEAM or JavaScript runtime are highly optimized for this style of programming. While this approach creates intermediate lists at each step, these are often optimized away by the compiler or are handled very efficiently by the garbage collector. The massive gains in code clarity, correctness, and maintainability almost always outweigh any micro-optimizations you might get from a manual, imperative loop.

What's the best way to handle different temperature units (e.g., Celsius and Fahrenheit)?

That's an excellent question that points to the next level of data modeling. You could extend the custom type to include the unit, for example: pub type Temperature { Celsius(Int) | Fahrenheit(Int) }. Your WeatherData type would then hold a Temperature. The parsing logic would become more complex to detect the unit, and the sorting comparator would need a helper function to convert all temperatures to a common unit before comparison. This shows how Gleam's type system scales to handle more complex business logic gracefully.

Conclusion: From Data Chaos to Code Clarity

The Weather Ranking module is more than just a coding exercise; it's a practical demonstration of Gleam's core philosophy. By working through it, you've seen how a potentially messy and error-prone data manipulation task can be transformed into a clean, predictable, and robust pipeline of functions. You have leveraged custom types for data integrity, pattern matching for declarative parsing, and higher-order functions for powerful sorting logic.

These skills are the bedrock of reliable software development. By internalizing this "Parse, Sort, Format" pattern, you are now better equipped to handle any data-centric challenge that comes your way, writing code that is not only correct but also a pleasure to read and maintain.

Disclaimer: The code snippets and explanations in this guide are based on Gleam v1.x and its standard library. As Gleam evolves, some function names or module paths may change. Always refer to the official Gleam documentation for the most current information.

Back to the Complete Gleam Guide

Published by Kodikra — Your trusted Gleam learning resource.

Post a Comment