What, in particular, are you looking for?

Something like enum variants?

Fixed, thanks for reporting!

It was correct on the main Factor website, but my blog was using the old links before we fixed the macos rename.

I agree, I've written much better Factor code. This was mainly to get a matching test case working simply...

I'm a bit biased as I've been working on and with Factor for 15 years and I am also the author of the linked article and "Re: Factor" blog.

I find Factor to have a compelling sweet spot of concise syntax, dynamic features, and (relatively) high performance. But in particular, I think we've done a good job with a few things:

1) Making the language very "clickable", so you can introspect and dig down into all function and type definitions.

2) Provide a lot of batteries-included in the standard library.

3) Make it super easy to accept contributions, there's a part of the distribution that is "extra" and has low barrier to entry and then we commit to keeping code working and promoting things to the main standard library when they are useful/documented/tested enough.

I always suspected that Factor appeared as an attempt to re-live Forth magic, but at higher level, more applicable outside of embedded domain

We are pretty proud of this release, it represents a big upgrade over the last one.

Getting dangerously close to 1.0. Congrats!

It won’t actually argue all sides of an issue. Take any controversial one, and it stays inside its guardrails no matter which opinion you want it to counter.

This type of product might be better served by using a completion API in the format of a debate, rather than chat api, to avoid the filters. Unfortunately, OAI made that too costly for most.

It will never happen. Its too politically suicidal to make money off of providing a service that gives arguments that go against the traditional narrative

Made the same experience. AI immediately went out of its way to agree with my ultra politically correct "opinion".

test

Comparative data across the Tesla fleet, by model and production years, is so interesting!

I love the Tesla approach to continuous improvement, and the Nikola app seems really cool!

This is David. I made Nikola. Glad you like the app! Happy to answer any questions you or anyone else has on the data / research here.

We did start a conversation about building a package manager, but have not had anyone champion this as a project. I admit to being a little lazy about this due to including so much code in the main repository.

https://gist.github.com/jckarter/3440892

I admit I have not read into detail the above specification, but I think that an approach in the style of Metacello (from the SmallTalk community) would be simple to develop and fit Factor nicely.

There need not be changes to the way vocabularies are loaded: instead one can make some words that change the vocab roots according to some configuration files. One could have a FACTOR-ROOT/cache directory in addition to work, core, and extras, where packages are arranged by version. Then some machinery could set the right vocab-roots based on a specification.

One would need

- some words to create structure that describe packages (Maven-like). This would allow to declaratively say that my project, at version x, consists of this and that vocabulary, and relies on project foo at version y and project bar at version z

- some words to automate fetching the dependencies of my project recursively from common repositories (one could start with github)

- a word to set the vocab roots according to my dependencies

Ideally, I would like to write a configuration file that lists my dependencies and then do something like

    USE: my project.config
    myconfig set-deps

On top of this, one could develop GUI tools to automate writing specification files, or even suggesting officially endorsed packages. See for instance the GUI tools in Pharo for a great example of this.

The advantage would be that we would not have any changes to the way vocabularies are loaded, and the change would be much more incremental

Although I must add that probably the monolithic approach that is being used right now has helped a lot to avoid fragmentation

The releases have varied over the years from less than a year, to almost two years between "releases". For some historical context:

0.93 was released April 16, 2010.

0.94 was released September 18, 2010 (+5 months).

0.95 was released August 16, 2012 (+23 months, 2500 commits).

0.96 was released April 20, 2013 (+9 months, 1100 commits).

0.97 was released November 1, 2014 (+19 months, 1400 commits).

The core developers (I am one) generally use the latest development version which, except for some changes to the build farm a few months ago, is made available as tested nightly builds from our build farm.

A partial reason for the delayed release was waiting for sufficient changes to "justify" a release (a bit of a soft qualitative delay, especially as we kept working on some new features). Going to a time-based release schedule might be nice, something to think about anyway.

Eh, the Rakudo Perl 6 implementation has been doing monthly releases since before 2010, and I don't get the impression that's done much to convince doubters. (Despite amazing progress since 2010.) Those of us working on developing it mostly grab the latest source from github and work from that, much the same as you guys.

Keep the faith, the world needs more powerful, offbeat languages!