Blogs:JaroslavTulach:Theory

From APIDesign

Revision as of 05:11, 18 October 2013 (edit) JaroslavTulach (Talk | contribs) ← Previous diff		Revision as of 15:44, 16 January 2014 (edit) (undo) JaroslavTulach (Talk | contribs) Next diff →
Line 91:		Line 91:
	--[[User:JaroslavTulach|JaroslavTulach]] 12:13, 31 July 2012 (UTC)		--[[User:JaroslavTulach|JaroslavTulach]] 12:13, 31 July 2012 (UTC)
-	==== Dependencies Between [[Jigsaw]] Modules Made Easy! ====	+	[[OlderBlogPosts]]
-		+
-	Those who observe my blog may remember that I have an obsession. I am trying to understand module versioning and dependencies between modules. Recently I was playing with [[JigsawServices]]:	+
-		+
-	<source lang="java">	+
-	module M1 {	+
-	requires service S;	+
-	}	+
-	</source>	+
-		+
-	The above concept is essentially [[NP-Complete]] as one may have choices from multiple modules providing implementation of the service and selecting the right one is NP-hard as explained in [[JigsawServices#NP-Complete_Services|this example]].	+
-		+
-	But I think I have found an [[JigsawServices#Providing_a_Hint|acceptable solution]]. Today I will have a presentation about it (here are the [[Media:PolynomialDependencies.pdf|slides]]). Wish me luck!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 13:56, 24 July 2012 (UTC)	+
-		+
-	==== [[JavaFX]] + [[Swing]]: Together at last! ====	+
-		+
-	I am proud to announce that the mutual [[JavaFX]] and Swing interoperability has been greatly simplified. No need for massive amount of asynchronous '''Runnable'''s! Your Swing code can directly talk to [[JavaFX]] data structures and your [[JavaFX]] code can manipulate with Swing objects. This is a small change, but huge step forward for Swing+[[JavaFX]] interoperability!	+
-		+
-	A related quiz: When your code runs, can it find a difference between threads it is executed in? My [[JavaFX|guess]] is that it cannot!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 10:35, 23 May 2012 (UTC)	+
-		+
-	==== An [[API]] [[Proximity]]. Are You Close Friend with Your [[API]]? ====	+
-		+
-	How [[Proximity|close]] are you to the API that you use? Are you friends? Do you hate each other? Have you memorize the API? Can you debug it? Is your API a [[clueless]] blackbox for you? Are you a calling client? Do you implement and provide some of the API concepts? Do you think I am asking silly questions?	+
-		+
-	It seems that [[proximity]] is one of the best ways to classify [[libraries]] into categories. So far I managed to recognize [[Simple library|Zero to Many]], [[Vendor library|One to Many]], [[Semantic versioning|Few to Many]] and [[Modular library|Many to Many]] [[proximity]] categories. They seem to directly influence the [[APIDesignPatterns]] one should use when designing such [[libraries]]. As such, when you are about to design your [[library]], think a bit about the [[proximity]] you want to have with your clients and providers.	+
-		+
-	Btw. Most of [[NetBeans]] [[libraries]] is using the [[Modular library|Many to Many]] [[proximity]]. I'll be more than glad if you decide to stick with our most favourite [[proximity]] style as well.	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 19:56, 12 May 2012 (UTC)	+
-		+
-	==== [[RangeDependencies]] May not Be Root of All Evil! But [[OSGi]]'s High Shot Missed the Sweet Spot. ====	+
-		+
-	Most recent work on [[RangeDependenciesAnalysed|understanding range dependencies]] in modular systems seems to reveal that all the flaws associated with [[RangeDependencies]] (e.g. resolving module dependencies being an [[NP-Complete]] problem) can in fact be eliminated by so called [[RangeDependenciesAnalysed#Complete_Module_Repository_with_Ranges|complete repositories]]. Looks like it is time when I should apologize to poor [[RangeDependencies]] - it is not your fault, it is the way people use you that is causing problems.	+
-		+
-	Should I also apologize to [[OSGi]]? No, it is probably too early. we need to wait until complete repositories are adopted by that system. Until that happens I can still claim that [[OSGi#Range_Dependencies|OSGi's high shot missed the sweet spot]]!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 10:33, 9 January 2012 (UTC)	+
-		+
-	==== Defending [[OSGi]] ====	+
-		+
-	My recent post about OSGi deficiencies generated some interesting [[Talk:OSGi|comments and observations]] which seem worth to be [[Talk:OSGi|shared]]. Thanks Mirko for stopping by and leaving your long [[Talk:OSGi|answer]].	+
-		+
-	I should probably mention that my talk [http://www.eclipsecon.org/2012/sessions/experiences-building-fastest-osgi-container-planet Experiences from Building the Fastest OSGi Container on the Planet] has been accepted for March 2012 '''OSGiCon''' - thus dear OSGi fans, I may be available for face to face exchange of arguments.	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 08:50, 25 November 2011 (UTC)	+
-		+
-	==== [[OSGi]] is Just Weird ====	+
-		+
-	Last week I submitted a paper to [[OSGi]]Con 2012. I'd like it to be accepted as I'd like to meet the Mylyn guys there. To attract a bit of attention to it I've decided to be a bit controversial:	+
-		+
-	[[OSGi]] is flexible, but not logical. [[OSGi]] is not well thought out. [[OSGi]] is over designed. Read [[OSGi|more]] to understand why.	+
-		+
-	In case the previous ramblings would not guarantee me the invitation for [[OSGi]]Con, I can also be nice and say: [[OSGi]] is good for interoperability. Can my paper be accepted now?	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 15:23, 13 November 2011 (UTC)	+
-		+
-	==== Less is More: [[Erasure]] of Generic Types in [[Java]] ====	+
-		+
-	People like to complain about [[erasure]] of the generic type information during runtime. Yes, the lack of introspection is unfortunate. Since [[JDK]] 1.1 people got used to inspecting and reflecting almost anything. The fact that information about generics is [[erasure|erased]] provokes them.	+
-		+
-	However not everything is so bad. The [[erasure]] of the type information has benefits. For example we all know that [[covariance]] and [[contravariance]] is not very useful when designing APIs in Java, right? However due to [[erasure]] of the proper type information, there are [[erasure|situations]] when one can rely on it.	+
-		+
-	The less type info due to [[erasure]] allows us to achieve [[erasure|more]]!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 18:05, 19 October 2011 (UTC)	+
-		+
-	==== [[Intelligent design]] or [[Evolution]]? ====	+
-		+
-	Are you fan of [[intelligent design]] or evolution? None, or you don't care? If you are designing APIs, then you should! Because [[intelligent design]] plays a central role in life of software architects. Your attitude towards [[intelligent design|it]] predefines how good architect you can be!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 11:55, 25 July 2011 (UTC)	+
-		+
-	==== Is [[Java]] an Object Oriented System? ====	+
-		+
-	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.	+
-		+
-	You are [[Smalltalk|welcomed to comment]]!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 14:58, 15 July 2011 (UTC)	+
-		+
-	==== Is God A Computer Scientist? ====	+
-		+
-	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.	+
-		+
-	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.	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 20:16, 7 June 2011 (UTC)	+
-		+
-	==== Disassemble Your Types! ====	+
-		+
-	[[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]] 17:08, 14 May 2011 (UTC)	+
-		+
-	==== Beginner's Guide to Modularity for [[DI]] Fans ====	+
-		+
-	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]] 16:49, 9 February 2011 (UTC)	+
-		+
-	==== Transactional Memory ====	+
-		+
-	{{:TransactionalMemory}}	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 11:33, 2 December 2010 (UTC)	+
-		+
-	==== [[Excel]] in Designing [[DSL]]s for [[Excel]] People ====	+
-		+
-	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]] ;-).	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 21:53, 27 October 2010 (UTC)	+
-		+
-	==== "Five" Principles of Modularity ====	+
-		+
-	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]] 01:09, 23 September 2010 (UTC)	+
-		+
-	==== Why [[SQL]] is not Ready for Internet Age? ====	+
-		+
-	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]] 20:23, 31 August 2010 (UTC)	+
-		+
-	==== A Brief, Incomplete, and Mostly Wrong History of [[SQL]] ====	+
-		+
-	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!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 09:53, 23 August 2010 (UTC)	+
-	.	+
-	==== 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]] 05:46, 22 July 2010 (UTC)	+
-		+
-	==== Choose Your Dependencies Wisely! ====	+
-		+
-	{{:Blogs:JaroslavTulach:Theory:RightDependencies}}	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 08:11, 19 May 2010 (UTC)	+
-		+
-	==== Simplest [[Teleinterface]] ====	+
-		+
-	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]] 10:11, 9 May 2010 (UTC)	+
-		+
-	==== Blame Your Architect! ====	+
-		+
-	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]]!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 07:44, 25 April 2010 (UTC)	+
-		+
-	==== Is [[OSGi]] Secret Society Ruling the World by Using [[MagicalStrings|Magical Buzzword]]s? ====	+
-		+
-	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]]...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 20:15, 8 April 2010 (UTC)	+
-		+
-	==== Ever met an architect? ====	+
-		+
-	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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 19:29, 10 March 2010 (UTC)	+
-		+
-	==== Know it Better! ====	+
-		+
-	Based on classical [[SuperVsInner]] example I'd like to formulate one [[SuperVsInner|important advice to follow]] when designing an [[API]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 12:40, 24 February 2010 (UTC)	+
-		+
-	==== What is a [[chance]]? ====	+
-		+
-	What is a [[chance]]?	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 19:11, 17 February 2010 (UTC)	+
-		+
-	==== History Repeats in Cycles ====	+
-		+
-	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?	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 05:23, 28 January 2010 (UTC)	+
-		+
-	==== Is [[Paradox]] unnatural? ====	+
-		+
-	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.	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 09:57, 19 January 2010 (UTC)	+
-		+
-		+
-	==== Quiz: Name the First [[OOP]] Language! ====	+
-		+
-	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!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 08:20, 3 November 2009 (UTC)	+
-		+
-	==== Retarded [[Swing]] Programmer. Was: AWT Dispatch Thread... ====	+
-		+
-	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]]!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 20:42, 30 October 2009 (UTC)	+
-		+
-	==== AWT Dispatch Thread Shall be Used Only for Painting! ====	+
-		+
-	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]] 14:32, 23 October 2009 (UTC)	+
-		+
-	==== [[OSGi]]: Too Much Love will Kill You ====	+
-		+
-	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]]!	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 19:53, 18 October 2009 (UTC)	+
-		+
-	==== Quiz: Who invented [[Convention over Configuration]]? ====	+
-		+
-	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]]?	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 12:16, 20 September 2009 (UTC)	+
-		+
-	==== Is [[Maven]] Over Abstracted? ====	+
-		+
-	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]] 09:14, 15 September 2009 (UTC)	+
-		+
-	==== Can Math Save Your Life? Sure, by eliminating [[NP-Complete]] Problem! ====	+
-		+
-	New [http://wiki.apidesign.org/index.php?title=LibraryWithoutImplicitExportIsPolynomial&useskin=monobook proof] is here!	+
-		+
-	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]].	+
-		+
-	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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 08:46, 2 September 2009 (UTC)	+
-		+
-	==== Imagine Living without Compatibility! ====	+
-		+
-	[[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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 20:46, 27 August 2009 (UTC)	+
-		+
-	==== Math that Affects Your Life. Learn to Avoid NP-complete Problems! ====	+
-		+
-	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.	+
-		+
-	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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 07:52, 25 August 2009 (UTC)	+
-		+
-	==== Changing Rules of the Game ====	+
-		+
-	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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 05:49, 25 June 2009 (UTC)	+
-		+
-	==== False Expectations ====	+
-		+
-	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]]...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 14:57, 16 June 2009 (UTC)	+
-		+
-	==== Close Proximity of [[API]]-less [[API]]s ====	+
-		+
-	Can you imagine [[APILessAPI|world without APIs]]? I can now...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 21:27, 11 June 2009 (UTC)	+
-		+
-	==== Hail to Modularity! ====	+
-		+
-	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]] 13:26, 22 May 2009 (UTC)	+
-		+
-	==== A Brief, Incomplete, and Mostly Wrong History of Programming Languages ====	+
-		+
-	{{:Blogs:JaroslavTulach:Theory:History of Programming Languages}}	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 17:14, 15 May 2009 (UTC)	+
-		+
-	==== Feeling Independent? ====	+
-		+
-	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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 16:47, 23 February 2009 (UTC)	+
-		+
-	==== How ''current'' can you be? Not much, that's ''certain''! ====	+
-		+
-	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]].	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 21:09, 6 February 2009 (UTC)	+
-		+
-	==== Just Three Kinds of [[BackwardCompatibility]]? ====	+
-		+
-	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]] 15:30, 21 December 2008 (UTC)	+
-		+
-	==== Declarative Registrations ====	+
-		+
-	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.	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 14:43, 5 December 2008 (UTC)	+
-		+
-	==== 3 Sides to Every API ====	+
-		+
-	[[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''...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 21:37, 24 November 2008 (UTC)	+
-		+
-	==== Beauty Matters ====	+
-	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)	+
-		+
-	==== What Makes a [[Technology]] [[Good Technology|good]]? ====	+
-		+
-	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?	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 18:26, 3 November 2008 (UTC)	+
-		+
-	==== The Better Compiler the Worse API!? ====	+
-		+
-	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]]?	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 18:57, 16 October 2008 (UTC)	+
-		+
-	==== More on Ruby, Gems and Modularity ====	+
-		+
-	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...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 09:32, 30 September 2008 (UTC)	+
-		+
-	==== Are APIs like diamonds or like stars? ====	+
-		+
-	{{:Blogs:JaroslavTulach:Theory:DiamondsVsStars}}	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 03:34, 26 September 2008 (UTC)	+
-		+
-	==== Can duck-typing help with API evolution? ====	+
-		+
-	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...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 15:54, 22 September 2008 (UTC)	+
-		+
-	==== getDate() method evolution thoughts by Tim Band ====	+
-		+
-	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:	+
-		+
-	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.	+
-		+
-	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.	+
-		+
-	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.	+
-		+
-	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).	+
-		+
-	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).	+
-		+
-	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.	+
-		+
-	I should probably stop now, although really I'm just getting started! Tim Band	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 07:32, 17 September 2008 (UTC)	+
-		+
-	==== Joel Neely on Enums in APIs ====	+
-		+
-	Today I found out that there is an interesting	+
-	[[: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...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 21:22, 26 August 2008 (UTC)	+
-		+
-	==== [[Blogs:JaroslavTulach:Theory:LanguagesForEvolution|Are there any Languages Ready for API Evolution?]] ====	+
-		+
-	{{:Blogs:JaroslavTulach:Theory:LanguagesForEvolution}}	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 06:50, 24 August 2008 (UTC)	+
-		+
-	==== Visual Aspects of an API ====	+
-		+
-	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]]...	+
-		+
-	--[[User:JaroslavTulach|JaroslavTulach]] 11:40, 11 August 2008 (UTC)	+
-		+
-	==== Dependencies Are Important Type of API ====	+
-		+
-	New type of API [[Blogs:JaroslavTulach:Theory:Dependencies Are Impotant Type of API|has been discovered]]!	+
-		+
-	[[User:JaroslavTulach|JaroslavTulach]] 07:05, 15 July 2008 (UTC)	+
	<endFeed />		<endFeed />

