Native reactive spreadsheet in 17 LOC | Hacker News Reader

Native reactive spreadsheet in 17 LOC

red-lang.org

152 pointsmakmanalp61 comments

A spreadsheet in fewer than 30 lines of JavaScript (uncompressed), no library:

https://news.ycombinator.com/item?id=6725387

You can compare it to the readable 67 lines of code in red-lang

There is kind of a wow effect to such short code examples but I resist to see consequences for real-life use. Adding a few more features like charts and actual Excel-file export and import is no rocket science but will render that code base unreadable. I rather prefer 5 kLoc boilerplate and have a proper foundation to start with.

Red's author here. In all fairness, for that JS spreadsheet to not look ugly, you need to account for the CSS code too, which is ~35 more lines of normally spaced code. Also, there's no realtime reactivity like in our demo where the cells update as you type.

For the "no library", well, you have tons of libraries included in a ~100MB runtime (browser) required to run and render that demo, while Red's one runs on the OS directly (our runtime is 0.6MB uncompressed and entirely written in Red, not a single 3rd-party library). ;-)

That said, that JS demo code is very nice, and its slickness impressive.

If we're really going to be fair, the JavaScript is a much more readable 30 loc than your nigh incomprehensible block of "17" loc which looks like something out of the obfuscated C contest. I expect you rely on the OS for some stuff, why not factor in the size of that?

@dockimbel: perhaps adding some syntax coloring of your code example might help here, the syntax is hard to parse if you don't know what to look for..

If you want the fully unfolded version you have it there [1]. If you count the JS + CSS lines, then it's about the same size as the Red unfolded version.

[1] https://gist.github.com/dockimbel/b0a413342dc39568696207412a...

If you really want to be fair, you all would count all the LOC that makes all that possible. Then we'll see who is pissing further!

given the size of the the entire thing, the LOC of these programs are a rounding error anyway.

I am no expert here, but given the Red system is under 1MB, and the Java browser is over 100MB, wouldn't what they use in the OS be the same, and therefore Red is still 100 times smaller. Just curious. I find the whole self-contained thing under 1MB with no dependencies very intriguing. Especially afer looking at the other demos that are not trying to code golf. Great GUIs and respectable speeds, and easy to distribute.

Code never runs in a vacuum, so arguing about the size of the elephants on the way down is pointless, which is my point.

What I do see is that the JavaScript does all of this much more cleanly and intelligibly, and has an honest line count.

Incidentally, I also think that cleanly separating presentation from logic is an advantage of the JS / CSS divide, even is JavaScript if far from perfect and CSS is actively horrible.

I did a VID version of the demo, that shows a hint at how styling works in Red.

https://gist.github.com/greggirwin/8d0b1c02ccdbd5520d9c77d49...

The reactive logic is all lifted from the original. Around line 40 you can see where styles are defined inline. Originally I had them just defining visual aspects, but then moved the actors into the cell style as well.

With native widgets, you don't get complete control, and they won't match across platforms. Rebol had its own GUI system, and I wouldn't be surprised to see something similar done by a clever Red...we don't have a name for folks who write Red yet. Racket got the best name, with Racketeers.

That's much clearer, thanks!

Folks who use Red could be referred to as communists ;-) If it takes off, you'll be Big Red.

Good to see that. After all, the article was close to code golfing and not using the new VID to keep it succinct.

More VID demos and the type of FRP in RED would be more enticing to me. But truth be told, I stumbled upon Red when looking at short programs translating text to morse code. The Red example (from Rebol actually) was very short, yet easy to read. I program in J, so I know what short, and unreadable means to others; I personally like J.

I don't think it is pointless. But I am curious, not being a JavaScript dev, what would be the closest analogy to Red's setup. For instance, you can download Red for multiple platforms under 1MB, and without a browser, it self-compiles and you have a full coding environment.

I realize browsers are ubiquitous, so in essence you just need to count the size of browser, JS engine and code. What would be the bare minimum JS setup to provide core libs, GUI, and other helper libs and a way to run it/distribute it sans relying on pre-installed browsers. Would that be Chromium or Electron? Can you choose the best engine with them, or are they attached to the browser or minimal browser?

Shameless plug: I wrote a Tcl/Tk spreadsheet inspired by that JavaScript one that others have since trimmed down to 29 lines: https://tcl.wiki/41294. (HN discussion of the initial version: https://news.ycombinator.com/item?id=9275268. Note the K spreadsheet in the comments.)

I am rather a fan of both Tcl's and Rebol's GUI DSL.

Edit: I'll explain how the Tcl/Tk spreadsheet works. I am not sure I understood Red's reactive framework quite enough to compare and contrast the two implementations correctly, so if you do understand it, I would love to read your comparison.

