Blogs:JaroslavTulach:Theory
From APIDesign
| Line 2: | Line 2: | ||
<startFeed /> | <startFeed /> | ||
| + | |||
| + | ==== [[Good Advice]] ==== | ||
| + | |||
| + | {{:Good Advice}} | ||
| + | |||
| + | --[[User:JaroslavTulach|JaroslavTulach]] 08:59, 5 February 2014 (UTC) | ||
==== Pervert Your [[Language]] to Become a Better Programmer ==== | ==== Pervert Your [[Language]] to Become a Better Programmer ==== | ||
Revision as of 08:59, 5 February 2014
Theory Thoughts
Good Advice
How do you recognize Good Advice? We already know what a good technology is, can we use the same concept to evaluate whether an advice is good or not? Let me answer that by a quote from TheAPIBook which Yoshiki asked about:
Page 363
Part 1 presents all of API design as a scientific discipline with a strong rational background, not as the art that it sometimes pretends to be. It defines terminology and initial prerequisites that can objectively help us measure if an API design is good. These rules try to be language neutral and applicable to any programming language, not just Java. The theory is unlikely to be complete. Other principles of API design exist elsewhere or are still waiting to be discovered.
However, that should not scare us, as Chapter 1 gives us a tool to evaluate the quality of various principles to find out whether a certain piece of advice helps us design better shared libraries and their APIs or not. It gives us the grand meta-principle: selective cluelessness. This cluelessness is a tool that can measure whether various goals really help. That’s because if they allow people to know less while achieving more and building better software systems more easily, then this advice is good. There is a need for this advice, especially in the future, when software systems will outsize the intellectual capacity of any of their designers.
Yoshiki: What do you mean by this advice?
"this advice" is a reference to advice mentioned in "to find out whether a certain piece of advice helps us design better shared libraries". To rephrase: any advice that helps users increase cluelessness is good and it will be even more valuable in the future when we start to build even bigger systems.
--JaroslavTulach 08:59, 5 February 2014 (UTC)
Pervert Your Language to Become a Better Programmer
Language that you speak and write defines what you can think and reason about. The worse language you can use the better programmer you are. Right?
--JaroslavTulach 13:02, 16 October 2013 (UTC)
Do You Know What a WeakReference Can Do to Your API?
References and WeakReferences play important role when designing an API contract or building a framework. Are you sure you use them properly? Read about problems we had when messing with WeakReferences in the Lookup API.
--JaroslavTulach 08:50, 11 October 2013 (UTC)
JDK8's Profiles in the Light of Harmony
A curious translator of my book asked me about project Harmony. That motivated me to sit down and write an incomplete and mostly wrong history of open source java implementations. While incomplete (for example it does not talk by whom Harmony was founded and why), it explains why JDK8 is/will be a huge step forward and what will be its most important feature. Btw. if you thought lamdas, you were wrong.
--JaroslavTulach 14:54, 12 August 2013 (UTC)
Cimrman's Planning
Short introduction to accurate, agile, modern, reliable, flexible, optimistic, forward looking, experience based, projective planning methodology.
--JaroslavTulach 15:10, 19 March 2013 (UTC)
Platón's Theory of Ideas for Developers
Those of you who heard about Platon in school probably also hard about his allegory of a cave (at least I did when I was at high school). It is not often easy to imagine what Platon meant by the cave, shadows, etc. Luckily (at least for developers who know what geometry is), there is a better explanation which which explains Platon's theory of ideas via geometry.
This geometric way of explaining [[ideas was much easier for me to swallow. That is why I decided to share it here.
--JaroslavTulach 08:45, 21 January 2013 (UTC)
On the fact that the Atlantic Ocean has two sides
Here are selected notes from my favorite write up by Edsger W. Dijkstra (the guy that invented semaphore). Few decades has passed since the initial publication and the difference between U.S. and Europe may not be as sharp anymore. Still, a lot of Dijkstra's comments apply - especially when it comes to the clash between programmers educated in soft vs. real science schools!
Btw. should this kind of analysis be found interesting, I can share another one: Why our U.S. friends can't read maps and are not aware of that. Just let me know if I should publish it.
--JaroslavTulach 11:56, 17 January 2013 (UTC)
Having a Hammer All Problems Look Like a Nail
A theoretical observation about a hammer with application to real world scenario as well as software user interface design.
--JaroslavTulach 13:37, 12 November 2012 (UTC)
TransitivityOfIncompatibleChange
A nice clash between real world and academic attempts to describe it can be seen on the case of TransitivityOfIncompatibleChange. While such transitivity is an easy to grasp concept, it is too simplistic and often too hard to apply for the real world of software dependencies. It took me a while to understand its alternative, but now I think I see it.
Last week I had a presentation about the topic of NP-Complete problems in module dependencies at MatFyz and one of the questions was: Why am I not using TransitivityOfIncompatibleChange in case of repositories with RangeDependencies? Well, I don't as it does not have a clear meaning. But the question forced me to sit and write the answer down.
Hopefully not only MatFyz guys find the essay useful.
--JaroslavTulach 02:00, 7 November 2012 (UTC)
Is Java a Language or a Framework?
Just a few thoughts about the difference between language and a framework (plus a wish how Java should evolve).
--JaroslavTulach 09:06, 18 October 2012 (UTC)
20 API Paradoxes Published!
Today I am ready to announce great news. My new book about 20 API Paradoxes is now publicly available. I'd like to thank everyone who helped me get it to e-readers all over the globe. Jeff corrected my English and made the structure of the book more consistent. Clay stopped me when I wanted to expand the scope and delay the publication. And, most importantly, Clay is responsible for this fantastic cover:
I asked Clay to select cover that would somehow reflect my relation with my home and I am glad he decided to use painting of Josef Lada - a painter of my childhood.
I hope you like the cover too. And not only that, I hope you'll like the content as well. Buy & enjoy!
--JaroslavTulach 18:11, 11 October 2012 (UTC)
100th Monkey Principle. Multicasting in a Nature?
James Borowski on 100th Monkey principle:
Found reading some stuff on your site really interesting. I have not finished reading yet, so, forgive me if you already know this, but I was reading the article DiamondsVsStars and wondered as I read your comments regarding the "something in the air" as people around the world all discover something at the same time, if you were aware of the 100th Monkey principle?
There are different versions of the tale, but essentially, there was an island with a load of monkeys that learnt a trait one at a time of how to knock nuts with a rock to get inside them (other versions of the story are about learning to wash them, but the principle is the same). It took a while for monkeys to copy each other, one at a time, and the speed of uptake was essentially linear and at a fixed rate until they reached the 100th Monkey. At this point, every monkey on the island, and every monkey on the three neighbouring islands all started the same trait, almost instantly. The point is: A species appears to be connected at some vibrational level to the extent that they share certain thought processes/notions. There is a tipping point (apparently this is the square route of 1% of the population pool / or 100 monkeys ) where once reached, this information is availiable to all. Almost as if an entire species are listening on the same multicast address.
Anyway, hope you find as interesting as I found your stuff. For more info see 100th Monkey at wikipedia.
Thanks, for sharing this observation, James!
--JaroslavTulach 19:29, 8 August 2012 (UTC)
How Strict a Backward Compatibility Should Be?
Here are some thoughts on the difference between 100% BackwardCompatibility and their slightly more practical variants.
--JaroslavTulach 12:13, 31 July 2012 (UTC)
Follow
