Live data from Hacker News

Show HN: Alumina Programming Language

github.com

61–70 of 90 posts

Re: Show HN: Alumina Programming Language

#61
post #22

Earlier quoted context omitted.

What's an example of a language with "good" FFI?

With the D programming language, to interface with C's stdio.h: import stdio; void main() { printf("hello from D!\n"); } is all that's necessary, as D has a built-in C compiler that reads stdio.h, compiles it, and presents its interface to the D code.

This is even more impressive than LuaJIT's FFI in my opinion, which I previously thought was state of the art. You basically pass in a preprocessed header, and LuaJIT does the rest.

All this to say, I feel that any FFI that requires you to manually write bindings is rubbish.

Re: Show HN: Alumina Programming Language

#62

Earlier quoted context omitted.

With the D programming language, to interface with C's stdio.h: import stdio; void main() { printf("hello from D!\n"); } is all that's necessary, as D has a built-in C compiler that reads stdio.h, compiles it, and presents its interface to the D code.

I hear about D often on HN but I never see it being used in the wild so to speak. When I looked at it, it seemed, like C++, a hodgepodge of features built up over time rather than being a more deliberately focused language. I hate to compare and contrast but Rust comes to mind as one of the latter, probably because it has a somewhat more intensive and extensive RFC process for adding new features.

D has made its mistakes (there's no way to evolve a language over 20 years and not make a mistake here and there), but we also have a deprecation process to remove them.

The people who use D tend to like it very much.

Re: Show HN: Alumina Programming Language

#64

Earlier quoted context omitted.

With the D programming language, to interface with C's stdio.h: import stdio; void main() { printf("hello from D!\n"); } is all that's necessary, as D has a built-in C compiler that reads stdio.h, compiles it, and presents its interface to the D code.

This is even more impressive than LuaJIT's FFI in my opinion, which I previously thought was state of the art. You basically pass in a preprocessed header, and LuaJIT does the rest. All this to say, I feel that any FFI that requires you to manually write bindings is rubbish.

We lived with manual bindings to interface with C for years. Building in direct support for C itself is a huge leap forward in usability. In several ways it's even better than C++'s support for C.

Re: Show HN: Alumina Programming Language

#65
post #27

New language posts have to stop. There are tons of other CS topics to talk about but instead LIPSs ()()()()((((())))) and random langs taka the spotlight on HN.

I upvote any new language post I see because I find them very interesting and want more of them. The nice thing about HN is you can just scroll past posts you don't find interesting. The "tons of other CS topics" are also discussed on HN.

Re: Show HN: Alumina Programming Language

#66

Earlier quoted context omitted.

What is it that people hate about Rust syntax beyond the terrible lifetime syntax? Seems pretty reasonable to me.

Rust's syntax is just baroque. It's full of unnecessary noise and additionally very irregular. (With complete craziness thrown in between like the semicolon rule to "visually distinguish" procedures and functions, which must be a kind of joke I don't get). I really don't understand how such a conceptionally well thought out language got this pretty ugly syntax. (And no, you don't need such ugly syntax "because langua…

Rust is a fly-pollinated flower. Without garbage collection, it needs flies.

Rust is in part designed to look familiar to C programmers. Rob Pike once famously described C syntax as able to survive a channel that mangled whitespace. That's less of an issue now, but habits die hard. Indentation in place of syntax is nevertheless controversial. That's a toy version of the bigger question: Why should text be required to carry a load that a smart editor can infer? In Clojure, some prefer ;; to ; because the comments stand out better. Um, syntax coloring? I dislike all comment characters, and for many years I preprocessed a practical version of "comments are flush, code is indented".

Ownership is nevertheless pure genius, and one can define more powerful operations on Rust's restricted notion of data than on general data. I'm imagining a "lisp without parentheses" that transpiles monadic parsers on steroids (aimed exactly at Rust data) to Rust. It will take me a while.

Re: Show HN: Alumina Programming Language

#67
post #18

Earlier quoted context omitted.

That's a strange take. Do you mean that you would rather call external binaries directly, like Bash does, or that you would rather re-implement all functionality you need, however complex?

To me, there is value in the process and craft. It started as a one year challenge to use only stdlib in all projects, for work and personal code, and became a way of life. Though it may not work for everyone, or all languages, or all skillsets, it was a revealing experience. In retrospect, it made sense given that in my community we make our own furniture, instruments, tools, foods from whole items. Code seemed like…

That's a whole lot of words for describing NIH syndrome [0].

But sure, yeah, there's value in practicing your craft and making all the things.

[0] https://en.wikipedia.org/wiki/Not_invented_here

Re: Show HN: Alumina Programming Language

#68

Earlier quoted context omitted.

What is it that people hate about Rust syntax beyond the terrible lifetime syntax? Seems pretty reasonable to me.

Rust's syntax is just baroque. It's full of unnecessary noise and additionally very irregular. (With complete craziness thrown in between like the semicolon rule to "visually distinguish" procedures and functions, which must be a kind of joke I don't get). I really don't understand how such a conceptionally well thought out language got this pretty ugly syntax. (And no, you don't need such ugly syntax "because langua…

I love the semicolon rule, I think that distinction is extremely important and too often gets muddled

(though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")

Re: Show HN: Alumina Programming Language

#69

Earlier quoted context omitted.

Rust's syntax is just baroque. It's full of unnecessary noise and additionally very irregular. (With complete craziness thrown in between like the semicolon rule to "visually distinguish" procedures and functions, which must be a kind of joke I don't get). I really don't understand how such a conceptionally well thought out language got this pretty ugly syntax. (And no, you don't need such ugly syntax "because langua…

Rust is a fly-pollinated flower. Without garbage collection, it needs flies. Rust is in part designed to look familiar to C programmers. Rob Pike once famously described C syntax as able to survive a channel that mangled whitespace. That's less of an issue now, but habits die hard. Indentation in place of syntax is nevertheless controversial. That's a toy version of the bigger question: Why should text be required to…

> Rust is in part designed to look familiar to C programmers.

Rust may be accompanied by a design statement like that somewhere, but it actually does no such thing.

Re: Show HN: Alumina Programming Language

#70
post #12

I thought people got along with Rust due to its features and semantics and learned to live with the syntax. Not it being something one would copy. (I'm personally still hoping for a Ratfor/Coffeescript transpiler) Also, wonder how long it'll take until we see a "Aluminia" fork...

I assume he means the basic syntax like the fact that everything is an expression, `name: type` not requiring brackets for `if` and `for` etc. Most of the ugly Rust syntax is for advanced features like lifetimes and generics.
Post reply on HN