Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

Hi Josh, I am one of the core Onyx developers, so I am biased in some respects. I'm going to only speak to specific advantages that code > data gives Onyx. An advantage with Onyx is the ability to build up your jobs dynamically using data that is easily transformable by code, using all of the

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

2016-02-03 0:36 GMT+01:00 kovas boguta : > > Out-of-band schemas/assumptions or automagic inference are incidental > complexity to deal with the fact that XML cannot directly represent the > concepts that algorithms want to deal in. This is the point I was making >

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

I find this subject interesting as I was just discussing this with a co-worker recently. There's a few points I'd like to make: Firstly, data is often a form of a DSL (domain specific language). Libraries like Onyx often contain (as Lucas mentioned) a parser that walks the data and performs some

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

Very good points, Timothy! On Wed, Feb 3, 2016 at 7:45 AM, Timothy Baldridge wrote: > I find this subject interesting as I was just discussing this with a > co-worker recently. There's a few points I'd like to make: > > Firstly, data is often a form of a DSL (domain

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

and let's not forget codata (e.g. infinite lists) and coprogramming (e.g. web apps). On Feb 1, 2016 4:02 PM, "Josh Tilles" wrote: > As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: > Distributed Computing for Clojure” >

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

XML is data, but its data that thwarts easy manipulation from a programming language. It doesn't cleanly map onto computational concepts. Quick: how many ways can you represent key-value pairs in XML? Of course, its also a disaster from an efficiency point of view, since there is basically only

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

On Mon, Feb 1, 2016 at 4:02 PM, Josh Tilles wrote: > As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: > Distributed Computing for Clojure” > , I'm distracted by a > nagging worry that we —as a

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

I do think the whole "code is data" thing is a bit overstated. The earliest computers used paper tape for data records: At Bletchley Park, the "data" (ciphertext to be broken) was encoded onto the paper tape in the photo. The "code" was hardwired into the design of the machine & its

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

2016-02-02 20:41 GMT+01:00 kovas boguta : > XML is data, but its data that thwarts easy manipulation from a > programming language. It doesn't cleanly map onto computational concepts. > How so? I mean, rolling key-value access and positional access into a single

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

Joining the "dump on XML" bandwagon, I believe that adoption of RDF and OWL a decade ago was greatly hindered by the W3C's decision to embrace XML as the serialization mechanism. I suspect I wasn't the only semantic web hacker to adopt the much simpler N3 and turtle notations for human

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

On Tue, Feb 2, 2016 at 3:45 PM, Herwig Hochleitner wrote: > > basically attributes, and child elements > In general yes, but there are endless specific ways to do this. Do you represent a kv-pair as a single element? Do you have and as elements? Or do you use the name

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

On Tue, Feb 2, 2016 at 6:15 PM, Herwig Hochleitner wrote: > > When dealing with ground tags generically (like data.xml does), i.e. the > mapped-to structures add no information over the ground tags, I'd say it > would be still pretty easy to create a reader, which uses

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

On Tue, Feb 2, 2016 at 2:05 AM, Mikera wrote: > I share the same unease. I haven't quite fully been able to articulate all > the reasons, but here are the things that concern me most: > > 1) Completing the API for data access with the representation > 2) Refactoring

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

2016-02-02 23:34 GMT+01:00 kovas boguta : > > In general yes, but there are endless specific ways to do this. Do you > represent a kv-pair as a single element? Do you have and as > elements? Or do you use the name of the key as the name of the element? And > then

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

I think the message is 'data doesn't have to be code' not 'code should be expressed in data' which is significantly different. XML went wrong because people tried to write code in XML. Nobody (I think) is saying explicitly that we should write code, logic etc. as data only that there is no need

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

I share the same unease. I haven't quite fully been able to articulate all the reasons, but here are the things that concern me most: 1) Completing the API for data access with the representation This is my biggest issue. Good practice IMHO is to keep APIs abstracted from underlying

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

I see the same issues/feel the same pain, but I attribute it much more to dynamic typing than data. Changing the API is always going to be expensive but without typing we pretty much to do it without tool support. Even in Java and the magic of IDEs there is still pain - changing the return type

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

> I don’t know much about why the industry seems to have rejected XML as “bad” Off-topic, but I think 2 issues dominated 1.) Unnecessary complexity in the standards: http://harmful.cat-v.org/software/xml/soap/simple 2.) draconian error-checking. I assume the move to JSON was to get away from

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

Josh To assume there is/was a problem because someone said so will waste your time. Through all the religious zealotry and opposing opinions, my comment would be: "Eschew commentary. View each technology option as a tool in your tool-belt, and expand it as time goes on. When the right problem

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

The reason XML has a bad rap is because it has been used for things like configuration files. XML was intended as a host/platform/language-agnostic data interchange format, not something humans would write by hand, much less have to read. > On Feb 1, 2016, at 4:02 PM, Josh Tilles

How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

As I’m watching Michael Drogalis’s Clojure/Conj 2015 presentation “Onyx: Distributed Computing for Clojure” , I'm distracted by a nagging worry that we —as a community— are somehow falling into the same trap as the those advocating XML in the early

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

Also watch Zach Tellman's "Always be composing". And keep in mind Alan Perlis' maxim "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures ". Is XML a data structure in that sense? Or is

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

To understand the XML problem you have to understand Java in the 2000s. Java was a very limited language, and it was extremely verbose. There were type declarations and coersions everywhere. Almost all looping was managed with for loops (there were no higher order functions, and recursion wasn't

Re: How is the emphasis of “data over code” different than the XML advocacy of the early 2000s?

Josh Tilles wrote on Monday, February 1, 2016 at 2:02 PM: So, am I incorrect in seeing a similarity between the “data > code” mentality and the rise of XML? I see it as the difference between: {:name "Sean" :age 52} And: public class Person { private String name; private Long age; public