Blogs:JaroslavTulach:Theory

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (06:02, 22 December 2021) (edit) (undo)
 
(79 intermediate revisions not shown.)
Line 3: Line 3:
<startFeed />
<startFeed />
-
==== Is [[Java]] an Object Oriented System? ====
+
==== Feeling the Pain! ====
-
Few years ago I was chatting about [[Smalltalk]] with Peter Ahé (originally JavaC maintainer). We laughed at ridiculous classical [[Smalltalk]] coding practices, but then realized that to some extent similar style was used when designing Java as well. Peter even said that Java is not object oriented language but [[Smalltalk|yaady-yaady-da oriented language]]. I no longer remember what exactly Peter called Java, but maybe you can read our [[Smalltalk]] objections and help find me the right name.
+
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 [[Pragmatic]] and less academic!
-
You are [[Smalltalk|welcomed to comment]]!
+
--[[User:JaroslavTulach|JaroslavTulach]] 06:02, 22 December 2021 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 14:58, 15 July 2011 (UTC)
+
==== The [[Genetics]] of an [[APIDesign]] ====
-
==== Is God A Computer Scientist? ====
+
The [[Genetics]] 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!
-
Last week I finished reading of the [[IsGodAMathematician|Is God A Mathematician?]] book and I can't prevent myself from recommending it by all means! My own book about API design uses various parables with the history of discovering the laws of real world. I used one very nice Czech book as an inspiration for these philosophical parts and I was always very sad that I cannot give my readers a chance to read it, as it was not translated to English. The [[IsGodAMathematician|Is God A Mathematician?]] book is a very good substitute.
+
--[[User:JaroslavTulach|JaroslavTulach]] 06:29, 29 June 2021 (UTC)
-
If you want deeper insight into the "battle" between rationalism and empiricism, [[IsGodAMathematician|Is God A Mathematician?]] is a perfect book to start with. It does not cover everything that I'd like to be covered, but never mind, it is still quite a good book. Plus I have enumerated the omissions on my [[IsGodAMathematician|review page]], including few notes about computer science.
+
==== The Science of [[APIDesign]] ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 20:16, 7 June 2011 (UTC)
+
[[ScienceOfAPIDesign]] 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 [[ScienceOfAPIDesign]] offers and use them in our daily policies. Or don't use them (but preferably knowing why).
-
==== Disassemble Your Types! ====
+
Anyone willing to join the quest on making [[ScienceOfAPIDesign]] better and sharper?
-
[[AssemblableTypes]] are your friend while modularizing your [[API]]s. With their help you can make sure you disassemble your monolithic system into flexible and independent parts that smoothly [[AssemblableTypes|assemble]] together when used by your [[API]] users.
+
--[[User:JaroslavTulach|JaroslavTulach]] 06:08, 15 October 2020 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 17:08, 14 May 2011 (UTC)
+
==== Adding [[DefaultMethods]] in a 100% [[BackwardCompatible]] Way! ====
-
==== Beginner's Guide to Modularity for [[DI]] Fans ====
+
I took a part in a tweetting about [[BinaryCompatibleDefaultMethods|incompatibilities related to
 +
CharSequence.isEmpty()]] over the weekend and I asked myself a simple question: ''Is it possible to add a default method in a 100% binary compatible way?'' The [[BinaryCompatibleDefaultMethods|newly written post]] provides the answer. Yes, [[BinaryCompatibleDefaultMethods|adding default methods to interfaces in a 100% binary compatible way]] is possible at the end!
-
Do you use [[Dependency Injection]] and are you curious about concepts of modularity? Then you can use this [[Dependency Injection|little guide]] explaining how certain concepts in [[Dependency Injection]] map to concepts in modular world.
+
--[[User:JaroslavTulach|JaroslavTulach]] 06:10, 30 September 2020 (UTC)
 +
