Hi Forum,
have a look at nimja ( https://github.com/enthus1ast/nimja )
a compiled and statically typed template engine, that looks like jinja2 or twig.
{% for (ii, item) in links.pairs() %}
{{ii}} <a href="{{item.target}}">This is a link to: {{item.title}}</a><br>
{% endfor %}
{% if aa == 1 %}
aa is: one
{% elif aa == 2 %}
aa is: two
{% else %}
aa is something else
{% endif %}nimja transforms templates to nim code on compilation, so you can write arbitrary nim code.
proc foo(ss: string, ii: int): string =
compileTemplateStr(
"""example{% if ii == 1%}{{ss}}{%endif%}{% var myvar = 1 %}{% myvar.inc %}"""
)
proc foo(ss: string; ii: int): string =
result &= "example"
if ii == 1:
result &= ss
var myvar = 1
inc(myvar, 1)this means you have the full power of nim in your templates.
the nimja template control statements leave their newline and whitespace when rendered. To fix this you can annotate them with "-":
aaaaaaaaaaaaaaa
{% if true -%}
<li> {{-foo-}} </li>
{%- endif %}
aaaaaaaaaaaaaaa
aaaaaaaaaaaaaaa
<li>FOO</li>
aaaaaaaaaaaaaaagive nimja a try, its fun!
Nimja actually can run in the browser, there is a (playground) demo:
https://github.com/enthus1ast/nimja/tree/master/playground/browser
I don't know yet where to go from there, it may be interesting for smaller parts of a website that needs to be dynamic.
a small update to nimja template engine https://github.com/enthus1ast/nimja :
slugify
====
converts any string to an url friendly one. Removes any special chars and replaces non ASCII runes to their ASCII representation.
```nim
slugify("Lession learned german umlauts: öüä")
```
will output:
```
lession-learned-german-umlauts-oua
```
come and give nimja a try!
You are welcome to hack on nimja, a good start is to implement a "filter" in nimjautils!should that not be:
Ä,ä : ae
Ö,ö : oe
Ü,ü : ue
ß : ssi've released a small update to Nimja,
two procs for the Nimja utils:
includeRawStatic
Includes the content of a file literally without any parsing, on compiletime. This means it is included into the executable.
includeStaticAsDataurl Includes the content of a file on compile time, it is converted to a data url. Eg:
<img src="{{includeStaticAsDataurl(getScriptDir() / "logo.jpg")}}">
is transformed to:
<img src="data:image/jpeg;charset=utf-8;base64,/9j/4AAQSkZJRg..."/>
these procs help to build an standalone executable, without staticRead the assets in the Nim executable but conveniently from the templates.
We also don't need more than one notation for math or music.
Ooph. That's a hard miss. Unless you really mean an IR, not a human-facing language.
Needs for exact and quickly readable notation for fretted stringed instruments is vastly different compared to percussion/drum sets. Percussion notation itself is barely suitable (notating polyrhythmic stuff for multiple limbs, for example, is awful), and as there's no standard body, there's now a multitude of subdialects and custom "extensions" used to hack around the limitations. The issue is, music notation is not just a language, it's also a form of a stenography (primarily for fast reading, not writing).
The punchline is there's nothing better enough to break the network effect, so musicians are stuck.
Sorry for a bit of a diversion from the topic.
This way I don't have to remember two different standard libraries, two different ways to write an if statement, etc etc.
For an "ecosystem" you can also simply have multiple implementations of the same things, see GCC vs clang. It works too.
That's a reasonable way to approach it. I think Nim does a great job at being of a jack-of-all trades PL, and it seems easier to persuade developers to try/use Nim than it is to get them on board with a batteries included Scheme/Lisp.
We also don't need more than one notation for math or music
I'm a bit leery of this line of reasoning. Two counter-examples:
APL started out as a means to provide precise expression in writing and teaching, e.g. on blackboards. Later it became a programming language. It's still in use as a (alternative) mathematical notation for e.g. Linear Algebra and modeling/authoring programs to perform those calculations. APL notation hasn't won out in classrooms and textbooks for teaching L.A., and the language isn't popular compared to say NumPy, but if you're in a specialty shop doing full-time work on problems for which it (or J, K, et al.) is especially well suited, I'd say it's very useful indeed.
Modern music notation is comprehensive, but if you're sight-reading Western plainchant, then a neume system such as Solesmes notation (as seen in the Liber Usualis) and the corresponding (performed) cheironomy is considered to be a better choice for the average schola/choir. The available singers can vary with the time of year, and it's easier to "find" C/F with the group on hand, relative to the printed neumes for the chants of the day, and go from there. I used to sing in the choir at my church; they did and still do sight-read Solemnes notation for plainchant, while the polyphony of e.g. Palestrina involves sight-reading modern musical notation.
Needs for exact and quickly readable notation for fretted stringed instruments is vastly different compared to percussion/drum sets.
Yes, there is a need for an exact and quickly readable notation. But there is no reason to assume a music notation couldn't be designed to work well with all kinds of instruments.
Genauso gut könnte ich behaupten, dass ich das hier unbedingt auf Deutsch schreiben musste, weil es sich nicht gut ins Englische übersetzen lässt.
"""The industry as a whole wastes unbelievable amounts of money, time, work and effort on all these different programming systems with trivial and annoying differences and incompabilities."""
Consider it price for diversification and robustness. If any of those path fails, the total wont be affected much.
Same way as the nature works, wide random evolution search tree.
And, the technology seems to progress with the exponent speed. You hardly cant wish faster than that.
So lots of simultaneous independed branches, are not waste, quite the opposite - its unbelievably efficient.
Also, suppose using single unified language is indeed much more efficient.
Why dont we observe it in the practice then? Companies that decided to use nim should be more efficient and take over the market.
Yet we dont see that. So, maybe the gain in efficiency, if theres any, is not that big, not enough to make a difference.
Yes, theres market effect preventing new players to the major market sectors. Still theres enough small niche sectors. And yet, we cant observe such companies even in niche sectors.