20 ms·
Gluon – A static, type-inferred and embeddable language written in Rust
- Xeoncross 8y agoLooks really interesting. The readme actually got me started with lots of good examples. Side note though: I won't ever use a symbols-instead-of-words language unless I have to. let { (*>), (<*), wrap } = import! std.applicative This is not my idea of good language syntax. I like jr developers, non-X language developers, hardware guys, and even graphic designers to be able to understand my code. Consider simple string concatenation. This is what it looks like in Objective-C: NSString *one = @"Hello"; NSString *two = @"World"; NSString *three = [[one stringByAppendingString:" "] stringByAppendingString:two] Total fail for something so simple.
- yiyus 8y agoI had the same opinion about symbols until I learned some APL. It taught me that symbols can be so useful as they are in math. It is true that non-math people, hardware guys, or graphic designers may not be able to understand a complex equation and think it is just some kind of hieroglyph, but the right notation can help to make things more clear. Anyway, it is very likely that, for example, a graphic designer would not be able to understand the Maxwell equations even if we wrote "rotational of the electric field" instead of using symbols. I am not claiming that symbols are always the best solution, but I think they have their place and there is usually a sweet spot for the problem at hand. I'd suggest you to try to keep an open mind. All this said, there are many (way too many) terrible examples.
- jlg23 8y ago> It is true that non-math people, hardware guys, or graphic designers may not be able to understand a complex equation and think it is just some kind of hieroglyph, but the right notation can help to make things more clear. The semantics of these "hieroglyphs" very much depend on the context, though: "a x B" itself only says "apply some operation x to the named entities a and B".
- yiyus 8y ago> The semantics of these "hieroglyphs" very much depend on the context We need context to understand words too. What is your point?
- rounce 8y agoWords also inform context (bi-directional), symbols derive their meaning entirely from context.
- yiyus 8y agoThey may give some more context, but you usually need to know the domain up to some point anyway. For example: a = &b; may just be a weird bunch of symbols if you don't know C. But my point is that, anyway, for someone who doesn't have any idea about what a pointer is: a is pointer_to b; is not going to make it obvious, and it is going to make a simple program with a linked list a nightmare to read for those who know. I am aware it is also very easy to show an example where symbols are much less helpful than words. Some good ones were given in this thread. I am just suggesting to keep an open mind because I have the feeling symbols can actually make some programs more readable, although finding the right balance is not an easy task.
- sitkack 8y agoIt is like symbols once internalized like strings, could be used as a tool of thought.
- DougBTX 8y agoAnother way to write that would be: NSString *one = @"Hello"; NSString *two = @"World"; NSString *three = [NSString stringWithFormat:@"%@ %@", one, two];
- GordonS 8y agoNot sure if you were trying to make it simpler, but honestly, this also looks needlessly difficult to understand.
- kccqzy 8y agoSometimes you are expressing a specialized concept that, even when translated into words, won't be readily understood by someone without domain knowledge. That's when I believe symbols are very useful. In this case we are dealing with an applicative functor. If you know what's an applicative functor, you will immediately know what these symbols mean. If you do not, even if we translate <* as `sequenceActionsKeepFirstValue` you still don't know what this is doing.
- hota_mazi 8y agoI know what an applicative functor is and I struggled to map what <* and *> are. These are not standard, even in the niche world of functional programming.
- jdreaver 8y agoThese symbols are part of the definition of the Applicative type class in Haskell http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html#v:-42--62- http://hackage.haskell.org/package/base-4.11.1.0/docs/Contro...
- djur 8y agoSame with Idris and Scalaz. I don't know how much more standard it could be.
- whatcanthisbee 8y agostandard it might be, but I seriously hope IDEs would give a hint on what to google when a junior sees "<"... try googling < or "scala <*"...
- hendi_ 8y agoI kind of miss the days where you would turn to the manual, read and understand it, before doing serious work in a language. I've had a junior dev ask me what kind of strange multiplication thing was going on in our C code base. If you don't even know about pointers, maybe you're not "junior" yet and should learn some more.
- VMG 8y agoWould you say the same about the operators in Java or C?
- djur 8y agoI'm confused by your example, which seems to be the opposite of symbols-instead-of-words. It's words-instead-of-symbols gone berserk.
- oblio 8y agoCleaning things up: NSString one = “Hello”; NSString two = “World”; NSString three = one.appendString(“ “).appendString(two); I agree with him, except for the super verbose method name, the symbols are a problem.
- djur 8y agoone, two, and three are pointers. @"Hello" is shorthand for creating an NSString instance, which is a heap-allocated object. Both of those are important in the context of Objective-C, so they can't just be left out entirely. (I also think Objective-C is a pretty extreme example here since its syntax is limited by its history as a preprocessor layer over C.) Setting aside those, the Objective-C code uses these symbols: ; = "" [] : And the example you provide uses these symbols: ; = "" () . It doesn't seem like the perceived improvement is from eliminating symbols, but from switching from Objective-C's Smalltalk-like method invocation syntax to a more familiar (to many devs) C++-style syntax. Also, it seems to me that leaning more on symbols makes the code even easier to read: NSString one = "Hello"; NSString two = "World"; NSString three = one + " " + two; Judicious use of overloadable/custom operators can make code easier to read, especially when they express an operation that can't be expressed clearly in a word or two. <>, > and <* fall into that category.
- kbenson 8y agoI really, really wish people would stop using + for string concatenation in new languages they design. It shares only a tangential relationship to arithmetic addition, and even that's a stretch. It's caused an enormous amount of bugs in numerous different languages. Please, let's just let that concept die for newer languages.
- 8y ago
- mikekchar 8y agoI'm dyslexic. I haven't looked into it in detail, but someone once told me that dyslexia is some kind of problem processing things that are pronounceable. When I was learning Japanese I was amazed how easy it was to read kanji (the Chinese) characters. Apparently processing things that are inherently symbolic (even if you can pronounce them) is done differently. It was like someone lifted a veil. Even now I prefer reading Japanese to English. I suspect if I learned Chinese I would enjoy it even more. The same goes for languages with symbols. For me, they are an order of magnitude more readable. Obviously people with dyslexia is a very narrow group to design a language around, but I suspect that there are others who also find it easier to think about symbols than words. That's why people design languages in this way (and as someone else pointed out, probably why math has such a large number of symbols). There are things that are easy to learn and things that are easy to use. Often there isn't as much overlap as you might expect between the two group. For something like programming languages, I'll take easy to use over easy to learn any day. Having said that, I am absolutely sure there are people who prefer having a big block of prose in their code. I see that kind of code frequently as well, so which one is easier to use almost certainly depends on the person.
- Xeoncross 8y agoGreat insight, thank you for sharing. I'll keep this in mind. Maybe in some cases a middle ground could be finding a way to use less symbols instead of more. Verbosity isn't always desired with symbol or prose.
- posterboy 8y agoThe input method for symbols is the other problem. Math notation is used for quickness.
- matchbok 8y agoAh, Objective-C, the language that seems designed as if on purpose to confuse and confound. I'm glad it's on the way into the garbage bin.
- jdreaver 8y agoGluon recently added implicit arguments with the latest release (see http://marwes.github.io/2018/06/19/gluon-0.8.html http://marwes.github.io/2018/06/19/gluon-0.8.html). In spirit it is like modular implicits (https://arxiv.org/pdf/1512.01895.pdf https://arxiv.org/pdf/1512.01895.pdf). This is really exciting because modular implicits represent a pragmatic balance between the flexibility of ML modules and the convenient overloading of type classes. Another cool feature of Gluon is modules are basically just records. This is a strict improvement over ML modules in my opinion. (See http://gluon-lang.org/book/modules.html http://gluon-lang.org/book/modules.html) Congrats on the recent release!
- MrBuddyCasino 8y ago> implicit arguments Because it worked so well in Scala?
- tutanchamun 8y agoWhat's the problem of implicit arguments in scala? I can see why implicit conversions can be a problem but aren't implicit arguments required for typeclasses and other nice features?
- pas 8y agoWhat's your opinion of Odersky's scala3 implicit plan?
- MrBuddyCasino 8y agoI'm not very familiar with Scala3, but as far as I'm aware implicits are still a core part of the language? Let me put it like this: I recently applied to two high-profile startups with experienced technical leadership, and they both explicitly asked me if I was a Scala fan. They weren't and made bad experience in the past regarding productivity due to complexity, tooling and developer onboarding, which unfortunately matches my experience. There is some good stuff for certain niches (Akka, Spark etc.), but otherwise I feel like Kotlin is winning.
- 8y ago
- kccqzy 8y agoLooks like a great language that's a nice mix of OCaml and Haskell! What's the interop story? If I am embedding this language inside my app, I reasonably want to make data structures in my app to be available through this language. How would that work?
- cjcole 8y agoThe support for interop looks strong: http://gluon-lang.org/book/embedding-api.html http://gluon-lang.org/book/embedding-api.html http://gluon-lang.org/book/marshalling-types.html http://gluon-lang.org/book/marshalling-types.html There are some marshalling traits that you can implement or derive.
- childintime 8y agoAs the `in` keyword seems key to understanding the language, could someone elaborate on it? It isn't obvious after reading the intro on http://gluon-lang.org/book/syntax-and-semantics.html http://gluon-lang.org/book/syntax-and-semantics.html.
- cobbal 8y agoLooks like a variant on ml-like `let`. let <variable> = <expression 0> in <expression 1> will bind the value of expression 0 to variable in expression 1.
- eximius 8y ago:sigh: I hate function call syntax without parens. It makes code much more difficult to read and, if it supports first class functions, passing around no arg functions is harder than it should be.
- PeCaN 8y agoI hate function call syntax with parens. It makes code much more difficult to read and, if it supports calling functions, calling functions with args is harder than it should be.
- bobdolebob 8y agoI hate parens call syntax with or without functions. It makes code much more difficult to read, and if it supports functions calling first, arguing with functions and passing is harder than it should be.
- kjeetgill 8y agoWhile I agree the parent could have elaborated more, would you like to as well? I've never worked in a language without parents for function calls so I share their confusion reading Haskell or Ruby code at a glance. I don't think a language needs to bend for non-users but being intelligible without knowing the language canI be nice. As an outsider, the examples: A(B(C)) A(B,C) A(B)(C) Could all be valid Python but still communicate a little bit about A B and C. Without parents they'd all look like "A B C". I'm sure it's more obvious if you know those languages.
- flomble 8y agoThe interesting thing is that in Haskell, the equivalents of Python's `A(B,C)` and `A(B)(C)` are identical: `a b c`. This is because of currying: you're allowed to supply one argument to a function at a time, and you get back a function that takes one fewer argument. So if `add(x,y) = x + y`, then `add(5)` is a function (let's call it add5) so that `add5(y) = 5 + y`, or in Haskelly notation, if `add x y = x + y` then `(add 5) y = 5 + y`. If you write `add (x,y)` in Haskell, then it means a function that takes a single tuple `(x,y)` as an argument. A(B(C)) would be `a (b c)` or `a $ b c` or `(a . b) c`. The first is the most vanilla way, the second is convenience (basically "evaluate everything after $ first, then plug it in") and the third uses the function composition operator `.`.
- tadfisher 8y agoThis looks very similar to Nix, with improvements such as real typing and lack of semicolons. That's a very good thing. Any plans for a purely-functional variant (i.e. a single expression per evaluation)?
- djur 8y agoAccording to the manual, Gluon doesn't have statements, but it elides "in": let n = 1 let m = 2 let nm = n + m nm is sugar for let n = 1 in let m = 2 in let nm = n + m in nm
- losvedir 8y agoNow this is what every language landing page should be like. I love the nontrivial code snippet solving a fun little problem front and center.
- wtetzner 8y agoWow, I've been wanting something just like this for Rust. And it has row polymorphism!
- sitkack 8y agoArguably, this is Rust.
- wtetzner 8y agoNot sure what you're trying to say here. Gluon is much more like OCaml than it is like Rust. And Rust _doesn't_ have row polymorphism.
- sitkack 8y agoBy being hosted in Rust, Gluon has access to the Rust ecosystem. So one could use Gluon and still be in the family depending how seamless the interop story is.
- wtetzner 8y agoI think we are in agreement. I was saying that I was looking for an embedded programming language like this for Rust, and now I've found it.
- knocte 8y agoLooks like F# but has a big design mistake in my opinion (which F# doesn't): the symbol '=' in a functional programming should be tied to comparison, not assignment. (The approach taken here is using "==" for comparison, which is less ugly than JavaScript's "===" but still ugly.)
- f311a 8y agoSo many new languages lately, does anyone is risky enough and using such languages in production?
- badsavage 8y agoI feel like every day a new programming language presented on HN. Maybe you didn't realize, but we know CL/scheme/clojure already and have no turning back..
- rixed 8y agoToo bad it has a different heap per thread. If I want to extend a C (or rust) posix-multithreaded program, it means I can't easily use gluon to access the state of my program (which requires accessing posix-multithreaded protected variables in the normal heap). Same thing that makes Lua useless to simply extend actual, pre existing C programs. Anyway, I'm still happy to see that more modern languages than algol have gained enough influence than the choice of type system, type inference and non C like syntax is not frowned upon anymore.
- lasagnaphil 8y agoIt would be great if someone made a UI framework with Rust and made this the scripting language (making the experience Elm-like, but with a better type system and without web technologies)