Excel
From APIDesign
Line 1: | Line 1: | ||
[[wikipedia:Microsoft_Excel|Excel]] is almost a synonymum for any spreadsheet program. An example where a product name became de-facto name for the whole technology. I have never learned how to use [[Excel]] (or rather [[OpenOffice]] Calc) effectively, but I know that non-programmers can do quite amazing things with it. | [[wikipedia:Microsoft_Excel|Excel]] is almost a synonymum for any spreadsheet program. An example where a product name became de-facto name for the whole technology. I have never learned how to use [[Excel]] (or rather [[OpenOffice]] Calc) effectively, but I know that non-programmers can do quite amazing things with it. | ||
- | [[Cluelessness]] is always a goal for any technology vendor. Everyone wants to provide | + | [[Cluelessness]] is always a goal for any technology vendor. Everyone wants to provide [[good technology]] which is easy to use and easy to get productive with. Everyone seeks such [[wikipedia:Holy_grail|holy grail]]. [[Excel]] got quite close. It managed to allow non-programmers to be productive with computers without learning what are the '''if''' or '''while''' or '''for''' statements. |
- | [[Rich Unger]] mentioned [[Excel]] few times during our [[DSL]] presentation at [[JavaOne2010]]. Rich said that his company had to design [[Apex]] in order to attract people that are familiar with [[Excel]], but are intimidated with [[Java]]. Actually when we (and also our audience) tried to summarize when to use [[DSL]]s (Rich's side of the shootout) and when to | + | === [[DSL]] or Library? === |
+ | |||
+ | [[Rich Unger]] mentioned [[Excel]] few times during our [[DSL]] presentation at [[JavaOne2010]]. Rich said that his company had to design [[Apex]] in order to attract people that are familiar with [[Excel]], but are intimidated with [[Java]]. Actually when we (and also our audience) tried to summarize when to use [[DSL]]s (Rich's side of the shootout) and when to write libraries ([[User:JaroslavTulach|my]] advice), we agreed that it basically depends on whether you are targeting ([[Java]]) programmers or not. For people with [[Excel]] knowledge the [[Apex]] was said to be a better fit. | ||
Our talk was supposed to be a shootout and I used strong [[wikipedia:Trash_talk|trash talk]] while preparing with Rich, but during the talk we treated each other with mutual respect. I somehow started to believe that Rich's ''[[excel]] argument'' is true. [[Apex]] was the language for [[Excel]] audience and it deserved its right to be a [[DSL]], not a library (as the [[TheAPIBook]] would advocate). We ended up our talk in complete reunion. | Our talk was supposed to be a shootout and I used strong [[wikipedia:Trash_talk|trash talk]] while preparing with Rich, but during the talk we treated each other with mutual respect. I somehow started to believe that Rich's ''[[excel]] argument'' is true. [[Apex]] was the language for [[Excel]] audience and it deserved its right to be a [[DSL]], not a library (as the [[TheAPIBook]] would advocate). We ended up our talk in complete reunion. | ||
- | + | === Unit Test [[Excel]] Formulas! === | |
+ | However later, when we were celebrating our successful presentation at ''The Chieftains'' irish pub we got to the topic of testing. We touched [[Apex]] again and I mentioned that I can't imagine someone writing unit tests in [[Apex]]. Rich replied that it is not true, people do write unit tests in [[Apex]]. I was shocked. I could not have imagined someone using [[Excel]] to write unit tests. Was [[Apex]] not supposed to be the language for [[Excel]] people, [[Rich]]? | ||
- | It turned out that in fact, if you want to use [[Apex]] and deploy your application, the system measures the percentage of unit tests written by you and it rejects any changes until you reach 75% of test coverage. That indeed implies that [[Apex]] is a language suitable for writing unit tests. But that also means that [[Apex]] is not a language for [[Excel]] people. That | + | It turned out that in fact, if you want to use [[Apex]] and deploy your application, the system measures the percentage of unit tests written by you and it rejects any changes until you reach 75% of test coverage. That indeed implies that [[Apex]] is a language suitable for writing unit tests. But that also means that [[Apex]] is not a language for [[Excel]] people. That may be a marketing goal or a vision, but not a reality. Just show me a regular [[excel]] user that can write unit tests! Those guys don't even know what a test it! |
During the whole talk about [[DSL]]s vs. Library [[APIDesignPatterns|design]] I tried to argue that the important thing is to create a library to wrap your functionality, the [[DSL]] is (at most) an additional wrapper to support more [[cluelessness]]. Rich tried to argue, that the library is not needed at all, that a [[DSL]] is enough. But in the light of those 75% unit test coverage, this is just a marketing dream, not a reality. Rich's company made an incorrect (technically, not from a marketing perspective) decision in the past to create their own [[DSL]] instead of producing a library in [[Java]] to access the same functionality. They have to stick to that decision (and even send [[Rich]] to talk about that), but to support other bussiness needs they give up on such level of [[cluelessness]] and their users to write tests (for [[good]] reasons which I agree with). However the whole story leaves quite a negative smell of [[doublethink]], don't you think? | During the whole talk about [[DSL]]s vs. Library [[APIDesignPatterns|design]] I tried to argue that the important thing is to create a library to wrap your functionality, the [[DSL]] is (at most) an additional wrapper to support more [[cluelessness]]. Rich tried to argue, that the library is not needed at all, that a [[DSL]] is enough. But in the light of those 75% unit test coverage, this is just a marketing dream, not a reality. Rich's company made an incorrect (technically, not from a marketing perspective) decision in the past to create their own [[DSL]] instead of producing a library in [[Java]] to access the same functionality. They have to stick to that decision (and even send [[Rich]] to talk about that), but to support other bussiness needs they give up on such level of [[cluelessness]] and their users to write tests (for [[good]] reasons which I agree with). However the whole story leaves quite a negative smell of [[doublethink]], don't you think? | ||
In spite of all my [[wikipedia:Trash_talk|trash talk]], my goal was never to say that [[DSL]]s are bad. My goal was to show that [[Java]] has amusing power too (see the [[LiveDB]] demo to agree). However if I knew all I know now, I would not let it be a tie! All the [[Rich]]'s [[excel]] like arguments worth not a penny! I should have [[Rich]] out of the stage. But too late, the only thing I can do about that now is to [[excel|blog about that]]. | In spite of all my [[wikipedia:Trash_talk|trash talk]], my goal was never to say that [[DSL]]s are bad. My goal was to show that [[Java]] has amusing power too (see the [[LiveDB]] demo to agree). However if I knew all I know now, I would not let it be a tie! All the [[Rich]]'s [[excel]] like arguments worth not a penny! I should have [[Rich]] out of the stage. But too late, the only thing I can do about that now is to [[excel|blog about that]]. |
Revision as of 11:46, 25 October 2010
Excel is almost a synonymum for any spreadsheet program. An example where a product name became de-facto name for the whole technology. I have never learned how to use Excel (or rather OpenOffice Calc) effectively, but I know that non-programmers can do quite amazing things with it.
Cluelessness is always a goal for any technology vendor. Everyone wants to provide good technology which is easy to use and easy to get productive with. Everyone seeks such holy grail. Excel got quite close. It managed to allow non-programmers to be productive with computers without learning what are the if or while or for statements.
DSL or Library?
Rich Unger mentioned Excel few times during our DSL presentation at JavaOne2010. Rich said that his company had to design Apex in order to attract people that are familiar with Excel, but are intimidated with Java. Actually when we (and also our audience) tried to summarize when to use DSLs (Rich's side of the shootout) and when to write libraries (my advice), we agreed that it basically depends on whether you are targeting (Java) programmers or not. For people with Excel knowledge the Apex was said to be a better fit.
Our talk was supposed to be a shootout and I used strong trash talk while preparing with Rich, but during the talk we treated each other with mutual respect. I somehow started to believe that Rich's excel argument is true. Apex was the language for Excel audience and it deserved its right to be a DSL, not a library (as the TheAPIBook would advocate). We ended up our talk in complete reunion.
Unit Test Excel Formulas!
However later, when we were celebrating our successful presentation at The Chieftains irish pub we got to the topic of testing. We touched Apex again and I mentioned that I can't imagine someone writing unit tests in Apex. Rich replied that it is not true, people do write unit tests in Apex. I was shocked. I could not have imagined someone using Excel to write unit tests. Was Apex not supposed to be the language for Excel people, Rich?
It turned out that in fact, if you want to use Apex and deploy your application, the system measures the percentage of unit tests written by you and it rejects any changes until you reach 75% of test coverage. That indeed implies that Apex is a language suitable for writing unit tests. But that also means that Apex is not a language for Excel people. That may be a marketing goal or a vision, but not a reality. Just show me a regular excel user that can write unit tests! Those guys don't even know what a test it!
During the whole talk about DSLs vs. Library design I tried to argue that the important thing is to create a library to wrap your functionality, the DSL is (at most) an additional wrapper to support more cluelessness. Rich tried to argue, that the library is not needed at all, that a DSL is enough. But in the light of those 75% unit test coverage, this is just a marketing dream, not a reality. Rich's company made an incorrect (technically, not from a marketing perspective) decision in the past to create their own DSL instead of producing a library in Java to access the same functionality. They have to stick to that decision (and even send Rich to talk about that), but to support other bussiness needs they give up on such level of cluelessness and their users to write tests (for good reasons which I agree with). However the whole story leaves quite a negative smell of doublethink, don't you think?
In spite of all my trash talk, my goal was never to say that DSLs are bad. My goal was to show that Java has amusing power too (see the LiveDB demo to agree). However if I knew all I know now, I would not let it be a tie! All the Rich's excel like arguments worth not a penny! I should have Rich out of the stage. But too late, the only thing I can do about that now is to blog about that.