Skip to content

CSEC: migrate to java-slang #80

Description

@martin-henz

All visualization should migrate here, from frontend: https://github.com/source-academy/frontend/tree/master/src/features/cseMachine/java

Frontend should be programming-language agnostic.

An issue: How about utils? https://github.com/source-academy/frontend/tree/master/src/features/cseMachine/utils

Activity

  1. mattcce commented on Sep 13, 2025

    @mattcce
    Contributor

    This is my personal opinion; just trying to throw some ideas on the table for future maintainers.

    The way I view the CSE machine is exactly as mentioned: language-agnostic. So from a superficial perspective, it makes sense that the visualisation is implemented in the frontend, and the frontend merely exposes as powerful of an interface as is needed for even the most expressive language to be properly represented (I think Java right now fits that bill as it has one entire new component - classes).

    If we go down the route of deciding that while the CSE abstract machine is in itself not a concrete realisation of a CSE machine that actually executes programs in a particular language, then it makes sense to move all of them back into their respective sublanguage repos. The only problem is that the styling must be kept consistent still across all realisations of CSE machines. Even then, it's still rather disconcerting to have to handle visualisation in sublanguage repos (that feel like they should be entirely focused on only the backend).

    One way I see that might fix this is to maintain CSE machine UI components in a separate repo (UI/component library) altogether that all sublanguage repos can use.

  2. martin-henz commented on Sep 13, 2025

    @martin-henz
    MemberAuthor

    The situation is analogous to our modules. They have a bundle of functions and a visualization that lives in a frontend tab. Both are loaded dynamically.

    We played with the idea of having a "generic" CSE machine (including visualization) last year. However, I think that the languages are too different in practice for a common visualization. Providing a common visualization codebase will make maintainance more complex. There will be some duplication as a result, but I think we can live with that. Let's find a good place for common util functions, maybe js-slang?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions