| Author |
Message |
|
| Mazen |
 Posted: Thu Sep 21, 2006 9:06 am |
 |
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
|
| Back to top |
 
|
| andreas |
| Posted: Thu Sep 21, 2006 12:35 pm |
|
|
|
User
Joined: 03 Jul 2006
Posts: 17
|
Maybe we should ask the question: Do we want to develop UI in erlang?
If then:
Do we use the internal Erlang UI framework?
Using web/HTML (YAWS) as an UI? |
|
|
| Back to top |
|
| francesco |
| Posted: Thu Sep 21, 2006 12:58 pm |
|
|
|
User
Joined: 07 Jul 2006
Posts: 249
Location: London
|
Erlang was not invented for GUI programming... Then again, nor was Java (It just resurrected as a GUI programming languages in one of its 9 lives).
What makes Erlang interesting in GUI development is its platform independence. Running tv, the toolbar or pman / debugger on linux, windows solaris or OSX, you run the same version of the code and use the same beam files.
The above is based on GS, which is very simple in functionality (GS was the result of a Master's thesis in 1994). More complex interfaces towards graphical systems are all open source, but not maintained. (Just to mention one, etk, an Erlang to TK binding which bypasses tcl). GS was kept simple from day one (When first released in 1995, and later rewritten in 1997). With little efforts, much more could have been added but the decision was not to. An effort do develop a GUI builder resulted in another Master's thesis finished in 1999, but the result was never released. The reason to keep everything simple was maintenance. They are struggling to maintain gs today (run pman / debugger on windows, and enjoy!). Imagine what would have happened with much higher complexity.
There are no tools to support GUI development in Erlang today, and there are no advanced libraries. This boils down to a simple answer. Right tool for the right job.
If you need a prototype or a quick fix, use Erlang. If you seed a complex, sexy GUI, use an appropiate language with appropiate tools. You will pay the overhead in complexity / mixing many technologies / interfacing costs and loose platform independence, but you will get something professional.
I will leave the yaws / html to some one else.
Francesco |
|
|
| Back to top |
|
| sander |
| Posted: Sat Sep 23, 2006 12:20 am |
|
|
|
Joined: 17 Aug 2006
Posts: 8
|
| A nice GUI application would be a realistic 3D game; if gamers add more nodes to their game cluster, the graphics will become more realistic and the AI will become smarter B-) |
|
|
| Back to top |
  
|
| uwiger |
| Posted: Fri Nov 24, 2006 9:39 am |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
francesco wrote: Erlang was not invented for GUI programming... Then again, nor was Java (It just resurrected as a GUI programming languages in one of its 9 lives).
What makes Erlang interesting in GUI development is its platform independence. Running tv, the toolbar or pman / debugger on linux, windows solaris or OSX, you run the same version of the code and use the same beam files.
[...]
There are no tools to support GUI development in Erlang today, and there are no advanced libraries. This boils down to a simple answer. Right tool for the right job.
As you mentioned, the main reason why no ambitious GUI library has been developed in Erlang is mainly the lack of a real end-user requirement for it (I'm now talking about the kind of end-user requirement that arrives attached to a bag of money).
I think that it has been shown in several prototypes that GUI programming in Erlang is quite enjoyable (except for the lack of sexy libraries). There are intermittent discussions on whether GUIs are inherently concurrent or inherently modal. I maintain that they at least should be concurrent, but the limitations of traditional programming approaches enforce a modality that is unintuitive.
(MS Outlook is a wonderful example of a captive user interface that may be "sexy", but frequently keeps the user from being able to do anything because the program is busy synchronizing with the server, or because an unrelated modal window is open. Having said this, it can be surprisingly difficult using e.g. GS to deliberately make an application modal.)
I think that the combination of JavaScript and SVG (Scalable Vector Graphics, http://www.w3.org/Graphics/SVG/ and http://www.svgbasics.com/) should make for quite interesting web-based GUIs. That, and the Canvas widget (look for example at http://www.abrahamjoffe.com.au/ben/canvascape/) should fit Erlang and Yaws very well.
There may be some growing pains initially, but we should be able to be in the forefront here ("we" as in you guys, who are outstanding programmers who don't have to develop GUI-less embedded systems for a living  )
BR,
Ulf W |
|
|
| Back to top |
|
| francesco |
| Posted: Mon Dec 04, 2006 10:34 am |
|
|
|
User
Joined: 07 Jul 2006
Posts: 249
Location: London
|
Quote: I think that it has been shown in several prototypes that GUI programming in Erlang is quite enjoyable (except for the lack of sexy libraries). There are intermittent discussions on whether GUIs are inherently concurrent or inherently modal. I maintain that they at least should be concurrent, but the limitations of traditional programming approaches enforce a modality that is unintuitive.
This reminded me of one of the two things got me hooked on Erlang in the first place. Having used the Mac API for windows programming back in 1992, where every window gets a time slot with call-backs and you have to release control as soon as you've done the updates.. The overhead and latency issues caused by dodgy algorithms disappeared in 1993 when we did the same using Concurrency Oriented Programming (Using a TCL/TK interface), assigning a process to every window.
I later heard that it was a rant on the Mac call-back API I had during an employment interview, describing how simple life would be if we could use Erlang for window handling in GUI programming that landed my first job at Erlang Systems...
Francesco |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
