johnsuder

Hi,

Over 16 years I've seen Scrum and Agile in-name-only done as pure performance theater but I've also see it done right. I was surprised to observe how much friction was created by the tools (Jira, Azure DevOps, Gitlab, Shortcut, etc.) and how they tend to encourage anti-Agile patterns.

Mevali is my attempt at genuinely Agile flavored software:

- stories fit on a note card and are structured around who benefits, what they need (short!), numeric estimate of worth, optionally why, and some acceptance criteria.

- oversized work can be split/reorganized really quickly.

- standup shows status by person and work item so people can collaborate rather than give a status report the software can provide.

- retro experiments stay visible during the next period of work.

- planning uses Monte Carlo simulation plus dependencies and team availability.

I’m not trying to convince teams to do Scrum if they hate it. I’m trying to remove a lot of the waste for user oriented teams that collaborate.

I’d love feedback, especially from people who have strong opinions about Jira, Scrum, Kanban, planning, etc..

I've used that style in 3 different companies over the last 10 years and I assumed the technique was ubiquitous. This just goes to show the standard deviation in engineering culture is high. There are some large bodies of water but also lots and lots of little isolated tide pools.

I apologize for the wall of text above, autobiography, and the sloppy questions. The repo documentation is very comprehensive about the language >>features<< and tool chain. I was hoping to get a little more clarity on the intended audience, and project roadmap / where this is in its lifecycle.

Is your audience language enthusiasts? Or working developers looking to try something on a small project?

Is this an experimental language where you are testing out language ideas and soliciting feedback? Or did you already build something substantial with this and you are releasing early so others can build too? If you built something with this already then that would be an awesome story to tell.

It looks like `check` checks the types as a command line operation. When I asked about the feedback loop I suppose I was asking if a language server was on your roadmap and how you would envision engineers working in the future.

Again, this is really impressive work and really exciting to Lisp and static type lovers.

This looks awesome!

I think it might benefit from additional context and selling of the solution. I am probably adjacent to the target audience and I am struggling to grasp the scope of this. I think this might be HUGE but the fact that I am struggling to assess its enormity might be signal to you that a brief problem statement early in your documentation might help.

My Lisp family experience: 3 books on Common Lisp and around 5,000 lines of Common Lisp. Read Structure and Interpretation of Computer Programs twice (Scheme). Tinkered with Racket (co-routines and flow-typing). Read two books on Clojure. I "get" the power of macros (understanding anaphoric / deictic macros).

Spent 4 years working with PureScript, Haskell, and Elm.

So given all of that... a static type system for a Lisp... I have been in PureScript, Haskell, Elm for production code so I've been out of this sphere. How novel is that? That seems pretty awesome to me. Static types + macros is cool - to say the least. How do the static types actually interact with the developer experience? Do you have a language server? What is the feedback loop for identifying type errors i.e. IDE, compile-time, run-time?

What is the specific "value-add" here? Is it a homoiconic language over Odin so you can write macros and so implement DSLs? Or that you introduce identity/state patterns for functional programming with some mutation Clojure style?

I love the concept and see the value for refactoring. There is tremendous value in knowing that two implementations are run-time equivalent.

I just wanted to share for others that there is a configuration language call Dhall (https://dhall-lang.org/) that has this kind of guarantee as one of its nicest features. See the "Refactor Fearlessly" section. In Dhall, most behavior preserving refactors produce the exact same hash code so you can know - for an absolute fact - that a refactor is behavior neutral. The point of sharing that other language is just to legitimize that "this is a thing" i.e. it has value recognized by others.