uG posted:

perl6 is great for all this poo poo

code:

perl6 -e '.say for 1..Inf;'

perl6 -e 'say $ಠ_ಠ.HOW;'

Malcolm XML posted:

Control.lens


>

Cocoa Crispies posted:

that whole page is just a list of "don't hold it like that" tier problems

yeah it doesn't nest comprehensions correctly

the fix is don't nest comprehensions you rear end, humans can't understand that either

Zombywuf posted:

Nesting comprehensions is really loving simple, and there is no possible way that coffeescript's interpretation of them is remotely correct to anyone.

You didn't look at old versions of that page did you? I know people who've been made to use coffeescript for over a year.

quote:

You build your own database by assembling community developed plugins

MononcQc posted:

http://rumoursdb.com dangit node.js people

Suspicious Dish posted:

QPZIL posted:

the poo poo does this even mean

AlsoD posted:

lens is the best new library i've used in ages. even just using it as an upgrade to record syntax is totally worth it and i haven't even delved much into all the wacky poo poo it can also do

Suspicious Dish posted:

fidel sarcastro posted:

after messing with it a bit i still don't really know why i'd want to use coffeescript instead of javascript + underscore, but i don't like significant whitespace soooo

Malcolm XML posted:

Unfortunately

code:

 >:) 

was not an emote, but an operator


I've watched ekmett attempt to explain lens a few times and i still have no idea what half the poo poo in Control.Lens does

maybe some day

MononcQc posted:

http://rumoursdb.com dangit node.js people

Notorious b.s.d. posted:

tacodb is a node.js binding for leveldb

which means actually being a database is something you have to do yourself. tacodb just handles calling into C for you

tef posted:

"A responsive database for responsive applications, core features strongly suite realtime."

i have no idea what responsive means or real-time means any more.

quote:

Suppose the libraries are all on different islands, and books and book requests are carried between the islands by brave librarian-sailors. The librarians are brave, but not fearless, and sometimes the inter-loan service is disrupted because of poor weather. At certain times of the year, disruptions are more frequent.

When you go to your local library to get a book out, there is always a chance that there is a new edition of that book that the library doesn’t even know about yet. You could check out a book, read it, return it, and then later, a new edition arrives at your library, fixing important errors in the edition that you read.

How do you know that you are reading the latest edition of your book? Especially in inclement weather?

You can’t. That is what the CAP theorem teaches us.

What kind of systems can you build if you don’t ever know if your data is true? Well, not systems you can really trust, at least.

So, what do you do if you need to know that the data you got was actually up to date? The best you can do is keep on checking back at the library to see if a new edition has arrived. Naively polling the database — but this multiplies reads and decreases performance!

A database-like phone service which has the CAP problem is described in A plain english introduction to the CAP Theorem. In certain scenarios, the clients of the service make a request, which is answered with what turns out to be out-of-date information. This explanation gives us a clue: the clients call the service on their telephones, but the service does not take advantage of the fact that telephones provide two-way communication.

If the clients had to keep calling back to check if information had changed, it would be very annoying for both the clients and the service. But if the service had the client’s phone numbers, the service could call back the clients when the information they are interested in changes, instead of hoping that the client will call back in time to make use of the new information.

This is my proposal: A “database” with push notifications!

tef posted:

so, uh, this is a pub/sub broker. but because it's persistent it's a database. maybe it's like triggers who knows

Hard NOP Life posted:

is it poop?

Cocoa Crispies posted:

nope, it's not even that

it adds callbacks or something


http://dominictarr.com/post/44516618714/working-around-the-cap-theorem-with-rumours-db


what if the service callbacks never come

what if the client is disconnected from the servers

is there a checklist or easy form you can fill out and give to people that think they've escaped the cruel grasp of dr. eric brewer's cap theorem

quote:

But what if there is another approach? What if, instead of trying to build a better database, we built something that isn’t a database, and so simply avoids the assumptions of the CAP theorem by stepping outside it? But what would this mean? What is a database, really?

Suspicious Dish posted:

it means you built something useless in javascript, dingus

Cocoa Crispies posted:

is there a checklist or easy form you can fill out and give to people that think they've escaped the cruel grasp of dr. eric brewer's cap theorem

Suspicious Dish posted:

it means you built something useless in javascript, dingus

quote:

What is a database, really?

quote:

WHAT IS TESSEL

Tessel is an Internet-connected microcontroller for software developers.

Embedded development is as easy as coding a web or mobile app. Or prototype a physical product, and refine the experience with telemetry and updates over Wifi. Create new ways to connect your life beyond a screen.

Tessel runs JavaScript right on the device—no server necessary. Use your own IDE and libraries to program it, just like web development. Uploading new firmware is as easy as tessel push!

Tessel supports packages from NPM to leverage the growing Node.js community and capabilities. That's HTTP, Twitter, web server, color, and async support right out of the box.

git clone trooper posted:

lisp machines reborn better and stronger