Is Swing's openness reason for its so bad reputation?
--JaroslavTulach 10:37, 26 August 2016 (UTC)
I was invited to give a talk at CurryOn 2016 about Truffle called Become Polyglot by Learning Java!. It provoked tweets like: If you only watch one talk from @curry_on_conf, this one from @JaroslavTulach on Graal/Truffle is stunning. Here is its recording:
Or go to YouTube page.
--JaroslavTulach 05:33, 22 July 2016 (UTC)
There are two pitfalls of an APIReview. Either there is no code to review or there is too much code already written. The too little code case can easily be fixed. As Linus Torwalds use to say: Talk is cheap. Show me the code!
However what to do when APIReview brings in complex, complete solution with code almost ready for integration? Isn't that insulting? What kind of review one is supposed to perform then? Claim that the solution is completely wrong? That won't make the author happy. On the other hand coming for an architecture advice with fully working version isn't polite to reviewers either. Shall we read it as: Look how great I am! Approve the APIReview now!
Maybe there is a way to handle such review as well. But it remains to be seen if it works. Wish me luck.
--JaroslavTulach 13:38, 17 July 2016 (UTC)
Hear the news! A new creature of the API design patterns rare species has been discovered. It looks like a builder pattern, but it ducks like something else. If you take a closer look you'll find out it is a chameleon! It changes its return type depending on its state.
Once you discover the beauty, you'll not stop until you get your own chameleon builder into your own design!
--JaroslavTulach 09:34, 16 June 2016 (UTC)
Do you believe people should only use runtime exceptions? That checked exception add too much overhead? Then you are wrong!
--JaroslavTulach 16:26, 6 April 2016 (UTC)
Truffle project is using Sigtest since today. I am maintaining the Truffle APIs since May, 2015 and I was applying my best knowledge and skills to design it properly. However I have to admit, I was operating in a blindness. Without having tests it is hard to decide whether your code change doesn't break your product. When designing API, it is important to know whether a change is or isn't backward compatible. Without a tool like Sigtest, it is almost impossible to do that manually!
--JaroslavTulach 10:34, 23 November 2015 (UTC)
Enforcing proper usage of an API is hard. One needs to strive for clarity, one can invent engineering solutions to the problem, but at the end clever hacker always find a way around it. But there is a cure: Let's choose our licenses wisely and scare the hackers with legal actions!
At the end it could also solve the famous sun.misc.Unsafe issue...
--JaroslavTulach 09:21, 15 June 2015 (UTC)
Domain Expert is a person who has knowledge of a particular system. With such knowledge it may seem easy to design APIs for the domain. However without understanding the API Paradoxes the quality of such API may not be high. It is likely going to cover the domain field, but the API usability or readiness for evolution will very likely suffer (unless such Domain Expert reads TheAPIBook first).
This is a new situation for me: In case of NetBeans or in case of HTML/Java APIs, I was also the architect of the system. I knew it by heart. Now I barely understand how Truffle works and what makes it the fastest execution system for dynamic languages. My biggest fear is that I will design something that will be inherently slow.
On the other hand, I am not yet damaged with the expert knowledge. I can still see the system with new comer eyes - just like you, users of Truffle will. As such I can perform a usability study on me, at least initially.
If I can design easy to use APIs for Truffle, then I can create a perfect API facade around everything! Soon we'll have a chance to see whether one can be good API designer without being real Domain Expert. Soon we'll find out if API Design can be offered as a service!
--JaroslavTulach 10:26, 17 May 2015 (UTC)
BinarySelection plays (except having its classical search meaning) an important role in theory of HR management. It defines what happens when employees are leaving the employer (either voluntarily or after being fired):
BinarySelection means, that "ones" leave and "zeros" stay.
I mention this definition whenever we chat about life of software developers and it always generates grin smile. Of course, because it is so true! I can confess that as for last seventeen years I have been sticking with my job surviving any layoffs and acquisitions: I've seen so many "ones" leaving, but the rest of us is still marching on!
--JaroslavTulach 06:20, 23 December 2014 (UTC)
When I was younger I used to believe that having invokeDynamic instruction in JVM can be beneficial. Now, few years later and after spending time to implement lambdas in my Bck2Brwsr VM and seeing things from the other side I have to admit I was wrong. invokeDynamic is wrong idea (especially for implementation of lambdas).
It is JavaOne time, I have a talk about my Bck2Brwsr together with Niclas from RoboVM, so let's show I understand what is wrong with JVM and start a little rant! I need something from the JDK guys, so let's give them a reason to welcome me with open arms when we see each other in San Francisco:
--JaroslavTulach 12:50, 25 September 2014 (UTC)
Hear the news: Sources in ZIP format are back!
My Hudson server crashed in early months of 2014. I had to configure it from scratch. While doing so, I forgot to configure the job to produce apidesign.zip file with sources. Has anyone noticed? Nobody sent me an email! Just yesterday Jáchym, my co-worker, who I torture by forcing him to read TheAPIBook and become good API designer, stopped in my office and timidly asked: Where can I get the sources? There is no ZIP file!
For a while I tried to blame him for not using Mercurial, but after a while I realized the problem is on my side. As a result, the zip file with sources is back as of Aug 8, 2014. Will anyone use them? It would be nice as reading Practical API Design book without having whole sources at your hand is like trying to understand Swing just by reading its Javadoc.
--JaroslavTulach 11:16, 8 August 2014 (UTC)
Epistemology of software design by Nathan is online! I greatly recommend it to everyone who wants to produce software that lasts! After all those years with NetBeans I can only confirm everything Nathans describes!
If you want to stop being a software engineer and become software architect, epistemology of software design is one of the things you have to memorize!
--JaroslavTulach 20:01, 15 May 2014 (UTC)
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:
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.
"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:04, 6 February 2014 (UTC)
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)
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)
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)
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.
--JaroslavTulach 02:00, 7 November 2012 (UTC)
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 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)
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)