Live data from Hacker News

Rama is a testament to the power of Clojure

blog.redplanetlabs.com

21–30 of 76 posts

Re: Rama is a testament to the power of Clojure

#21

> Lisps have great control over what happens at compile-time, which lets you do incredible things. > Lisp programmers have struggled ever since it was invented to explain why this is so powerful and why this has a major impact on simplifying software development I've written some Common Lisp, Scheme, Racket. I like them. But what op defines as a feature is actually what kills all those lisps but Clojure where macro a…

This is one of those perpetual myths about macros. Ruby on Rails metaprogramming is often harder to debug than macros in Common Lisp. Flink and Spark work by generating and loading Java code at runtime (macros) but, since Java has no language-level support for macros, the generated code is very hard to inspect and debug.

What killed most lisps was the AI Winter and the concurrent drying up of DARPA funding.

Re: Rama is a testament to the power of Clojure

#22
post #17

>Rama’s language is Turing-complete… Amazing they could accomplish such a feat.

This seems unnecessarily cynical, they're just stating one of the design decisions that they made. When you design a new DSL you could choose to make it Turing-complete (e.g. Ruby on Rails) or not Turing-complete (e.g. Terraform's HCL). The point isn't that one is more technically difficult to build than the other.

Re: Rama is a testament to the power of Clojure

#23
> At its core is a new programming language implementing a new programming paradigm, at the same level as the “object-oriented”, “imperative”, “logic”, and “functional” paradigms... Rama generalizes the concept of a function into something called a “fragment”... a fragment can output many times (called “emitting”), can output to multiple “output streams”, and can do more work between or after emitting.

This sounds really similar to programming with observables (e.g. RxJS), is a "fragment" an even more general concept?

I used observables when I did frontend development, I found it a useful paradigm (once I got my head around the idea).

Re: Rama is a testament to the power of Clojure

#24

> At its core is a new programming language implementing a new programming paradigm, at the same level as the “object-oriented”, “imperative”, “logic”, and “functional” paradigms... Rama generalizes the concept of a function into something called a “fragment”... a fragment can output many times (called “emitting”), can output to multiple “output streams”, and can do more work between or after emitting. This sounds re…

A fragment itself is a generic programming construct that serves the same purpose as a function (just more general). When used in Rama topologies, they serve a similar role as observables in terms of reacting to new data as it flows through and sending any amount of information downstream to any number of output streams.

Re: Rama is a testament to the power of Clojure

#25

> Lisps have great control over what happens at compile-time, which lets you do incredible things. > Lisp programmers have struggled ever since it was invented to explain why this is so powerful and why this has a major impact on simplifying software development I've written some Common Lisp, Scheme, Racket. I like them. But what op defines as a feature is actually what kills all those lisps but Clojure where macro a…

For compile time control and meta programming, I found Zig's comptime system to be the best. It blends with the regular syntax seamlessly and solves several problems at the same time. It's one of the best things came out of language design in recent years.

Re: Rama is a testament to the power of Clojure

#26
I remember when the first time i read about Rama, with the blog post about having duplicated Twitter scale at 100x code or some such.

Which all in all, if you have built a platform/runtime/language and you pick one particular example to highlight it, being able to achieve XXXX% less than is trivial.

I was curious about all the bluster then, Seeing this post I am somewhat disappointed that there does not appear to have been a lot of visible progression.

But I guess it is still running semi stealth in private beta.

I will be interesting to see what becomes of it.

Re: Rama is a testament to the power of Clojure

#27

> Lisps have great control over what happens at compile-time, which lets you do incredible things. > Lisp programmers have struggled ever since it was invented to explain why this is so powerful and why this has a major impact on simplifying software development I've written some Common Lisp, Scheme, Racket. I like them. But what op defines as a feature is actually what kills all those lisps but Clojure where macro a…

I've used Lisps on and off for a decade or so, and my experience with it is pretty much in line with the Grammarly devs' summary: misuse of macros is one of those things people just assume is a major problem, but in reality is quite rare, even in cases like Emacs Lisp where most packages are developed by just one person. Lisp is not Perl, its users do not create spaghetti mazes for fun.

Re: Rama is a testament to the power of Clojure

#28

> Lisps have great control over what happens at compile-time, which lets you do incredible things. > Lisp programmers have struggled ever since it was invented to explain why this is so powerful and why this has a major impact on simplifying software development I've written some Common Lisp, Scheme, Racket. I like them. But what op defines as a feature is actually what kills all those lisps but Clojure where macro a…

This is one of those perpetual myths about macros. Ruby on Rails metaprogramming is often harder to debug than macros in Common Lisp. Flink and Spark work by generating and loading Java code at runtime (macros) but, since Java has no language-level support for macros, the generated code is very hard to inspect and debug. What killed most lisps was the AI Winter and the concurrent drying up of DARPA funding.

I don't think I've expressed myself well.

When I say software at scale I mean:

- going on GitHub opening a file and understanding what's happening

- reviewing a PR and figuring out stuff without requiring an ide

- having easy onboarding with devs already accustomed to a base language and its patterns

Java, C, TypeScript, Scala, Kotlin, etc. Pretty much all major languages offer this: less power but much less ambiguity and mental overhead.

Lisps (with a minor exception for clojure) and Haskell are just not those languages.

Which, again, is why all of those languages produced very little software worth of mentioning for decades.

Re: Rama is a testament to the power of Clojure

#29

Earlier quoted context omitted.

This is one of those perpetual myths about macros. Ruby on Rails metaprogramming is often harder to debug than macros in Common Lisp. Flink and Spark work by generating and loading Java code at runtime (macros) but, since Java has no language-level support for macros, the generated code is very hard to inspect and debug. What killed most lisps was the AI Winter and the concurrent drying up of DARPA funding.

I don't think I've expressed myself well. When I say software at scale I mean: - going on GitHub opening a file and understanding what's happening - reviewing a PR and figuring out stuff without requiring an ide - having easy onboarding with devs already accustomed to a base language and its patterns Java, C, TypeScript, Scala, Kotlin, etc. Pretty much all major languages offer this: less power but much less ambiguit…

And this is just not true: I’ve worked on large lisp programs in various situations with minimal documentation and done just fine.

Re: Rama is a testament to the power of Clojure

#30

I remember when the first time i read about Rama, with the blog post about having duplicated Twitter scale at 100x code or some such. Which all in all, if you have built a platform/runtime/language and you pick one particular example to highlight it, being able to achieve XXXX% less than is trivial. I was curious about all the bluster then, Seeing this post I am somewhat disappointed that there does not appear to hav…

Indeed, we're in private beta and aren't publicizing much about what we're doing. We'll eventually be releasing many case studies on how our private beta users are using Rama.
Post reply on HN