24 ms·

And the circle of life continues! I have seen exactly this method in 2004-2006 but with XML. If you are reading this, and you think it is a good idea, please

And the circle of life continues! I have seen exactly this method in 2004-2006 but with XML. If you are reading this, and you think it is a good idea, please don't follow it as it is not. Back in 2006-2009 I worked at MobiTV, which we had the same exact way/method of programing our mobile apps, on J2ME/feature phones. The made up language was called CEF which was based on XML. While the idea is sound in paper, This turns really fast into an ugly, debug everywhere type of scenario, where it is hard to both develop and debug properly. The only way this is ok, is when you have some fully automated UI tool, that stores some kind of state, and retrieves it back, but with no human intervention and some very very limited logic. Otherwise you are in a world of pain. If you try to include real application logic into something like this it is going to hurt your business long term. It will turn your business logic like some Maven configuration, full of gotchas and more.

jchw 5y ago
I am not saying that you are wrong. Not at all. However, something I’ve come to learn is that some ideas I thought were bad were actually not bad. They were poorly executed and the exact reasoning why they did not work well in a given application was not well-understood. So I can see an argument for “this was horrible back when it was done in the early 2000s” simultaneously with “this could actually still be a good idea for some use cases.”
- janderland 5y ago
  Currently reading about agriculture throughout human history. It made me wonder how many people failed to domesticate a single kind of crop and assumed crop domestication as a whole isn’t a good idea. I realize that people need to make decisions based on their personal experience, and I don’t have a good rule-of-thumb for when to try a variation of a “bad” idea.
  - marksbrown 5y ago
    ‘Many of life’s failures are people who did not realise how close they were to success when they gave up' -- Thomas Edison.
    - burnished 5y ago
      said the man who tested something like 6000 different kinds of plant materials as filaments for a light bulb
      - smitty1e 5y ago
        Three cheers for brute force methods. Sometimes you need the BFH to get to the elegant solution.
    - craftinator 5y ago
      Said the man who lied, cheated, and stole his way to fortune and historical fame.
      - fruityrudy 5y ago
        You’re just jealous
  - samus 5y ago
    Agriculture is difficult because it is literally a fight against nature/entropy. And it still has to be proven that it is a viable way to drive human civilization in the long term. In nature, species populations compete with each other and are kept in a dynamic equilibrium. If population size of a species increases, then its predators will have more opportunities to predate, and their population size increases as well. This leads to more predation pressure, which should negate the population increase and decreases opportunities for predators as well. "Predators" is to be understood in a very general way. It can also apply to fungi and other microbial forms of life. Changes to this equilibrium arise when prey species evolve to resist the predation pressure by predators. And vice versa if the predators improve. Then, ecosystems change, and these changes can be very disruptive. Agriculture is a rebellion against this dynamic equilibrium because it creates irresistible opportunities for predators. They have to be held in check either by brute force (hunting, pesticides, containment) or by hacking the ecosystem (for lack of a better term) to ensure that helpful predators are around. The former is probably unsustainable in the long term as it is not at all clear that we will forever be able to outsmart the evolutionary potential of predator species. The latter is difficult as well. Apart from predation, the other challenge to agriculture is that it depletes the soil in the long term. Fertile soil arises as a result of a ecosystem where the decomposers cannot keep up. Most forms of agriculture interrupt such ecosystems and thus deplete the soil in various ways. To keep this in check, different methods were evolved, such as slash-and-burn, crop rotation and artificial fertilization. But it is not at all sure that we will always be able to stop depletion of our soils just in time to prevent civilizational collapse. Currently, availability of phosphorus is a looming danger because most of it is mined. Once we hit peak phosphorus, we better have solutions in place to get it from somewhere else.
- valenterry 5y ago
  Sharing code between frontend and backend isn't a bad idea, yes. However, using Json for it is. And the problems and limitations with json can't be "fixed" in any way.
  - dragonwriter 5y ago
    > Sharing code between frontend and backend isn't a bad idea, yes. However, using Json for it is. I don't see why serializing close to JSON is any worse than doin so to, say, S-expressions, or Algol-style syntax, or WASM. If you aren't manually coding it, but generating it, the capabilities matter, the syntax matters a lot less.
    - valenterry 5y ago
      I think there are very good reasons why languages have their own custom formats and none of them ever decided to serialize into json, even when just "generating it".
      - gnulinux 5y ago
        No I don't think there is a good reason. You're completely missing that programming language syntax is designed for humans. You can still serialize all languages to json syntax trees, just like you can do so with lisp notation, Polish notation etc.
        valenterry 5y ago
        I'm not saying that you _cannot_ do it. But tell me: why has no programming-language done that? They all could have chosen to serialize their code or AST into json but they didn't. (except JsonLogic I guess)
        andyana 5y ago
        Because someone didn't have the time to do it? Or they didn't think of it? Just because nobody has had success at an idea, doesnt mean that the idea can't work. Or do you think we are at our peak?