==== Never Update ([[API]]) Tests! ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 16:49, 9 February 2011 (UTC)
+
Designing an API that shall last? Then [[Never update tests]]! The need to update tests is a sign of an [[incompatible]] change.
-
==== Transactional Memory ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 04:05, 24 January 2019 (UTC)
-
{{:TransactionalMemory}}
+
==== Never hold a lock when calling a foreign code! ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 11:33, 2 December 2010 (UTC)
+
Fighting with [[deadlock]]s is hard in normal code. In case of [[API]]s it is even harder. Yet, the advice is simple [[Deadlock|Never hold a lock when calling a foreign code]]. See the typical example rewritten to be [[deadlock]]-free in the dedicated [[deadlock]] page.
-
==== [[Excel]] in Designing [[DSL]]s for [[Excel]] People ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 07:11, 2 August 2018 (UTC)
-
Do you unit test your [[Excel]] formulas? Is that even possible? My new [[excel|post]] is not going to teach [[excel]] users new tricks, but it may help you to [[excel]] in designing domain specific languages. Either external or embedded (into Java or [[Excel]] ;-).
+
==== Shocking: [[Default Listener Methods]] ain't Dangerous! ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 21:53, 27 October 2010 (UTC)
+
Using [[Default Listener Methods]] is perfectly fine! Those who remember my recent arguments against using [[DefaultMethods]] in [[API]]s maybe the surprised by this statement, but it has to be made. Looks like using [[Default Listener Methods]] doesn't violate any practices of [[good]] [[API Design]].
-
==== "Five" Principles of Modularity ====
+
Thanks Dušane, for pointing that out!
-
Here is quite nice [[Modularity patterns|summary]] describing the content of our yesterday presentation about [[Patterns for Modularity]] written by Roger Rached. I really enjoyed the talk and I'd like to thank everyone for stopping by.
+
--[[User:JaroslavTulach|JaroslavTulach]] 06:49, 19 April 2018 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 01:09, 23 September 2010 (UTC)
+
==== Where's your [[Frontend]]? On a desktop!? ====
-
==== Why [[SQL]] is not Ready for Internet Age? ====
+
What does term [[Frontend]] mean to you? [[Frontend|Tell]] us!
-
Time to finish my [[SQL#Internet Age|SQL]] story. Today has been my last day in [[Sun]]. Tomorrow I'll sit at the same office and chair, but I'll be Oracle employee. Before that happens I can enjoy for the last time complete cluelessness about [[SQL#Internet Age|SQL]]. So here is it: follow this [[SQL#Internet Age|link]] to learn why [[SQL#Internet Age|SQL]] is not ready for internet age.
+
--[[User:JaroslavTulach|JaroslavTulach]] 10:27, 6 April 2018 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 20:23, 31 August 2010 (UTC)
+
==== Don't rely on [[Jenkins]] and co. They hurt your [[API]] design skills! ====
-
==== A Brief, Incomplete, and Mostly Wrong History of [[SQL]] ====
+
Recently I observed an incompatible API change and I received following explanation: ''Everything is OK, my [[ContinuousIntegration]] server is still green!'' In a shock I decided to write a philippic against [[ContinuousIntegration]].
-
The [[SQL]] story was in my mind for a while. I was lazy to write it down, I just talked about it with various persons directly. But I can't wait any longer. Since Sep 1, 2010 I will start working for a major [[SQL]] database vendor and as such I should publish my [[SQL]] essays as soon as possible. Later it might contradict opinion of my employer. Learn about the alternative view of [[SQL]] history now!
+
If you have to fix your tests in a significant way after making a change to your [[API]], 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 [[BackwardCompatibility]].
-
--[[User:JaroslavTulach|JaroslavTulach]] 09:53, 23 August 2010 (UTC)
+
In some sense: When designing APIs, relying only on [[ContinuousIntegration]] is bad!
-
.
+
-
==== Are You Waiting for Your Application to Launch? ====
+
-
I am not sure what is your experience, but fast [[Startup]] is one of the important things [[netbeans:performance]] team focuses on. Did you find yourself having coffee break while waiting for your application to [[startup|start]]? Then, you probably care. However not every kind of [[startup]] is similarly important. As such I have written little [[startup|classification]] or [[startup]]s. Walk through various [[startup]] types [[startup|here]].
+
--[[User:JaroslavTulach|JaroslavTulach]] 14:16, 4 April 2018 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 05:46, 22 July 2010 (UTC)
+
==== [[Turing speed]]: The Real Speed of a [[Language]] ====
-
==== Choose Your Dependencies Wisely! ====
+
Let me coin a new term: [[Turing speed]] - the real speed a programming language has. The speed of a general (e.g. Turing complete) computation. Read [[Turing speed|here]] why we need such classification.
-
{{:Blogs:JaroslavTulach:Theory:RightDependencies}}
+
--[[User:JaroslavTulach|JaroslavTulach]] 08:40, 9 March 2018 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 08:11, 19 May 2010 (UTC)
+
==== Avoid usage of [[default methods]] in an [[API]]! Support [[Cluelessness]]! ====
-
==== Simplest [[Teleinterface]] ====
+
Don't use [[default methods]] when designing your [[API]]. (For example when writing extensible [[visitor]] pattern) they just increase [[fuzziness]] and that is not what users of your [[API]] are searching for!
-
New [[Teleinterface]] has just been discovered! I was reading through my older posts today and I realized that [[MagicalStrings]] are in fact a form of [[Teleinterface]].
+
--[[User:JaroslavTulach|JaroslavTulach]] 11:32, 5 March 2018 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 10:11, 9 May 2010 (UTC)
+
==== Design for [[JDK]]9: Use [[PropertyChangeListener]], get whole [[Swing]] with that! ====
-
==== Blame Your Architect! ====
+
[[DesignForJDK9|Designing for JDK9]] is going to be more and more important when JDK9 is finally about to be released. However the [[modular]] design of [[Jigsaw]] brings in new challenges. Hear [[DesignForJDK9|my story]] where I tried to update a library to run on headless JDK9: because there is a hidden catch - once you try to use [[PropertyChangeListener]] you get whole AWT/Swing user interface with that!
-
As a [[MetaDesign#Blame_the_Architect.21|continuation]] of my sporadic thoughts about [[MetaDesign]] I decided to look closer to the topic of responsibility today. To introduce [[MetaDesign#Blame_the_Architect.21|the topic]] let me ask. What is more effective: if one architect does its job correctly or if thousands of users adjust to poor design? Find the [[MetaDesign#Blame_the_Architect.21|the answer]] and instructions for proper use of your trashcan [[MetaDesign#Blame_the_Architect.21|here]]!
+
Learn how to avoid that: [[DesignForJDK9]]!
-
--[[User:JaroslavTulach|JaroslavTulach]] 07:44, 25 April 2010 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 16:59, 14 August 2017 (UTC)
-
==== Is [[OSGi]] Secret Society Ruling the World by Using [[MagicalStrings|Magical Buzzword]]s? ====
+
==== Designing API as a Service? Yes, I can. ====
-
Do you know how to build a secret society? Use [[MagicalStrings]]! Recently my [[OSGi]] adventures and generous [[Talk:NetbinoxPerformance|help of Tom Watson]] resulted in two things: I made [[Netigso]] more efficient. I realized that any [[API]] that uses strings can be made [[MagicalStrings|quite cryptic]]! [[MagicalStrings|Learn more about my inquiry]]...
+
[[TwoYearsWithTruffle|Two years ago]] I asked whether I can design [[Truffle]] [[API]] without being [[Domain Expert]] in the area of partial evaluation. Time has come to [[TwoYearsWithTruffle|summarize my experience]]. 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 [[APIDesign]] skills.
-
--[[User:JaroslavTulach|JaroslavTulach]] 20:15, 8 April 2010 (UTC)
+
Read my [[TwoYearsWithTruffle]] essay to understand that once you are in a need of an [[API]] designer, you should [[talkback]]...
-
==== Ever met an architect? ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 12:08, 2 August 2017 (UTC)
-
Is there anything like [[MetaDesign|universal architecture rules]]? For a while I am seeking for ones and today it is the right time to share [[MetaDesign|my findings]]. They are not complete, but join me with your comments on this [[MetaDesign|discovery journey]].
+
==== Don't Push and Pull! ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 19:29, 10 March 2010 (UTC)
+
It is hard to [[PullXorPush|push and pull]] at once in real life and people tend to know it. Yet [[I]] have witnessed many attempts that try to put both approaches into the same [[API]] at the same time and pretend those are equal. Small advice from a [[Truffle|former]] [[API]] [[NetBeans|designer]]: don't do it!
-
==== Know it Better! ====
+
For a longer advice please see the [[PullXorPush|pull vs. push]] essay.
-
Based on classical [[SuperVsInner]] example I'd like to formulate one [[SuperVsInner|important advice to follow]] when designing an [[API]].
+
--[[User:JaroslavTulach|JaroslavTulach]] 13:54, 16 June 2017 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 12:40, 24 February 2010 (UTC)
+
==== Just Code ====
-
==== What is a [[chance]]? ====
+
Is it [[JustCode]] 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 [[JustCode|the code]]? Is it better to keep snapshot of an API in [[JustCode|the code]] or track it independently with additional tools?
-
What is a [[chance]]?
+
Check my [[JustCode]] essay to see the benefits and drawbacks of both approaches.
-
--[[User:JaroslavTulach|JaroslavTulach]] 19:11, 17 February 2010 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 08:54, 6 June 2017 (UTC)
-
==== History Repeats in Cycles ====
+
==== [[Swing]]'s Bad Reputation ====
-
Let me quote Tim and Andreas conversation about [[Ruby]]. Is every human activity destined to repeat what has already been invented? Repeat on a ''new'', ''advanced'' level, so we can not only repeat old mistakes, but also add new ones?
+
Is [[Swing]]'s openness reason for its so bad reputation?
-
--[[User:JaroslavTulach|JaroslavTulach]] 05:23, 28 January 2010 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 10:37, 26 August 2016 (UTC)
-
==== Is [[Paradox]] unnatural? ====
+
==== Become Polyglot by Learning Java! ====
-
Do you like [[paradox]]es? Do you seek for them? Do you find them strange? Here is [[paradox|my little explanation]] why this is very natural, very human.
+
{{:CurryOn}}
-
--[[User:JaroslavTulach|JaroslavTulach]] 09:57, 19 January 2010 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 05:33, 22 July 2016 (UTC)
 +
==== Pitfalls of [[APIReview]]s ====
-
==== Quiz: Name the First [[OOP]] Language! ====
+
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!''
-
Do you know what was the first [[OOP]] language? I thought I knew - till yesterday when I read great essay about [[OOP]]. Enlighten yourself, [[OOP|read it]] too and learn name of the grandfather of all [[OOP]] languages!
+
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!
-
--[[User:JaroslavTulach|JaroslavTulach]] 08:20, 3 November 2009 (UTC)
+
Maybe there is a way to handle such review as well. But it remains [[APIReview|to be seen]] if it works. Wish me luck.
-
==== Retarded [[Swing]] Programmer. Was: AWT Dispatch Thread... ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 13:38, 17 July 2016 (UTC)
-
I have to [[DCIAndLeakyAbstractions|defend myself]]. I have received a [[Talk:RationalismVsEmpiricism|lot of comments]] in response to my [[RationalismVsEmpiricism|recent essay]] about use of AWT Dispatch Thread. Especially this one: ''Why was the event display thread used for non-painting computation in the first place? It's Swing 101 to not have long delays on the EDT...it's covered in any book on Swing as well.'' made me feel retarded for a while. But I am not bad ([[Swing]]) programmer. Thus I started to seek deeply in my soul and I have an explanation why some think we are doing things in wrong way, while we don't: It is because of [[DCIAndLeakyAbstractions|DCI's specifics]]!
+
==== Make Your Builder Whine! ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 20:42, 30 October 2009 (UTC)
+
[[WhiningBuilder|Another variation]] on the topic of builder patterns. A [[WhiningBuilder|builder]] that can track '''N''' essential attributes and [[WhiningBuilder|whine]] (by throwing a checked exception) until all of them are specified.
-
==== AWT Dispatch Thread Shall be Used Only for Painting! ====
+
Learn how to make your [[WhiningBuilder|builder whine]]!
-
Here is a [[RationalismVsEmpiricism|little essay]] building up on adventures of this week and explaining the difference between our attitude towards [[RationalismVsEmpiricism|rationalism and empiricism]].
+
--[[User:JaroslavTulach|JaroslavTulach]] 20:00, 26 June 2016 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 14:32, 23 October 2009 (UTC)
+
==== Chameleon [[Builder]]: Changes its Return Color! ====
-
==== [[OSGi]]: Too Much Love will Kill You ====
+
Hear the news! A [[ChameleonBuilder|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.
-
Recently I was thinking about the way [[RangeDependencies]] are specified in [[OSGi]] and I was trying to find reasons why that is wrong and inside out. I don't think I succeeded yet, but I can at least show that with [[RangeDependencies]] one increases the risk of running into [[NP-Complete]] problems. [[RangeDependencies]] give you so much lovely power, that they somehow need to strike back and hurt you. Get [[RangeDependencies|ready for that]]!
+
Do you want to protect your own [[BuilderUnfinished|builder]] like a chameleon? Follow [[BuilderUnfinished|this link]] and learn [[BuilderUnfinished|the trick]]!
-
--[[User:JaroslavTulach|JaroslavTulach]] 19:53, 18 October 2009 (UTC)
+
Once you discover the beauty, you'll not stop until you get your own [[BuilderUnfinished|chameleon builder]] into your own design!
-
==== Quiz: Who invented [[Convention over Configuration]]? ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 09:34, 16 June 2016 (UTC)
-
Do you know who invented [[Convention over Configuration]] paradigm? Me!? No, I am joking. But today I wanted to write a blog about one [[APIDesignPatterns|API Design Anti Pattern]] and surprisingly I realized that [[Convention over Configuration]] hype started by modern frameworks was in fact outrun by one core [[Java]] framework. Or do you know about older example of [[Convention over Configuration]] in [[Java]]? [[C]]? [[Fortran]]?
+
==== [[Builder]] to Tame Your [[Checked exception]]! ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 12:16, 20 September 2009 (UTC)
+
Here is a [[BuilderWithConditionalException|nice extension]] to the [[builder]] pattern that allows one to control whether the final ''build()'' method throws a [[Checked exception|Checked IOException]] or not.
-
==== Is [[Maven]] Over Abstracted? ====
+
Enjoy [[BuilderWithConditionalException|this new addition]] to the list of [[APIDesignPatterns]].
-
Not really. It is just not [[DocumentDeclarativeAPI|properly documented]]. I'd like to thank you all for your [[Talk:Maven|feedback]] on my recent post about [[Maven]]. I have successfully [[Maven#It_is_Ready.21_It_is_Just_Different.|used the assembly plugin]] to create ZIP containing all my application [[JAR]]s. This time I'd like to [[Maven#Lessons_Learned|point out why I failed to do so without your help]] before.
+
--[[User:JaroslavTulach|JaroslavTulach]] 08:00, 13 June 2016 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 09:14, 15 September 2009 (UTC)
 
-
==== Can Math Save Your Life? Sure, by eliminating [[NP-Complete]] Problem! ====
+
==== Uncheck Your [[Checked exception]]! ====
-
New [http://wiki.apidesign.org/index.php?title=LibraryWithoutImplicitExportIsPolynomial&useskin=monobook proof] is here!
+
[[Checked exception]]s are Java invention and many like to argue that they are the worst invention ever. [[I]] like exceptions and [[I]] like [[Checked exception]]s. Today [[I]] am ready to explain why!
-
The [[LibraryReExportIsNPComplete]] outlined the problem one has to face when practicing [[DistributedDevelopment]]. The [[LibraryReExportIsNPComplete|page]] also proved that in its global scope the problem is [[NP-Complete]] with all its [[LibraryReExportIsNPComplete#Implications|implications]].
+
Do you believe people should only use runtime exceptions? That [[checked exception]] add too much overhead? Then you are wrong!
-
Surprisingly there seems to be an easy cure that eliminates the [[NP-Complete]] nature of the [[LibraryReExportIsNPComplete|library re-export]]. Visit [[LibraryWithoutImplicitExportIsPolynomial]] to learn about [[LibraryWithoutImplicitExportIsPolynomial|complete repositories]].
+
[[I]] agree that the concept of [[checked exception]]s in [[Java]] has some drawbacks, but [[I]] am ready to explain how to overcome the restrictions and '''uncheck your''' [[checked exception]] whenever you want. [[Checked exception|Enjoy]]!
-
--[[User:JaroslavTulach|JaroslavTulach]] 08:46, 2 September 2009 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 16:26, 6 April 2016 (UTC)
-
==== Imagine Living without Compatibility! ====
+
==== Introducing [[Sigtest]] into Your Project Workflow! ====
-
[[BackwardCompatibility]] is the only weapon we have against the madness of [[wikipedia::NP-Complete]] problems. Unless you want to turn your developers and application assemblers into highly performant [http://wiki.apidesign.org/index.php?title=LibraryReExportIsNPComplete&useskin=monobook NP problem] solvers, learn how to achieve [[BackwardCompatibility]].
+
[[TruffleSigtest|Truffle project is using Sigtest]] since today. I am maintaining the [[TruffleSigtest|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 [[TruffleSigtest|Sigtest]], it is almost impossible to do that manually!
-
--[[User:JaroslavTulach|JaroslavTulach]] 20:46, 27 August 2009 (UTC)
+
Every project that designs an [[API]] needs an automated compatibility check. Learn what it takes to introduce [[TruffleSigtest|such checks]] into your project by reading about the [[TruffleSigtest]] showcase!
-
==== Math that Affects Your Life. Learn to Avoid NP-complete Problems! ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 10:34, 23 November 2015 (UTC)
-
Hi all mathematicians out there! At least I hope there is someone with a little bit of math background among people reading this blog. I have a [http://wiki.apidesign.org/index.php?title=LibraryReExportIsNPComplete&useskin=monobook proof] of existence of a new [[wikipedia::NP-Complete|NP-Complete]] problem. First of all I need someone to look at it and tell me if it is correct. I believe the idea is fine, I am not sure if the [http://wiki.apidesign.org/index.php?title=LibraryReExportIsNPComplete&useskin=monobook proof itself] is technically correct.
+
==== Enforcing Proper [[API]] Usage by Law ====
-
Hi the rest of us! For those who don't want to bother with [[wikipedia::Computational_complexity_theory|complexity theory]] and rather stick with their keyboards or planning sheets, there is also a [[LibraryReExportIsNPComplete#Implications|summary]]. Look at it and learn why a little bit of math can be [[LibraryReExportIsNPComplete#Implications|good for your own design skills]].
+
[[EnforcingProperUsage|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 [[EnforcingProperUsage|choose our licenses wisely]] and scare the hackers with legal actions!
-
--[[User:JaroslavTulach|JaroslavTulach]] 07:52, 25 August 2009 (UTC)
+
At the end it could also solve the famous [[EnforcingProperUsage|sun.misc.Unsafe issue]]...
-
==== Changing Rules of the Game ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 09:21, 15 June 2015 (UTC)
-
When facing a problem, what can you do? Either seek a solution or redefine the problem. If you have power to [[Modular_Java_SE#Changing_Rules_of_the_Game|change the rules of the game]], then all problems become immediately much simpler. See this general principle in action during [[Modular_Java_SE#Changing_Rules_of_the_Game|modularization of the Java SE]].
+
==== Is [[L10N|localizing]] an [[API]] bad idea? ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 05:49, 25 June 2009 (UTC)
+
What is the relation between [[I18N]] and API design? Should [[API]] be [[I18N|internationalized]] and [[L10N|localized]]?
-
==== False Expectations ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 07:48, 31 May 2015 (UTC)
-
Are you about to modularize your API? Do you understand what such step can bring you? Good. However check this note to also understand what it [[Modular_Java_SE#False_Expectations|cannot help with]]...
+
==== [[API]] Design as a Service ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 14:57, 16 June 2009 (UTC)
+
{{:Domain_Expert}}
-
==== Close Proximity of [[API]]-less [[API]]s ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 10:26, 17 May 2015 (UTC)
-
Can you imagine [[APILessAPI|world without APIs]]? I can now...
+
==== [[JavaScript]] is the x86 of the Web ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 21:27, 11 June 2009 (UTC)
+
[[Brendan Eich]], the inventor of [[JavaScript]]: '''I said '[[JavaScript|JS]] is the [[wikipedia:x86|x86]] of the web' ... the point is [[JavaScript|JS]] is about as low as we can go...''', here is a video to document the current [[JavaScript]] situation together with showing excellent demos as [[DEW|a proof]]:
-
==== Hail to Modularity! ====
+
{{#ev:youtube|o6wh9HtP6v8}}
-
I've moved the [[NetBeans_Runtime_Container|modular programming manifesto]] into wiki. Will it stimulate readers to fix it and make it more up-to-date?
+
--[[User:JaroslavTulach|JaroslavTulach]] 07:00, 22 April 2015 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 13:26, 22 May 2009 (UTC)
+
==== [[Gradle]] belongs to Stone Age! ====
-
==== A Brief, Incomplete, and Mostly Wrong History of Programming Languages ====
+
My friends keep talking about the greatness of [[Gradle]]. It is hard to stand it, especially knowing there is a significant flaw introduced in [[Gradle]]'s core.
-
{{:Blogs:JaroslavTulach:Theory:History of Programming Languages}}
+
The flaw is so huge that I rank [[Gradle]] along Ant. Into [[Gradle|Ant-age]]!
-
--[[User:JaroslavTulach|JaroslavTulach]] 17:14, 15 May 2009 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 15:56, 15 March 2015 (UTC)
-
==== Feeling Independent? ====
+
==== [[BinarySelection]] - #1 Rule of HR ====
-
Most of our programs don't live in a vacuum. They require some supporting environment in order to work. One might think that such [[TypesOfDependencies|dependencies]] on surrounding are unified for whole lifecycle of a library. That would be false assumption. As the following note discusses there seem to be many [[TypesOfDependencies]].
+
{{:BinarySelection}}
-
--[[User:JaroslavTulach|JaroslavTulach]] 16:47, 23 February 2009 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 06:20, 23 December 2014 (UTC)
-
==== How ''current'' can you be? Not much, that's ''certain''! ====
+
==== [[invokeDynamic]] is wrong idea. Especially for implementation of [[closure|lambdas]]! ====
-
Looks like the ''Practical API Design'' book has a new reader. Welcome! Moreover David is not an ordinary reader. He is not afraid to [[The_Art_of_Building_Modern_Software#Current_or_Certain.3F|ask questions]]. Perfect! Thanks for your interesting question and please check [[The_Art_of_Building_Modern_Software#Current_or_Certain.3F|my answer]].
+
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).
-
--[[User:JaroslavTulach|JaroslavTulach]] 21:09, 6 February 2009 (UTC)
+
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:
-
==== Just Three Kinds of [[BackwardCompatibility]]? ====
+
[[InvokeDynamic]] should have never been added to [[Java]] and should be removed from the specification. Read [[InvokeDynamic|why]]...
-
Finally I finished the online page describing what it is [[BackwardCompatibility]]. It defines three different kinds: source, binary and functional and I am curios to know: Is that all? Or can you think about other types of compatibility?
+
--[[User:JaroslavTulach|JaroslavTulach]] 12:50, 25 September 2014 (UTC)
-
--[[User:JaroslavTulach|JaroslavTulach]] 15:30, 21 December 2008 (UTC)
+
==== [[Sources]] for the [[TheAPIBook|Practical API Design]] book ====
-
==== Declarative Registrations ====
+
Hear the news: [[Sources]] in ZIP format are back!
-
I see the year 2009 as [[Declarative_Programming#Less_is_Better|the year of annotations]]. At least for the [[NetBeans]] project - we are about to use them much more frequently than we did so far. That is why I cannot stop thinking about various ways of using [[Declarative Programming]]. As a result, there will be more blog posts about such programming style. Here is one: my little explanation why [[Declarative_Programming#Less_is_Better|less is better]] when using the [[Declarative Programming]] registrations.
+
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!''
-
--[[User:JaroslavTulach|JaroslavTulach]] 14:43, 5 December 2008 (UTC)
+
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 [http://hudson.apidesign.org/job/samples/ zip file with sources] is back as of Aug 8, 2014. Will anyone use them? It would be nice as reading [[TheAPIBook|Practical API Design]] book without having whole [[sources]] at your hand is like trying to understand [[Swing]] just by reading its [[Javadoc]].
-
==== 3 Sides to Every API ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 11:16, 8 August 2014 (UTC)
-
[[3SidesToEveryAPI|3 Sides to Every API]] is my reaction to excellent [[Blogs:PetrHejl:BeautyMatters|Beauty matters]] summary provided [[User:PetrHejl|PetrHejl]]. It is my attempt to agree with him, while defending [[TheAPIBook]]'s often proposition that ''beauty does not matter''...
+
==== Epistemology of Software Design ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 21:37, 24 November 2008 (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!
-
==== Beauty Matters ====
+
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!
-
J. Tulach in his Practical API Design book claims that beauty is not the most important requirement when you design your API. Because he is repeating this multiple times at various places I got the bad feeling that this could be easily misunderstood. [[Blogs:PetrHejl:BeautyMatters|Let me clarify...]]
+
-
--[[User:PetrHejl|PetrHejl]] 14:38, 11 November 2008 (UTC)
+
--[[User:JaroslavTulach|JaroslavTulach]] 20:01, 15 May 2014 (UTC)
-
==== What Makes a [[Technology]] [[Good Technology|good]]? ====
+
==== Lower Your Profile! Adopt [[JDK]]8! ====
-
Dear API users, can you help me define term [[Good Technology]]? What makes a [[technology]] good, useful? How do you evaluate quality of the [[API]]s you use? I've just written [[Good Technology|few thoughts about this topic]] down, however I'll be glad to hear your opinion. Is [[NetBeans]] platform [[Good Technology]] or bad?
+
By [[LowerProfile|lowering profile]] of our libraries, we can make them more ready for [[JDK]]8. Here is [[LowerProfile|few patterns]] one can use to adopt own library to [[JDK]]8 [[profiles]].
-
--[[User:JaroslavTulach|JaroslavTulach]] 18:26, 3 November 2008 (UTC)
+
[[LowerProfile|Lower your profile]], let (your library usage) get higher!
-
==== The Better Compiler the Worse API!? ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 11:40, 23 March 2014 (UTC)
-
Today I am ready to announce a really [[APITypes:CompilerOptimizations|nice addition]] to the collection of weird examples of [[APITypes]]. Did you ever suffered with [[APITypes:CompilerOptimizations|compiler optimizations]]? Did you ever thought about them as being an example of an [[APITypes|API]]?
+
==== It, this and that: Optimizing for [[Cost of Ownership]] ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 18:57, 16 October 2008 (UTC)
+
As [[Errata_9#Page_154|paragraph on page 154]] shows, it is not easy to find out what a meaning of ''it'', ''this'' and ''that'' may be. Thanks [[Yoshiki]] for contributing this first [[Errata]] for [[Errata 9|Chapter 9]]!
-
==== More on Ruby, Gems and Modularity ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 10:53, 11 February 2014 (UTC)
-
The ''Ruby'' anonymous coward which brought duck-typing into attention of readers of this blog, added new comments to our [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution#Modularity|discussion]]. The note presents Gems and I have to admit that by having Gems as standard packaging and dependency management tool, the [[Ruby]] gets far ahead standard offerings of [[Java]]. Of course unless you decide to use [[NetBeans]] runtime container or similar...
+
==== [[Good Advice]] ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 09:32, 30 September 2008 (UTC)
+
{{:Good Advice}}
-
==== Are APIs like diamonds or like stars? ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 08:04, 6 February 2014 (UTC)
-
{{:Blogs:JaroslavTulach:Theory:DiamondsVsStars}}
+
==== Pervert Your [[Language]] to Become a Better Programmer ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 03:34, 26 September 2008 (UTC)
+
[[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?
-
==== Can duck-typing help with API evolution? ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 13:02, 16 October 2013 (UTC)
-
I've just received a [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|comment]] mentioning Ruby's duck-typing as a solution to evolution problem in API [[Blogs:JaroslavTulach:Theory:LanguagesForEvolution|discussed herein earlier]]. Interesting food for thought! Thanks! However so far I have to admit that there is no obvious benefit, at least not in the particular case. [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution|Read more]] and feel free to comment...
+
==== Do You Know What a [[WeakReference]] Can Do to Your [[API]]? ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 15:54, 22 September 2008 (UTC)
+
References and [[WeakReference]]s 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 [[WeakReference]]s in the [[Lookup]] API.
-
==== getDate() method evolution thoughts by Tim Band ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 08:50, 11 October 2013 (UTC)
-
Imagine that you have a class with method ''getDate()'' which returns the date of creation of that object. Can you add ''setDate()'' in new version? Can that change be compatible? This is topic discussed recently by [http://lambda-the-ultimate.org/node/2950#comment-43612 Tim Band at LtU] discussion forums:
+
==== [[JDK]]8's Profiles in the Light of [[Harmony]] ====
-
If the get_date function had a comment stating "Returns the date at which the object was created" then you have to update that comment -- and that semantic change to get_date is the break.
+
A curious translator of my book asked me about project [[Harmony]]. That motivated me to sit down and write an [[Harmony|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 [[JDK]]8 is/will be a huge step forward and what will be its most important feature. Btw. if you thought lamdas, you were wrong.
-
It is hard to think of a semantic meaning for a get_date function that covers the setting of an arbitrary date, so let's imagine that we want to add "refresh_date" and that the original documentation of get_date said "Returns some date between the creation of the object and the calling of the function", then adding refresh_date is OK.
+
--[[User:JaroslavTulach|JaroslavTulach]] 14:54, 12 August 2013 (UTC)
-
If get_date is undocumented or ambiguously documented, you need some process to resolve this. At Symbian we have a board of beard-strokers (of whom I am an occaisional member) who deliberate on the difficult cases and inform the customers of our decisions, and get feedback on certain issues. This process is considered integral to our backwards compatibility promise.
+
==== Cimrman's Planning ====
-
It is tempting to dream of a world where a programming language or supporting infrastructure would free us of the compatibility burden, turning it into just another language feature. However, it is in the mucky world of semantics, where interfaces meet the world of human use and abuse where this stuff really matters. You can break compatibility if you know it won't matter (we once changed our formerly weird floating-point implementation to match IEEE with no-one even noticing), but you can't make some compatible changes (changing priorities of processes that have no stated dependency on each other is a classic).
+
Short [[estimate|introduction]] to accurate, agile, modern, reliable, flexible, optimistic, forward looking, experience based, projective [[estimate|planning methodology]].
-
Having said all that, there is much work to be done on merely keeping interfaces stable. You can get quite far just by assuming that the source interface (your class and function signatures in your .h files in C++) matches the semantics, and picking up incompatible changes to that over time (removal of functions for example) and alterations of the binary interface in relation to the source interface (adding a virtual function for example).
+
--[[User:JaroslavTulach|JaroslavTulach]] 15:10, 19 March 2013 (UTC)
-
Of course, occasionally you must allow customers to override common sense; I'm sure many readers here are familiar with the story of Microsoft Windows' memory manager running in a different mode if it detected Sim City running -- this is always a risk and you have to be aware that you might be forced to retract changes in the face of politics.
+
==== Platón's Theory of Ideas for Developers ====
-
I should probably stop now, although really I'm just getting started! Tim Band
+
Those of you who heard about [[Platonic|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 [[Platonic|Platon]] meant by the cave, shadows, etc. Luckily (at least for developers who know what geometry is), there is a [[Platonic|better explanation]] which which explains [[Platonic|Platon]]'s theory of ideas via geometry.
-
--[[User:JaroslavTulach|JaroslavTulach]] 07:32, 17 September 2008 (UTC)
+
This geometric way of explaining [[[[Platonic|ideas]] was much easier for me to swallow. That is why I decided to share it here.
-
==== Joel Neely on Enums in APIs ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 08:45, 21 January 2013 (UTC)
-
Today I found out that there is an interesting
+
==== On the fact that the Atlantic Ocean has two sides ====
-
[[:Talk:Blogs:AndreiBadea:EnumsInAPIs#Joel_Neely_said_...|comment]]
+
-
to the blog entry published by
+
-
[[AndreiBadea|Andrei]] a week ago. [[AndreiBadea|Andrei]] shared with us few thoughts on the [[Blogs:AndreiBadea:EnumsInAPIs|use of enums in API]]. [[Talk:Blogs:AndreiBadea:EnumsInAPIs#Joel_Neely_said_...|Joel Neely noted]] that it all depends on how the '''enum''' is used in the API. I cannot do anything else than agree with
+
-
[[Talk:Blogs:AndreiBadea:EnumsInAPIs#Joel_Neely_said_...|his words]], yes it depends on whether the '''enum''' is used [[wikipedia::Covariance_and_contravariance_(computer_science)|covariantly or contravariantly]]. If the enum is used covariantly only, then extending it with new constant in new version of the API is OK.
+
-
The only problem is that as soon as you publish an '''enum''', one can immediately write a '''switch''' statement over it. And the '''switch''' statement's behaviour is contravariant. That is no good news for the API writers and compatible extensibility of their '''enum''' based APIs...
+
Here are selected [[Two sides|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 [[Two sides|Dijkstra's comments]] apply - especially when it comes to the clash between programmers educated in [[Two sides|soft vs. real science]] schools!
-
--[[User:JaroslavTulach|JaroslavTulach]] 21:22, 26 August 2008 (UTC)
+
Btw. should this [[Two sides|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.
-
==== [[Blogs:JaroslavTulach:Theory:LanguagesForEvolution|Are there any Languages Ready for API Evolution?]] ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 11:56, 17 January 2013 (UTC)
-
{{:Blogs:JaroslavTulach:Theory:LanguagesForEvolution}}
+
==== Having a [[Hammer]] All Problems Look Like a Nail ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 06:50, 24 August 2008 (UTC)
+
A theoretical observation about a [[hammer]] with application to real world scenario as well as software user interface design.
-
==== Visual Aspects of an API ====
+
--[[User:JaroslavTulach|JaroslavTulach]] 13:37, 12 November 2012 (UTC)
-
The usual consensus is that [[APITypes:VisualAspects|visual aspects]] that are presented just to the end user are not part of API of some application. This is usually well justified and correct, except in [[APITypes:VisualAspects|some situations]]...
+
==== [[TransitivityOfIncompatibleChange]] ====
-
--[[User:JaroslavTulach|JaroslavTulach]] 11:40, 11 August 2008 (UTC)
+
A nice clash between real world and academic attempts to describe it can be seen on the case of [[TransitivityOfIncompatibleChange]]. While such [[TransitivityOfIncompatibleChange|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 [[TransitivityOfIncompatibleChange|its alternative]], but now I think I see [[RangeDependenciesAnalysed|it]].
-
==== Dependencies Are Important Type of API ====
+
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 [[TransitivityOfIncompatibleChange|the answer]] down.
-
New type of API [[Blogs:JaroslavTulach:Theory:Dependencies Are Impotant Type of API|has been discovered]]!
+
Hopefully not only [[MatFyz]] guys find [[TransitivityOfIncompatibleChange|the essay]] useful.
-
[[User:JaroslavTulach|JaroslavTulach]] 07:05, 15 July 2008 (UTC)
+
--[[User:JaroslavTulach|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).
 +
 
 +
--[[User:JaroslavTulach|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:
 +
 
 +
[[Image:ParadoxesCover.png]]
 +
 
 +
I asked Clay to select cover that would somehow reflect my relation with [[wikipedia:Czech Republic|my home]] and I am glad he decided to use painting of [[wikipedia:Josef Lada|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. [http://buy.apidesign.org Buy] & enjoy!
 +
 
 +
--[[User:JaroslavTulach|JaroslavTulach]] 18:11, 11 October 2012 (UTC)
 +
 
 +
==== 100th Monkey Principle. Multicasting in a Nature? ====
 +
 
 +
{{:100th Monkey}}
 +
 
 +
Thanks, for sharing this observation, James!
 +
 
 +
--[[User:JaroslavTulach|JaroslavTulach]] 19:29, 8 August 2012 (UTC)
 +
 
 +
==== How Strict a Backward Compatibility Should Be? ====
 +
 
 +
Here are [[BackwardCompatibility#Strictness|some thoughts]] on the difference between 100% [[BackwardCompatibility]] and their slightly more practical variants.
 +
 
 +
--[[User:JaroslavTulach|JaroslavTulach]] 12:13, 31 July 2012 (UTC)
 +
 
 +
[[OlderBlogPosts]]
<endFeed />
<endFeed />

Current revision

Contents

Theory Thoughts

Feeling the Pain!

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 Pragmatic and less academic!

--JaroslavTulach 06:02, 22 December 2021 (UTC)

The Genetics of an APIDesign

The Genetics 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!

--JaroslavTulach 06:29, 29 June 2021 (UTC)

The Science of APIDesign

ScienceOfAPIDesign 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 ScienceOfAPIDesign offers and use them in our daily policies. Or don't use them (but preferably knowing why).

Anyone willing to join the quest on making ScienceOfAPIDesign better and sharper?

--JaroslavTulach 06:08, 15 October 2020 (UTC)

Adding DefaultMethods in a 100% BackwardCompatible Way!

I took a part in a tweetting about incompatibilities related to CharSequence.isEmpty() over the weekend and I asked myself a simple question: Is it possible to add a default method in a 100% binary compatible way? The newly written post provides the answer. Yes, adding default methods to interfaces in a 100% binary compatible way is possible at the end!

--JaroslavTulach 06:10, 30 September 2020 (UTC)

Never Update (API) Tests!

Designing an API that shall last? Then Never update tests! The need to update tests is a sign of an incompatible change.

--JaroslavTulach 04:05, 24 January 2019 (UTC)

Never hold a lock when calling a foreign code!

Fighting with deadlocks is hard in normal code. In case of APIs it is even harder. Yet, the advice is simple Never hold a lock when calling a foreign code. See the typical example rewritten to be deadlock-free in the dedicated deadlock page.

--JaroslavTulach 07:11, 2 August 2018 (UTC)

Shocking: Default Listener Methods ain't Dangerous!

Using Default Listener Methods is perfectly fine! Those who remember my recent arguments against using DefaultMethods in APIs maybe the surprised by this statement, but it has to be made. Looks like using Default Listener Methods doesn't violate any practices of good API Design.

Thanks Dušane, for pointing that out!

--JaroslavTulach 06:49, 19 April 2018 (UTC)

Where's your Frontend? On a desktop!?

What does term Frontend mean to you? Tell us!

--JaroslavTulach 10:27, 6 April 2018 (UTC)

Don't rely on Jenkins and co. They hurt your API design skills!

Recently I observed an incompatible API change and I received following explanation: Everything is OK, my ContinuousIntegration server is still green! In a shock I decided to write a philippic against ContinuousIntegration.

If you have to fix your tests in a significant way after making a change to your API, 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 BackwardCompatibility.

In some sense: When designing APIs, relying only on ContinuousIntegration is bad!

--JaroslavTulach 14:16, 4 April 2018 (UTC)

Turing speed: The Real Speed of a Language

Let me coin a new term: Turing speed - the real speed a programming language has. The speed of a general (e.g. Turing complete) computation. Read here why we need such classification.

--JaroslavTulach 08:40, 9 March 2018 (UTC)

Avoid usage of default methods in an API! Support Cluelessness!

Don't use default methods when designing your API. (For example when writing extensible visitor pattern) they just increase fuzziness and that is not what users of your API are searching for!

--JaroslavTulach 11:32, 5 March 2018 (UTC)

Design for JDK9: Use PropertyChangeListener, get whole Swing with that!

Designing for JDK9 is going to be more and more important when JDK9 is finally about to be released. However the modular design of Jigsaw brings in new challenges. Hear my story where I tried to update a library to run on headless JDK9: because there is a hidden catch - once you try to use PropertyChangeListener you get whole AWT/Swing user interface with that!

Learn how to avoid that: DesignForJDK9!

--JaroslavTulach 16:59, 14 August 2017 (UTC)

Designing API as a Service? Yes, I can.

Two years ago I asked whether I can design Truffle API without being Domain Expert in the area of partial evaluation. Time has come to summarize my experience. 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 APIDesign skills.

Read my TwoYearsWithTruffle essay to understand that once you are in a need of an API designer, you should talkback...

--JaroslavTulach 12:08, 2 August 2017 (UTC)

Don't Push and Pull!

It is hard to push and pull at once in real life and people tend to know it. Yet I have witnessed many attempts that try to put both approaches into the same API at the same time and pretend those are equal. Small advice from a former API designer: don't do it!

For a longer advice please see the pull vs. push essay.

--JaroslavTulach 13:54, 16 June 2017 (UTC)

Just Code

Is it JustCode 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 the code? Is it better to keep snapshot of an API in the code or track it independently with additional tools?

Check my JustCode essay to see the benefits and drawbacks of both approaches.

--JaroslavTulach 08:54, 6 June 2017 (UTC)

Swing's Bad Reputation

Is Swing's openness reason for its so bad reputation?

--JaroslavTulach 10:37, 26 August 2016 (UTC)

Become Polyglot by Learning Java!

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)

Pitfalls of APIReviews

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)

Make Your Builder Whine!

Another variation on the topic of builder patterns. A builder that can track N essential attributes and whine (by throwing a checked exception) until all of them are specified.

Learn how to make your builder whine!

--JaroslavTulach 20:00, 26 June 2016 (UTC)

Chameleon Builder: Changes its Return Color!

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.

Do you want to protect your own builder like a chameleon? Follow this link and learn the trick!

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)

Builder to Tame Your Checked exception!

Here is a nice extension to the builder pattern that allows one to control whether the final build() method throws a Checked IOException or not.

Enjoy this new addition to the list of APIDesignPatterns.

--JaroslavTulach 08:00, 13 June 2016 (UTC)


Uncheck Your Checked exception!

Checked exceptions are Java invention and many like to argue that they are the worst invention ever. I like exceptions and I like Checked exceptions. Today I am ready to explain why!

Do you believe people should only use runtime exceptions? That checked exception add too much overhead? Then you are wrong!

I agree that the concept of checked exceptions in Java has some drawbacks, but I am ready to explain how to overcome the restrictions and uncheck your checked exception whenever you want. Enjoy!

--JaroslavTulach 16:26, 6 April 2016 (UTC)

Introducing Sigtest into Your Project Workflow!

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!

Every project that designs an API needs an automated compatibility check. Learn what it takes to introduce such checks into your project by reading about the TruffleSigtest showcase!

--JaroslavTulach 10:34, 23 November 2015 (UTC)

Enforcing Proper API Usage by Law

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)

Is localizing an API bad idea?

What is the relation between I18N and API design? Should API be internationalized and localized?

--JaroslavTulach 07:48, 31 May 2015 (UTC)

API Design as a Service

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).

However can it work backwards? E.g. can one be just an API expert and then design good enough API without appropriate domain knowledge?

I am now participating in an experiment that will check that. OracleLabs guys asked me to help them design Truffle interoperability APIs. I do understand bit about Truffle, but certainly I am not a Domain Expert, yet I am supposed to design something as complicated as API to allow mixing of languages: imagine part of program written in Ruby, part in JavaScript, part in Java with objects floating between these languages without any borders!

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!

Update from summer 2017: After TwoYearsWithTruffle I'd say there is a lot of things one can do to design API as a service without being a Domain Expert.

--JaroslavTulach 10:26, 17 May 2015 (UTC)

JavaScript is the x86 of the Web

Brendan Eich, the inventor of JavaScript: I said 'JS is the x86 of the web' ... the point is JS is about as low as we can go..., here is a video to document the current JavaScript situation together with showing excellent demos as a proof:

--JaroslavTulach 07:00, 22 April 2015 (UTC)

Gradle belongs to Stone Age!

My friends keep talking about the greatness of Gradle. It is hard to stand it, especially knowing there is a significant flaw introduced in Gradle's core.

The flaw is so huge that I rank Gradle along Ant. Into Ant-age!

--JaroslavTulach 15:56, 15 March 2015 (UTC)

BinarySelection - #1 Rule of HR

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)

invokeDynamic is wrong idea. Especially for implementation of lambdas!

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:

InvokeDynamic should have never been added to Java and should be removed from the specification. Read why...

--JaroslavTulach 12:50, 25 September 2014 (UTC)

Sources for the Practical API Design book

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

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)

Lower Your Profile! Adopt JDK8!

By lowering profile of our libraries, we can make them more ready for JDK8. Here is few patterns one can use to adopt own library to JDK8 profiles.

Lower your profile, let (your library usage) get higher!

--JaroslavTulach 11:40, 23 March 2014 (UTC)

It, this and that: Optimizing for Cost of Ownership

As paragraph on page 154 shows, it is not easy to find out what a meaning of it, this and that may be. Thanks Yoshiki for contributing this first Errata for Chapter 9!

--JaroslavTulach 10:53, 11 February 2014 (UTC)

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:04, 6 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:

Image:ParadoxesCover.png

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)

OlderBlogPosts

Retrieved from "http://wiki.apidesign.org/wiki/Blogs:JaroslavTulach:Theory"
Personal tools
buy