tag:blogger.com,1999:blog-9620948.post6673890126817634425..comments2023-10-20T12:24:17.734-07:00Comments on Binstock on Software: Restarting the Platypus And the Lessons LearnedAndrew Binstockhttp://www.blogger.com/profile/16321156191558412680noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-9620948.post-55031676715609550102009-01-05T20:59:00.000-08:002009-01-05T20:59:00.000-08:00@Anonymous re Lout: When I started Platypus, Lout ...@Anonymous re Lout: When I started Platypus, Lout had been untouched for years by its developer, Jeffrey Kingston, and its output driver for PDF was broken. At the time, it was not a realistic option. <BR/><BR/>Lout has improved in the intervening period, as Kingston is more active once again. Lout is an improvement over troff and TeX, but it has constraints, which Platypus looks to transcend:<BR/><BR/>1) Lout emits only PostScript and text.<BR/>2) Lout has no scripting language.<BR/>3) Lout is advanced very slowly, with long gaps before bugs are fixed.<BR/>4) Lout has poor support for Windows.<BR/><BR/>#1 and #4 are deal-killers for me. And #2 is definitely problematic.<BR/><BR/>Still, as I said, it is an improvement over TeX and troff.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-83697097707510812442009-01-05T16:22:00.000-08:002009-01-05T16:22:00.000-08:00you might also look at lout.wiki.sourceforge.net w...you might also look at lout.wiki.sourceforge.net which is another typesetting system that addresses weaknesses in TeX.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-4140298715645139332008-08-06T15:26:00.000-07:002008-08-06T15:26:00.000-07:00i use itext's xml-scripting to produce a huge prod...i use itext's xml-scripting to produce a huge product-catalog which is a composition of text (descriptions), images and prices.<BR/><BR/>im not lucky with that and i guess that a platypus 1.0.x would be a much better hit of my needs ...<BR/><BR/>have you considered to integrate platypus with itext as a subproject/module or associated project ? i believe this would give it's polularity a boost.<BR/><BR/>i also use groovy which IMO is a much better choice than JS. but be warned. groovy makes things easy only if you have reached a certain level of knowledge. beyond that level is loss.<BR/><BR/>have a nice time !Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-87237650672317865292008-06-11T09:36:00.000-07:002008-06-11T09:36:00.000-07:00@ittay Interesting you should mention Gradle. I am...@ittay Interesting you should mention Gradle. I am in the process of evaluating it. Initial results looks promising. Thanks for the post.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-13779327029306410782008-06-11T03:31:00.000-07:002008-06-11T03:31:00.000-07:00I think the gradle project got things right:1. you...I think the gradle project got things right:<BR/><BR/>1. you can easily use any ant task<BR/>2. there's a model for defining dependencies, that uses ivy<BR/>3. plugins can provide model objects a-la maven's pom. they can also provide standard targets (so to build a standard jar, your build file is just 'usePlugin("java")'.<BR/>4. you can rewrite any target<BR/>5. each module has an object representing it. then, in the root build file (or any module's build file) you can manipulate these objects, rather than needing to create a build file in each (even if it is just 5 lines). but, if you do have a build file, it inherits methods & variables from its parent (the one that defined to use it).<BR/>6. build scripts are groovy, so you have methods, control structures etc.<BR/>7. cross module target dependencies. so you can generate sources in module M1, then compile module M2, then compile module M1.Ittay Drorhttps://www.blogger.com/profile/06786072335349487451noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-43524516580756572942008-04-16T21:15:00.000-07:002008-04-16T21:15:00.000-07:00I've been following the project for a while, it's ...I've been following the project for a while, it's unfortunate that the project has to be restarted from the ground up but I'm still excited about using Platypus in the future. Anyway best of luck on the project, I'm looking forward to testing the new releases!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-13299509316061391212008-04-12T17:55:00.000-07:002008-04-12T17:55:00.000-07:00You need not post this, but just as some additiona...You need not post this, but just as some additional comments - if you think about it the internet is just one giant specification.<BR/>Implementations come and go, but the spec is stable. There are 1000s of web server implementations, but there is only on specification.<BR/>RFC's never deal with implementations, only with what gets done, not how.<BR/><BR/>Moral: Spend more time up front creating good specification for your project, and it will have a long life. Implementations may come and go, but a good design lives on.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-89686828613180630382008-03-31T00:03:00.000-07:002008-03-31T00:03:00.000-07:00@anonymous. Thanks for your follow-up post. Your c...@anonymous. Thanks for your follow-up post. Your comments had the effect of making me get around to updating the requirements doc from my various notes. I've now posted the revised reqs on the Platypus site at: http://platypus.pz.org/PlatypusFunctionalRequirements-v2.01.pdf<BR/><BR/>You're right that I should also post the interfaces, especially for the plug-ins. I am still working on these and so won't have them posted for a little bit yet.<BR/><BR/>Thanks for the push to get this info published on the site.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-24575342900601681612008-03-29T12:47:00.000-07:002008-03-29T12:47:00.000-07:00Ok, now I have to ask, why have you not done any v...Ok, now I have to ask, why have you not done any visible design work.<BR/><BR/>I can't find even a high level design. While I am not a proponent of death by analysis, you do need some.<BR/><BR/>But how can any design be done when there is no functional specification? I am not a typesetting domain expert, I am a software engineer.<BR/><BR/><BR/>I hardly think typesetting is a moving target as far as a specification. Right now you need to stop and create a detailed specification that defines exactly what the program will DO specifically. Sorry, "but typesetting like TeX but better" won't work as a functional specification.<BR/>If I were to decide I wanted to help, I would have no idea how I could help you.<BR/>Then after you have a specification, which should not in any way address HOW it will be done, you should then create a design that at least names the components that are responsible for implementing the features in the specification.<BR/>After the the high level design is done, you need to define the interfaces between the components.<BR/>With no mention of how those components will work.<BR/><BR/>I know you know all this, and yet you haven't done it. Until you do you will just be drifting. You are way too caught up in tools and implementations, and I think you are not addressing the big picture. <BR/><BR/>If you do as I suggest, you will find it much easier to get help as well. If you have this design with clear interfaces, others can go off and build pieces of it. You must have a team if you ever expect to achieve this goal.<BR/><BR/>You know it's like that letter to the editor about patterns - he expected a pattern was a substitute for a specification. Even if his co-worker had know the facade pattern he still would not have gotten the API he wanted. (another big problem with patterns).<BR/><BR/>A pattern is not a specification, it is a means of implementing a specification.<BR/>The design follows the specification, the implementation follows the design.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-40090887140196292972008-03-27T13:38:00.000-07:002008-03-27T13:38:00.000-07:00@anonymous Thanks for a very thoughtful post. I ap...@anonymous Thanks for a very thoughtful post. I appreciate your comments.<BR/><BR/>Agreed that if Platypus simply replaces TeX, it has little value. The legacy TeX crowd is not about to switch. <BR/><BR/>However, Platypus aims to go beyond the TeX document use case and address the following:<BR/><BR/>1) lack of tools for developers. Especially the lack of tools for documentation, which I believe is one of the key factors that so many projects have such poor or non-existent docs. The ability to handle code intelligently, provide special support for listings, and to create docs in PDF, HTML, and other formats should also help in using Platypus for documentation.<BR/><BR/>2) templating: Data fields can be read from a file and loaded into the document, enabling the creation of reports as well as live documents.<BR/><BR/>The graphical front-end will need to be addressed at some point. First with a Platypus-friendly editor and possibly eventually a GUI tool. Possibly LyX modified to output Platypus. That's a bit down the road at the moment, but I agree it's important.<BR/><BR/>The time frame for Platypus should be more favorable to me than it was to Knuth with TeX. He was starting from scratch. I can (and do) ride on his shoulders; plus he had to invent a whole font system, which is not an issue for me. Moreover, there are excellent back-end libraries for PDF document creation, as well as for other formats. Still, to succeed, other developers will surely need to participate in Platypus.<BR/><BR/>I am coming around to your opinion on JS, and am now looking more closely at Groovy as the language for scripting. Fortunately, there are choices ;-)Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-19102598549901387132008-03-26T19:01:00.000-07:002008-03-26T19:01:00.000-07:00While it is a admirable project to do a follow on ...While it is a admirable project to do a follow on th TeX, I have to wonder who will use it?<BR/>While there is a user base for TeX it seems that they are mostly, shall we say, "legacy" users.<BR/>One would think that the next generation of academicians would be more inclined to use a graphical interface. <BR/>Also, there is the matter of time frame. It took Knuth the better part of 10 years just to get the basic program done. It does not seem much more efficient than he.<BR/>What will be useful 10 years from now?<BR/>Last, I would never consider using JS. While it is a widely know language, and it is easy to put in, I don't see that it is particularly applicable. <BR/>These are just my thoughts, and I would be interested in your opinion.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9620948.post-92155696235250449952008-02-22T12:21:00.000-08:002008-02-22T12:21:00.000-08:00No, I haven't. Java has better tools than JS; I kn...No, I haven't. Java has better tools than JS; I know Java better; and by staying with Java, I can reuse some of the code that's already been written. That being said, if I can find a way to unit-test JS-based routines and they don't cause too much havoc in terms of performance and memory consumption, I am likely to use JS for implementing some commands.Andrew Binstockhttps://www.blogger.com/profile/16321156191558412680noreply@blogger.comtag:blogger.com,1999:blog-9620948.post-547938019900775892008-02-21T19:29:00.000-08:002008-02-21T19:29:00.000-08:00Since you are using JavaScript as the internal com...Since you are using JavaScript as the internal command language, have you considered "going Rhino" for the whole shebang?Anonymousnoreply@blogger.com