Data is central. More specifically: the information schema. This is useful for different cases, for example for data integration and database management (other than the coercion example in the post).
However this makes me think about "types-driven development" and static typing a-la Scala or Haskell. I'm more inclined toward the dynamic typing camp, but I'm still debating with myself about this.
In the first post about Schema and in the recently released talk about it static typing was cited but my key takeaway was: schema is about data-shape validation and documentation, similar to static typing but much more lightweight and a-la carte. So good so far. Now with the 0.2.0 version schemas (an information model encoding) can be leveraged to do coercions, code generation, etc. Schema encodings start to resemble abstract data types and a kind-of optional and a-la carte "static" typing. Maybe the main difference is that while static types are central and a way of thinking, here schemas are a tool that can be used in different ways.
Just my crude ruminations, soon I'll come around studying Haskell. What do you think?
I don't know if someone has already cited this lengthy interview to Hal Abelson (co-author of SICP) about this change, but I think it is worthy to point it out:
It depends on you. Personally I play with it sometimes, but for me there is no danger of addiction.
It's a fun and creative game, even relaxing. However, sometime in the future there will be an adventure mode with NPC and a better fighting system, so it might become TOO fun for someone.
In the end, however, it depends on your personality.
> While some degree of human control could make up for heterostatic forces, a swing too far in either direction would quickly exceed our ability to compensate.
Exactly. That's why I'm suggesting that the "not worse" solution could be to artificially heat up the earth to the actual temperature for every latitude. Politics aside, a different temperature would probably disturb the current equilibrium and potentially cause some side-effects worse than the suspected mini ice-age.
Well, I think this would be the simplest: the temperature at any given latitude will be the average of the last n years. Period. But maybe I'm too naive.
I'm a happy Linux user for years now (GNU/Linux for the most difficult ones), but I went through the same process:
1. Excitement. Compiling the kernel? Cool! Configure an SMTP server just for fun? Cool! Having "fun" for hours fiddling with configuration files to make something work? Cool! Making a sound card, a video card or a modem work after hours of compilations and configurations feels just like "beating the system".
2. Well, there is more to IT besides editing udev rules and iptables profiles. But now my system works quite well, so I can go on with my life.
3. Update time. Or perhaps I need a new computer: maybe it's that I'm becoming old and impatient, but now I have stuff to do and other interests to nurture. I don't have time and patience to waste on making this damn piece of hardware work.
You want to make Linux a viable desktop operating system "for the masses"? Well, then don't tell me "it's free software, if you don't like it then write some code and change it!". Or "works for me". Thanks George.
Don't get me wrong: I like and support hacking, experimenting, FLOSS, open culture, open hardware, open whatever. I use FLOSS and Linux every single day and (for now) it works fine for me. But let's pretend for a minute that not everyone is a programmer. The truth is: even if I'm actually a professional programmer, I want an OS that "Just Works"(c).
PS: It's the same for... Linus Torvalds. He uses (as far as I know) Fedora. Not certainly Slackware, Gentoo or Arch (3 very good and interesting distributions BTW, I've used them all). His motivations? Paraphrasing: "because I'm familiar with it and I want to get things done".
Sure, this is a solution. But my confusion remains: why I should't put all these dependencies in the repository with the code that uses them? In the end, doing so I have (almost) all I need to produce the intended software artifact.
I still don't understand why dependencies don't belong to the repo. My naive reasoning: I just have to clone the repo and bam, I already have all the dependecies needed to build the artifact. When I need to upgrade to a new version of a library, I only have to commit a new version and delete the old one (possibly integrating the new library in a separate branch if the process is not trivial).
Well, this is true. But again, if I can't make a decision for myself then I'm not completely free. Even if that decision limits my freedom henceforth, I've made that decision excercising my free will.
Probably your definition of freedom is something along the line of "the right to exercise free will and take responsibility for my decisions, and the ability to do so now and forever". With this definition, restricting your own rights is against this concept of freedom. My definition doesn't have that restriction.
So, everyone must be free? I can't consciously trade some of my civil liberties for something in return? My idea of freedom is the power of choice. Choice to be free, or NOT free.
It's like boiling a frog: if you throw one in boiling water it will immediatly jump away. But if you place a frog in cold water and slowly making it hot, the frog won't even notice it is being boiled.
As with frogs, we humans need constant awareness on the context in which we live.
Let me recap the issue as I understand it so far: Oracle filed a lawsuit against Google regarding patents infringement for their use of Dalvik in Android. This is a big problem for Google and for every other alternative JVM (especially open-source) because even for a clean-room implementation you need to be licensed by Oracle.
But as far as I can see this is not so interesting to general application developers since, I think, the majority of them targets the official JVM (open or not) anyway. The same goes for other JVM based languages, since they can generally run well in the OpenJDK.
However the general consent that I see is that this is a bad move for the innovation of the JVM platform and a move that will likely reduce the trust of the industry in this technology.
Maybe new projects will be developed upon another and more open platform, but the vast majority of application-level projects (such as the myriad of enterprise webapps) won't be so interested.
What do you think?
Disclosure: I'm interested in alternative JVM languages because in my company (who is J[ava/VM] centric) we're evaluating technologies to rewrite one of our products from scratch. Aside from my personal interest in new languages obviously.
However this makes me think about "types-driven development" and static typing a-la Scala or Haskell. I'm more inclined toward the dynamic typing camp, but I'm still debating with myself about this.
In the first post about Schema and in the recently released talk about it static typing was cited but my key takeaway was: schema is about data-shape validation and documentation, similar to static typing but much more lightweight and a-la carte. So good so far. Now with the 0.2.0 version schemas (an information model encoding) can be leveraged to do coercions, code generation, etc. Schema encodings start to resemble abstract data types and a kind-of optional and a-la carte "static" typing. Maybe the main difference is that while static types are central and a way of thinking, here schemas are a tool that can be used in different ways.
Just my crude ruminations, soon I'll come around studying Haskell. What do you think?
edit: fixed a typo and added some minor things.