Show HN: Yaksha Programming Language (yakshalang.github.io)

yes there are pointers. See some samples here: https://github.com/YakshaLang/Yaksha/blob/e72d7984a4c8d49e4d...

There are some samples. But yes this is a good idea.

done. Thank you!

https://www.reddit.com/r/ProgrammingLanguages/comments/11vnm...

I had help with the landing page. However, rest is mostly me. But I'm using lot of third-party stuff also.

REPL I have been thinking for a while, I'm not sure how I would do it unless there is a way to run zig cc in browser.

Would be harder without having a backend at the moment as it needs to run a C compiler to generate the final executable. (Not an interpreter)

BTW glicol looks & sounds really good. I have always day dreamed how I would DJ but instead of using traditional tools, I'd be using a programming language to do it. I never had guts to do it in real life tho! :)

Thank you.

yes it is in my local repo. but it is not done yet.

Yes very good point, I started this by writing a spec. However I already started a tutorial section in github discussions: https://github.com/orgs/YakshaLang/discussions/categories/tu.... I should add a link to it in main page.

Yes I originally wanted to add support for OpenCL style C code too. Time will tell if I figure out how to implement it.

Logo is based on a Sri Lankan traditional mask for Fire Devil (Gini Yaka). https://uk.lakpura.com/pages/raksha-masks

yes, indirectly.. likely named after Yakshas themselves - https://en.wikipedia.org/wiki/Yaksha

Home page was actually built by my wife. https://github.com/tashvit.

Other CSS are probably just luck ;)

I had to scale down the design to 50% scale to get it to fit on my screen without everything looking huge and wrapping, but after that everything looked usable.

[1] Full size: https://i.imgur.com/R0I6Vxs.png

[2] Half size: https://i.imgur.com/tQ6KpR4.png

Not sure if huge text is just the style these days, though. Probably looks great on a huge screen.

You don't even need a setup like that to feel that pain. That pretty accurately describes my experience with those websites - and many others - with just a 24" 1920x1200 monitor.

The weird silver lining is that most sites are also using fonts a bit too far on the small side for me, and don't respond too well if you jack them up much. But that unused 2/3s of the screen ends up allowing most websites to take a fair bit of zoom without any changes in layout.

I really don't get modern website design.

I think mainly

1) Easy to parse (less ambiguous) 2) We like Python

It is easier to parse and you don't get the abomination that is C function pointers

Variable/Parameter names are nicely aligned so there's less scanning to read them. Personally I usually read function arguments before return type, but I can see instances where I'd want to look at return type first. If you're line breaking on parameters for long function signatures, it's not so bad though—the return type will be in a predictable place.

The convention dates back to at least ML in the 70s, possibly even longer time back. So it is not some new thing, it's recent rise in popularity is more a reflection in MLs increasing influence in language design space.

If I'd had to guess, the syntax might be inspired by math notation such as x ∈ ℝ

Well, note that partly due to the way variables and functions are declared in C and C++, parsing those languages (especially C++) is a complete mess.

I think the readability argument is pretty subjective. Personally I find declarations in for instance Rust a lot easier to quickly scan than C++. For one thing the names of functions are all at the same offset, which to me is actually the most important thing. I can see at a glance whether it's a function or variable being declared. I've never found the fact that the return type is at the end to be a problem - why would it be?

fn first_function(...) -> i32 { ... }

fn second_function(...) -> Vec<i32> { ... }

const X: i32 = 0;

vs

int first_function(...) { ... }

vector<int> second_function(...) { ... }

int X = 0;

I think the C syntax was actually a compromise to simplify the grammar. Remember C dates back to the 60s, and computers had very little RAM and storage back then, so they had to be very clever in how they designed the language. The C function pointer syntax is the way it is because you can reuse the same grammatical rules for parsing types as you do expressions. Pointers are prefix and function calls are suffix.

It's been like this in the academia (Mathematics in particular) since ever.

Also, some people say that it makes for easier (less ambiguous?) parsing.

But the -> part is a bit weird. It "shouldn't" be

    def factorial(x: int) -> int:

but it "should" be

    def factorial(x: int): int =

Maybe it's that way because of Python?

    (int) -> int

    int -> int

Because type before name is simply worse in every metrics, hard to parse, hard to omit when infer (change to auto, var, etc), hard to grep for definition (hence the hack <type>\n<name>).

Why do you care about the return type before the name?

The : and -> are not strictly speaking necessary. Some languages, like go, put the type after the variable name and return type at the end of the function signature without requiring a : or a ->.

Having to always use a colon before the type is better than having to sometimes write "typename" before the type. Not to mention that it makes the code easier to read.

If you had never heard about C and its legacy, and were to create your own programming language, would you come up with a syntax like C's?

The structure 'term: definition' is pretty common in many natural languages and has a lot of advantages: all terms are aligned, you can sort them, you can grep the term you're looking for, etc.

I even think it should be extended to functions, too. That 'def' ruins the harmony. Instead of

  def factorial(int) -> int

it should be

  factorial: fn(int) -> int

You trade a keyword ('def') for another ('fn') but open the way to lambdas (just the part after the colon).

I agree that the -> serves no purpose, it could be made optional. Alternatively one could require the -> and dismiss the 'fn' keyword, like this:

  factorial: (int) -> int

It's slightly harder for the parser who has to wait until the -> to understand what it's reading, but it's doable.

About putting the return type after the parameters, that absolutely reflects how I reason about functions: I will want to first examine its input, and then its output. Even the man pages for common functions and commands explain the parameters first, and leave the return value last.

Yes I agree. Time will tell how it will grow. Hopefully it will have a good use.

Sure, main goal was fun. But I should have a write up some time.

I wanted to see following:

1) Does manual memory management become easier when you use python-esque syntax? 2) OpenCL with @device like syntax so you can mix kernel code and client code in same .yaka file. - Not even started (Not sure if achievable with my time constraints)

Why did anyone make an album after the Beatles Rubber Soul ?

What's wrong with compiling to C? By using C as an intermediate language LLVM can be a backend through Clang, but so can GCC, MSVC, Intel C, etc. It's actually a pretty common choice (see Nim, Chicken Scheme, etc.).

I did not want to use that because LLVM was just too big! I tried building a sample and it gave me > 1GB debug .exe file.

zig wraps things up to a nicer package, so I thought might as well use zig cc.

That is the point!

Boom! it is an unsafe language. Hence the fire devil logo.

Nice !

Everything compiles to a big .c file. capntr - tool that acts as builder knows which part of runtime to compile and link. Imports are not dynamic like python. Does not have all the features of Python import also.

I have seen its language design and compiler implementation, and I am sure I will continue to follow and watch the development of Yaksha Programming Language. If possible, I would like to contribute.

Glad you liked it.