Native reactive spreadsheet in 17 LOC

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.

draegtun• 10 years ago

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

ComodoHacker• 10 years ago

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.

dragonbonheur• 10 years ago

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

kevan• 10 years ago

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...

taneq4• 10 years ago

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.)

ffggvv• 10 years ago

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

taneq4• 10 years ago

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.

srean• 10 years ago

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.

kwhitefoot• 10 years ago

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

taneq4• 10 years ago

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.

tonyle• 10 years ago

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.

greggirwin6• 10 years ago

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. ;)

dockimbel3• 10 years ago

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...

frik• 10 years ago

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

http://jsfiddle.net/ondras/hYfN3/

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

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

blablabla123• 10 years ago

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.

dockimbel3• 10 years ago

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.

Tloewald3• 10 years ago

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?

networked2• 10 years ago

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.

Ohp4boo44• 10 years ago

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

WaxProlix• 10 years ago

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.

greggirwin6• 10 years ago

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.

Zelphyr2• 10 years ago

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.

dmitriid• 10 years ago

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.

fleitz• 10 years ago

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.

mapcars3• 10 years ago

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?

kpierre• 10 years ago

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

Ohp4boo44• 10 years ago

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.

Ohp4boo44• 10 years ago

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)

statictype• 10 years ago

A formula which is allowed:

    =alert("whatever")

Still, pretty cool though

asciihacker• 10 years ago

How fast is the red language?

Zelphyr2• 10 years ago

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.

greggirwin6• 10 years ago

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.

greggirwin6• 10 years ago

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.

Native reactive spreadsheet in 17 LOC

Related Stories