- healsjnr1 5y ago
  I think the key point on this is `some use cases`. For people who've spent a lot of time with ANT, you might be familiar with this article from its creator: https://web.archive.org/web/20041217023752///x180.net/Journal/2004/03/31.html https://web.archive.org/web/20041217023752///x180.net/Journa... It was possible and even made sense to use XML as the format for a build tool, however, it got stretched way to far. The idea was applied in use cases that were less and less appropraite, as a result years later you end up with something that is unwieldy and doesn't make sense and, generally, thought of as "terrible". There are use cases were JsonLogic might make a lot of sense, and for those that is great. Generally, I'm sceptical as there is high risk of increasing couplings in a way that will make change much harder. This will be particularly true if it is applied to use cases that don't truly warrent this kind of solution.
enriquto 5y ago
> exactly this method in 2004-2006 but with XML. Of course! JSON is the modern equivalent of XML. In 10 years everybody will mock JSON just like today we mock XML.
- juped 5y ago
  JSON mania has given me an appreciation for XML not having been so bad after all.
  - dnautics 5y ago
    I dunno, to me it's pretty clear that JSON has improvements over XML; XML: - does not entirely make it clear what should go into a tag attribute versus a nested tag - conversion of those two features into a unified internal datatype can be tricky (for example, this property led to choices that for erlang's xmerl causes a security regression if you are handling user-submitted xml). - first class support for text inside of a tag is not what you want in 90% of data interchange events, and support for it creates a burden when deserializing. - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. - because there aren't good "best practices" around it, everyone rolls their XML schemas with their own ideas about what sort of thing should go where. The major benefit of XML is its obession with schematization means that at least in many case you can grab a schema and figure out an appropriate declarative command to obtain what you want (if you have the right library), but this has basically been conquered in JSONland using JsonSchema/OpenAPI, and stuff like JsonLogic.
    - bokchoi 5y ago
      > - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. JSON's types are pretty anemic compared to the XMLSchema's datatypes[0]. Even it you don't use all of XSD's complex type system, having these basic datatypes is extremely useful and I wish JSON had similar. [0] https://www.w3.org/TR/xmlschema11-2/ https://www.w3.org/TR/xmlschema11-2/
sebmellen 5y ago
Maybe you can tell me if there's a better solution. I'm open to hearing any options because I'm at a loss of how to do this otherwise: Say we have a schema which defines certain data. Let's say it's a "credential" which is a "COVID-19 Back to Work Credential." The credential is valid in the case that someone either 1) has a COVID vaccination or 2) has a negative COVID test in the past 72 hours. That data might look like this: { "credentialName": "COVID-19 Back to Work Credential", "credentialIssuer": "Acme Labs Inc.", "credentialData": { "rapidSarsCov2PCRTest": { "hasTestResult": true, "testResult": "negative", "testTime": 1622145851 }, "covid19Vaccination": { "hasVaccination": false } } } Now, say I want to define the conditions under which this "credential" is valid or invalid, but I want to include this "matrix" within the schema (not any business logic, just matrix logic that pertains to the data within the schema itself). Optimally, I'd be able to do this within the same schema or file. With JsonLogic, that might look like this (probably flawed logic, just a demo, not using this in production, may cause your computer to go up in flames, etc.): { ... "parsingMatrix": { "if": [ { "or": [ { "===": [ { "var": "credentialData.rapidSarsCov2PCRTest.testResult" }, "negative" ] }, { "===": [ { "var": "credentialData.covid19Vaccination.hasVaccination" }, true ] } ] }, "valid", "invalid" ] } } Can you think of another way to do this that doesn't rely on using JsonLogic or something like it (or a cleaner method for doing it in JSON)?
- asah 5y ago
  I'm not sure how to express how much I loathe everything about this "solution." To answer your question, what you have is (effectively) code, and just use a programming language for this, call it a function, give it a name, arguments, test suite and register it as a plugin to your platform. Oh, and documentation, change history, etc. Seriously - the "overhead" more than pays for itself when 100 other yahoos do this nonsense and you end up with data files containing untestable code that breaks when combined with other code, breaks when the platform is changed, etc etc
  - 5y ago
