I think I prefer using curly braces to indentation. I seem to remember reading that Nim strictly enforces spaces over tabs (rather than having it as a linter rule, or just asking you pick one consistently) which has kept me away from the language for some time, whereas you don't tend to get those hard rules with curly braces. Could be wrong on that, and would be happy to be corrected
Sorry to detract from the main thread though, looks really nice regardless
Programming in Nim actually "feels" quite different from python to me, due to things like a much lighter OOP system (that is somewhat discouraged), the type system, and UFCS, though it "looks" like python at first glance.
In my experience, a lot of programmers will shout from the rooftops about the importance of consistency until the agreed upon standard isn't their standard, at which point consistency is no longer the most important matter at stake.
My style is consistency. I'm happy to use any language that enforces that rather than leaving room for bikeshedding, even if the aesthetics aren't my personal favorite. Better than wasting time debating e.g. tabs vs. spaces.
I have to deal with different coding styles at every work place, and it takes me all of a week to forget any objections I had to it when I started.
Braces are unnecessary.
I get asked this question a lot. My goal for this project is not to convince you to use it. This new language does _nothing_ that you couldn't find in other languages today. This project won't take over the world, and many people ask me what the point of it is. It's purely a project stemmed from curiosity with absolutely no capitalistic motives. I did it based on my years of self-directed research studying many incredible programming languages, and this is what I have to show for my research.
My motivation for this was to learn how to build a programming language with a grammar, virtual machine, and garbage collector. It's a hobby project, not intended to be used for business.
Its not that the project has to be ground breaking or anything, just be nice to know what we're looking at.
Because from the readme, it doesn’t look like this language brings anything to the table compared to Python/Node.
Wish you all the best.
When I implemented Mindcode, I realized that “while” is the basic construct and that all enumerations and looping compiled down into goto.
Mindcode is a Ruby-like language for the Mindustry game. Mindustry has an assembly-like language with a visual editor in-game. Mindcode has a more traditional text-based flow.
At the programmer interface, sure. At the implementation level ("underlying"), all that abstraction is being turned into loops and jumps.
At least I'm not aware of any CPUs that are not imperative in operation.
> primitive and fundamental concepts do not go away even if things are abstracted by high level features in high-level languages.
Loops do not go away in fp. They are just hidden under layers of abstraction.
The loops are obviously there deep down the the language that they are implemented in but you never explicitly use them.
A language that tries to advance the state of programming is the only selling point worth noting. This is a toy language, which means it either adds to the noise or will disappear.
PHP already has a ton of well tested infrastructure to interact with web servers so you don't want to reimplement that again. And by compiling to PHP you get the same request model that PHP has which works great for quick and dirty web jobs. You can also leverage the performance improvements of PHP.
If you could hook that up to apache with a handler it would be great
compile to PHP language file extension -> Apache handler -> compile it to PHP -> Apache handler -> PHP Apache SAPI
I am unfamiliar with PHP, wondering what benefits it has that might lead someone to choose it for a task today.
You can do stupid stuff like
<table> <?php foreach($array as $row){ ?> <tr><td><?php echo $row[0];?></td></tr> <?php } ?>
Meaning you can just inlay PHP in your raw HTML as you please, this example will reprint the <tr> and <td> for every key in $array
Dynamic typing didn't come to dominate for no reason.
Edit: here it is https://nitter.net/andy_kelley/status/1483677253682675713
Are you thinking of Roc or is this another language?
Overall the most difficult things to understand were:
- How context-free grammars are parsed, and how they're defined. I'm still not an expert, but I can say that I can write a recursive parser by hand. I wrote my own JSON parser based on my understanding [0]
- Garbage collection. I think most GC's are based on the mark-sweep algorithm. Perhaps even Java's most advanced algorithms are a version of mark-sweep. Mark-sweep is so simple, that it took me a _long_ time to understand it. Reference counting and mark-sweep go together.
I love everything about this sentence
You mean the sweep phase goes through and cleans out all the objects with zero reference counts?
I always thought the point of reference counting was to deallocate the object once the count goes to zero (which is why people complain it is slow as it can lead to cascading effects).
As to “most GC's are based on the mark-sweep algorithm” — I have a whole folder of papers on different GC algorithms, probably not the rabbit hole you want to go down if you have something you’re happy with. The minischeme interpreter I poke at every once in a while has a super simple GC that I have to resist messing with because it Just Works™ and I’d be chasing my tail for who knows how long getting another one working.
> Tracing and reference counting are uniformly viewed as being fun- damentally different approaches to garbage collection that possess very distinct performance properties. We have implemented high- performance collectors of both types, and in the process observed that the more we optimized them, the more similarly they behaved — that they seem to share some deep structure.
> We present a formulation of the two algorithms that shows that they are in fact duals of each other. Intuitively, the difference is that tracing operates on live objects, or “matter”, while reference count- ing operates on dead objects, or “anti-matter”. For every operation performed by the tracing collector, there is a precisely correspond- ing anti-operation performed by the reference counting collector.
> Using this framework, we show that all high-performance col- lectors (for example, deferred reference counting and generational collection) are in fact hybrids of tracing and reference counting. We develop a uniform cost-model for the collectors to quantify the trade-offs that result from choosing different hybridizations of trac- ing and reference counting. This allows the correct scheme to be selected based on system performance requirements and the ex- pected properties of the target application.
That's awesome. Which papers do you find the most useful?
But it means you are partly right
With go, they had to come up with a nickname for it (golang). So now the language has two names.
As a result, the typical "go <something>" and "golang <something>" search results will always be potentially imprecise, and partial (unless everybody in the world stops calling it "go" in favour of "golang".
The really incredible part of this story is that Go came from... Google.
Yeah. They leave SEO to other shops.
I think they did not even intend to have this language released in public at first.
The good ol Scunthorpe problem.
But I agree it seems weird to make a new language without any distinguishing features.
That link is a little out of date. There's a spreadsheet floating around with more projects on it but I'm not exactly sure of the link.
It's a small but vibrant community. Our founding fathers would probably be Alan Kay and Bret Victor rather than Dennis Ritchie and Ken Thompson (not saying they founded our group but they are an endless font of inspiration for us).
We're trying all kinds of things in programming languages, and the main unspoken rule seems be be: no ALGOL derived languages allowed. Being ALGOL derived is what gives the "very similar to each other, with small variations" vibe that most programming languages have these days. In the PL field we iterated on improving imperative languages for the last 30-40 years, so a surefire way to end up with a radically different language is to build one in a different branch of the PL family tree.
https://futureofcoding.org if it wasn't obvious what the link is to the main site.
Edit: here's the spreadsheet: https://docs.google.com/spreadsheets/d/12sTu7RT-s_QlAupY1v-3...
https://en.m.wikipedia.org/wiki/Cyclone_(programming_languag...
The biggest issue with all these alternative languages, outside the yearly PhD work on compiler thesis across all universities and SIGPLAN papers, is making them into a product worthwhile adopting, the killer framework or platform that forces regular devs to actually adopt them.
[1] Compiled, though, not interpreted.
[2] Specifying what goes into the language, small snippets of code to show how certain features will look and behave, etc (basically language design) is very enjoyable, and I spend a lot of time doing (and redoing) this. Once I started on parsing into an AST I lose interest.
If you're getting hung up on parsing and what not, you might be more successful using a parser generator. People hate them, often for good reason, but they do allow you to iterate quickly at first.
I haven't used it personally, but if you plan on using LLVM I hear that is a nightmare to use. Probably would also fit in to the "hardest", "tedious" and "least enjoyable" category for you too.
I find using a parser combinator library or a PEG (https://en.wikipedia.org/wiki/Parsing_expression_grammar) is a better way to go. Usually expressing your grammar in these ways is not much more work than expressing it in an EBNF-esque style that a parser generator takes as input. The benefit is that you have a custom parser that is easier to modify and customize.
I don't think I would use a parsing lib to build a general purpose programming language though. At least not one that I intended to ship.
Maybe it wasn't intended, but having that screenshot as the tool's showcase sends a message to me.
The same problem bit me multiple times when pretty-printing nested data structures. There's often an arbitrary limit to the depth the printer recurse to and/or the number of elements that get displayed, with the rest hidden behind "..." or something similar. No matter what number you pick, sooner or later you're going to get a case where you miss a really interesting/important piece of information because it got hidden. And if you try to change the default, you're going to get a case where you miss important info because you couldn't be bothered to scroll that far up...
Anyway: you're right, this is bad, but also pretty common. Though in this particular case it's really bad, because most of the column width is taken by irrelevant data. Replacing `<function '` with λ would already help a lot.
[0] https://github.com/analang/ana/commit/a2a62301388ae1843c60f2... [0] https://github.com/analang/ana/commit/a361c4498c0f44c4d28f4f...
The README showcases some opcodes. Maybe they borrowed PHP's bytecode format or the VM design? If true, that would actually be a pretty neat thing to borrow, since PHP has made a lot of improvement in VM performance and memory management lately.
However, come to think of it, it's more close to Python and C then it is PHP.
If you wish, could you add more details to your README file.
I intend to update the README soon.
I wonder what they took from c not counting the parts of c that literally everyone took
Author could copy this title to the github description.
