4 ms·
The next big data framework must be a programming language. Most languages make the assumption that the data it is processing, is available locally. This was tr
by wicknicks 13y ago
The next big data framework must be a programming language. Most languages make the assumption that the data it is processing, is available locally. This was true until the last few years for almost all situations. But not anymore.
- tbrownaw 13y agoWhy? And where does the language end and the library begin?
- justincormack 13y agoWell there are issues of where you do the computation and what can be done in parallel. A language could help by having well defined semantics that makes this easier. Embedding one language in another (as with SQL) is a pain as a programmer. Although no solutions that caught on emerged here despite some promising research.
- wicknicks 13y agoExactly! Some of the research is very new though, and still needs more work. The timing is just about right to get some new languages/ideas flowing (given there being lots of talk about Java taking the back seat, and no other language really taking up the lead).
- webjprgm 13y agoI think I misread this the first time. You mean a "big data" framework not a big "data framework", right? The idea of using a programming language as a database language: MUMPS (aka M), JavaScript as query language to some new NoSQL databases, ORM like Ruby ActiveRecrod which makes it look like you work on data in just Ruby. As for the "big data" interpretation, I don't have much to say.
- xkcdfanboy 13y agoNot everything is Ruby. Pretty much all web frameworks have an ORM for querying databases, namely Django (Python.) You really didn't have much to say except throwing Ruby around. What is with Ruby and fanboys?
- CountHackulus 13y agoSo like Fortress, X10, Chapel, UPC, or (arguably) IBM InfoSphere Streams.