Re: [fonc] What Should The Code Look Like? (was: Show Us The Code!)
True. If I'm writing code I probably want to be sitting at a desk to do it. And I imagine Gauss or Euler sitting at a desk in the middle ages writing on parchment, not trying to scribble something down on a notebook while barreling down the streets in their equivalent of a daily commute. Still, I think programming needs to be interactive. I don't think we need to give up text to give up keyboards. 90% of the stuff we type can be predicted by what we have already written in the past. Maybe these new devices really are for everyone else. Cubicles are good enough for programmers :) On Mon, Dec 20, 2010 at 11:07 AM, Brian Gilman brian.gil...@gmail.com wrote: Clearly there are some gaps in the programming models of this new era. How can people express themselves in a mathematical notation that isn't bound to 19th century keyboard technology? I think that the fundamental problem is that keyboards are good for entering text, and text scales very well. Artists and musicians tend to heavily favor visual node based programming, which is a better fit for mobile platforms. Just drag nodes out, and draw connections. For non-programmers, being able to see the relationships between visual blocks of code is much more intuitive than text. The problem is, that it doesn't scale very well. Once a program reaches even a moderate level of complexity, the graph of nodes end up looking like a pile of spaghetti. If you want to rearrange your program, you end up having to disconnect and reconnect tons of nodes. For systems without keyboards, spatial representation of code seems like the intuitive direction to go, and would work regardless of whether the user is using a multitouch tablet, or is wearing a pair of AR glasses. Getting that to scale however, seems like a very difficult problem. ___ 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] What Should The Code Look Like? (was: Show Us The Code!)
To see how far you can scale visual node programming I recommend looking at Pure Data, Quartz Composer, and LabView. Also interesting is Little Big Planet. On Dec 20, 2010, at 11:07 AM, Brian Gilman wrote: Clearly there are some gaps in the programming models of this new era. How can people express themselves in a mathematical notation that isn't bound to 19th century keyboard technology? I think that the fundamental problem is that keyboards are good for entering text, and text scales very well. Artists and musicians tend to heavily favor visual node based programming, which is a better fit for mobile platforms. Just drag nodes out, and draw connections. For non-programmers, being able to see the relationships between visual blocks of code is much more intuitive than text. The problem is, that it doesn't scale very well. Once a program reaches even a moderate level of complexity, the graph of nodes end up looking like a pile of spaghetti. If you want to rearrange your program, you end up having to disconnect and reconnect tons of nodes. For systems without keyboards, spatial representation of code seems like the intuitive direction to go, and would work regardless of whether the user is using a multitouch tablet, or is wearing a pair of AR glasses. Getting that to scale however, seems like a very difficult problem. ___ 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] What Should The Code Look Like? (was: Show Us The Code!)
On 21/12/2010, at 4:51 AM, Steve Wart wrote: So is there anything interesting from a FONC perspective in mobile devices? It may be a coincidence that Apple's success with the iPhone is to a large extent due to a Smalltalk-derived C dialect, but most people who know Smalltalk would agree that it's more like C than it is Smalltalk. Apple's certainly made it clear that they've got little appetite for dynamic languages on iOS (other than web apps), but the reality is that keyboard-less mobile devices are not suitable for programming activities at all, from any manufacturer. I wouldn't really agree with this. Have you used Objective-C? I code in it daily, and Apple's frameworks and particularly the design patterns baked inherently into those frameworks make it so Smalltalk-like that I'm rather surprised you would say something like this. It *is* a dynamic language (assuming I know what you mean by dynamic here) - in other words, it uses live realtime message-sending. If you look at what Apple are doing with Grand-Central Dispatch, LLVM and their other realtime optimisation-focussed frameworks, you begin to see that they're very focussed on getting as much performance as they can from these devices, hence the focus on Objective-C (which is as close to smalltalk as we can get while being highly portable and optimised at the same time). I'd wager that just like switching architectures from PowerPC to Intel, if there was something better and more efficient, Apple would most likely have no issue or difficulty with switching to something else. This is kind of irrelevant, though, to FONC, because FONC obviously needs to be pure. Other interesting things are happening in other places... have you seen what Gemstone have done (is doing) with their implementation of their persisted distributed Ruby (which sits on top of their Smalltalk implementation). If any artefact FONC brings is relevant, it will obviously need to address persistence properlly... (The not-yet-finished ruby implementation is at http://www.gemstone.com/products/maglev) I'm not actually sure how relevant something that doesn't join in the conversation rather than try to reinvent EVERYTHING is, though... what I mean by that, is Apple have got very very good at layering their architecture with replaceable bits... I think this approach is infinitely useful, because it means if any single piece needs fixing, replacing or modification, then it can be re-tooled relatively easily and quickly. It's proper objected-orientedism. (For want of a better word). The fact that FONC have built O-META as a base artefact brings me immense excitement in relation to this, because O-META couldn't be a more functional implementable piece in the puzzle to the existing context of coding... the potential here is huge... being able to plug in various pieces of code in various languages is an amazing idea. (Assuming I'm properly interpreting what its potential is, though). Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] What Should The Code Look Like? (was: Show Us The Code!)
On 21/12/2010, at 6:07 AM, Brian Gilman wrote: I think that the fundamental problem is that keyboards are good for entering text, and text scales very well. Artists and musicians tend to heavily favor visual node based programming, which is a better fit for mobile platforms. Just drag nodes out, and draw connections. For non-programmers, being able to see the relationships between visual blocks of code is much more intuitive than text. The problem is, that it doesn't scale very well. Once a program reaches even a moderate level of complexity, the graph of nodes end up looking like a pile of spaghetti. If you want to rearrange your program, you end up having to disconnect and reconnect tons of nodes. For systems without keyboards, spatial representation of code seems like the intuitive direction to go, and would work regardless of whether the user is using a multitouch tablet, or is wearing a pair of AR glasses. Getting that to scale however, seems like a very difficult problem. If you're interested in music, you might know bout the Reaktor, Max/MSP and Reason programs. Their method of programming is indeed this. They are missing something (the idea of scale), but I very much like this. Check them out if you haven't already. I personally love writing code with words, but I don't think that this approach is revolutionary enough. I quite like the Self language approach to objects and programming (to a degree, though, it's still keyboard-tied), but the problem with GUI-based coding system such as these is that you ALWAYS have to use the mouse. This doesn't address the power users. They need to be addressed. Having keyboard-based coding systems addresses the power users, but doesn't really address the n00bs. I think everyone needs to be treated as a n00b, because potentially everyone *IS*... we need COMPLETE self-documenting code that explains how every part of itself works, in exactly the same attitude that the COLA boostrapping attitude exhibits. Even Apple, arguably the best asset the entire world presently have in terms of presenting things simply and easily, in my opinion fail quite hard at trying to explain objects to n00bs... their documentation is great, but they miss huge chunks out of things when explaining. If documentation was literally baked into the objects themselves, then the process of introspection could be used for education. Teaching someone how to use the system and learn about it would take about the same amount of time as teaching someone the syntax of smalltalk - it's a simple, easy grammar. The powerful ideas are the connecting ones, IMHO. Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] What Should The Code Look Like? (was: Show Us The Code!)
On Mon, Dec 20, 2010 at 3:54 PM, Julian Leviston jul...@leviston.net wrote: On 21/12/2010, at 4:51 AM, Steve Wart wrote: So is there anything interesting from a FONC perspective in mobile devices? It may be a coincidence that Apple's success with the iPhone is to a large extent due to a Smalltalk-derived C dialect, but most people who know Smalltalk would agree that it's more like C than it is Smalltalk. Apple's certainly made it clear that they've got little appetite for dynamic languages on iOS (other than web apps), but the reality is that keyboard-less mobile devices are not suitable for programming activities at all, from any manufacturer. I wouldn't really agree with this. Have you used Objective-C? I code in it daily, and Apple's frameworks and particularly the design patterns baked inherently into those frameworks make it so Smalltalk-like that I'm rather surprised you would say something like this. It *is* a dynamic language (assuming I know what you mean by dynamic here) - in other words, it uses live realtime message-sending. I used Objective-C pretty much every day for the past 2 years, but for the past 6 months I've been coding in Smalltalk (good old VisualWorks/Envy and GemStone) again. Objective-C has a static compiler and an interesting runtime (with Smalltalk-like message sends), but the compiler and the runtime are very distantly separated in time. You use GDB to debug your code. It's not a dynamic language. Objective-C is a good language for what it is. I don't think it's a replacement for C++ or Smalltalk, but it obviously has a strong niche in iOS, and Apple's done as an amazing job of designing their APIs as they have in designing the consumer-facing bits. I think the language has played a big part in the success of both NextStep and the iPhone and it's clearly suitable for building complex systems. I'm not actually sure how relevant something that doesn't join in the conversation rather than try to reinvent EVERYTHING is, though... what I mean by that, is Apple have got very very good at layering their architecture with replaceable bits... I think this approach is infinitely useful, because it means if any single piece needs fixing, replacing or modification, then it can be re-tooled relatively easily and quickly. It's proper objected-orientedism. (For want of a better word). I agree. I think that FONC shouldn't be tied down to an implementation, but ultimately we have to deploy to some hardware. I have been very focused on iOS and have struggled with geting Squeak and Croquet to expose the low-level bits in a productive way. And in the end I decided if I'm going to do iOS programming, there's no point in fighting the platform, and so I do it in Objective C where I can and C++ where I must. In fact, I don't really care about platform independence. At all. But you must know the edit, compile, download loop is not the most efficient way to be doing things. We do it because the platform demands it, and it's the best way to deliver quality to the end-user. The point of Smalltalk to me is that the programmer is the end-user, and very few of the dynamic languages I've seen really live up to that standard. [other interesting stuff snipped] The fact that FONC have built O-META as a base artefact brings me immense excitement in relation to this, because O-META couldn't be a more functional implementable piece in the puzzle to the existing context of coding... the potential here is huge... being able to plug in various pieces of code in various languages is an amazing idea. (Assuming I'm properly interpreting what its potential is, though). I'm excited about the potential too. I was hoping to build a NodeBox-like environment in Squeak. I struggled getting an OMeta parser to work in Squeak and getting the OpenGL context working (thanks Croquet) but it wasn't quite what I had hoped for. Now I'm thinking maybe it's better to look at WebGL and OMeta, but my heart's not really in it. I'm probably too old and unlettered to become a mathematician, but I love geometry. All I really want to do is instill that in my kids and give them the tools to explore on their own, without having to be consumers all the time. Unfortunately the tools that can expose the really amazing power of modern computing hardware are still too complicated for us to share, and the productive tools I'm used to can't get down to the level I want, at least not yet. It seems there is so much scaffolding we never actually get around to doing the actual building. Why can't the scaffolding be made of the same stuff? OMeta showed you can do that with compilers, Smalltalk showed you can do it with, well an OS. The stuff I'm trying to do is pretty simple in comparison, but I'm still not sure I'm asking the right questions. Cheers, Steve Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] What Should The Code Look Like? (was: Show Us The Code!)
On Mon, Dec 20, 2010 at 5:07 PM, Julian Leviston jul...@leviston.net wrote: On 21/12/2010, at 12:00 PM, Steve Wart wrote: I used Objective-C pretty much every day for the past 2 years, but for the past 6 months I've been coding in Smalltalk (good old VisualWorks/Envy and GemStone) again. Objective-C has a static compiler and an interesting runtime (with Smalltalk-like message sends), but the compiler and the runtime are very distantly separated in time. You use GDB to debug your code. It's not a dynamic language. I'm interested in what you mean by dynamic here. The fact that I can choose my selectors to send messages with at runtime would make it dynamic in at least one sense, no? Sure. It's duck typing according to the way most people talk about it these days. To me a dynamic language has runtime access to the compiler, at least to the point you can build a REPL. Objective-C has the potential to take on more of Smalltalk's dynamic features. The Etoile project has some good ideas for integrating libclang into the runtime, so you could fake it out. And since Smalltalk is also faking it at a certain level, it's hard to quibble with smoke and mirrors. It's theoretically not dynamically typed, but the id type kinda makes it fairly dynamically typed. This wikipedia entry seems to think Objective-C is dynamic. http://en.wikipedia.org/wiki/Dynamic_programming_language I never read it. But I don't agree with everything I read either :) The thing about Objective-C is that it's 2 parts, the language and the runtime. A lot of decisions are deferred until runtime, but there's nothing stopping you from sticking 0x0BADF00D into an id pointer and having your program crash. Dynamic languages shouldn't do that. Cheers Steve Julian. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
