Tweets for 2010-08-29
- Really unfortunate! RT @newsycombinator: IPhone App in Approval Limbo for 3 Mths, Dev Decides to Open Source It http://j.mp/c2m51z #
- Some useful thoughts. Projects are evil and must be destroyed http://ff.im/-pSjcI #
- An Example of Multithreaded Processing using Python's "multiprocessing" Module http://ff.im/-pSjuo #
- Will we see more of these now? Paul Allen Sues Apple, Google, Others Over Patents http://ff.im/-pSjOY #
- Random thoughts on Clojure Protocols http://ff.im/-pSk6M #
- RT @ptrthomas: #agile RT @wakaleo: RT @evanbottcher: Holy crap. Brilliant. http://www.halfarsedagilemanifesto.org/ (via @jamesladd) #
- Ladies. Look at your code. (on lambdas and JDK 7) http://ff.im/-pSn6o #
- RT @jneira: skilldrick.co.uk ยป Static typing: the presumption of guilt http://bit.ly/a8A60K #
- Evan Bottcher: DevOps and the Iteration Showcase http://ff.im/-pSYhN #
- I like this notion of thinking of OODA loop http://is.gd/eJMsZ time. You perhaps cycle fastest in your favourite lang? (via @debasishg) #
- @psnively I thought parts of it were a little strange. eg. "more reliable is a myth". His comment on metaprogramming was right on in reply to psnively #
- @psnively I believe static typing more reliable than dynamic, but there is a flexibility tradeoff. Different folks weigh them differently. in reply to psnively #
- @psnively That one is beyond my knowledge sphere. But it would be interesting to find out how metaprogramming works in that context. in reply to psnively #
- @psnively I assuming you were saying that in half jest, 'cos I very firmly believe thats not true. in reply to psnively #
- @psnively If I could buy "fooling myself" insurance / cover. I would always buy it regardless of my position /cc @jteigen @kaleidic in reply to psnively #
- @jteigen unit testing is a strange topic that always enters the typing debates – something imo isn't a central aspect to the choice. in reply to jteigen #
- @jteigen I suspect most dynamic type proponents don't actually write all the unit tests it would take to provide a iron clad assurance in reply to jteigen #
- @psnively Not quite. I buy life cover since the stakes are high, but rarely if ever extended warranties based on the economic tradeoffs. in reply to psnively #
- @psnively A example is people externalising metadata (to XML?) when using static langs and then feeling happy about the productivity gains in reply to psnively #
- @psnively I'm going to have to read up on that one. Will revert later. in reply to psnively #
- @psnively Much Ruby s/w out there where people not looking 4 that insurance. I shall continue to sit on the fence n say no 1 right way
in reply to psnively # - @psnively I am not convinced of all his statements eg. Reliability, Refactoring. Some say thats 'cos I haven't seen power of smalltalk tools in reply to psnively #
- @psnively As a java dev I used to feel utterly jealous of python/ruby 4 their natural expression. I guess that changed after Scala @kaleidic in reply to psnively #
- @kaleidic Whoa! in my experience the darling of financial sector is Java. No one. Repeat – no one comes even remotely close /cc @psnively in reply to kaleidic #
- @psnively On the face of it Camlp4 is a preprocessor. I would imagine one could implement something similar 2 implement metalinguistic (1/2) in reply to psnively #
- @psnively abstractions for java. But thats going to be unnatural and the preprocessed language probably is dynamically typed (2/2) in reply to psnively #
- @psnively I would still imagine python/ruby/javascript/clojure provide much more natural and integrated metaprogramming capabilities in reply to psnively #
- @psnively Hypothesis: Most static langs don't treat metalinguistic abstraction because they can't implement a statically typed preprocessor. in reply to psnively #
- @psnively Sorry I didn't see your camlp4/metaocaml tweet before my last tweet. Am back digging into details
in reply to psnively # - @psnively imo dyn typed langs allow me to "program ahead" to a type I only partially know, or doesn't exist & will get created @ runtime in reply to psnively #
- @psnively If I understood metalinguistic abstractions properly, homoiconicity would be a "higher goal", but not mandatory. in reply to psnively #
- @psnively my understanding of dyn languages is they allow "internal DSLs" whereas (perhaps) camlp4 allows construction of "external DSLs" ?? in reply to psnively #
- @psnively afaik, type inferencing will allow binding only if to a known interface, will not allow or bind to types on the fly at runtime in reply to psnively #
- @psnively you've educated me on an interesting possibility thats going to take some time to follow up on. in reply to psnively #
- @vdichev count me in as one of those
in reply to vdichev # - @jteigen ahh.. understood. in reply to jteigen #
- @psnively Yes and in nonhomoiconic python / ruby one can invoke methods on types which are metalinguistic abstractions(?) created @ runtime in reply to psnively #
- @fogus sorry, I used it just a tad loosely. But allow me to explain. In python/ruby, one can use metaclasses and build a dsl around it (1/2) in reply to fogus #
- @fogus to express new type construction, and usage of such types (internal). Play framework does it thru bytecode @ startup (external) in reply to fogus #
- @fogus Other examples of external would be preprocessor macros (not the lisp kind). Scala DSLs afaik will not allow new type construction in reply to fogus #
- @debasishg Yes, Lisp, PlayFramework (bytecode on fly), camlp4 are different than cpp macro model, which defy clear classification @psnively in reply to debasishg #
- @debasishg I take back my statement on Lisp .. thats actually clearly understood as a read cycle macro at runtime not compiletime @psnively in reply to debasishg #
- @jneira what does uau and jum stand for ? in reply to jneira #
- @jneira thanks .. you had me hunting all over the internet acronym finders
in reply to jneira #