Re: [fonc] The Language Barrier
You might find 'Software Integrated Circuits' and such interesting. I've worked with one such implementation (based on http://valleyofglen.com/SGlen_Chippery_Disseration.doc) and although we managed to deliver software with it, including a 'mobile charging platform' for a large telecoms operators in the Philippines, the concepts were foreign enough to most of the developers to not make it a successful platform. IMO creating software component based on 'chips' and assembling them in various configurations in a distributed, dynamic environment will do that to you unless you have good discipline, great tools and a clear vision of what/how to build 'components'. Cheers Carlo On 23 Aug 2011, at 6:09 PM, BGB wrote: IMO, building software could be more like, say, assembling a computer from parts (selecting, buying, and assembling various parts), or doing automotive customization (adding on different tires, fancy-looking hubcaps, a spoiler, under-lights, swapping out for a more powerful engine with dual-turbo or similar, or NOS, ...), just without the heavy/lifting aspects (yanking engine with an engine jack, ...) because manual lifting is lame (the analogue of the manual lifting in software is the large piles of code one often has to write to complete trivial tasks, and how abstract/distant/unrelated the code tends to be vs the task at hand). ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Language Barrier
You might also find David Harel's article Can Programming Be Liberated, Period? (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.3837) interesting. He takes quite a different approach to specification of system behavior, as well as programming in general. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Language Barrier
Here's another citation: http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingProgramming.pdf On Tue, Aug 23, 2011 at 9:39 AM, Dale Schumacher dale.schumac...@gmail.comwrote: You might also find David Harel's article Can Programming Be Liberated, Period? (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.3837) interesting. He takes quite a different approach to specification of system behavior, as well as programming in general. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Language Barrier
Have you seen Causeway? Sounds like it might be a start toward what you desire. http://www.erights.org/elang/tools/causeway/ Causeway is an open source postmortem distributed debugger for examining the behavior of distributed programs built as communicating event loops. Its message-oriented approach follows the flow of messages across process and machine boundaries. http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html An increasing number of developers face the difficult task of debugging distributed asynchronous programs. This trend has outpaced the development of adequate debugging tools and currently, the best option for many is an ad hoc patchwork of sequential tools and printf debugging. This paper presents Causeway, a postmortem distributed debugger that demonstrates a novel approach to understanding the behavior of a distributed program. Our message-oriented approach borrows an effective strategy from sequential debugging: To find the source of unintended side- effects, start with the chain of expressed intentions. We show how Causeway's integrated views - describing both distributed and sequential computation - help users navigate causal pathways as they pursue suspicions. We highlight Causeway's innovative features which include adaptive, customizable event abstraction mechanisms and graphical views that follow message flow across process and machine boundaries. Monty On Fri, Aug 19, 2011 at 3:26 PM, Casey Ransberger casey.obrie...@gmail.com wrote: At work there are generally a small pile of languages in play: a backend language (Perl and Java seem common here,) sometimes a separate language for the web front end, this has often been Ruby of late, a relational language (thus far always a SQL variant,) and the now ubiquitous Javascript. I test big web apps, usually. When I'm doing automation, I'm often frustrated by a language barrier. Sometimes I can get a lot of mileage out of a meta-object protocol in languages which have one. But as the application under test is regularly written in multiple languages, the places where different subcomponents connect are problematic, I lose this leverage here, because these languages don't share a MOP. In the future, I want to be able to have this cake and eat it too. I'm not sure what that looks like or even what to call it. Maybe it's a domain specific language for test automation, or perhaps more interestingly, a meta-meta-object protocol (TM!) I note that when my backend is written in Java, it still makes some sense to choose (of the company approved languages) e.g. Ruby to do the automation. More and more I just wish they'd let me use Lisp. This is partly because I'm typically outnumbered by line developers by a wide margin and want all of the leverage I can get. I wonder what people here would think about these ideas. Alex Warth mentioned an omnidebugger and I almost wonder if whatever approach works for that might work for this. Maybe a common intermediate representation is all I need to do it. -- Casey Ransberger ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
