archive-org.com » ORG » A » ALARMINGDEVELOPMENT.ORG

Total: 134

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • An IDE is not enough
    am Permalink The problem with semantic structure editors is as you say that they are hard I saw this first hand when I was working at Intentional Software the software is magical but extraordinarily complex The challenge is twofold how do you build such a complex piece of software but also how do you hide this complexity while allowing developers to be productive in both using and extending it The first challenge building such a thing is hard enough I have very little hope we will see the second challenge being risen to until there are a few working systems available that are cumbersome and hard to use We re not even there yet so I am skeptical I will still be alive when the great structural editor renaissance comes to be Geoff Posted April 30 2012 at 4 45 pm Permalink Building a structural editor is certainly challenging I have been working on such a project myself recently Your experience at Intentional is interesting you said that the second challenge is particularly tough How does the usability of Intentional s code editor compare to that of Jetbrains MPS Does it manage to emulate the free form interface of a text editor successfully or do you have to learn a new set of interactions to use it Hope you don t mind me asking I am very curious about these things Jake Brownson Posted April 30 2012 at 5 15 pm Permalink Hey Geoff I also have worked at ISC not at the same time as Greg I m not sure we ve ever met maybe we should fix that Greg I ve also used MPS quite a bit recently Emulating a text editor isn t one of the values of ISC s editor and I think that s the right decision ultimately though to get people to try it you might need at least one projection that does emulate a text editor I find editing using either ISC s editor or MPS very quick I d be interested to hear more about your project Even if it s in super early stages You can email me if you want to take this offline so to speak jbrownson gmail com Greg Posted May 1 2012 at 5 03 pm Permalink I probably can t talk too much about ISC s editor but as Jake says it was altogether a different experience at the time than using a traditional text editor It was fast once you got used to the shift When I referred to complexity it wasn t about its usability as an editor As an editor when all is set up and your languages are in place it s quite fine The complexity comes into play just by the nature of what you are dealing with since the medium itself is more complex than raw text This wasn t really a dig saying its complex is the same as saying the space shuttle is complex it s a necessary condition based upon the environment being worked in The open question to me is if this is necessary complexity or incidental complexity within the problem space of domain driven design So far it seems necessary but I m not going to bet against someone coming up with a worse is better solution that gets you 80 of the way there with much less complexity involved I ve certainly racked my brain trying but have failed to come up with anything that doesn t make me weak in the knees when setting out trying to build such a thing Jonathan Edwards Posted May 1 2012 at 5 19 pm Permalink I have been bugging ISC for a long time to publish their work By many accounts they have the best structure editor ever built but only sketchy details have been revealed They almost did an Onward paper this year so I ll keep trying Personally I think LISP had the right idea it s just that S expressions aren t expressive enough Jake Brownson Posted May 1 2012 at 5 22 pm Permalink Gah disappointing to hear they didn t follow through on Onward Greg Posted May 1 2012 at 5 23 pm Permalink Yeah I am pretty pumped about LightTable When I get my grubby hands on it the first thing I will be doing is seeing how hard it is to turn it into a projectional editor of s expressions raw text on left higher level read only projection on right Geoff Posted May 2 2012 at 4 12 am Permalink I have just hastily prepared a video of my syntax recognizing structure editor that I have built as part of my project The Larch Environment Here http www youtube com watch v cURRW6usg2E While the Larch editor operates on a structural data model it editor behaves much like a normal text editor so it should operate in a fashion familiar to most programmers Jonathan Edwards Posted May 2 2012 at 8 28 am Permalink Thanks Geoff Larch looks very highly developed I am interested in why you built a Python environment in Java More importantly what have you learned What are the technically hard parts and unsolved open problems How do people react to it Geoff Posted May 2 2012 at 12 13 pm Permalink Thank you for your compliments I targeted Python because its a nice language that I got to like It was originally pure Python but performance problems pushed me to implement much of it in another faster language I chose Java As for what I have learned I built a pure structure editor early on in which all edit operations were structure oriented Keyboard short cuts were used to create ifs whiles fors etc while specific key presses etc wrapped expressions in operators It was a bit faster to use than an equation editor I found that it was an interesting prototype but essentially useless So I followed in the footsteps of Andrew Ko s Barista and made a syntax recognizing editor to replace it I find this to be a very acceptable compromise The text editor style behaviour should ensure that it is not completely alien to existing programmers and should make adoption easier while still retaining the benefits of structural model A Python structure editor is not the valuable in and as of itself the main value comes from avenues for further work Structural models allow you to properly embed languages within one another instead of putting the embedded language within a comment or string of the host language They also provide opportunities to enhance the presentation of difficult Having the ability to construct visual representations of objects throughout the system is also very valuable Dynamic languages such as Python are useful because you can immediately compile and execute code and they are very flexible This allowed me to build my Notebook interface Technically hard parts Getting a syntax recognizing structure editor to the point where it is usable Quite a lot of effort went into this along with the effort required to develop the presentation GUI system that supports it Unsolved open problems Integration with existing tools like version control etc I have demoed Larch at Python conferences Europython 2011 PyCon UK 2011 and PyCon Ireland 2011 and the questions have often centred around how do I use this with existing text based projects Unfortunately there is a lot of text based code out there which people can t throw away they have to continue to build upon it People who would like to use my editor often have to work with others who refuse to leave emacs vi etc As a consequence allowing Larch to interoperate with these existing ecosystems is almost certainly a requirement I think that the two problems that need to be addressed are 1 Integration with text based projects export to text in such a way that it will minimise the diff s it will create to avoid sending your version control software crazy 2 Direct version control at the object AST level so that you can at least do version control if you are willing to abandon text People s reaction Peoples reaction has been mostly positive They would like to use it but can t yet see how it will fit into their current workflow This is quite understandable it doesn t play well with external tools yet Yifan Posted April 30 2012 at 12 55 pm Permalink The idea is not crazy at all Why are we using files in programming Because it is portable Why we program the same way as before why we call it programming language At beginning programmer has to remember every thing now you don t have to at least for some tasks It makes sense to start something completely new Roel Wuyts Posted May 3 2012 at 7 54 am Permalink I never program with files conceptually I program with objects when I m doing OO or functions when it is functional or predicates when it is Prolog None of these are files I consider it very unfortunate that in almost all programming languages files have an implicit or explicit influence on the semantics Therefore I have to think about files as compilation units Note that it should not necessarily be like that but in most cases it is For an exception in OO languages look at Smalltalk or Self There you work all the time with objects and textual representations of Objects so the coding itself is still purely textual not with files You can store programs as files if you want to but that is only for storage in the mindset of most Smalltalkers even though there is no problem editing this file and then loading it back in which most Smalltalker would consider stone age development Regarding portability as a storage medium files are portable Why would this make them good for editing Do molecular biologists use files to edit their molecules Do architects use files to work or their buildings or 3D editors Etc Mr Handy Posted April 30 2012 at 1 21 pm Permalink Why is there an apostrophe in IDEs It s not possessive You re right it seems most authorities agree on that Except the New York Times Jonathan Mark M Posted April 30 2012 at 1 35 pm Permalink Another is getting rid of source text files I agree relying on text files and the file system seems like a very 20th century technology to me Text files and the file system leak a tremendous amount of interesting information There was a time when storage limitations made this a reasonable tradeoff Nowadays there s no reason not to store programs in different formats saijanai Posted April 30 2012 at 3 10 pm Permalink Take a look at the Spoon project for Smalltalk http www netjam org spoon Sebastian Posted May 1 2012 at 2 10 pm Permalink I like text files because pragmatically all I need is a text editor to at least be able to see the code and when it s three in the morning you are working with someone else s code and you aren t even sure which language it was written in then NotePad or cat are your friends I shudder when I remember reverse engineering a binary file because someone left and destroyed the source How will I interact with these semantic structure editors Will it be an OS level tool David Barbour Posted May 1 2012 at 3 45 pm Permalink Your concern is valid We want our code to be accessible and portable We don t want our code locked up in proprietary binary formats subject to administrative whims beyond our control But I believe we can address those concerns without limiting ourselves to text editors We just need transparent structure and open standards for access e g SQL or XML or JSON for structure and odbc or HTTP or a mongo or git protocol for access These days there wouldn t be a problem creating web services for programming even on the client side Browsers are as widely accessible as text editors Think about it Jake Brownson Posted May 1 2012 at 3 49 pm Permalink I agree It s easy to forget that text files are binary files too It s just a really widespread standard with many editors available I think we need a similarly strong format that we can use to edit structure XML is nice but its design is constrained by the requirement it sits on top of text Part of the standard will likely need to be a schema DSL and projection DSL that describes specific data domains as well as having general purpose projections that can display anything Peter Wilson Posted May 1 2012 at 9 56 pm Permalink The debate about text vs binary storage is pointless As as been pointed out text is just another binary format with lots of editors It is easy to conceive of a text format which simplifies parsing and refactoring for an IDE Say every variable method definition is followed by a GUID and thereafter every reference is to the GUID Method overloading is moot renaming is trivial I sure would not want to program directly in such a language but a suitable editor would work and so would all the source control tools The problem is not the storage medium it is the archaic things we store Jonathan Edwards Posted May 1 2012 at 10 19 pm Permalink That is a key point Peter A major problem with textual languages is that they assume identifiers are identified by their spelling In Subtext I am in fact using unique IDs with an associated non unique name This requires a fancy editor to be usable But when you do this you realize that much of the standard class module constructs are all about resolving name clashes and suddenly become obsolete What exactly to replace them with is not immediately obvious though Jake Brownson Posted May 1 2012 at 10 59 pm Permalink 1 strong identities are a key part of the solution to this problem David Barbour Posted May 1 2012 at 11 09 pm Permalink Or you could pursue modularity without names Philo Posted April 30 2012 at 2 00 pm Permalink I think it s funny that a video about usability is hosted in a video player that has a progress bar that can be manipulated but doesn t actually do anything Jake Brownson Posted April 30 2012 at 2 43 pm Permalink Yes It s such a pet peeve of mine how awful web video players are Jamie Scanlon Posted April 30 2012 at 2 02 pm Permalink So your argument is that since IDE s shouldn t be used because they can never be perfect I would argue that the reason that IDE s exist is that text editors are such a pain in the ass to learn configure and use And I don t buy the argument that we have to program in descendants of text editors I would remind you that these things are COMPUTERS We tell them what to do not the other way around saijanai Posted April 30 2012 at 2 08 pm Permalink IDEs originated with Smalltalk While it is true that IDEs for non reflective languages have the limitations that you suggest the IDE for Smalltalk evolved along with the language itself which in turn evolved along with the virtual machine that is the target of the Smalltalk compiler The GUI found in current Smalltalk IDEs is very primitive compared to what can be done The folks behind Pharo Smalltalk are currently exploring how to move the GUI to OpenGL This will enable the creation of many new kinds of IDEs Projects like SiliconSqueak which are creating CPUs designed around fully or at least highly reflective languages and designed to scale to mega multi processor systems conceivably programmed by multiple people working on the same application at the same time will require new kinds of IDEs that will make current concepts obsolete Tycho Posted April 30 2012 at 2 41 pm Permalink There are extra rather a lot of people who would like to entertain these crazy ideas and I think they all read your blog I agree with your feelings though about IDEs and I find it really disappointing not many more people are attempting revolutionary things It s all so careful spineless We haven t progressed much since high level programming languages were invented and that accounts for the small jumps in productivity and fairly constant bugs per line of code counts I do believe it s good these kind of projects we are seeing now are getting a lot of attention people might admit something is off David Barbour Posted April 30 2012 at 2 56 pm Permalink For some problems or domains text is an excellent way to program And even in cases where it is not we ll generally want a well defined serialization format to share code between developers The use of files is a bit awkward especially in this Internet 2 0 era I d think more people would have built languages upon wikis and web services by now Compilers as web services and IDEs as web applications seems quite viable and useful I would prefer the choice of surface structure be made by the user on a per module basis Originally I thought more in terms of extensible syntax but that s a mistake because extending the language importing fexprs etc itself becomes a form of per module boiler plate Best keep syntax spec to one small line or attribute per module Graphical or structured editing would be one way for an IDE to present and manipulate code in modules that have suitable languages The fundamental reason IDEs have dead ended is that they are constrained by the syntax and semantics of our programming languages Well this isn t quite true It is not unusual to build IDEs atop frameworks rather than atop languages and rely on some programmer discipline to cover any gaps e g make sure all your methods terminate For example we can understand Croquet as an IDE for Smalltalk atop the Teatime framework And I shouldn t have to mention IDEs for various Java Beans and ESB frameworks Where a language can help is improving robustness reducing the need for self discipline and boiler plate What about mutable state What about I O What about non determinism and asynchrony I agree we need better ways to handle these for live programming especially in open systems One valuable observation is that we must push state outside our programs if we wish to replace arbitrary parts of our programs without losing or damaging accumulated information I ve developed several suitable state models for my RDP paradigm They look pretty in cherry picked examples but they don t work for the whole range and scale of real world programs I agree The gaming example of manipulating physics to make a jump seems especially awful given that in a real game you d have to rerun the whole level with the new physics possibly multiple levels Jake Brownson Posted April 30 2012 at 5 04 pm Permalink Okay that s it I ve seen enough references to Inform 7 recently that I need to read something about it Sean McDirmid Posted April 30 2012 at 6 47 pm Permalink David I don t think you d have to rerun the whole level When we are testing simulations we often create a smaller dare I say unit test case that establishes the context needed to test a feature You don t program the game en masse and you won t run whole levels until you are doing integration testing at which case live coding and visualization isn t as useful anyways David Barbour Posted April 30 2012 at 7 03 pm Permalink If you had local gravity values e g based on each platform you re leaping from perhaps you could get by with unit testing Otherwise a tweak in gravity to make a leap at platform 108 will require you to test whether you can still make the leaps for platforms 1 107 Unfortunately making gravity a local parameter has terrible gameplay implications unless carefully integrated into the gameplay mechanic Even having a different gravity value per level is pushing it Physics is generally not a local property subject to easy unit tests There are many features that can readily be tested locally But I was harping specifically on the manipulation of physics Sean McDirmid Posted April 30 2012 at 7 31 pm Permalink You can test physics with a small controlled case of a limited number of frames Replay actually doesn t require any resources since the initial context is provided by the test case you can then record and memoize a few minutes to get some omniscient debugging if you want David Barbour Posted April 30 2012 at 7 46 pm Permalink This isn t about testing physics Sean It s about testing whether a level is still playable after changing the physics Sean McDirmid Posted April 30 2012 at 7 56 pm Permalink You can still do that with integration testing I agree that Bret s example is too contrived to see that that you wouldn t be testing a jump with specific physics parameters rather you would probably be testing the level parts themselves João Pimentel Posted April 30 2012 at 3 07 pm Permalink Regarding the visualization ideas I believe they are pretty much domain based e g Bret Victor s with no one size fits it all solution Nonetheless IDE could be enhanced to facilitate the creation of such visualization instead of providing a standard one Stephen Posted April 30 2012 at 3 08 pm Permalink The reason is that there are fundamental and intractable problems What about mutable state What about I O What about non determinism and asynchrony Exactly I m glad to see other people like yourself not only recognizing this which seems a bit obvious but also working on the paradigm shift required to actually have revolutionary IDEs vs more tarted up editors Sean McDirmid Posted April 30 2012 at 6 45 pm Permalink The programmer experience PX analog UX includes language library editing debugging and so on it makes sense for language designers to become programming experience designers PXD analog UXD and consider programming holistically I hereby relinquishment my title of programming language designer and will now refer to myself as a PXD time to reprint my business cards There is a lot we can do with live programming and visualization in targeted domains For example physics simulations computer vision and so on have frame based semantics that allow for easy replay as well as inputs and outputs that are easily visualized as AfterEffects style movie clips or even use contrails as Bret does Supporting these features in general is much more difficult and perhaps impossible Rather we might as well consider domain specific IDEs for domain specific languages or better yet a language with the appropriate hooks to enable live programming and visualization think how toString customizes debugger views today There are so many ideas in this area Perhaps we should do a workshop or something Alas too late for SPLASH Jake Brownson Posted April 30 2012 at 6 54 pm Permalink Why bother differentiating Aren t we programmers just users of programming tools Sean McDirmid Posted April 30 2012 at 7 34 pm Permalink Yes we are users no we are not end users Designers for expert tools are very specialized you don t throw a typical UX designer on Adobe Illustrator or Autocad and expect anything decent to result for the first few years So we have the illustrator experience and the architect experience to consider with designers who specialize in these areas Programming experience is more like that Jake Brownson Posted May 1 2012 at 5 56 pm Permalink I understand what you re saying but I d prefer to think of PX as a subcategory of UX and not a peer The activities we and architects and editors etc are doing aren t fundamentally different from normal users it s just more specialized imho Sean McDirmid Posted May 1 2012 at 6 01 pm Permalink Of course all designers specialize to some extent But designers for expert tools are very different from end user designers they have to immerse themselves in a technically non trivial domain and they have to efficiently leverage the investment that the users are willing to put into the tool as well as the existing investments they have already made for existing tools this is a biggy That we deal with abstraction more heavily than other UX disciplines means we are necessarily more dissimilar than similar Jake Brownson Posted May 1 2012 at 6 34 pm Permalink It seems we ve reached the nesting limit so I m replying to my own I think we only disagree on semantics here but I think the semantics are important I feel it s a mistake to not include programmers firmly in the category of users I recognize that is is common practice to do so now If I m building a word processor or spreadsheet I should say user to describe folks that will use the spreadsheet or word processor and programmer to describe myself I think everyone would agree on this If I m building a programming tool I should also use the term programmer to refer to myself but I think it s important that I continue to think of the folks that will use this tool as users It so happens that my users are also then programmers for their own users making this case a bit meta but if you only go one level deep it s still a programmer user relationship I don t understand why we seem to use a whole different standard of design principles for our programmer users than for our end users It could be described as condescending to our end users I think if we were to follow the semantics I m proposing it will encourage more things like the things Jonathan linked in this post Sean McDirmid Posted May 1 2012 at 6 47 pm Permalink Programmers are users and so usability should be considered To me this is just so intrinsic that it is not very debatable and doesn t deserve much mention Design principles do you have a list Even designers for end users don t seem to have such a list I worked in a studio for 2 years rather they rely on knowledge experience taste and refined common sense As there are very few universals in design its not harmful to distinguish ourselves from other designers who are free to distinguish themselves also the design field is very diverse Titles are fairly meaningless anyways I don t really have business cards Don t get me wrong I think we should be interacting and exchanging ideas with designers in other areas a lot more than we do I do this and I have found every experienced designers to be very different from each other the field is quite eclectic David Barbour Posted May 1 2012 at 9 25 pm Permalink I ve been pursuing the idea from the other side aren t UIs just domain specific programming tools Jake Brownson Posted May 1 2012 at 10 57 pm Permalink Yes Sean McDirmid Posted May 1 2012 at 11 02 pm Permalink So like UX is PX and not vice versa Actually HCI in its early days was full of VPL folks like Lieberman David Barbour Posted April 30 2012 at 8 03 pm Permalink Programming Experience Designers I like it I agree that we need to consider the programming experience more holistically The associated community and social experience is also relevant Jonathan Edwards Posted April 30 2012 at 9 16 pm Permalink Agree totally Sean in fact I had considered discussing domain specific IDEs for domain specific languages but thought it would muddy my main point The most plausible new IDE concepts have been in gaming including some of Bret s demos and your own work Ironically many researchers are automating the generation of boilerplate IDEs for DSLs The real opportunity may be for a custom IDE to exploit domain specific semantics and syntax That is a much more pragmatic route forward than IDEs for Javascript I like PXD A new field is born Mark the date Svick Posted April 30 2012 at 8 46 pm Permalink Wait getting rid of imperative semantics is one of your goals I thought functional languages like Haskell already solved this Jonathan Edwards Posted April 30 2012 at 9 00 pm Permalink A common misconception As Bob Harper says Haskell is the ultimate imperative programming language Monads just ghettoize imperative semantics they don t transcend them Svick Posted May 1 2012 at 8 37 am Permalink I think that s the point If you want to do any kind of IO you simply need to do it imperatively In Haskell at least you can isolate that to a small part of your program and be sure that the rest of your code is pure David Barbour Posted May 1 2012 at 9 39 am Permalink Even much pure Haskell code is imperative e g you re still concerned about order of operations in a State or ST monad PeterisP Posted May 1 2012 at 2 45 am Permalink Sentences like Getting rid of imperative semantics is one of the goals Another is getting rid of source text files are invalid by definition I agree that these things have a lot of drawbacks but getting rid of X is a reasonable goal only when it can be phrased as let s replace X by Y Only with a specific replacement in mind you can even rationally argue if getting rid of X is good or not worth it Sean McDirmid Posted May 1 2012 at 5 34 am Permalink I don t believe that is what rational means For example oil is bad let s find a better alternative is a perfectly rational thought even if you don t know what the alternative is i e belief that a better alternative exists is reasonable and not irrational and so won t get you committed to a mental institution Peter Wilson Posted May 1 2012 at 8 09 am Permalink Thirty years ago I lead the design and development of the Synon 2 IDE It used Action Diagrams for code editing which were stored directly in a database It used Entity Relationship modeling to model the database design and to automatically produce form report designs Much in the same way that the Microsoft Lightswitch product does now The generated programs could switch target language between RPG III Cobol or PL I by changing a project setting The Model and the Action Diagrams were integrated together There was no round trip problem as the generated code was never amended I am amazed that in thirty years the state of the art has hardly advanced at all I thought that by now we would have vastly more powerful design abstractions and automated designers for particular problem domains The problem is indeed that the programming languages have been tailored for hand crafted design using a text editor as the main tool Current programming languages seem to have been designed by the guild of programmers to preserve tradecraft and to prevent automation Only by modeling the artifacts we are creating can we develop tools to assist us And no I don t mean UML diagramming Jonathan Edwards Posted May 1 2012 at 9 13 am Permalink Peter I am surprised how little the people working on DSLs today are aware of the history of 4GLs in the 80s and 90s The problem I observed with 4GLs was vendor lock in You could only do exactly what the tool let you do and you were completely at the mercy of the vendor s enhancement schedule That is why so called frameworks are the dominant pattern these days By using a mainstream PL with an open source framework you have much more freedom But you pay in much more complexity and the loss of domain specific IDEs Jonathan Edwards Posted May 1 2012 at 8 57 am Permalink Here s another one Instant C Sean McDirmid Posted May 1 2012 at 6 05 pm Permalink Nice find It should be noted that if the program is small enough we can achieve expressive visualizations and live programming easily via brute force This isn t useful in practice I did this with ScalaPad when at EPFL but we should exploit it like crazy to get people to realize the benefits of what if AgileOrWaterfall Posted May 1 2012 at 9 38 am Permalink Programming Languages have made no fundamental progress In fact conceptually they have even regressed Originally OO was meant to SIMULATE real world that simulation focus has quite disappeared That s how I tried to restore with Fractal MVC http lepinekong com the advantage of fractal mvc architecture simple bdd testing and looking for tools there weren t any so I did ask developers to build our own simple even simplistic tool to complete the IDE Ralph Mack Posted May 1 2012 at 10 42 am Permalink Isn t narrative text about what people are about though I mean we talk and speech is inherently linear As we tell a story over and over we edit it into a form that expresses it better When we use symbols to preserve speech on paper we re writing Then we shift our editing to the written word but it works the same way progressive linear We also draw we make lines and arrows and things We make pictures of ideas Even when we re presenting abstract concepts though we tell their story Media lets us dramatize ideas combining words and actions we ve been doing that for a long time too as a more immersive way of telling a story Name one thing you ve learned that interested you that you didn t learn via a story of some kind However we re imagine programming if we go from imperative to declarative models one primary requirement is that the result must tell a story or it won t communicate anything Mathematics is declarative and proofs and derivations in mathematics have a drama to them in the many transformations the parting and uniting that the mighty heroes x and y undergo Maybe that s a place to look But I m not inclined to believe there s anything to this until I see a proposed form has an underlying narrative that people can follow that can capture their imagination Jonathan Edwards Posted May 1 2012 at 2 04 pm Permalink The standard example is a spreadsheet But I would be happy even with the narrative power of English Programs are like narratives that talk of neuron firing patterns rather than emotions and motives Eric Maupin Posted May 1 2012 at 3 41 pm Permalink There is a long history of sketchy demos of live code execution that have never progressed past the demo including my own The reason is that there are fundamental and intractable problems What about mutable state What about I O What about non determinism and asynchrony If live code execution only works for factorial functions and the like it is pretty much irrelevant to real programmers No doubt there is an entire class of problems that this doesn t cover but I don t believe it s limited to factorial functions and the like REPLs wouldn t be anywhere

    Original URL path: http://alarmingdevelopment.org/?p=680 (2016-04-30)
    Open archived version from archive


  • Kickstarter: the aftermath
    good cause Or to paraphrase P T Barnum is there a micro investor born every minute Share this Twitter Google Email This entry was posted in General Bookmark the permalink Both comments and trackbacks are currently closed Kickstarting research An IDE is not enough 2 Comments Jake Brownson Posted April 27 2012 at 11 12 am Permalink I know I personally would continue to support software projects that intend to produce an interesting and useful product I ve supported 2 successful Kickstarter projects and 1 that was canceled before its deadline despite having reached its goal which I consider a pretty good This is the first software Kickstarter project I ve backed and my primary reason is I want to encourage development in this area Sure I d really like to see this guys succeed but I want others to see that this model works and that people are interested in projects like this The latter is still accomplished even if this particular project fails If I backed 5 software projects and none of them succeeded I might reconsider philip Posted April 27 2012 at 10 15 pm Permalink It will end up being a toy like smalltalk is for

    Original URL path: http://alarmingdevelopment.org/?p=674 (2016-04-30)
    Open archived version from archive

  • Kickstarting research
    methods for building software as evidenced by the response that Light Table has generated whether it has merit or not Peter Tom Lieber Posted April 26 2012 at 12 59 am Permalink Would extra funding buy a researcher time to release a 1 0 that funders would be happy with It seems like chasing the next paper deadline would take priority and that delivering a finished product would only slow down their career I m sure it s doing the opposite for Chris Ondra Posted April 26 2012 at 3 37 am Permalink I m a bit worried about the license of Light Table Although it s listed on KS as Open Software WTF is that this might suggest something different What s a license then In order to download packaged distributions you ll need a license Preliminarily we re thinking licenses will be based on a pay what you can what you believe it is worth model for individuals This gives everyone access to the tools to help shape our future but also helps us stick around to continue making the platform awesome We think what we build will be worth at least 50 and so that s what we ve used for our rewards Paul Tarvydas Posted April 26 2012 at 10 39 am Permalink Futurist Richard Worzel in his book Who Owns Tomorrow http www futuresearch com predicted that new grads would be involved in projects based on the film model get a team get funding execute disband and move on John Z Bo Zabroski Posted April 26 2012 at 7 46 pm Permalink Programmers charge way too much to their credit cards and largely don t know how to manage their wallets despite making more than people with 3 jobs philip Posted April 27 2012 at

    Original URL path: http://alarmingdevelopment.org/?p=670 (2016-04-30)
    Open archived version from archive

  • Onward! Call for Research Visions
    2012 cfp due april 13 2012 380 onward papers Share this Twitter Google Email This entry was posted in General Bookmark the permalink Both comments and trackbacks are currently closed The Visi vision Kickstarting research Links About me Send me email Subtext Subscribe to Blog via Email Enter your email address to subscribe to this blog and receive notifications of new posts by email Email Address RSS Posts RSS Comments

    Original URL path: http://alarmingdevelopment.org/?p=666 (2016-04-30)
    Open archived version from archive

  • The Visi vision
    back Share this Twitter Google Email This entry was posted in General Bookmark the permalink Both comments and trackbacks are currently closed Microsoft endorses JavaScript except when they need to get work done Onward Call for Research Visions 11 Comments Henning Hoefer Posted January 7 2012 at 3 02 pm Permalink So so true Codea is already on Apples Targeting Radar http daringfireball net linked 2012 01 06 codea downgrade Shad Sterling Posted January 7 2012 at 4 03 pm Permalink The Mono Project makes NET run on iOS without violating Apple s rules I expect the same techniques could work for any language or development environment I don t think most programmers are in love with Apple I think they want their products to have similarly high standards and to make them available to users who have already shown some appreciation for that I don t think they want Apple I think they want Apple s customers It s also worth noting that iOS devices are deliberately intended to not work like computers which among other things means no on device development tools If he s trying to make development tools that run on iOS device that is a mistake but if he s making development tools for iOS devices that run on real computers I think he s making sense Jonathan Edwards Posted January 7 2012 at 4 54 pm Permalink The issue is being able to download code to the iPad Apple allows just two ways via their app store or JavaScript running in their browser The former prevents true seamless cloud programming The later forces many compromises compared to native code Visi seems to be hoping that Apple will cut it an exception Good luck with that Shad Sterling Posted January 9 2012 at 8 36 am Permalink Ah I got caught up in reading about the language features and forgot about the cloud part Yes that is a problem I expect that will have to wait until Apple makes its own cloud computing toolset which won t be soon but they ll have to eventually Sean McDirmid Posted January 7 2012 at 8 33 pm Permalink It always makes me sad when I read people claiming iPads are not real computers and don t deserve programming environments We are literally killing our seed corn Shad Sterling Posted January 9 2012 at 8 49 am Permalink It s not that the devices aren t capable it s that the OS is designed to restrict access and the curation of the store restricts use cases They do seem to be moving toward merging mobile and desktop and I expect we ll be able to use them interchangeably eventually but not soon On that front I think Microsoft is pulling ahead with Windows 8 but it s too soon to be sure For the time being if you want to use your tablet for coding you ll have to use one that isn t running iOS Ondra Posted

    Original URL path: http://alarmingdevelopment.org/?p=662 (2016-04-30)
    Open archived version from archive

  • Microsoft endorses JavaScript (except when they need to get work done)
    visual programming The Visi vision 6 Comments Guim Posted November 23 2011 at 7 51 pm Permalink What we need is a simple and portable bytecode specification so everybody can use the language they want And no javascript is not a good target language Ben L Titzer Posted November 23 2011 at 8 14 pm Permalink Agreed And a good free VM available for most browsers Stefano Posted November 24 2011 at 3 46 am Permalink It s there already It s called Silverlight Sean McDirmid Posted November 23 2011 at 9 05 pm Permalink As far as I can tell Microsoft didn t announce anything very confusing What I will say is that there is a big difference between defining a new language like Dart that is Javascript compatible but will need its own libraries ecosystem to survive and just enhancing or wrapping via transformation Javascript with N features that still feeds into the existing Javascript ecosystem of libraries its not hypocrisy just a different approach Scala was very similar It could leverage Java libraries of course but encouraged new libraries that used Scala s specific abstractions effectively forking the Java and Scala ecosystems Groovy is very different it doesn t really need its own libraries and therefore the ecosystem isn t forked Both approaches are different and have their merits Nek Posted December 3 2011 at 10 15 am Permalink Don t you think Dart is too bloated and lacks some features There is already an alternative called haXe It has got more concise feature list and syntax The syntax is less Java in a good way Overall it s a good language for fans of classic OOP with classes interfaces etc but it also supports functional programming on par with javascript http haxe org Also an interesting

    Original URL path: http://alarmingdevelopment.org/?p=657 (2016-04-30)
    Open archived version from archive

  • Real world visual programming
    becoming software platforms unto themselves This is a great target domain for end user programming tools The second interesting thing was how radical they are in conceptually simplifying the language For example they tried eliminating variable binding essentially using only global variables That turned out not to work so they brought back a limited form of binding I really like that they are going at conceptual simplicity rather than the focus on syntactic simplicity that most end user work seems stuck in For example rather than use standard nested if then else blocks like everyone else they have imposed a global decision tree structure on the program Whether or not that works it is the kind of radical simplification we need to make progress I also like that they are working with real end users and adjusting based on what works This language is a valuable data point on how simple we can make an end user programming language and has some fresh thinking Worth following Share this Twitter Google Email This entry was posted in General Bookmark the permalink Both comments and trackbacks are currently closed Devolving Subtext to JavaScript Microsoft endorses JavaScript except when they need to get

    Original URL path: http://alarmingdevelopment.org/?p=654 (2016-04-30)
    Open archived version from archive

  • Devolving Subtext to JavaScript
    up I expect this is going to be one of the most controversial features of the language I think lexical binding leads to many problems while structural editing will be able to do smart implicit refactoring But maybe I am being too stubborn on this and will need to compromise to get people to use the language John Z Bo Zabroski Posted November 17 2011 at 3 18 pm Permalink I call in 2005 you had a long debate on LtU about abstraction and naming with Marc Hamaan or however you spell his name Jules Jacobs Posted November 18 2011 at 10 35 pm Permalink When implementing structured editors it s wasn t just the coding part that s hard but even more so the interaction design I couldn t figure out a good way to navigate and edit with the keyboard in a structured editor Touch tablets certainly make this a lot easier but for the time being we are still with keyboards On the one hand you can take a purist approach and navigate the syntax tree logically with commands for going up down left and right in the tree structure But this is not very intuitive though perhaps it just takes time to get accustomed to There are questions like what do you do if the user presses the left command on a leftmost child On the other hand you can take a textual approach and navigate the tree with a cursor like in a text editor This is not very appealing either it just doesn t seem like a good way to edit a tree It s easy in the sense that we re used to it from text editors but that s just an accident of history Do you have any ideas on this What are good navigation editing commands What problems do you think lexical binding leads to I ve found it quite natural in the context of structured editors A node that introduces new names like a variable declaration or a function declaration with parameters simply passes an environment structure to its children Jonathan Edwards Posted November 20 2011 at 7 51 pm Permalink One problem with lexical binding is that when you copy and paste a piece of text the meaning of all its symbols potentially change based on the context Another problem is that defining or undefining a symbol can implicitly change the bindings of symbols in nested scopes Most programmers are so used to these problems that it seems natural to them I envision the Subtext environment as making bindings explicitly and persistently with textual names being no more than search keys to assist Name clashes and shadowing are irrelevant Bindings once made do not change because the code moves or other bindings change Jules Jacobs Posted November 21 2011 at 4 47 am Permalink Ah I see what you mean I agree that variable names should just be programmer aids but that doesn t mean that scoping isn t lexical For example in the De Bruijn representation of lambda calculus http en wikipedia org wiki De Bruijn index there are no variable names yet it is lambda calculus Even if you have variables point directly to definitions instead of via textual names that doesn t solve the copy paste problem yet If you copy a subexpression inside a function that refers to the function s parameters to another function how are you going to do that in a meaningful way If the variables keep pointing to the other function then the code doesn t have any meaning If your representation is such that the variables now point to other things which things do they point to As far as I can see the most sensible thing to do is to flag ill scoped variables in the IDE so that the programmer can fix them manually instead of using some heuristic to try to do it automatically Or do you have a way of giving the variables new meanings in their new context that still makes sense Jonathan Edwards Posted November 21 2011 at 10 16 pm Permalink Jules Copying code out of a function body would be like taking a closure the default values of the arguments would be captured This is possible because bindings are arbitrary tree paths not just upward references as with lexical scope By providing a notion of binding that can be conserved across structural edits I can enable the sort of fancy IDE features you suggest That can not be done gracefully in an IDE based on character editing nor would it be tolerated by many who have spent years learning how to exploit the properties of lexical scope while editing code The proof will be in the pudding and I must admit I am a long ways from having that kind of IDE as I have decided that I need to sell Subtext first based on its expressive power So initially it is going to be a textual language with some strange features that may be awkward to use from a text editor Jules Jacobs Posted November 22 2011 at 9 41 am Permalink Suppose you have the following code function foo a b return a b 10 function bar c return c 5 And say you copy the subexpression b 10 and paste it inside bar What is the analog to this in the language you re envisioning What is b pointing to when pasted in bar If your language is so different that there isn t an analog to this can you give your own example Jonathan Edwards Posted November 22 2011 at 10 49 am Permalink Copying b 10 would produce a reference to the foo function prototype s b argument Often function arguments are given default values in the prototype and that value would be bound to In this case there is no default value so execution would produce an undefined value error It might look something like this

    Original URL path: http://alarmingdevelopment.org/?p=637 (2016-04-30)
    Open archived version from archive



  •