pydry 5y ago
It sounds like your language didn't steer clear of Turing completeness. That's usually how this type of thing goes wrong. I've seen similar things both work and fail for that reason. This language made it an explicit goal, though.
marktolson 5y ago
I have successfully implemented this exact project in the past. The project allowed for runtime logic modification however tracking states was built into the platform to make debugging simple. As with every other library or framework, JsonLogic is a great tool if you implement it responsibly.
commandlinefan 5y ago
> If you are reading this, and you think it is a good idea I came to the comment section here hoping that the site was actually a joke...
solidsnack9000 5y ago
Maybe it's a kind of having your cake and eating it too: enjoying the flexibility of passing code around and running it with eval, while not having the security, stability and runtime problems implied by eval. There are limited scopes in which this can work but it seems to be more about the environment or code loader than about the programming language, per se: for example, plugin systems for build tools and servers. The plugin might be isolated by runtime features (like in the JVM) or by processes (as some web servers do, or as Postgres does) but it's not language features that tend to be useful. Tensorflow models and CSS selectors are both examples of fairly useful plugins that still have limited enough semantics to be sandboxed effectively.
rhacker 5y ago
LOL, I am just going to leave this here, but to those that complain about JSON or XML or any future format X: It's always going to be shitty, messy and hard to read. You can only do so much to get rid of extraneous symbols but at the end of the day the format is hard to read because there is hierarchy and repetition. It seems like everyone is waiting for a format that will make reading 2000 configurations "easy". I'll have to say, good luck.
noduerme 5y ago
I agree that there's basically never a good use case for shipping logic from server to client or vice versa in a formal application setting. BUT. I could definitely see a scenario where something like this would be handy for farming distributed processing out to naive nodes or workers that don't / shouldn't have access to the core logic.
Too 5y ago
One valid use case for solutions like this is if users are allowed to run their queries inside a database or api. I'm often in the situation where you try to add all kinds of parameters to a query-field in the UI but no matter how hard you try there will always be a power user with the request to do some combination of AND/OR/CONTAINS/NOT with nested parenthesis that is not supported. After hundred such requests you get sick of it and just want to expose the raw DB-query to the front end, which obviously is a bad idea for security reasons. Having a safe intermediate representation that is sophisticated enough for some logic can be a good idea. Instead of reinventing your own, using this language can be done, as long as it has a mapping into each database query language.
- smitty1e 5y ago
  > there will always be a power user with the request to do some combination of AND/OR/CONTAINS/NOT with nested parenthesis that is not supported. If that power user is properly skilled, authorized and authenticated, why not give them a read-only connection to the DB and let them write their own SQL? How many times has the UI been nothing but an impediment?
oreally 5y ago
Precisely. If you want to do logic, use a programming language, not a data format.

jchw 5y ago

I am not saying that you are wrong. Not at all. However, something I’ve come to learn is that some ideas I thought were bad were actually not bad. They were poorly executed and the exact reasoning why they did not work well in a given application was not well-understood. So I can see an argument for “this was horrible back when it was done in the early 2000s” simultaneously with “this could actually still be a good idea for some use cases.”

janderland 5y ago
Currently reading about agriculture throughout human history. It made me wonder how many people failed to domesticate a single kind of crop and assumed crop domestication as a whole isn’t a good idea. I realize that people need to make decisions based on their personal experience, and I don’t have a good rule-of-thumb for when to try a variation of a “bad” idea.
- marksbrown 5y ago
  ‘Many of life’s failures are people who did not realise how close they were to success when they gave up' -- Thomas Edison.
  - burnished 5y ago
    said the man who tested something like 6000 different kinds of plant materials as filaments for a light bulb
    - smitty1e 5y ago
      Three cheers for brute force methods. Sometimes you need the BFH to get to the elegant solution.
  - craftinator 5y ago
    Said the man who lied, cheated, and stole his way to fortune and historical fame.
    - fruityrudy 5y ago
      You’re just jealous