The spreadsheet cells are ::ttk::entry widgets comparable to <input type="text"> that are created in a loop and laid out using the built-in [grid] geometry manager. When a cell is created its value is bound to a variable like "A2" by two-way data binding. We then add a "trace" to that variable so that when it is read the command [recalc] runs to update its value based on the formula for the cell before the read completes. This triggers update cascades that resolve chains of dependencies between the cells' formulas. The formulas are plain Tcl expressions mangled by a regexp to allow you to reference the values of variables like "A2" without the "$" prefex.

Your Tcl/Tk version is duly appreciated in the original post as well.

Thanks for pointing that out! The "How does it work?" subsection header caught my eye and I totally missed the mention. :-) I am happy to see it inspire others.

That's pretty fancy, and (as another poster said) a great way to pitch the language. Nice work!

While I feel that expressiveness is good to an extent, I can't help feeling that there's a certain point beyond which increasing expressiveness is detrimental to productivity and overall code quality. While it's certainly elegant and satisfying, in order to read or understand the code you have to 'unpack' it mentally, requiring much more work than if it had been written at a lower level of abstraction. This seems to me to be related to something I read recently (I wish I could find the link), saying that all human languages tend towards a fairly predictable word entropy which allows a good balance between efficiency and error correction capability.

(Obviously this was a demo to highlight the language's power, and not how you'd write real-world code, but still.)

Maybe this is why so many people love Golang (including me). It's a corporate language after all.

I still default to C++ (or at least, the subset thereof which works for me). Occasionally I've eyed newcomers like Rust and Go from across the room but haven't yet found a compelling enough reason to burn a bunch of my free time learning another language.

Golang looks at very cursory glance to be yet another entry in the "modern C-like" column. If you could recommend one link to read to convince me that it's worth learning, what would it be? My main dev work is native Windows/Linux GUI, Linux command line utils/servers, and embedded development.

I don't have a good link at my fingertips, but IMHO the killer features of Go are:

- super-fast compilation, so much so that you can write Go "scripts" that are compiled and run from the #! line every time you call them, faster than it takes the Python interpreter to start;

- static binaries: this eliminates an entire class of problems, such as DLL hell and OS version dependencies;

- great concurrency model, easy, powerful, and safe, based on CSP;

- implicit interface implementation, which makes it easy to integrate different libraries (I'm not sure what the academic name is for this feature, but it's taken straight from Common LISP, Haskell, etc.)

Highly recommended. Easy to learn and very comprehensive standard library.

Go has had some surprising success in command line tools, probably because it's one of the easier languages to deploy static binaries in. Windows/Linux GUI is more-or-less a no-go, and "embedded", well, it depends on how you feel about 3MB+ executables as the minimum size. If "embedded" here means "cell phone" level of capabilities, that may not bother you. If embedded means "I'm counting the kilobytes" then it's also a no-go.

A general comment, noting related to any specific language.

The mental unpacking to read does improves over time, as you get familiar with frequently occurring patterns. But what I find more interesting is the "write" side of the story, not the "read" side. I have encountered many who think just because the code is short and succinct it must have taken no more than a jiffy to write. It takes mental effort to distill a complex idea to a short idiomatic string.

What you get rewarded with after that exercise is less space for subtle bugs to hide. It is quite difficult to write very short pieces of code with non-obvious or subtle bugs.

Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte.

    I would have written a shorter letter, but I did not have the time.

        Provincial Letters : Letter XVI (4 December 1656)

via https://en.wikiquote.org/wiki/Blaise_Pascal

True, it's applicable to any language which aims to be dense in this way - just something that's been bugging me.

Unpacking ability certainly improves over time. The problem is, so does packing, such that they tend (at least in my experience) to balance out. The time taken to write, and read, code is dominated by the per-concept costs. So you end up with the writer and the reader of the code still taking the same amount of time per concept, but they're also doing a bunch of translation steps alongside. Since these steps are fallible, you've reduced the overall efficiency.

There's not less space for subtle bugs to hide. The space is just folded up, and bugs can also hide in between the folds.

Agreed. We can't say that packing is universally good or bad. You can have a dense tangle or distilled elegance.

Pretty cool.

However, how can you call it 17 LOC and then put in a link to a "readable" version with 67 LOC on the same page.

I think the manually minified version was done for fun. A lot of programmers like to play this game. For me, the tiny version is fun to see, but not to read, so I'm glad he made the regular version available as well.

You make a good point, though, in that examples benefit from being readable.

Also, maybe it made you look. ;)

The 17 LOC version is still relatively readable for someone fluent in Red/Rebol, despite the tight vertical packing. I could have claimed 14 LOC using the minified version [1], but in such case, I couldn't have called it "readable" at all. ;-)

[1] https://gist.github.com/dockimbel/091cc787b366a3d88972b8cb9e...

This is nothing, I've seen some pretty substantial JS apps that are only one line.

Care to share any examples?

https://fb.me/react-15.2.0.min.js

Well, you're technically correct, but minified JS is kindof cheating, right? I mean, I've written multi megabyte C# programs that I could minify to just a single line, but it wouldn't be right.