---

Revision as of 15:44, 16 January 2014

Contents 1 Theory Thoughts 1.1 Pervert Your Language to Become a Better Programmer 1.2 Do You Know What a WeakReference Can Do to Your API? 1.3 JDK8's Profiles in the Light of Harmony 1.4 Cimrman's Planning 1.5 Platón's Theory of Ideas for Developers 1.6 On the fact that the Atlantic Ocean has two sides 1.7 Having a Hammer All Problems Look Like a Nail 1.8 TransitivityOfIncompatibleChange 1.9 Is Java a Language or a Framework? 1.10 20 API Paradoxes Published! 1.11 100th Monkey Principle. Multicasting in a Nature? 1.12 How Strict a Backward Compatibility Should Be?

Theory Thoughts

Pervert Your Language to Become a Better Programmer

Language that you speak and write defines what you can think and reason about. The worse language you can use the better programmer you are. Right?

--JaroslavTulach 13:02, 16 October 2013 (UTC)

Do You Know What a WeakReference Can Do to Your API?

References and WeakReferences play important role when designing an API contract or building a framework. Are you sure you use them properly? Read about problems we had when messing with WeakReferences in the Lookup API.

--JaroslavTulach 08:50, 11 October 2013 (UTC)

JDK8's Profiles in the Light of Harmony

