Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Luna – Visual and textual functional programming language

luna-lang.org

Post reply on HN
Print view View original

321–330 of 331 posts

Re: Luna – Visual and textual functional programming language

#321

Post by watersb »

the_cat_kittles wrote: post #239
simplify wrote: post #214

Earlier quoted context omitted.

If the hate were towards a person, I would completely agree with you. But OP is only hating JavaScript-the-tool, so I have no contempt towards his opinion. In contrast, if OP were hating on JavaScript programmers , then your indignation would be completely justified. But he's not, and I admit to holding a similar position: I hate C++ and prefer to never lay eyes on it again, but I have nothing against C++ programmers…

thats a good distinction, and i suppose its defensible. but imagine you are a trumpet player, and a pianist walks by and says "i hate that non-instrument trumpet" unprovoked. no one is wrong to hate the trumpet. but saying it to a trumpet player, and then saying they aren't even a musician (implied by "non-language"), is going to catch heat. and its undeniably true that javascript has got loads of warts. i mean, look…

Two days after you two posted this thread of comments, and I must thank you for it.

The analogy of musical instruments may be appropriate here; I feel that my ability or failure to be productive with a particular set of tools to be an aspect of my identity.

Set me to debugging a C++ or Java class library and I can get to work, but these may not be the tools I would prefer to start with.

Am I a bad programmer? Hmm. Identity can be a fragile thing.

Re: Luna – Visual and textual functional programming language

#322

Post by watersb »

athenot wrote: post #2

Very nice! I feel this space is under-developped. Luna reminds me a lot of Apple's Quartz Composer. Visually representing anything complex is an immense challenge, but just like code is broken down into units (files/functions/whatever), a visual tool that can provide a fractal-like representation of a system would be awesome. (I'm looking to dig deeper in this space for some pet projects.)

Exactly! And Quartz Composer leads to OpenGL shader trees.

You may wish to address people who consider themselves "Designers" rather than "Programmers".

Seems as if platforms for computer graphic systems production- like Unity or Unreal - would provide a receptive audience.

I wonder how they would react.

Re: Luna – Visual and textual functional programming language

#323

Post by tentaTherapist »

coldtea wrote: post #96
adgasf wrote: post #44

Why implement a new language rather than a GUI on top of Idris, PureScript or similar? (That aside, very excited!)

Because few care for Idris and PureScript. They wanted simplicity and to control the language and syntax -- not to tie themselves to some Haskell-like environment.

The irony being that this itself is a Haskell-like environment, and a complex, dependently-typed one at that, with full type inference and strange function name choices (in my opinion, of course.)

Re: Luna – Visual and textual functional programming language

#324

Post by tentaTherapist »

wdanilo wrote: post #72
tree_of_item wrote: post #25

Earlier quoted context omitted.

It's bogus, they just wanted to use the word "category" to try and lure in FP enthusiasts.

It's not a bogus! We are FP enthusiasts and the word "category" has really strong connections to our type system. However, the name might be a little misleading so we've already changed it. Anyway, we treat our types as categories. For example 1 belongs to a singleton category 1 (thus you can write 1 :: 1) but it also belongs to category of positive numbers or all numbers in general, thus again you can write (1 :: 1…

That's just plain-old dependent typing, isn't it? What's in this and not in, say, Idris, such that you can say that it's a whole new paradigm?

Re: Luna – Visual and textual functional programming language

#325

Post by tentaTherapist »

kustosz wrote: post #69
thecity2 wrote: post #4

I like the idea of category-oriented programming. Would be interested to see a white paper on what that means.

This feature is a bit of a misnomer, as it immediately brings up discussions about category theory. That being said, the idea behind it is pretty simple, yet powerful. Our typechecker will be able to track the shape of data on a deeper level than usual types. Basically will be tracking the exact constructors used to construct data, not just types – something that is a huge pain in most existing typed languages. If yo…

That sounds like a horribly leaky abstraction if you mean that you're literally going to statically track the call stack to attempt to verify invariants. Hopefully it's just a misunderstanding on my part.

Re: Luna – Visual and textual functional programming language

#326

Post by tentaTherapist »

stormbrew wrote: post #21
indigo0086 wrote: post #16

Earlier quoted context omitted.

For sure without the text representation, or manual code aspect a language would ultimately fail. I feel that languages that seek to "simplify" often oversimplify and leave those that require more granularity (most programmers) not to buy in. These languages can definitely offer a new paradigm on top of existing languages but it requires some fine control to get mind-share and ultimately take off. I'd say the real te…

I fundamentally despise this concept of 'non-devs'. There's just a cyclical definition of non-devs as people who use non-dev tools and vice versa. It's extremely common to dismiss tools used by certain classes of people as non-programmer tools because of who's using them. Look at Excel, which is basically a visual programming language that probably more people know how to program in than know C. But because your boss…

Excel's programmability is vastly underrated for some reason. It's easily one of the most high-level and successful languages ever, fulfilling a wide variety of roles for countless people, so simple that a child could use it, and so flexible that your boss probably does, too.

Re: Luna – Visual and textual functional programming language

#327

Post by [deleted] »

wdanilo wrote: post #134
svtiger wrote: post #108

May want to remove from your "About Us" bio: "hates Java Script" -- can't say I disagree, but you might alienate potential converts -- really should inject as much positivity as possible. Any negative messaging will do nothing but harm.

I prefer to alienate potential converts than convert JavaScripters! Just joking of course. It is hard to hide hate to a non-language treated as a super cool language. But you are right, I've never thought about it this way. I will change it, thank you!

[deleted]

Re: Luna – Visual and textual functional programming language

#328

Post by libeako »

kustosz wrote: post #132
mixedbit wrote: post #122

How do you envision version control/code reviews with Luna projects? Can diffs be explored at visual level or only source code level? If one developer moves nodes around without altering any logic are such changes tracked in the code repository?

For starters we've made sure to make git diffs as readable as possible. The visual data is kept at the end of text file (hidden when using our editor), usually in a single line. So if you just move nodes around, one line gets changed and it is clear what to ignore when scanning the diff, while making sure to retain the changes in the repository. For later stages, we envision much deeper integrated version control, in…

This sounds bad. Any info in the text related to the visual representation will be unreadable i guess. Hiding such for diff review is helpful but not enough. Because in merge conflict resolution one may not have the luxury to neglect it.

Re: Luna – Visual and textual functional programming language

#330

Post by libeako »

kustosz wrote: post #36
jancsika wrote: post #13

Where are the node positions stored?

We store them in a separate section in the source file, which is hidden by default when editing. So a bare .luna file is a readable text file, containing some metadata at the bottom, which is not shown when editing with our editor. This way we achieve clear representation and full portability of the source files.

Why do you store the visual node positions? For me it is hard to imagine anyone want to edit those. Why not just automatic layout?
Post reply on HN