If it makes any easier for you, you should know that this is what all governments do. Some governemnts are better at it than others. This is going to continue as long as governments are around. I'm not pro nor against. Just stating the fact.
In this case, there is clearly a disconnect between idealization and the reality.
Today, Stallman's and FSF's real political and social influence is miniscule.
FSF had some impressive achievements in the 90s, but they failed to utilize the social capital efficiently and couldn't catch up with rapid ecosystem changes (e.g. software and computer programming becoming mainstream).
An example of this is tivoization clause in GPLv3 which is a nuisance for businesses and contributes to marginalization of the license.
You are essentially talking about various effects associated with choice of the GNU GPL license. I agree with you on that. It is a useful tool.
My point was that the social movement for software freedom is not going anywhere. These are two different things.
According to Stallman, using GPL helps to achieve "software freedom". But many people use it as a tool for achieving their own (project, community, commercial, etc) goals and don't care about Stallman's social movement. See Linus Torvalds for example.
Personal computers have been commodity for at least a decade. In this respect they are no different from modern cars or any other highly computerized equipment. Users do not mess with their car's firmware. The whole point is lost.
Regardless of Stallman's contributions, the whole point of "free software" is no longer relevant. Not even for software enthusiasts -- those who care just use open source.
I don't think JSON as a _data interchange format_ should have comments. Key factors contributing to JSON's popularity and great practical value is simplicity and the fact that JSON is a final specification (i.e. no versioning, no extensions, no backward compatibility requirements).
Although JSON is human-readable, it wasn't specifically designed for human interaction. There are other projects and languages that address this specific topic. For example, Yaml and Piq. (Piq is the one that I'm working on as a part of the Piqi project -- http://piqi.org).
Thanks! Feel free to reuse as many ideas as you like :) It took me more than 2 years to get it there -- it is by far the toughest system I've ever designed.
ismarc, thank you for the comment! I really appreciate it -- I didn't know anyone else was using Piqi-RPC (other than myself).
I'd like to know more about your use case and the need for JavaScript generation. I'm open to new ideas. Could you please contact me at [email protected] Thanks!
Out of frustration with existing schema languages and tool support for them, I've been working on Piqi[1] which is concise, expressive and agnostic to data representation formats. It works for JSON, XML and Protocol Buffers.
> The language/tools are not the problem, it's the people/organization.
The language is a problem, because Java was specially created for this type of organizations. And it is not surprising that Java attracts this type of people (fungible crowds having no pride in their craft).
Please don't do that! Programming is just not there yet.
All attempts to establish best "engineering practices" in programming have so far been resulting in incredibly messy and inefficient technologies. UML, Corba, Object Oriented programming -- just to mention a few.
Also, whatever comes from an academic institution, as a rule, doesn't pass the reality check until it get stress-tested by the industry. Professors who don't build real-life software systems, can't tech engineering by definition -- they should stick mainly to theory.
Until programming matures, CS algorithms and data structures should remain our nails and wood.
Hi there! I do quite a bit of both OCaml and Erlang.
In fact, I borrowed Yojson's json parser for my project (piqi.org). Also, I'm familiar with MPL. It looks very nice, but from what I heard it is fairly immature. And you definitely can't parse HTTP this way :)
Fair enough. I didn't mean to criticize Haskell. In fact, I'm planning to learn it.
I was just surprised that this code was presented as a good example of Haskell's fit to the parsers domain. It would be interesting to see if my perception of this code changes once I get more familiar with the language.
The HTTP request parser doesn't look readable or trivial to me at all.
I'm not familiar with Haskell, so to me the code looks like a mix of high-level declarative and low-level specialized constructs (e.g. skipWhile, takeWhile) interleaved with syntax noise. And it seems to be using quite a lot of external libraries. Also, correspondence of the code with the HTTP spec is completely non-obvious.
I've just noticed that the code you are referring to is an example. Well, looking at the example, I can hardly come to a conclusion that Haskell shines for parsing.
There are two things. First, although the above transformation is theoretically possible to achieve with statically typed language, it is for sure harder in practice. In contrast, in Erlang it is super easy and natural although it may often seem as ad-hoc. But being able to do something like like on the fly is tremendously useful in practice.
Second, which is more important -- in my first example, I forgot to mention about the ability to use two versions of the same module at the same time. Check the thread below for more details.