A curious translator of my book asked me about project Harmony. That motivated me to sit down and write an incomplete and mostly wrong history of open source java implementations. While incomplete (for example it does not talk by whom Harmony was founded and why), it explains why JDK8 is/will be a huge step forward and what will be its most important feature. Btw. if you thought lamdas, you were wrong.

--JaroslavTulach 14:54, 12 August 2013 (UTC)

Cimrman's Planning

Short introduction to accurate, agile, modern, reliable, flexible, optimistic, forward looking, experience based, projective planning methodology.

--JaroslavTulach 15:10, 19 March 2013 (UTC)

Platón's Theory of Ideas for Developers

Those of you who heard about Platon in school probably also hard about his allegory of a cave (at least I did when I was at high school). It is not often easy to imagine what Platon meant by the cave, shadows, etc. Luckily (at least for developers who know what geometry is), there is a better explanation which which explains Platon's theory of ideas via geometry.

This geometric way of explaining [[ideas was much easier for me to swallow. That is why I decided to share it here.

--JaroslavTulach 08:45, 21 January 2013 (UTC)

On the fact that the Atlantic Ocean has two sides

Here are selected notes from my favorite write up by Edsger W. Dijkstra (the guy that invented semaphore). Few decades has passed since the initial publication and the difference between U.S. and Europe may not be as sharp anymore. Still, a lot of Dijkstra's comments apply - especially when it comes to the clash between programmers educated in soft vs. real science schools!

Btw. should this kind of analysis be found interesting, I can share another one: Why our U.S. friends can't read maps and are not aware of that. Just let me know if I should publish it.

--JaroslavTulach 11:56, 17 January 2013 (UTC)

Having a Hammer All Problems Look Like a Nail

A theoretical observation about a hammer with application to real world scenario as well as software user interface design.

--JaroslavTulach 13:37, 12 November 2012 (UTC)

TransitivityOfIncompatibleChange

A nice clash between real world and academic attempts to describe it can be seen on the case of TransitivityOfIncompatibleChange. While such transitivity is an easy to grasp concept, it is too simplistic and often too hard to apply for the real world of software dependencies. It took me a while to understand its alternative, but now I think I see it.

Last week I had a presentation about the topic of NP-Complete problems in module dependencies at MatFyz and one of the questions was: Why am I not using TransitivityOfIncompatibleChange in case of repositories with RangeDependencies? Well, I don't as it does not have a clear meaning. But the question forced me to sit and write the answer down.

Hopefully not only MatFyz guys find the essay useful.

--JaroslavTulach 02:00, 7 November 2012 (UTC)

Is Java a Language or a Framework?

Just a few thoughts about the difference between language and a framework (plus a wish how Java should evolve).

--JaroslavTulach 09:06, 18 October 2012 (UTC)

20 API Paradoxes Published!

Today I am ready to announce great news. My new book about 20 API Paradoxes is now publicly available. I'd like to thank everyone who helped me get it to e-readers all over the globe. Jeff corrected my English and made the structure of the book more consistent. Clay stopped me when I wanted to expand the scope and delay the publication. And, most importantly, Clay is responsible for this fantastic cover:

I asked Clay to select cover that would somehow reflect my relation with my home and I am glad he decided to use painting of Josef Lada - a painter of my childhood.

I hope you like the cover too. And not only that, I hope you'll like the content as well. Buy & enjoy!

--JaroslavTulach 18:11, 11 October 2012 (UTC)

100th Monkey Principle. Multicasting in a Nature?

James Borowski on 100th Monkey principle:

Found reading some stuff on your site really interesting. I have not finished reading yet, so, forgive me if you already know this, but I was reading the article DiamondsVsStars and wondered as I read your comments regarding the "something in the air" as people around the world all discover something at the same time, if you were aware of the 100th Monkey principle?

There are different versions of the tale, but essentially, there was an island with a load of monkeys that learnt a trait one at a time of how to knock nuts with a rock to get inside them (other versions of the story are about learning to wash them, but the principle is the same). It took a while for monkeys to copy each other, one at a time, and the speed of uptake was essentially linear and at a fixed rate until they reached the 100th Monkey. At this point, every monkey on the island, and every monkey on the three neighbouring islands all started the same trait, almost instantly. The point is: A species appears to be connected at some vibrational level to the extent that they share certain thought processes/notions. There is a tipping point (apparently this is the square route of 1% of the population pool / or 100 monkeys ) where once reached, this information is availiable to all. Almost as if an entire species are listening on the same multicast address.

Anyway, hope you find as interesting as I found your stuff. For more info see 100th Monkey at wikipedia.

Thanks, for sharing this observation, James!

--JaroslavTulach 19:29, 8 August 2012 (UTC)

How Strict a Backward Compatibility Should Be?

Here are some thoughts on the difference between 100% BackwardCompatibility and their slightly more practical variants.

--JaroslavTulach 12:13, 31 July 2012 (UTC)

OlderBlogPosts