(HN has indentation, though.)

It’s important to realize that this is good design. It’s hard to separate yourself from the time you live in, but the rewards are worthwhile.

There's a big difference between "code being in one file" and "code being in one function." It sounds like the OP had something reasonably close to "one function," whereas the HN code has a lot of (what appear to be) small well designed methods.

  (def add1 (x|int)
    (+ x 1))

I've been implementing it for a couple years now, though not seriously till the past couple months. There are some interesting (and overlooked) ideas in Bel.

Bel is sort of the limit case of generality. For example, you might expect the "type" above to be a separate kind of object, the way that types are separate kinds of things in TypeScript.

But in fact, it's simply a function that receives the argument and can throw an error. So for example, you can do something like:

  (def positive (x)
    (if (< x 0) (err 'negative) x))

  (def sqrt (x|positive)
     ...)

[1] https://docs.racket-lang.org/ts-reference/Experimental_Featu...

Which IDE do you like? I'll see about getting some highlighting for it.

As for actually running arc, it’s hard to run the original arc3.1 due to racket updates. I’ve made a few branches over the years that try to preserve the original spirit of arc (no significant changes) while making it easy to run. Try this one:

https://github.com/tensorfork/tlarc

I believe you can simply install racket, then run make && bin/arc and be dropped into a repl. From there you can follow the arc tutorial, whose link I’ll dig up after I’m finished driving home.

EDIT: That fork is actually a lot different from arc3.1 proper. I’ll try to locate a more faithful one.

EDIT 2: Unfortunately it's quite a lot of work to remove the mzscheme dependency from the old arc3.1 codebase. And I'm not sure it's even possible to install the mzscheme lib on the latest racket (e.g. `brew install racket` doesn't seem to have it).

So the above instructions are the best I can do for now.

I like how the "html" and "css" part was embedded in that "news.arc" file. Do you think that VIM script will highlight and lint the "css" part of an "arc" file?

I try to use Arc for as much as possible. We wrote our TPU monitoring software in it: http://tensorfork.com/tpus

Eventually I became frustrated with Racket's FFI. So I eventually made my own arclike language called elflang: https://github.com/elflang/elf

... which itself is a fork of Lumen (https://github.com/sctb/lumen) by Scott Bell.

The performance is good enough to run a minecraft-style game engine: https://i.imgur.com/iyr0YrB.png which was satisfying.

Nowadays I've been trying to implement Bel, mostly for the challenge of it than for any practical reason.

> I like how the "html" and "css" part was embedded in that "news.arc" file. Do you think that VIM script will highlight and lint the "css" part of an "arc" file?

Nope. https://i.imgur.com/o9aUG6j.png

But it has one very important feature: it can properly highlight atstrings: https://i.imgur.com/wO4f742.png

It's probably hard to tell, but the "@(hexrep border-color*)" would normally be highlighted as if it were a string. Arc has a feature called atstrings, where you can use @foo to reference the enclosing variable "foo". It can also call functions, e.g. "The value of 1 plus 2 is @(+ 1 2)" will become "The value of 1 plus 2 is 3".

Best practices were the usual suspects DRY, IOC, SQL + NoSQL, separation of concerns, config files over code, composition over inheritance, unexplainable overlapping annotations, dozens of oversimplified components doing their own thing, and some $something_someone_read_on_a_medium_post

The Single Java File was around 500 lines no db, lots of globals, a dozen or so classes and some interfaces, Threads for simulating event based concurrency, generous use of Java queues and stacks but i specifically made it static with Zero dynamic hashmaps.

It actually runs in my IDE, I can understand what the hell the product is supposed to do what component is doing more than it should and more valuable was to predict what could break if I change that value in the helm chart from 5.0 to 5.1.

It is quite useful and pleasing, I can actually reason about things and I have new found use and appreciation for Type Systems and compile errors. And I can write tests that run in under 3seconds.

These best practices really only make sense in large organizations, i.e. Conways law.

After all, you can't really ask 100 developers to all add code to one file in a couple weeks - they will spend a month or so just resolving conflicts...

100 file repos are designed so that 100 developers can edit them (in theory), and have relatively few conflicts, not because its better code.

As another anecdote, I find whenever I do solo code I can easily spin out thousands of lines of code within a week (includes testing), when doing code on a project with many other devs my rate drops into the range of maybe 200 a week, just because so much time is spent interlinking other code, finding fixing bugs and tests strewn across many files...

[1] https://docs.microsoft.com/en-us/previous-versions/visualstu...

Like most of the world at one point, it ran on Excel 2003

/s

For a while, I was the only developer working in a small module of a bigger project: I started the code base, discussed requirements with clients, implemented the needed features, tested the whole product end to end. I developed a very good instinct about it and about what any change would do, much better than any other project. My theory is that the code base matched my way of thinking, so thinking about it was pretty easy.

The other thing is style - when used well, state machines don't require testing. There's nothing to test - either your machine works or it doesn't, there is no point testing state transitions because that is the fundamental job of the state machine. You may as well test that addition works.

Ofc, they must be used well - problems may be difficult or overly complex to model as a state machine or even set of state machines - the pattern excels for small problems, less for large ones.

That application would likely fall apart if multiple developers of with diverse backgrounds had to maintain it and add new features.

When working on projects by myself, I like putting everything in one big file too. Trying to find the "right" place for something is some unnecessary overhead, not to mention the navigation cost. It's a different story when a team is involved though.

Ya, you could just go in there and mess with the code all over the place.