- samus 5y ago
  Agriculture is difficult because it is literally a fight against nature/entropy. And it still has to be proven that it is a viable way to drive human civilization in the long term. In nature, species populations compete with each other and are kept in a dynamic equilibrium. If population size of a species increases, then its predators will have more opportunities to predate, and their population size increases as well. This leads to more predation pressure, which should negate the population increase and decreases opportunities for predators as well. "Predators" is to be understood in a very general way. It can also apply to fungi and other microbial forms of life. Changes to this equilibrium arise when prey species evolve to resist the predation pressure by predators. And vice versa if the predators improve. Then, ecosystems change, and these changes can be very disruptive. Agriculture is a rebellion against this dynamic equilibrium because it creates irresistible opportunities for predators. They have to be held in check either by brute force (hunting, pesticides, containment) or by hacking the ecosystem (for lack of a better term) to ensure that helpful predators are around. The former is probably unsustainable in the long term as it is not at all clear that we will forever be able to outsmart the evolutionary potential of predator species. The latter is difficult as well. Apart from predation, the other challenge to agriculture is that it depletes the soil in the long term. Fertile soil arises as a result of a ecosystem where the decomposers cannot keep up. Most forms of agriculture interrupt such ecosystems and thus deplete the soil in various ways. To keep this in check, different methods were evolved, such as slash-and-burn, crop rotation and artificial fertilization. But it is not at all sure that we will always be able to stop depletion of our soils just in time to prevent civilizational collapse. Currently, availability of phosphorus is a looming danger because most of it is mined. Once we hit peak phosphorus, we better have solutions in place to get it from somewhere else.
valenterry 5y ago
Sharing code between frontend and backend isn't a bad idea, yes. However, using Json for it is. And the problems and limitations with json can't be "fixed" in any way.
- dragonwriter 5y ago
  > Sharing code between frontend and backend isn't a bad idea, yes. However, using Json for it is. I don't see why serializing close to JSON is any worse than doin so to, say, S-expressions, or Algol-style syntax, or WASM. If you aren't manually coding it, but generating it, the capabilities matter, the syntax matters a lot less.
  - valenterry 5y ago
    I think there are very good reasons why languages have their own custom formats and none of them ever decided to serialize into json, even when just "generating it".
    - gnulinux 5y ago
      No I don't think there is a good reason. You're completely missing that programming language syntax is designed for humans. You can still serialize all languages to json syntax trees, just like you can do so with lisp notation, Polish notation etc.
      - valenterry 5y ago
        I'm not saying that you _cannot_ do it. But tell me: why has no programming-language done that? They all could have chosen to serialize their code or AST into json but they didn't. (except JsonLogic I guess)
        andyana 5y ago
        Because someone didn't have the time to do it? Or they didn't think of it? Just because nobody has had success at an idea, doesnt mean that the idea can't work. Or do you think we are at our peak?
healsjnr1 5y ago
I think the key point on this is `some use cases`. For people who've spent a lot of time with ANT, you might be familiar with this article from its creator: https://web.archive.org/web/20041217023752///x180.net/Journal/2004/03/31.html https://web.archive.org/web/20041217023752///x180.net/Journa... It was possible and even made sense to use XML as the format for a build tool, however, it got stretched way to far. The idea was applied in use cases that were less and less appropraite, as a result years later you end up with something that is unwieldy and doesn't make sense and, generally, thought of as "terrible". There are use cases were JsonLogic might make a lot of sense, and for those that is great. Generally, I'm sceptical as there is high risk of increasing couplings in a way that will make change much harder. This will be particularly true if it is applied to use cases that don't truly warrent this kind of solution.

enriquto 5y ago

> exactly this method in 2004-2006 but with XML. Of course! JSON is the modern equivalent of XML. In 10 years everybody will mock JSON just like today we mock XML.

juped 5y ago
JSON mania has given me an appreciation for XML not having been so bad after all.
- dnautics 5y ago
  I dunno, to me it's pretty clear that JSON has improvements over XML; XML: - does not entirely make it clear what should go into a tag attribute versus a nested tag - conversion of those two features into a unified internal datatype can be tricky (for example, this property led to choices that for erlang's xmerl causes a security regression if you are handling user-submitted xml). - first class support for text inside of a tag is not what you want in 90% of data interchange events, and support for it creates a burden when deserializing. - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. - because there aren't good "best practices" around it, everyone rolls their XML schemas with their own ideas about what sort of thing should go where. The major benefit of XML is its obession with schematization means that at least in many case you can grab a schema and figure out an appropriate declarative command to obtain what you want (if you have the right library), but this has basically been conquered in JSONland using JsonSchema/OpenAPI, and stuff like JsonLogic.
  - bokchoi 5y ago
    > - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. JSON's types are pretty anemic compared to the XMLSchema's datatypes[0]. Even it you don't use all of XSD's complex type system, having these basic datatypes is extremely useful and I wish JSON had similar. [0] https://www.w3.org/TR/xmlschema11-2/ https://www.w3.org/TR/xmlschema11-2/

sebmellen 5y ago