I think that's their point.

This code neither does anything (it's a library) nor does it fit the criteria for "LOC" given in the article: minified code formatted into ≤82 characters per line.

http://xem.github.io/miniCodeEditor

It's true that there are impressive one-line JS apps.

That doesn't mean that this is nothing.

Ah, I sense sarcasm.

On the one hand you're right, size can be of arbitrary value. Saying "No external libs!" and then using (presumably) several parts of the standard lib kinda cancels each other out.

But it seems like a great language for making GUIs (possibly), and this seems an excellent demonstration of that, so it has plenty of merit.

I do relate to the over use of "n in x LOC!" posts. Like we get it list comprehensions are cool.

NB. There's nothing stopping this Red code being just one line. All the newlines are for readability only :)

Wow. That's how one should pitch a new programming language to programmers.

>Yeah, we still count in KB.

Sadly, no one cares about such things nowadays.

I care. Demomakers care. Serious compiler and interpreter writers care. Embedded systems developers who have to write for microcontrollers based on 8051 architecture care. Even the 6502 and Z80 may still be in production in some capacity and their buyers care.

Maybe web developers don't care, but nobody really cares that web developers don't care. /s

Most web developers probably don't, but neither do most native application developers. In any area there's a subset that cares a lot [1] but for most apps getting the business model right is more effective than squeezing out a few kb.

[1] https://code.facebook.com/posts/1365439333482197/how-we-buil...

Doing something is often more important than doing it well.

Great to see Doc and the team doing more cool stuff with Red. What's the word on Faces and other UI elements? Tough language to get into, but really intriguing.

Red uses native UI elements. Windows was first, with OS X and GTK coming. Still just basics right now, which is enough to start playing. It also has a drawing dialect.

I think what the Rebol guys found was that it was generally tough to get into by experience programmers who were used to looking at C-style syntax. New programmers, however, tended to pick it up very quickly.

If by expressiveness the author (wrongly) assumes number of characters per line and LOCs per commit, then Red/Rebol has nothing on J/K (and probably Perl as well).

However. At one point reading and deconstructing a tangled mess of characters outweighs the "expressiveness" of the language.

More than "expressiveness" a language needs docs, community, tools.

It's also a language we don't understand.

Haskell is virtually unreadable to me, however, I do understand that it's a quite powerful language. I would imagine that if I took the time to learn Red / Haskell the code would make a lot more sense.

I had the same experience with ruby, initially ruby code looked very foreign to me, however, now it's quite easy for me to read.

>then Red/Rebol has nothing on J/K

And of course, you will show us same capabilities, gui, reactiveness in J/K, won't you?

A spreadsheet in k3, demonstrating gui and reactive capabilities: http://nsl.com/papers/spreadsheet.htm

Glad to oblige, for K:

    S..t:".[`D;(;);{. y};S[]];S[.;`f]:9$D[]"
    S:D:.+(`$'_ci 97+!26;26 99#,"")
    `show$`S

This K (K2/K3) version of a simple spreadsheet (so demoing GUI, "reactiveness") is also mentioned in the original post's comments.

So, I did this: https://gist.github.com/maximvl/8d4cd6c9139f6f8f3729f4ba59fa... and nothing happened. How do I run this?

Seems you're running Kdb+ (also known as "Q" or "K4"). You need K in the older K2 or K3 version to run the above. Kx stopped selling K2/K3 so they are basically no longer available.

I see, well, it's good that Red is open-source.

The author unfortunately cites the rather worthless Redmonk language expressiveness writeup, which has since been rightly berated for its lack in methodological rigour. (HN thread on the Redmonk writeup: https://news.ycombinator.com/item?id=5438755)

A formula which is allowed:

    =alert("whatever")

Still, pretty cool though

How fast is the red language?

My understanding is that when compiled it is nearly as fast as C.

But my feeling on "fast" is generally; how fast does the solution need to be? I have a co-worker who complained that more business logic client-side would slow down our application (it won't, of course). Our application gets on average about 2 requests per second for any given customer. It is by all human perception plenty fast. It doesn't need to be any faster and even being a little slower would go unnoticed. Its all behind a login and isn't intended to be crawled so SEO isn't an issue. Yet once again the ultra-vague benchmark of "fast" gets bandied about needlessly.

But back to Red. From what I've seen its pretty fast but its also early days for the language and they're not focused yet on optimization. Looking at how it is designed I can see how it will be eventually VERY fast once optimized.

In the early 90s I was using VB1 to write Windows apps, while a colleague was writing in C. He said my app would be a lot slower than his. I countered that my app would be a lot faster than his. Probably 12-18 weeks faster.

Fast at what?

There are 2 levels in Red. Red is the high level language (think scripting level) while Red/System is the low level dialect (think C). In general, because the compiler is new and non-optimizing, Red/System will probably be half the speed of C from an optimizing compiler right now. As always, algorithms are the big win.

Reply on news.ycombinator.com