http://wiki.apidesign.org/index.php?title=Blogs:JaroslavTulach:Theory&action=feed&feed=atomTheory2024-03-29T07:16:25ZAPIDesign - Blogs:JaroslavTulach:TheoryMediaWiki 1.12.0rc1 via WikiArticleFeeds 0.6.3http://wiki.apidesign.org/wiki/Pragmatic Feeling the Pain! 2021-12-22T06:02:00Z
<p>It always helps when maintainers of a library or framework feel the pain of using it themselves. Then they become more open to address limitations of their own design. It's not users of (even of some obscure feature of) a library that shall "feel some pain every time they use it, to keep the usage as limited as possible". The maintainers should feel the pain. That helps them to get more <a href="http://wiki.apidesign.org/wiki/Pragmatic" title="Pragmatic">Pragmatic</a> and less academic!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 06:02, 22 December 2021 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Genetics The Genetics of an APIDesign 2021-06-29T06:29:00Z
<p>The <a href="http://wiki.apidesign.org/wiki/Genetics" title="Genetics">Genetics</a> of an API design comes with own surprises: APIs shall not be copied, but only re-implemented. That's the paradox of copying an API!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 06:29, 29 June 2021 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/ScienceOfAPIDesign The Science of APIDesign 2020-10-15T06:08:00Z
<p><a href="http://wiki.apidesign.org/wiki/ScienceOfAPIDesign" title="ScienceOfAPIDesign">ScienceOfAPIDesign</a> is possible and can be almost as sharp as the most accurate science of all times - geometry. To achieve such sharpness it is better/easier/more useful to focus on binary compatibility in Java rather than source compatibility. Enhancing language can mitigate many issues, but regular library designers (mere mortals) can't change their language. We can only learn what advises the <a href="http://wiki.apidesign.org/wiki/ScienceOfAPIDesign" title="ScienceOfAPIDesign">ScienceOfAPIDesign</a> offers and use them in our daily policies. Or don't use them (but preferably knowing why).
</p><p>Anyone willing to join the quest on making <a href="http://wiki.apidesign.org/wiki/ScienceOfAPIDesign" title="ScienceOfAPIDesign">ScienceOfAPIDesign</a> better and sharper?
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 06:08, 15 October 2020 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/BinaryCompatibleDefaultMethods Adding DefaultMethods in a 100% BackwardCompatible Way! 2020-09-30T06:10:00Z
<p>I took a part in a tweetting about <a href="http://wiki.apidesign.org/wiki/BinaryCompatibleDefaultMethods" title="BinaryCompatibleDefaultMethods">incompatibilities related to
CharSequence.isEmpty()</a> over the weekend and I asked myself a simple question: <i>Is it possible to add a default method in a 100% binary compatible way?</i> The <a href="http://wiki.apidesign.org/wiki/BinaryCompatibleDefaultMethods" title="BinaryCompatibleDefaultMethods">newly written post</a> provides the answer. Yes, <a href="http://wiki.apidesign.org/wiki/BinaryCompatibleDefaultMethods" title="BinaryCompatibleDefaultMethods">adding default methods to interfaces in a 100% binary compatible way</a> is possible at the end!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 06:10, 30 September 2020 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Never_update_tests Never Update (API) Tests! 2019-01-24T04:05:00Z
<p>Designing an API that shall last? Then <a href="http://wiki.apidesign.org/wiki/Never_update_tests" title="Never update tests">Never update tests</a>! The need to update tests is a sign of an <a href="http://wiki.apidesign.org/wiki/Incompatible" class="mw-redirect" title="Incompatible">incompatible</a> change.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 04:05, 24 January 2019 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Deadlock Never hold a lock when calling a foreign code! 2018-08-02T07:11:00Z
<p>Fighting with <a href="http://wiki.apidesign.org/wiki/Deadlock" title="Deadlock">deadlocks</a> is hard in normal code. In case of <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">APIs</a> it is even harder. Yet, the advice is simple <a href="http://wiki.apidesign.org/wiki/Deadlock" title="Deadlock">Never hold a lock when calling a foreign code</a>. See the typical example rewritten to be <a href="http://wiki.apidesign.org/wiki/Deadlock" title="Deadlock">deadlock</a>-free in the dedicated <a href="http://wiki.apidesign.org/wiki/Deadlock" title="Deadlock">deadlock</a> page.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 07:11, 2 August 2018 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Default_Listener_Methods Shocking: Default Listener Methods ain't Dangerous! 2018-04-19T06:49:00Z
<p>Using <a href="http://wiki.apidesign.org/wiki/Default_Listener_Methods" title="Default Listener Methods">Default Listener Methods</a> is perfectly fine! Those who remember my recent arguments against using <a href="http://wiki.apidesign.org/wiki/DefaultMethods" title="DefaultMethods">DefaultMethods</a> in <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">APIs</a> maybe the surprised by this statement, but it has to be made. Looks like using <a href="http://wiki.apidesign.org/wiki/Default_Listener_Methods" title="Default Listener Methods">Default Listener Methods</a> doesn't violate any practices of <a href="http://wiki.apidesign.org/wiki/Good" title="Good">good</a> <a href="http://wiki.apidesign.org/wiki/API_Design" class="mw-redirect" title="API Design">API Design</a>.
</p><p>Thanks Dušane, for pointing that out!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 06:49, 19 April 2018 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Frontend Where's your Frontend? On a desktop!? 2018-04-06T10:27:00Z
<p>What does term <a href="http://wiki.apidesign.org/wiki/Frontend" title="Frontend">Frontend</a> mean to you? <a href="http://wiki.apidesign.org/wiki/Frontend" title="Frontend">Tell</a> us!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 10:27, 6 April 2018 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/ContinuousIntegration Don't rely on Jenkins and co. They hurt your API design skills! 2018-04-04T14:16:00Z
<p>Recently I observed an incompatible API change and I received following explanation: <i>Everything is OK, my <a href="http://wiki.apidesign.org/wiki/ContinuousIntegration" title="ContinuousIntegration">ContinuousIntegration</a> server is still green!</i> In a shock I decided to write a philippic against <a href="http://wiki.apidesign.org/wiki/ContinuousIntegration" title="ContinuousIntegration">ContinuousIntegration</a>.
</p><p>If you have to fix your tests in a significant way after making a change to your <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a>, then you should think twice. Maybe such change isn't really compatible enough to become smoothly part of your framework. There is probably a lot of code similar to your tests out there and there is nobody to fix them as part of your refactoring. Better to learn and invest in keeping a bit of <a href="http://wiki.apidesign.org/wiki/BackwardCompatibility" title="BackwardCompatibility">BackwardCompatibility</a>.
</p><p>In some sense: When designing APIs, relying only on <a href="http://wiki.apidesign.org/wiki/ContinuousIntegration" title="ContinuousIntegration">ContinuousIntegration</a> is bad!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 14:16, 4 April 2018 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Turing_speed Turing speed: The Real Speed of a Language 2018-03-09T08:40:00Z
<p>Let me coin a new term: <a href="http://wiki.apidesign.org/wiki/Turing_speed" title="Turing speed">Turing speed</a> - the real speed a programming language has. The speed of a general (e.g. Turing complete) computation. Read <a href="http://wiki.apidesign.org/wiki/Turing_speed" title="Turing speed">here</a> why we need such classification.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 08:40, 9 March 2018 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Default_methods Avoid usage of default methods in an API! Support Cluelessness! 2018-03-05T11:32:00Z
<p>Don't use <a href="http://wiki.apidesign.org/wiki/Default_methods" class="mw-redirect" title="Default methods">default methods</a> when designing your <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a>. (For example when writing extensible <a href="http://wiki.apidesign.org/wiki/Visitor" title="Visitor">visitor</a> pattern) they just increase <a href="http://wiki.apidesign.org/wiki/Fuzziness" title="Fuzziness">fuzziness</a> and that is not what users of your <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> are searching for!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 11:32, 5 March 2018 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/DesignForJDK9 Design for JDK9: Use PropertyChangeListener, get whole Swing with that! 2017-08-14T16:59:00Z
<p><a href="http://wiki.apidesign.org/wiki/DesignForJDK9" title="DesignForJDK9">Designing for JDK9</a> is going to be more and more important when JDK9 is finally about to be released. However the <a href="http://wiki.apidesign.org/wiki/Modular" class="mw-redirect" title="Modular">modular</a> design of <a href="http://wiki.apidesign.org/wiki/Jigsaw" title="Jigsaw">Jigsaw</a> brings in new challenges. Hear <a href="http://wiki.apidesign.org/wiki/DesignForJDK9" title="DesignForJDK9">my story</a> where I tried to update a library to run on headless JDK9: because there is a hidden catch - once you try to use <a href="http://wiki.apidesign.org/wiki/PropertyChangeListener" class="mw-redirect" title="PropertyChangeListener">PropertyChangeListener</a> you get whole AWT/Swing user interface with that!
</p><p>Learn how to avoid that: <a href="http://wiki.apidesign.org/wiki/DesignForJDK9" title="DesignForJDK9">DesignForJDK9</a>!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 16:59, 14 August 2017 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/TwoYearsWithTruffle Designing API as a Service? Yes, I can. 2017-08-02T12:08:00Z
<p><a href="http://wiki.apidesign.org/wiki/TwoYearsWithTruffle" title="TwoYearsWithTruffle">Two years ago</a> I asked whether I can design <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a> <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> without being <a href="http://wiki.apidesign.org/wiki/Domain_Expert" title="Domain Expert">Domain Expert</a> in the area of partial evaluation. Time has come to <a href="http://wiki.apidesign.org/wiki/TwoYearsWithTruffle" title="TwoYearsWithTruffle">summarize my experience</a>. I've written down list of eleven topics that I focused on mostly and (surprisingly even to myself) in most of the cases I was able to apply my <a href="http://wiki.apidesign.org/wiki/APIDesign" class="mw-redirect" title="APIDesign">APIDesign</a> skills.
</p><p>Read my <a href="http://wiki.apidesign.org/wiki/TwoYearsWithTruffle" title="TwoYearsWithTruffle">TwoYearsWithTruffle</a> essay to understand that once you are in a need of an <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> designer, you should <a href="http://wiki.apidesign.org/wiki/Talkback" title="Talkback">talkback</a>...
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 12:08, 2 August 2017 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/PullXorPush Don't Push and Pull! 2017-06-16T13:54:00Z
<p>It is hard to <a href="http://wiki.apidesign.org/wiki/PullXorPush" title="PullXorPush">push and pull</a> at once in real life and people tend to know it. Yet <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> have witnessed many attempts that try to put both approaches into the same <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> at the same time and pretend those are equal. Small advice from a <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">former</a> <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> <a href="http://wiki.apidesign.org/wiki/NetBeans" title="NetBeans">designer</a>: don't do it!
</p><p>For a longer advice please see the <a href="http://wiki.apidesign.org/wiki/PullXorPush" title="PullXorPush">pull vs. push</a> essay.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 13:54, 16 June 2017 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/JustCode Just Code 2017-06-06T08:54:00Z
<p>Is it <a href="http://wiki.apidesign.org/wiki/JustCode" title="JustCode">JustCode</a> that matters in a project or do projects need more? Is it necessary to have a bug tracking system or can we embed everything in <a href="http://wiki.apidesign.org/wiki/JustCode" title="JustCode">the code</a>? Is it better to keep snapshot of an API in <a href="http://wiki.apidesign.org/wiki/JustCode" title="JustCode">the code</a> or track it independently with additional tools?
</p><p>Check my <a href="http://wiki.apidesign.org/wiki/JustCode" title="JustCode">JustCode</a> essay to see the benefits and drawbacks of both approaches.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 08:54, 6 June 2017 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Swing Swing's Bad Reputation 2016-08-26T10:37:00Z
<p>Is <a href="http://wiki.apidesign.org/wiki/Swing" title="Swing">Swing</a>'s openness reason for its so bad reputation?
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 10:37, 26 August 2016 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/CurryOn Become Polyglot by Learning Java! 2016-07-22T05:33:00Z
<p>I was invited to give a talk at <a href="http://wiki.apidesign.org/wiki/CurryOn" title="CurryOn">CurryOn</a> 2016 about <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a> called <i>Become Polyglot by Learning Java!</i>. It provoked <a href="http://wiki.apidesign.org/wiki/Twitter" title="Twitter">tweets</a> like: <i>If you only watch one talk from @curry_on_conf, this one from @JaroslavTulach on Graal/Truffle is <a href="http://www.curry-on.org/2016/sessions/become-a-polyglot-by-learning-java.html" class="external text" title="http://www.curry-on.org/2016/sessions/become-a-polyglot-by-learning-java.html" rel="nofollow">stunning</a>. Here is its recording:</i>
</p>
<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/N__8TBcaDTs"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/N__8TBcaDTs" type="application/x-shockwave-flash" wmode="transparent" allowfullscreen="true" width="425" height="350"></embed></object>
<p>Or go to <a href="https://www.youtube.com/watch?v=N__8TBcaDTs" class="external text" title="https://www.youtube.com/watch?v=N__8TBcaDTs" rel="nofollow">YouTube</a> page.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 05:33, 22 July 2016 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/APIReview Pitfalls of APIReviews 2016-07-17T13:38:00Z
<p>There are two pitfalls of an <a href="http://wiki.apidesign.org/wiki/APIReview" title="APIReview">APIReview</a>. Either there is no code to review or there is too much code already written. The <i>too little code</i> case can easily be fixed. As Linus Torwalds use to say: <i>Talk is cheap. Show me the code!</i>
</p><p>However what to do when <a href="http://wiki.apidesign.org/wiki/APIReview" title="APIReview">APIReview</a> 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 <a href="http://wiki.apidesign.org/wiki/APIReview" title="APIReview">APIReview</a> now!
</p><p>Maybe there is a way to handle such review as well. But it remains <a href="http://wiki.apidesign.org/wiki/APIReview" title="APIReview">to be seen</a> if it works. Wish me luck.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 13:38, 17 July 2016 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/WhiningBuilder Make Your Builder Whine! 2016-06-26T20:00:00Z
<p><a href="http://wiki.apidesign.org/wiki/WhiningBuilder" title="WhiningBuilder">Another variation</a> on the topic of builder patterns. A <a href="http://wiki.apidesign.org/wiki/WhiningBuilder" title="WhiningBuilder">builder</a> that can track <b>N</b> essential attributes and <a href="http://wiki.apidesign.org/wiki/WhiningBuilder" title="WhiningBuilder">whine</a> (by throwing a checked exception) until all of them are specified.
</p><p>Learn how to make your <a href="http://wiki.apidesign.org/wiki/WhiningBuilder" title="WhiningBuilder">builder whine</a>!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 20:00, 26 June 2016 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/ChameleonBuilder Chameleon Builder: Changes its Return Color! 2016-06-16T09:34:00Z
<p>Hear the news! A <a href="http://wiki.apidesign.org/wiki/ChameleonBuilder" title="ChameleonBuilder">new creature</a> of the API design patterns rare species has been discovered. It looks like a <b>builder</b> 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.
</p><p>Do you want to protect your own <a href="http://wiki.apidesign.org/wiki/BuilderUnfinished" class="mw-redirect" title="BuilderUnfinished">builder</a> like a chameleon? Follow <a href="http://wiki.apidesign.org/wiki/BuilderUnfinished" class="mw-redirect" title="BuilderUnfinished">this link</a> and learn <a href="http://wiki.apidesign.org/wiki/BuilderUnfinished" class="mw-redirect" title="BuilderUnfinished">the trick</a>!
</p><p>Once you discover the beauty, you'll not stop until you get your own <a href="http://wiki.apidesign.org/wiki/BuilderUnfinished" class="mw-redirect" title="BuilderUnfinished">chameleon builder</a> into your own design!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 09:34, 16 June 2016 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/BuilderWithConditionalException Builder to Tame Your Checked exception! 2016-06-13T08:00:00Z
<p>Here is a <a href="http://wiki.apidesign.org/wiki/BuilderWithConditionalException" title="BuilderWithConditionalException">nice extension</a> to the <a href="http://wiki.apidesign.org/wiki/Builder" title="Builder">builder</a> pattern that allows one to control whether the final <i>build()</i> method throws a <a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">Checked IOException</a> or not.
</p><p>Enjoy <a href="http://wiki.apidesign.org/wiki/BuilderWithConditionalException" title="BuilderWithConditionalException">this new addition</a> to the list of <a href="http://wiki.apidesign.org/wiki/APIDesignPatterns" class="mw-redirect" title="APIDesignPatterns">APIDesignPatterns</a>.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 08:00, 13 June 2016 (UTC)
</p><p><br />
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Checked_exception Uncheck Your Checked exception! 2016-04-06T16:26:00Z
<p><a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">Checked exceptions</a> are Java invention and many like to argue that they are the worst invention ever. <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> like exceptions and <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> like <a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">Checked exceptions</a>. Today <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> am ready to explain why!
</p><p>Do you believe people should only use runtime exceptions? That <a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">checked exception</a> add too much overhead? Then you are wrong!
</p><p><a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> agree that the concept of <a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">checked exceptions</a> in <a href="http://wiki.apidesign.org/wiki/Java" class="mw-redirect" title="Java">Java</a> has some drawbacks, but <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> am ready to explain how to overcome the restrictions and <b>uncheck your</b> <a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">checked exception</a> whenever you want. <a href="http://wiki.apidesign.org/wiki/Checked_exception" title="Checked exception">Enjoy</a>!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 16:26, 6 April 2016 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/TruffleSigtest Introducing Sigtest into Your Project Workflow! 2015-11-23T10:34:00Z
<p><a href="http://wiki.apidesign.org/wiki/TruffleSigtest" title="TruffleSigtest">Truffle project is using Sigtest</a> since today. I am maintaining the <a href="http://wiki.apidesign.org/wiki/TruffleSigtest" title="TruffleSigtest">Truffle</a> 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 <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a>, it is important to know whether a change is or isn't backward compatible. Without a tool like <a href="http://wiki.apidesign.org/wiki/TruffleSigtest" title="TruffleSigtest">Sigtest</a>, it is almost impossible to do that manually!
</p><p>Every project that designs an <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> needs an automated compatibility check. Learn what it takes to introduce <a href="http://wiki.apidesign.org/wiki/TruffleSigtest" title="TruffleSigtest">such checks</a> into your project by reading about the <a href="http://wiki.apidesign.org/wiki/TruffleSigtest" title="TruffleSigtest">TruffleSigtest</a> showcase!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 10:34, 23 November 2015 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/EnforcingProperUsage Enforcing Proper API Usage by Law 2015-06-15T09:21:00Z
<p><a href="http://wiki.apidesign.org/wiki/EnforcingProperUsage" title="EnforcingProperUsage">Enforcing proper usage</a> of an API is hard. One needs to strive for <a href="http://wiki.apidesign.org/wiki/Clarity" class="mw-redirect" title="Clarity">clarity</a>, 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 <a href="http://wiki.apidesign.org/wiki/EnforcingProperUsage" title="EnforcingProperUsage">choose our licenses wisely</a> and scare the hackers with legal actions!
</p><p>At the end it could also solve the famous <a href="http://wiki.apidesign.org/wiki/EnforcingProperUsage" title="EnforcingProperUsage">sun.misc.Unsafe issue</a>...
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 09:21, 15 June 2015 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/I18N Is localizing an API bad idea? 2015-05-31T07:48:00Z
<p>What is the relation between <a href="http://wiki.apidesign.org/wiki/I18N" title="I18N">I18N</a> and API design? Should <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> be <a href="http://wiki.apidesign.org/wiki/I18N" title="I18N">internationalized</a> and <a href="http://wiki.apidesign.org/wiki/L10N" class="mw-redirect" title="L10N">localized</a>?
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 07:48, 31 May 2015 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Domain_Expert API Design as a Service 2015-05-17T10:26:00Z
<p><a href="http://wiki.apidesign.org/wiki/Domain_Expert" title="Domain Expert">Domain Expert</a> is a person who has <a href="http://en.wikipedia.org/wiki/Domain_knowledge" class="extiw" title="wikipedia:Domain_knowledge">knowledge</a> of a particular system. With such knowledge it may seem easy to design <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">APIs</a> for the domain. However without understanding the <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> <a href="http://wiki.apidesign.org/wiki/Paradoxes" title="Paradoxes">Paradoxes</a> the quality of such <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> may not be high. It is likely going to cover the domain field, but the <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> usability or readiness for <a href="http://wiki.apidesign.org/wiki/Evolution" class="mw-redirect" title="Evolution">evolution</a> will very likely suffer (unless such <a href="http://wiki.apidesign.org/wiki/Domain_Expert" title="Domain Expert">Domain Expert</a> reads <a href="http://wiki.apidesign.org/wiki/TheAPIBook" title="TheAPIBook">TheAPIBook</a> first).
</p><p>However can it work backwards? E.g. can one be <i>just</i> an <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> expert and then design <a href="http://wiki.apidesign.org/wiki/Good" title="Good">good</a> enough <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> without appropriate <a href="http://en.wikipedia.org/wiki/Domain_knowledge" class="extiw" title="wikipedia:Domain_knowledge">domain knowledge</a>?
</p><p><a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> am now participating in an experiment that will check that. <a href="http://wiki.apidesign.org/wiki/Oracle" title="Oracle">Oracle</a>Labs guys asked me to help them design <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a> interoperability <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">APIs</a>. I do understand bit about <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a>, but certainly <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> am not a <a href="http://wiki.apidesign.org/wiki/Domain_Expert" title="Domain Expert">Domain Expert</a>, yet I am supposed to design something as complicated as <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> to allow mixing of <a href="http://wiki.apidesign.org/wiki/Language" title="Language">languages</a>: imagine part of program written in <a href="http://wiki.apidesign.org/wiki/Ruby" title="Ruby">Ruby</a>, part in <a href="http://wiki.apidesign.org/wiki/JavaScript" title="JavaScript">JavaScript</a>, part in <a href="http://wiki.apidesign.org/wiki/Java" class="mw-redirect" title="Java">Java</a> with objects floating between these languages without any borders!
</p><p>This is a new situation for me: In case of <a href="http://wiki.apidesign.org/wiki/NetBeans" title="NetBeans">NetBeans</a> or in case of <a href="http://wiki.apidesign.org/wiki/Html4Java" title="Html4Java">HTML/Java APIs</a>, I was also the architect of the system. <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> knew it by heart. Now I barely understand how <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a> 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.
</p><p>On the other hand, <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> am not yet <i>damaged</i> with the expert knowledge. I can still see the system with new comer eyes - just like you, users of <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a> will. As such <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> can perform a <i>usability study</i> on me, at least initially.
</p><p>If <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> can design easy to use <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">APIs</a> for <a href="http://wiki.apidesign.org/wiki/Truffle" title="Truffle">Truffle</a>, then I can create a perfect <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> facade around everything! Soon we'll have a chance to see whether one can be good <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> designer without being real <a href="http://wiki.apidesign.org/wiki/Domain_Expert" title="Domain Expert">Domain Expert</a>. Soon we'll find out if <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> Design can be offered as a service!
</p><p>Update from summer 2017: After <a href="http://wiki.apidesign.org/wiki/TwoYearsWithTruffle" title="TwoYearsWithTruffle">TwoYearsWithTruffle</a> I'd say there is a lot of things one can do to <a href="http://wiki.apidesign.org/wiki/Design_API_as_a_service" class="mw-redirect" title="Design API as a service">design API as a service</a> without being a <a href="http://wiki.apidesign.org/wiki/Domain_Expert" title="Domain Expert">Domain Expert</a>.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 10:26, 17 May 2015 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Brendan_Eich JavaScript is the x86 of the Web 2015-04-22T07:00:00Z
<p><a href="http://wiki.apidesign.org/wiki/Brendan_Eich" title="Brendan Eich">Brendan Eich</a>, the inventor of <a href="http://wiki.apidesign.org/wiki/JavaScript" title="JavaScript">JavaScript</a>: <b>I said '<a href="http://wiki.apidesign.org/wiki/JavaScript" title="JavaScript">JS</a> is the <a href="http://en.wikipedia.org/wiki/x86" class="extiw" title="wikipedia:x86">x86</a> of the web' ... the point is <a href="http://wiki.apidesign.org/wiki/JavaScript" title="JavaScript">JS</a> is about as low as we can go...</b>, here is a video to document the current <a href="http://wiki.apidesign.org/wiki/JavaScript" title="JavaScript">JavaScript</a> situation together with showing excellent demos as <a href="http://wiki.apidesign.org/wiki/DEW" title="DEW">a proof</a>:
</p>
<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/o6wh9HtP6v8"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/o6wh9HtP6v8" type="application/x-shockwave-flash" wmode="transparent" allowfullscreen="true" width="425" height="350"></embed></object>
<p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 07:00, 22 April 2015 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Gradle Gradle belongs to Stone Age! 2015-03-15T15:56:00Z
<p>My friends keep talking about the greatness of <a href="http://wiki.apidesign.org/wiki/Gradle" title="Gradle">Gradle</a>. It is hard to stand it, especially knowing there is a significant flaw introduced in <a href="http://wiki.apidesign.org/wiki/Gradle" title="Gradle">Gradle</a>'s core.
</p><p>The flaw is so huge that I rank <a href="http://wiki.apidesign.org/wiki/Gradle" title="Gradle">Gradle</a> along Ant. Into <a href="http://wiki.apidesign.org/wiki/Gradle" title="Gradle">Ant-age</a>!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 15:56, 15 March 2015 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/BinarySelection BinarySelection - #1 Rule of HR 2014-12-23T06:20:00Z
<p><a href="http://wiki.apidesign.org/wiki/BinarySelection" title="BinarySelection">BinarySelection</a> plays (except having its <a href="http://en.wikipedia.org/wiki/Binary_search_algorithm" class="extiw" title="wikipedia:Binary_search_algorithm">classical search</a> meaning) an important role in theory of <a href="http://en.wikipedia.org/wiki/Human_resource_management" class="extiw" title="wikipedia:Human_resource_management">HR</a> management. It defines what happens when employees are leaving the employer (either voluntarily or after being fired):
</p>
<pre><a href="http://wiki.apidesign.org/wiki/BinarySelection" title="BinarySelection">BinarySelection</a> means, that "<b>one</b>s" leave and "<b>zero</b>s" stay.
</pre>
<p><a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> mention this definition whenever we chat about life of software developers and it always generates grin smile. Of course, because it is so true! <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> can confess that as for last seventeen years <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a> have been sticking with <a href="http://wiki.apidesign.org/wiki/NetBeans" title="NetBeans">my job</a> surviving any layoffs and <a href="http://wiki.apidesign.org/wiki/Sun" title="Sun">acqui</a><a href="http://wiki.apidesign.org/wiki/Oracle" title="Oracle">sitions</a>: <a href="http://wiki.apidesign.org/wiki/I" class="mw-redirect" title="I">I</a>'ve seen so many "<b>one</b>s" leaving, but the rest of us is still marching on!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 06:20, 23 December 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/InvokeDynamic invokeDynamic is wrong idea. Especially for implementation of lambdas! 2014-09-25T12:50:00Z
<p>When I was younger I used to believe that having <a href="http://wiki.apidesign.org/wiki/InvokeDynamic" title="InvokeDynamic">invokeDynamic</a> instruction in <a href="http://wiki.apidesign.org/wiki/JVM" class="mw-redirect" title="JVM">JVM</a> can be beneficial. Now, few years later and after spending time to implement lambdas in my <a href="http://wiki.apidesign.org/wiki/Bck2Brwsr" title="Bck2Brwsr">Bck2Brwsr</a> <a href="http://wiki.apidesign.org/wiki/VM" class="mw-redirect" title="VM">VM</a> and seeing things from the other side I have to admit I was wrong. <a href="http://wiki.apidesign.org/wiki/InvokeDynamic" title="InvokeDynamic">invokeDynamic</a> is wrong idea (especially for implementation of lambdas).
</p><p>It is <a href="http://wiki.apidesign.org/wiki/JavaOne" title="JavaOne">JavaOne</a> time, I have a talk about my <a href="http://wiki.apidesign.org/wiki/Bck2Brwsr" title="Bck2Brwsr">Bck2Brwsr</a> together with Niclas from <a href="http://wiki.apidesign.org/wiki/RoboVM" title="RoboVM">RoboVM</a>, so let's show I understand what is wrong with <a href="http://wiki.apidesign.org/wiki/JVM" class="mw-redirect" title="JVM">JVM</a> 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:
</p><p><a href="http://wiki.apidesign.org/wiki/InvokeDynamic" title="InvokeDynamic">InvokeDynamic</a> should have never been added to <a href="http://wiki.apidesign.org/wiki/Java" class="mw-redirect" title="Java">Java</a> and should be removed from the specification. Read <a href="http://wiki.apidesign.org/wiki/InvokeDynamic" title="InvokeDynamic">why</a>...
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 12:50, 25 September 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Sources Sources for the Practical API Design book 2014-08-08T11:16:00Z
<p>Hear the news: <a href="http://wiki.apidesign.org/wiki/Sources" title="Sources">Sources</a> in ZIP format are back!
</p><p>My <a href="http://wiki.apidesign.org/wiki/Hudson" title="Hudson">Hudson</a> 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 <i>apidesign.zip</i> file with <a href="http://wiki.apidesign.org/wiki/Sources" title="Sources">sources</a>. Has anyone noticed? Nobody sent me an email! Just yesterday Jáchym, my co-worker, who I torture by forcing him to read <a href="http://wiki.apidesign.org/wiki/TheAPIBook" title="TheAPIBook">TheAPIBook</a> and become <a href="http://wiki.apidesign.org/wiki/Good" title="Good">good</a> <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">API</a> designer, stopped in my office and timidly asked: <i>Where can I get the sources? There is no <a href="http://wiki.apidesign.org/wiki/ZIP" title="ZIP">ZIP</a> file!</i>
</p><p>For a while I tried to blame him for not using <a href="http://wiki.apidesign.org/wiki/Mercurial" title="Mercurial">Mercurial</a>, but after a while I realized the problem is on my side. As a result, the <a href="http://hudson.apidesign.org/job/samples/" class="external text" title="http://hudson.apidesign.org/job/samples/" rel="nofollow">zip file with sources</a> is back as of Aug 8, 2014. Will anyone use them? It would be nice as reading <a href="http://wiki.apidesign.org/wiki/TheAPIBook" title="TheAPIBook">Practical API Design</a> book without having whole <a href="http://wiki.apidesign.org/wiki/Sources" title="Sources">sources</a> at your hand is like trying to understand <a href="http://wiki.apidesign.org/wiki/Swing" title="Swing">Swing</a> just by reading its <a href="http://wiki.apidesign.org/wiki/Javadoc" title="Javadoc">Javadoc</a>.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 11:16, 8 August 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Epistemology Epistemology of Software Design 2014-05-15T20:01:00Z
<p><a href="http://wiki.apidesign.org/wiki/Epistemology" title="Epistemology">Epistemology</a> 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 <a href="http://wiki.apidesign.org/wiki/NetBeans" title="NetBeans">NetBeans</a> I can only confirm everything Nathans describes!
</p><p>If you want to stop being a software engineer and become software architect, <a href="http://wiki.apidesign.org/wiki/Epistemology" title="Epistemology">epistemology</a> of software design is one of the things you have to memorize!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 20:01, 15 May 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/LowerProfile Lower Your Profile! Adopt JDK8! 2014-03-23T11:40:00Z
<p>By <a href="http://wiki.apidesign.org/wiki/LowerProfile" title="LowerProfile">lowering profile</a> of our libraries, we can make them more ready for <a href="http://wiki.apidesign.org/wiki/JDK" title="JDK">JDK</a>8. Here is <a href="http://wiki.apidesign.org/wiki/LowerProfile" title="LowerProfile">few patterns</a> one can use to adopt own library to <a href="http://wiki.apidesign.org/wiki/JDK" title="JDK">JDK</a>8 <a href="http://wiki.apidesign.org/wiki/Profiles" title="Profiles">profiles</a>.
</p><p><a href="http://wiki.apidesign.org/wiki/LowerProfile" title="LowerProfile">Lower your profile</a>, let (your library usage) get higher!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 11:40, 23 March 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Errata_9#Page_154 It, this and that: Optimizing for Cost of Ownership 2014-02-11T10:53:00Z
<p>As <a href="http://wiki.apidesign.org/wiki/Errata_9#Page_154" title="Errata 9">paragraph on page 154</a> shows, it is not easy to find out what a meaning of <i>it</i>, <i>this</i> and <i>that</i> may be. Thanks <a href="http://wiki.apidesign.org/wiki/Yoshiki" title="Yoshiki">Yoshiki</a> for contributing this first <a href="http://wiki.apidesign.org/wiki/Errata" title="Errata">Errata</a> for <a href="http://wiki.apidesign.org/wiki/Errata_9" title="Errata 9">Chapter 9</a>!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 10:53, 11 February 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Good_Advice Good Advice 2014-02-06T08:04:00Z
<p>How do you recognize <a href="http://wiki.apidesign.org/wiki/Good_Advice" title="Good Advice">Good Advice</a>? We already know what a <a href="http://wiki.apidesign.org/wiki/Good_technology" class="mw-redirect" title="Good technology">good technology</a> is, can we use the same concept to evaluate whether an advice is <a href="http://wiki.apidesign.org/wiki/Good" title="Good">good</a> or not? Let me answer that by a quote from <a href="http://wiki.apidesign.org/wiki/TheAPIBook" title="TheAPIBook">TheAPIBook</a> which <a href="http://wiki.apidesign.org/wiki/Yoshiki" title="Yoshiki">Yoshiki</a> asked about:
</p>
<a name="Page_363"></a><h5> <span class="mw-headline"> Page 363 </span></h5>
<p><a href="http://wiki.apidesign.org/wiki/Outline" title="Outline">Part 1</a> 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 <a href="http://wiki.apidesign.org/wiki/Good" title="Good">good</a>. These rules try to be language neutral
and applicable to any programming language, not just <a href="http://wiki.apidesign.org/wiki/Java" class="mw-redirect" title="Java">Java</a>. The theory is unlikely to be
complete. Other principles of API design exist elsewhere or are still waiting to be discovered.
</p><p>However, that should not scare us, as <a href="http://wiki.apidesign.org/wiki/Chapter_1" class="mw-redirect" title="Chapter 1">Chapter 1</a> 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 <a href="http://wiki.apidesign.org/wiki/API" class="mw-redirect" title="API">APIs</a> or not. It gives us the grand meta-principle: selective <a href="http://wiki.apidesign.org/wiki/Cluelessness" title="Cluelessness">cluelessness</a>. This <a href="http://wiki.apidesign.org/wiki/Cluelessness" title="Cluelessness">cluelessness</a>
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.
</p>
<a name="Yoshiki:_What_do_you_mean_by_this_advice.3F"></a><h5> <span class="mw-headline"> <a href="http://wiki.apidesign.org/wiki/Yoshiki" title="Yoshiki">Yoshiki</a>: What do you mean by <i>this advice</i>? </span></h5>
<p>"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 <a href="http://wiki.apidesign.org/wiki/Cluelessness" title="Cluelessness">cluelessness</a> is <a href="http://wiki.apidesign.org/wiki/Good" title="Good">good</a> and it will be even more valuable in the future when we start to build even bigger systems.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 08:04, 6 February 2014 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Language Pervert Your Language to Become a Better Programmer 2013-10-16T13:02:00Z
<p><a href="http://wiki.apidesign.org/wiki/Language" title="Language">Language</a> that you speak and write defines what you can think and reason about. The worse <a href="http://wiki.apidesign.org/wiki/Language" title="Language">language</a> you can use the better programmer you are. Right?
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 13:02, 16 October 2013 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/WeakReference Do You Know What a WeakReference Can Do to Your API? 2013-10-11T08:50:00Z
<p>References and <a href="http://wiki.apidesign.org/wiki/WeakReference" title="WeakReference">WeakReferences</a> 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 <a href="http://wiki.apidesign.org/wiki/WeakReference" title="WeakReference">WeakReferences</a> in the <a href="http://wiki.apidesign.org/wiki/Lookup" title="Lookup">Lookup</a> API.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 08:50, 11 October 2013 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Harmony JDK8's Profiles in the Light of Harmony 2013-08-12T14:54:00Z
<p>A curious translator of my book asked me about project <a href="http://wiki.apidesign.org/wiki/Harmony" title="Harmony">Harmony</a>. That motivated me to sit down and write an <a href="http://wiki.apidesign.org/wiki/Harmony" title="Harmony">incomplete and mostly wrong history of open source java implementations</a>. While incomplete (for example it does not talk by whom <a href="http://wiki.apidesign.org/wiki/Harmony" title="Harmony">Harmony</a> was founded and why), it explains why <a href="http://wiki.apidesign.org/wiki/JDK" title="JDK">JDK</a>8 is/will be a huge step forward and what will be its most important feature. Btw. if you thought lamdas, you were wrong.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 14:54, 12 August 2013 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Estimate Cimrman's Planning 2013-03-19T15:10:00Z
<p>Short <a href="http://wiki.apidesign.org/wiki/Estimate" title="Estimate">introduction</a> to accurate, agile, modern, reliable, flexible, optimistic, forward looking, experience based, projective <a href="http://wiki.apidesign.org/wiki/Estimate" title="Estimate">planning methodology</a>.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 15:10, 19 March 2013 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Platonic Platón's Theory of Ideas for Developers 2013-01-21T08:45:00Z
<p>Those of you who heard about <a href="http://wiki.apidesign.org/wiki/Platonic" title="Platonic">Platon</a> 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 <a href="http://wiki.apidesign.org/wiki/Platonic" title="Platonic">Platon</a> meant by the cave, shadows, etc. Luckily (at least for developers who know what geometry is), there is a <a href="http://wiki.apidesign.org/wiki/Platonic" title="Platonic">better explanation</a> which which explains <a href="http://wiki.apidesign.org/wiki/Platonic" title="Platonic">Platon</a>'s theory of ideas via geometry.
</p><p>This geometric way of explaining [[<a href="http://wiki.apidesign.org/wiki/Platonic" title="Platonic">ideas</a> was much easier for me to swallow. That is why I decided to share it here.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 08:45, 21 January 2013 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Two_sides On the fact that the Atlantic Ocean has two sides 2013-01-17T11:56:00Z
<p>Here are selected <a href="http://wiki.apidesign.org/wiki/Two_sides" title="Two sides">notes</a> 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 <a href="http://wiki.apidesign.org/wiki/Two_sides" title="Two sides">Dijkstra's comments</a> apply - especially when it comes to the clash between programmers educated in <a href="http://wiki.apidesign.org/wiki/Two_sides" title="Two sides">soft vs. real science</a> schools!
</p><p>Btw. should this <a href="http://wiki.apidesign.org/wiki/Two_sides" title="Two sides">kind of analysis</a> 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.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 11:56, 17 January 2013 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Hammer Having a Hammer All Problems Look Like a Nail 2012-11-12T13:37:00Z
<p>A theoretical observation about a <a href="http://wiki.apidesign.org/wiki/Hammer" title="Hammer">hammer</a> with application to real world scenario as well as software user interface design.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 13:37, 12 November 2012 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange TransitivityOfIncompatibleChange 2012-11-07T02:00:00Z
<p>A nice clash between real world and academic attempts to describe it can be seen on the case of <a href="http://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange" title="TransitivityOfIncompatibleChange">TransitivityOfIncompatibleChange</a>. While such <a href="http://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange" title="TransitivityOfIncompatibleChange">transitivity</a> 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 <a href="http://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange" title="TransitivityOfIncompatibleChange">its alternative</a>, but now I think I see <a href="http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed" title="RangeDependenciesAnalysed">it</a>.
</p><p>Last week I had a presentation about the topic of <a href="http://wiki.apidesign.org/wiki/NP-Complete" class="mw-redirect" title="NP-Complete">NP-Complete</a> problems in module <a href="http://wiki.apidesign.org/wiki/Dependencies" title="Dependencies">dependencies</a> at <a href="http://wiki.apidesign.org/wiki/MatFyz" title="MatFyz">MatFyz</a> and one of the questions was: Why am I not using <a href="http://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange" title="TransitivityOfIncompatibleChange">TransitivityOfIncompatibleChange</a> in case of repositories with <a href="http://wiki.apidesign.org/wiki/RangeDependencies" title="RangeDependencies">RangeDependencies</a>? Well, I don't as it does not have a clear meaning. But the question forced me to sit and write <a href="http://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange" title="TransitivityOfIncompatibleChange">the answer</a> down.
</p><p>Hopefully not only <a href="http://wiki.apidesign.org/wiki/MatFyz" title="MatFyz">MatFyz</a> guys find <a href="http://wiki.apidesign.org/wiki/TransitivityOfIncompatibleChange" title="TransitivityOfIncompatibleChange">the essay</a> useful.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 02:00, 7 November 2012 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Framework Is Java a Language or a Framework? 2012-10-18T09:06:00Z
<p>Just a few thoughts about the difference between language and a <a href="http://wiki.apidesign.org/wiki/Framework" title="Framework">framework</a> (plus a wish how Java should evolve).
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 09:06, 18 October 2012 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/Paradoxes 20 API Paradoxes Published! 2012-10-11T18:11:00Z
<p>Today I am ready to announce great news. My new book about 20 API <a href="http://wiki.apidesign.org/wiki/Paradoxes" title="Paradoxes">Paradoxes</a> 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:
</p><p><a href="http://wiki.apidesign.org/wiki/Image:ParadoxesCover.png" class="image" title="Image:ParadoxesCover.png"><img alt="Image:ParadoxesCover.png" src="http://wiki.apidesign.org/images/4/4e/ParadoxesCover.png" width="500" height="748" border="0" /></a>
</p><p>I asked Clay to select cover that would somehow reflect my relation with <a href="http://en.wikipedia.org/wiki/Czech_Republic" class="extiw" title="wikipedia:Czech_Republic">my home</a> and I am glad he decided to use painting of <a href="http://en.wikipedia.org/wiki/Josef_Lada" class="extiw" title="wikipedia:Josef_Lada">Josef Lada</a> - a painter of my childhood.
</p><p>I hope you like the cover too. And not only that, I hope you'll like the content as well. <a href="http://buy.apidesign.org" class="external text" title="http://buy.apidesign.org" rel="nofollow">Buy</a> & enjoy!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 18:11, 11 October 2012 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/100th_Monkey 100th Monkey Principle. Multicasting in a Nature? 2012-08-08T19:29:00Z
<p>James Borowski on <a href="http://wiki.apidesign.org/wiki/100th_Monkey" title="100th Monkey">100th Monkey</a> principle:
</p><p>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 <a href="http://wiki.apidesign.org/wiki/DiamondsVsStars" title="DiamondsVsStars">DiamondsVsStars</a>
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 <a href="http://wiki.apidesign.org/wiki/100th_Monkey" title="100th Monkey">100th Monkey</a> principle?
</p><p>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 <a href="http://wiki.apidesign.org/wiki/100th_Monkey" title="100th Monkey">100th Monkey</a>. 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.
</p><p>Anyway, hope you find as interesting as I found your stuff. For more info see
<a href="http://en.wikipedia.org/wiki/100th_Monkey" class="extiw" title="wikipedia:100th_Monkey">100th Monkey</a> at wikipedia.
</p><p>Thanks, for sharing this observation, James!
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 19:29, 8 August 2012 (UTC)
</p>
JaroslavTulachhttp://wiki.apidesign.org/wiki/BackwardCompatibility#Strictness How Strict a Backward Compatibility Should Be? 2012-07-31T12:13:00Z
<p>Here are <a href="http://wiki.apidesign.org/wiki/BackwardCompatibility#Strictness" title="BackwardCompatibility">some thoughts</a> on the difference between 100% <a href="http://wiki.apidesign.org/wiki/BackwardCompatibility" title="BackwardCompatibility">BackwardCompatibility</a> and their slightly more practical variants.
</p><p>--<a href="http://wiki.apidesign.org/wiki/User:JaroslavTulach" title="User:JaroslavTulach">JaroslavTulach</a> 12:13, 31 July 2012 (UTC)
</p><p><a href="http://wiki.apidesign.org/wiki/OlderBlogPosts" title="OlderBlogPosts">OlderBlogPosts</a>
</p><p>JaroslavTulach