Maybe you can tell me if there's a better solution. I'm open to hearing any options because I'm at a loss of how to do this otherwise: Say we have a schema which defines certain data. Let's say it's a "credential" which is a "COVID-19 Back to Work Credential." The credential is valid in the case that someone either 1) has a COVID vaccination or 2) has a negative COVID test in the past 72 hours. That data might look like this: { "credentialName": "COVID-19 Back to Work Credential", "credentialIssuer": "Acme Labs Inc.", "credentialData": { "rapidSarsCov2PCRTest": { "hasTestResult": true, "testResult": "negative", "testTime": 1622145851 }, "covid19Vaccination": { "hasVaccination": false } } } Now, say I want to define the conditions under which this "credential" is valid or invalid, but I want to include this "matrix" within the schema (not any business logic, just matrix logic that pertains to the data within the schema itself). Optimally, I'd be able to do this within the same schema or file. With JsonLogic, that might look like this (probably flawed logic, just a demo, not using this in production, may cause your computer to go up in flames, etc.): { ... "parsingMatrix": { "if": [ { "or": [ { "===": [ { "var": "credentialData.rapidSarsCov2PCRTest.testResult" }, "negative" ] }, { "===": [ { "var": "credentialData.covid19Vaccination.hasVaccination" }, true ] } ] }, "valid", "invalid" ] } } Can you think of another way to do this that doesn't rely on using JsonLogic or something like it (or a cleaner method for doing it in JSON)?

asah 5y ago
I'm not sure how to express how much I loathe everything about this "solution." To answer your question, what you have is (effectively) code, and just use a programming language for this, call it a function, give it a name, arguments, test suite and register it as a plugin to your platform. Oh, and documentation, change history, etc. Seriously - the "overhead" more than pays for itself when 100 other yahoos do this nonsense and you end up with data files containing untestable code that breaks when combined with other code, breaks when the platform is changed, etc etc
- 5y ago

pydry 5y ago

It sounds like your language didn't steer clear of Turing completeness. That's usually how this type of thing goes wrong. I've seen similar things both work and fail for that reason. This language made it an explicit goal, though.

marktolson 5y ago

I have successfully implemented this exact project in the past. The project allowed for runtime logic modification however tracking states was built into the platform to make debugging simple. As with every other library or framework, JsonLogic is a great tool if you implement it responsibly.

commandlinefan 5y ago

> If you are reading this, and you think it is a good idea I came to the comment section here hoping that the site was actually a joke...

solidsnack9000 5y ago

Maybe it's a kind of having your cake and eating it too: enjoying the flexibility of passing code around and running it with eval, while not having the security, stability and runtime problems implied by eval. There are limited scopes in which this can work but it seems to be more about the environment or code loader than about the programming language, per se: for example, plugin systems for build tools and servers. The plugin might be isolated by runtime features (like in the JVM) or by processes (as some web servers do, or as Postgres does) but it's not language features that tend to be useful. Tensorflow models and CSS selectors are both examples of fairly useful plugins that still have limited enough semantics to be sandboxed effectively.

rhacker 5y ago

LOL, I am just going to leave this here, but to those that complain about JSON or XML or any future format X: It's always going to be shitty, messy and hard to read. You can only do so much to get rid of extraneous symbols but at the end of the day the format is hard to read because there is hierarchy and repetition. It seems like everyone is waiting for a format that will make reading 2000 configurations "easy". I'll have to say, good luck.

noduerme 5y ago

I agree that there's basically never a good use case for shipping logic from server to client or vice versa in a formal application setting. BUT. I could definitely see a scenario where something like this would be handy for farming distributed processing out to naive nodes or workers that don't / shouldn't have access to the core logic.

Too 5y ago

One valid use case for solutions like this is if users are allowed to run their queries inside a database or api. I'm often in the situation where you try to add all kinds of parameters to a query-field in the UI but no matter how hard you try there will always be a power user with the request to do some combination of AND/OR/CONTAINS/NOT with nested parenthesis that is not supported. After hundred such requests you get sick of it and just want to expose the raw DB-query to the front end, which obviously is a bad idea for security reasons. Having a safe intermediate representation that is sophisticated enough for some logic can be a good idea. Instead of reinventing your own, using this language can be done, as long as it has a mapping into each database query language.

smitty1e 5y ago
> there will always be a power user with the request to do some combination of AND/OR/CONTAINS/NOT with nested parenthesis that is not supported. If that power user is properly skilled, authorized and authenticated, why not give them a read-only connection to the DB and let them write their own SQL? How many times has the UI been nothing but an impediment?

oreally 5y ago

Precisely. If you want to do logic, use a programming language, not a data format.