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 alavrik@piqi.org Thanks!
I couldn't agree more!
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.
[1] http://piqi.org
This is why I placed my xterm title bar at the bottom and it works like a charm.
My comment was about the language, not the people. I have no doubt that there are many good programmers who use Java.
But I'm not sure one can be a good programmer if Java (or any other mediocre language) is the only thing she knows.
> 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 :)
That's definitely an interesting perspective! Thanks for pointing it out.
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.
In contrast, here's an HTTP response parser I wrote in OCaml using just one library: https://github.com/alavrik/piqi/blob/master/piqi-tools/piqi_... (see lines 26 - 218).
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.
Documents are semi-structured data, that is they are a mix of text and structured data elements put into a structured hierarchy.
What is it the tool that generates C++ codecs for JSON from .proto specifications?
(I wrote a generic command-line Protobuf-JSON converter).
http://piqi.org -- a better alternative to XML, JSON, CSV, S-expressions, etc.
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.
I think you can do both in static and dynamic languages, but in dynamic language everything is just practically easier.
Another thing I forgot to mention, and it is more important than my first example, -- in Erlang, during the upgrade procedure, you can have two versions of the same module loaded simultaneously and their code can execute at the same time until all the code starts using functions from the second module. Basically, when you call a function, you can specify explicitly to call it the current module or from the new module. I can hardly imagine how you can get away with it in statically-typed language.
If you are interested in the topic I recommend reading Joe Armstrong's PhD thesis. It describes this and many other advanced topics in detail. Actually, it changed the way I think about concurrent and fault-tolerant systems and languages.
For example, over time you dynamically upgrade a module going from version 1 to 2 and, later, to version 3.
During the first module upgrade, data types from the newer module (2) can be incompatible with the data types from the older module (1).
Such incompatibilities are resolved dynamically during the upgrade procedure (implemented as a part of v2) which knows about type incompatibilities between versions 1 and 2.
After the upgrade from version 1 to 2, any subsequent module versions (e.g. 3) doesn't have to know anything about types from the initial module (1).
Here's a good article and the HN discussion about Russia. http://news.ycombinator.com/item?id=1409194
Basically, you would probably want to stay away from it. You can find decent engineers there but everything else is terrible for business: corruption, taxes, banks, cost of living, visas, etc.
The post doesn't say anything about innovation which is the key part of technology entrepreneurship.
If one can't innovate and create something radically new and efficient, then yes, he should probably stick with traditional business models and limit his ambitions to small markets, slow growth and modest returns focusing on efficient execution.
And there's more to it. Good engineers could do much better if they join an existing ambitious startup rather than if they convert to a small software workshop owners.
It is true that Protocol Buffers are not optimized for low-mem systems. On the other hand, for preserving bandwidth and storage one can use lightweight compression algorithms on top of general-purpose serialization library. (This is the approach that Google ended up using, AFAIK.)
I think such approach is more flexible than making explicit assumptions on how much data is actually carried in integers.
I agree that old and modern are not very appropriate terms when comparing technologies. However I didn't mean to express an objective statement in my comment.
The specs were definitely closed last time when I checked (about 6 months ago).
Still don't think this old telecom technology is superior compared to modern serialization tools like Protocol Buffers.
I have a T400s. Highly recommend! T410s seems to have some cosmetic but nice updates: http://lenovoblogs.com/insidethebox/?p=349&utm_source=fe...
Upd: I don't care much about battery life, it works fine for me. It comes in stock with 6-cell battery which doesn't stick out of the body unlike in previous models. It is very quiet -- previously I've been constantly annoyed by R61 being too noisy. And new T400s has 5400 rpm drive which makes it even less noisy. Overall it is a great laptop, can't think of any disadvantages.
To make a lot more money, for example.
set editing-mode vi set -o vi set -o emacs