It is amazing to me how many language landing pages are largely devoted to install guides rather than explaining the language's raison d'etre.
My guess is the audience of this readme are not the users of the programming language but people who want to work on the programming language.
The current landing page lists features [1], and if my memory serves me the original landing page 15-ish years ago did not primary focus on an install guide. I can't check right now, since Wayback Machine is still down.
What also could happen with repository readmes is, that the sections devoted for explaining the language moves to github pages or a landing pages hosted somewhere, and the sections with install guides stay in the readme, as they are useful for people who want to contribute to the github repo.
[1] https://boo-language.github.io/
Still seems inadvisable not to have a link to the actual documentation in the GitHub README, in case people wind up there.
`Boo` was always an interesting language to me, but a bit hard to play with (as some others here have already commented) and now mostly abandonware. If you like its ideas, many of them have been taken further in Nim ( https://nim-lang.org/ ) which is still actively maintained & extended. (They are not phylogenetically related, to my knowledge (except possibly for Python as a common ancestor), and are also distinct in many ways). Nim is also less Windows-centric while also being cross-platform (Windows, OSX, Linux, *BSDs).
They say programming languages never die, but Boo’s definitely in palliative care.
I liked it, but the better C# got, the less reason you’d have to use something with worse tooling.
A long time ago Boo was one of the languages that Unity 3D supported. I think it hasn’t been supported for more than 10 years.
> no unnecessary keywords, brackets or semi-colons makes for highly readable code.
i always find it funny that people think removing symbols magically makes code more readable its almost as if theyve never read english ocaml is definitely harder to read because of the lack of symbols it just turns in to a word soup definitely not for me
well put sir there is no need for periods run on sentences definitely dont exist
Two things about Boo that have left a lasting mark:
First, it was the first time I'd seen quasi-quotes, where you can write code that them so converted to AST. Very very lovely dynamic programming. It was so awesome having a static runtime but being able to do multi-phase programming in it, was so much nicer than anything I'd seen in java. Excellent easy to understand macro writing.
Second, the boo test cases rocked. Test cases start with a string which is the expected output. Then the rest of the testcase is a short bit of code that outputs. It was so easy to debug & see what was happening, such an elegant frameworkless way to run tests.
I used it a couple times commercially at small webdev shops, but had a bunch of personal projects using Boo. Lead author Bamboo got hired by Unity and their (I believe now deprecated?) UnityScript was related/similar I understand, but Boo kept going for a whole. Great docs for the time too. But yeah tapered off.
The two techniques I describe, quasi-quotes & tests-as-executable are both visible in this macro testcase, https://github.com/boo-lang/boo/blob/master/tests/testcases/...
Thanks Bamboo et al!
The Nim macro system also has quasi-quotes (whose heritage ultimately goes back to Lisp, I believe, though Quine 1940 probably deserves the ultimate "credit" [1]). E.g.:
import std/macros
macro check(ex: untyped) =
let info = ex.lineInfo
let exStr = ex.toStrLit
result = quote do:
if not `ex`:
echo `info` & ": Check failed: " & `exStr`
check 1 == 2
and then saved in `/tmp/j.nim` and run via `nim r /tmp/j` gives
Hint: mm: arc; opt: none (DEBUG BUILD, `-d:release` generates faster code)
17090 lines; 0.191s; 24.699MiB peakmem; proj: /tmp/j; out: /u/cb/.cache/nim/j_d/j_56B19E2DE1BC31D8D53BA27494BE816EB824A493 [SuccessX]
Hint: /u/cb/.cache/nim/j_d/j_56B19E2DE1BC31D8D53BA27494BE816EB824A493 [Exec]
/tmp/j.nim(8, 8): Check failed: 1 == 2
[1]
https://en.wikipedia.org/wiki/Quasi-quotationReading the first few paragraphs, I note
- heavy dependence on large (Mono) and/or unusual tools (nmake ... in 2024 ... really?)
- worse than that, dependence on specific (older) versions of exotic, non-standard things
- not much in the way of "this is what the language looks like" or "this is what this language is good at"
- the windows world smell surrounding the project is pungent, to say the least
Not too appealing to have to install that much crap on one's system just to play with a new language.
I hope for the sake of the project this is a temporary state of affairs.
[EDIT]: a maybe slightly better intro to the language than the github page:
https://boo-language.github.io/
There is a lot to read in their wiki, https://github.com/boo-lang/boo/wiki
>Not too appealing to have to install that much crap on one's system just to play with a new language.
Ironically, this is what I thought about C# and Visual Studio when I used it 20 years ago. Boo was much easier to get started with back then, when you just wanted to try out .NET 2.0. It took me a few minutes to download and install .NET Framework (~20 MB) and SharpDevelop (~15 MB) versus five CDs of Visual Studio 2002 which took an hour or so to install on the machines of that time. And yes, I already skipped the installation of the Microsoft Developer Network (MSDN) documentation which as far as I remember already took an hour alone.
For some reason the installation of a development environment for Java was also much easier than Visual Studio, i.e. one had to download Java Runtime Environment (~100 MB) and unpack it, and then download Eclipse IDE (~100 MB) and unpack it. When you downloaded both archive files already it took a few seconds to unpack it and double-click on the eclipse.exe.
The last real commit was 7yrs ago, I don't think it's temporary.
Yeah, good point.
That also makes some of my remarks kind of irrelevant.
Mono is not large. It is, however, outdated. That is, the Mono that is used here. Otherwise, you should really not use it over vanilla .NET's CoreCLR.
(and surely you can do better than immediately resort to "the windows world smell surrounding the project is pungent"?)