[HN Gopher] Show HN: Yaksha Programming Language
___________________________________________________________________
Show HN: Yaksha Programming Language
I have been working on this for a while. Main goal was to build a
usable programming language. I even end up building few tools for
this such as IntelliJ plugin, etc. I also plan on building some
games with it in future. Main use case would be: small games
(raylib), tools (static linux binaries with musl-libc) and
recreational programming (wasm4). Works in Windows also. If you
have emscripten in path you can even build these games/tools
(raylib) to WASM. Please have a look. Thank you.
------------------------------------- Main Repo:
https://github.com/YakshaLang/Yaksha Doc:
https://yakshalang.github.io/documentation.html Library:
https://yakshalang.github.io/library-docs.html Tutorials:
https://github.com/orgs/YakshaLang/discussions/categories/tu...
---------------------------------------- Started after a comment
from WalterBright here
https://news.ycombinator.com/item?id=28929840
Author : JaDogg
Score : 135 points
Date : 2023-03-19 11:13 UTC (11 hours ago)
(HTM) web link (yakshalang.github.io)
(TXT) w3m dump (yakshalang.github.io)
| rlupi wrote:
| This is totally unrelated to the language itself, but...
|
| You have my greatest appreciation for building proper responsive
| websites in all those links, with proper CSS styles and sizing
| (rem units)!
|
| I use a 40" 4K screen (no HiDPI) and almost any other website,
| including the most popular ones (I just checked github, google,
| bing) do not really follow responsible principles, use px units,
| and end up using just a tiny column of the screen... and they are
| not even consistent: bing and google use the left 1/3rd of the
| screen, github the central 1/3rd.
| drusepth wrote:
| 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.
| JaDogg wrote:
| Sorry, not so good with CSS. Home page should look better I
| think. :) Will fix it at some point
| topaz0 wrote:
| My experience is that tiny text is the style. I'm much more
| likely to have to scale something up than down. I can't
| remember the last time I scaled something down, but I scale
| things up every day. (I also liked the size choices of the
| OP... honestly wouldn't have minded slightly bigger).
| JaDogg wrote:
| Home page was actually built by my wife.
| https://github.com/tashvit.
|
| Other CSS are probably just luck ;)
| aka878 wrote:
| A+ family
| rtepopbe wrote:
| 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.
| [deleted]
| chaosprint wrote:
| That's really lots of work from a one-man band. I can empathise
| as I am also developing https://github.com/chaosprint/glicol
|
| Since you mentioned wasm, I think it would be great to have a
| REPL on the website in the future.
| JaDogg wrote:
| 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)
| chaosprint wrote:
| perhaps refer to the tech behind rust playground:
| https://play.rust-lang.org/help
| alwaysbeconsing wrote:
| The Compiler Explorer aka Godbolt also would be a good
| example: https://c.godbolt.org Source:
| https://github.com/compiler-explorer/compiler-explorer
| JaDogg wrote:
| Thank you.
| JaDogg wrote:
| 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! :)
| DeathArrow wrote:
| Obvious question: why a new low level programming language when
| we have C, Zig, Nim? What are its strengths over these?
| Boxxed wrote:
| Looks pretty cool! What happens if a program attempts a use-
| after-free? If this is "memory safe" (aside from leaks) then I
| think it sits in a pretty interesting space!
| yazzku wrote:
| Very nice. I had experimented with transpiling Python to C
| straight from the AST in Python itself. Does this plan to add
| type inference or "generics"? Currently it appears everything
| must be explicitly typed.
| JaDogg wrote:
| yes it is in my local repo. but it is not done yet.
| elcritch wrote:
| Reminds me of Nim, but with more Python influence on the standard
| library and overall syntax. It does share the ideal that a
| Python-esque syntax can be nice for system's programming.
|
| Its surprising how fun programming can be when you eschew
| unneeded syntactical complexity! Though personally I prefer
| having memory management and lifetimes handled automatically by
| default, but with the option for manual management when desired.
| JaDogg wrote:
| Yes I agree. Time will tell how it will grow. Hopefully it will
| have a good use.
| DeathArrow wrote:
| Why aren't you using the LLVM infrastructure?
| WoodenChair wrote:
| 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.).
| abhayhegde wrote:
| Nice. Is it named after the folklore Yakshagana[1]? The logo does
| resemble the face of a Yaksha.
|
| [1]: https://en.wikipedia.org/wiki/Yakshagana
| FraaJad wrote:
| yes, indirectly.. likely named after Yakshas themselves -
| https://en.wikipedia.org/wiki/Yaksha
| JaDogg wrote:
| Logo is based on a Sri Lankan traditional mask for Fire Devil
| (Gini Yaka). https://uk.lakpura.com/pages/raksha-masks
| mshockwave wrote:
| Are you planning to add alternative backends in addition to
| transpiling to C99?
| JaDogg wrote:
| Yes I originally wanted to add support for OpenCL style C code
| too. Time will tell if I figure out how to implement it.
| 29athrowaway wrote:
| Another language that compiles to C: Vala.
|
| It has a C#-like syntax.
| blakerandall wrote:
| What's with newer languages putting types after variable/function
| names? Then you need an extra symbol : or -> and a function
| keyword. It also breaks readability of long function headers as
| you have to read the name skip to the end to read the return type
| then back to the first argument. Is there a good reason for this
| trend?
| zokier wrote:
| 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 [?] R
| mikebenfield wrote:
| 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;
| zumu wrote:
| 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.
| waselighis wrote:
| 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.
| JaDogg wrote:
| I think mainly
|
| 1) Easy to parse (less ambiguous) 2) We like Python
| sideeffffect wrote:
| 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?
| JaDogg wrote:
| yes
| Yujf wrote:
| It is easier to parse and you don't get the abomination that is
| C function pointers
| MathMonkeyMan wrote:
| It makes me wonder why C put the ultimate type on the left
| and not on the right.
|
| C type/variable declarations are an expression that
| transforms the type/variable into a primitive type, which is
| then annotated on the left of the expression. Why not on the
| right?
| jejones3141 wrote:
| The intent, as I understand it, is that "declaration should
| look like use", so that the base type is on the left. If
| you declare int *foo; then *foo is an int.
|
| IMHO the existence of "cdecl" is evidence that it might not
| have been the right choice.
| jstimpfle wrote:
| Because parsers, like humans, read from left to right.
| Important parsing decisions are usually made as early as
| possible. An example is recursive descent parsing, which
| derives its simplicity from making decisions first,
| allowing a top-down parse. And when humans skim text, I bet
| it can be shown that it's easier if the syntactically
| significant locations are aligned near the beginning of
| each statement.
| dom96 wrote:
| Nice! My initial take: love Python-inspired languages but I think
| manual memory management is distinctly anti-Python so not sure
| how well that works together.
| gatane wrote:
| There are no pointers?
| JaDogg wrote:
| yes there are pointers. See some samples here:
| https://github.com/YakshaLang/Yaksha/blob/e72d7984a4c8d49e4d...
| netbioserror wrote:
| Do you mind having a "Why a new language?" primer with some
| deeper philosophy on your choices? I will never question anyone's
| desire to make a language for learning or hobby. However, when
| presenting it to the world for practical use, there has to be
| some persuasion to move people off of existing tools.
|
| I use Nim at work (I'm lucky) so I'd love to see that comparison
| in particular, it also being a transpiled-to-C language. I also
| use it to build static binaries with musl-libc and it's quite
| easy and clean.
| JaDogg wrote:
| 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)
| hsfzxjy wrote:
| A great job! But I found the docs too formal and techincal, which
| is more like a lang spec. It would be more appealing if some
| tutorials added.
| JaDogg wrote:
| Yes very good point, I started this by writing a spec. However
| I already started a tutorial section in github discussions: htt
| ps://github.com/orgs/YakshaLang/discussions/categories/tu.... I
| should add a link to it in main page.
| pacifika wrote:
| Looks like gdscript. Not a bad thing!
| JaDogg wrote:
| Thank you.
| Aisen8010 wrote:
| It's probably in your plans, but it would be nice a page showing
| the syntax (for example, control flow and variable declaration).
| JaDogg wrote:
| There are some samples. But yes this is a good idea.
| eps wrote:
| Show it to /r/ProgrammingLanguages when you have a chance.
| JaDogg wrote:
| done. Thank you!
|
| https://www.reddit.com/r/ProgrammingLanguages/comments/11vnm...
| JaDogg wrote:
| It is a rather large project. So here is some information about
| tech stack.
|
| ----------------------------------
|
| Tech stack: Code is written in C++ for the compiler
|
| carpntr - which acts as the builder is built using Yaksha itself.
| (I use a python script to bootstrap and carpntr to build carpntr
| as a second step)
|
| hammer - cross compiler for C/C++ projects written in Yaksha (I'm
| building Linux version of Yaksha compiler on Windows box
| leveraging `zig c++`)
|
| Yaksha comes with zig to use zig cc.
|
| Runtime: this is written in C. (There are no .dlls involved,
| things get built statically, only subset will be built and
| linked)
|
| Standard library: written in Yaksha.
|
| YakshaIntelliJ - written in Java
|
| Various scripts - Python.
| realworldperson wrote:
| [dead]
___________________________________________________________________
(page generated 2023-03-19 23:00 UTC)