
Native reactive spreadsheet in 17 LOC - makmanalp
http://www.red-lang.org/2016/07/native-reactive-spreadsheet-in-17-loc.html
======
frik
A spreadsheet in fewer than 30 lines of JavaScript (uncompressed), no library:

[http://jsfiddle.net/ondras/hYfN3/](http://jsfiddle.net/ondras/hYfN3/)

[https://news.ycombinator.com/item?id=6725387](https://news.ycombinator.com/item?id=6725387)

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

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

~~~
Tloewald
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?

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

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

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

[https://gist.github.com/greggirwin/8d0b1c02ccdbd5520d9c77d49...](https://gist.github.com/greggirwin/8d0b1c02ccdbd5520d9c77d49ea91ada)

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.

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

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

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

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

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

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

~~~
dockimbel
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...](https://gist.github.com/dockimbel/091cc787b366a3d88972b8cb9e2878b2)

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

~~~
spinningarrow
Care to share any examples?

~~~
quantumtremor
[https://fb.me/react-15.2.0.min.js](https://fb.me/react-15.2.0.min.js)

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

~~~
nathancahill
I think that's their point.

------
ComodoHacker
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
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
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...](https://code.facebook.com/posts/1365439333482197/how-we-built-
facebook-lite-for-every-android-phone-and-network/)

~~~
imtringued
Doing something is often more important than doing it well.

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

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

~~~
mapcars
>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?

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

~~~
mapcars
So, I did this:
[https://gist.github.com/maximvl/8d4cd6c9139f6f8f3729f4ba59fa...](https://gist.github.com/maximvl/8d4cd6c9139f6f8f3729f4ba59fa78d1)
and nothing happened. How do I run this?

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

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

------
statictype
A formula which is allowed:

    
    
        =alert("whatever")
    

Still, pretty cool though

------
asciihacker
How fast is the red language?

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

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

