Not really I’m afraid. Effects can be anywhere and they are not wrapped at all.

In technical terms it’s stack-oriented meaning the only way for functions (called “words”) to interact with each other is via a parameter stack.

Here’s an example:

: TIMES-10  ( x -- y )
  10 
  * 
;

12
TIMES-10
.S
120

TIMES-10 is a word which pops one parameter from stack and pushes the result of its calculation onto stack. The ( x -- y) is a comment which conventionally documents the “stack effect” of the word.

Now when you type 12 and press RETURN, the integer 12 is pushed onto stack. Then TIMES-10 is called which in turn pushes 10 onto stack and invokes * which pops two values from stack and multiplies them and pushes the result onto stack.

That’s why when type .S to see the contents of the stack, you get 120 in response.

Another example is

5 10 20 - *
.S
50

This simple example demonstrates the reverse Polish notation (RPN) Forth uses. The arithmetic expression is equal to 5 * (20 - 10) the result of which is pushed onto stack.

PS: One of the strengths of Forth is the ability to build a vocabulary (of words) around a particular problem in bottom-to-top fashion, much like Lisp. PPS: If you’re ever interested to learn Forth, Starting Forth is a fantastic resource.

Besides the fun of stretching your mental muscles to think in a different paradigm, Forth is usually used in the embedded devices domain (like that of the earlier Mars rover I forgot the name of).

This project for me is mostly for the excitement and joy I get out of implementing a Forth (which is usually done in Assembler and C) on the JVM. While I managed to keep the semantics the same the underlying machinery is vastly different from, say, GForth. I find this quite a pleasing exercise.

Last but not least, if you like concatenative but were unable to practice fun on the JVM, bjForth may be what you’re looking for.

Hope this answers your question.

Whoa! This is pretty rad! Thanks for sharing!

That’s definitely an interesting idea. Thanks for sharing.

Though it means that someone down the line must have written a bootstrap programme with C/Assembler to run the host forth.

In case of jbForth, I decided to write the bootstrap too.

That’s impossible unless you’ve got a Forth machine.

Where the OS native API is accessible via C API, you’re bound to write, using C/C++/Rust/etc, a small bootstrap programme to then write your Forth on top of. That’s essentially what bjForth is at the moment: the bootstrap using JVM native API.

Currently I’m working on a set of libraries to augment the 80-something words bjForth bootstrap provides. These libraries will be, as you suggested, written in Forth not Java because they can tap into the power of JVM via the abstraction API that bootstrap primitives provide.

Hope this makes sense.

Haha…good point! That said bjForth is still a fully indirect threaded Forth. It’s just that instead of assembler and C/C++ it calls Java API to do its job.

Done ✅

Thanks for your interest 🙏

Please do drop a line in either !lemmy_meter@lemmy.ml or #lemmy-meter:matrix.org if you’ve got feedback/ideas for a better lemmy-meter. I’d love to hear them!

Oh and feel free to link back to lemmy-meter from Blåhaj if you’d like to, in case you’d prefer the community to know about it.

First off, I was ready to close the tab at the slightest suggestion of using Velocity as a metric. That didn’t happen 🙂

I like the idea that metrics should be contained and sustainable. Though I don’t agree w/ the suggested metrics.

In general, it seems they are all designed around the process and not the product. In particular, there’s no mention of the “value unlocked” in each sprint: it’s an important one for an Agile team as it holds Product accountable to understanding of what is the $$$ value of the team’s effort.

The suggested set, to my mind, is formed around the idea of a feature factory line and its efficiency (assuming it is measurable.) It leaves out the “meaning” of what the team achieve w/ that efficiency.

My 2 cents.

Good read nonetheless 👍 Got me thinking about this intriguing topic after a few years.

A bit too long for my brain but nonetheless it written in plain English, conveys the message very clearly and is definitely a very good read. Thanks for sharing.

When i read the title, my immediate thought was “Mojolicious project renamed? To a name w/ an emoji!?” 😂

We plan to open-source Mojo progressively over time

Yea, right! I can’t believe that there are people who prefer to work on/with a closed source programming language in 2023 (as if it’s the 80’s.)

… can move faster than a community effort, so we will continue to incubate it within Modular until it’s more complete.

Apparently it was “complete” enough to ask the same “community” for feedback.

I genuinely wonder how they managed to convince enthusiasts to give them free feedback/testing (on github/discord) for something they didn’t have access to the source code.

PS: I didn’t downvote. I simply got upset to see this happening in 2023.

I’ve been using sdkman for about a decade now and am totally pleased w/ it. It does a very good job of managing JDK versions for you and much more, eg SBT, Gradle, Scala, Groovy, Leiningen, SpringBoot, …

Now, technically you could use sdkman in your CI/CD pipeline too but I’d find it a strong smell. I’ve always used dedicated images pre-configured for a particular JDK version in the pipeline.

I work primarily on the JVM & the projects (personal/corporate) I work w/ can be summarised as below:

1. Building & running the repo is done on the host using an SCM (software configuration management tool) such as Gradle or SBT.
2. The external dependencies of the repo, such as Redis, are managed via adocker-compose.yml.
3. The README contains a short series of commands to do different tasks RE (1)

However one approach that I’ve always been fond of (& apply/advocate wherever I can) is to replace (3) w/ a Makefile containing a bunch of standard targets shared across all repos, eg test, integration-test. Then Makefiles are thinly customised to fit the repo’s particular repo.

This has proven to be very helpful wrt congnitive load (and also CI/CD pipelines): ALL projects, regardless of the toolchain, use the same set of commands, namely

• make test
• make integration-test
• make compose-up
• make run

In short (quoting myself here):

Don’t repeat yourself. Make Make make things happen for you!

Since I haven’t heard/read about any bugs, I plan to release v5.0.0 on the 13th (😬)

I’ll keep this post, well, posted 🙂

Recently, I’ve found myself posting more often on Mastodon a Lemmy & blog way less - indeed credits go to Fediverse and the mods for making it a safe and welcoming place ❤

Here’s my latest one: https://www.bahmanm.com/2023/07/firefox-profiles-quickly-replicate-your-settings.html

It’s not self-hosted, rather I’m using Google’s blogspot. I used to host my own website and two dozens of clients’ and friends’ until a few years ago (using Plone and Zope.) But at some point, my priorities changed and I retired my rock-solid installations and switched to blogspot.

I used to be in a relatively similar position years ago so I totally relate to what you’ve got to do on a daily basis.

These are the the titles that come to my mind (leaving ths seniority level up to you):

• Software engineer
• Software engineer in Integrations
• Software engineer in Enterprise Applications
• ERP Implementation consultant

Bookmarked!

Oh, I see. It kind of makes sense. Who’d need Jython when GraalVM’s out there nowadays!? Well, unless it’s a legacy app 😬

I genuinely wonder why the downvotes?

Good refresher on the topic and ineteresting gory details of CPython impl.

On another note, is Jython still a thing?

Effective method…so long as your kid doesn’t hate you 😂 in which case, IMHO, it should be a favourite aunt/uncle/teacher/… who introduces them to the topic while the parents try to stay quite on the topic as much as possible.