The Artima Developer Community
Sponsored Link

Java Community News
Enterprise Software Freakishness

31 replies on 3 pages. Most recent reply: Nov 16, 2007 12:31 AM by Gregor Zeitlinger

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 31 replies on 3 pages [ « | 1 2 3 | » ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Enterprise Software Freakishness Posted: Oct 29, 2007 6:40 AM
Reply to this message Reply
Advertisement
> > There is no much better to way to communicate an idea
> than
> > to visualize it. As the Chinese say, a picture is worth
> a
> > thousand words.
> >
> > Imagine a web development environment where the
> developers
> > could go to the client, open a screen, draw the gui,
> > specify the information flow, encode processing
> > algorithms, and all that by using only graphical tools!
>
>
> I'm a naturally visual person and prefer diagrams to text
> to explain concepts, processes, etc. Given that I prefer
> text based development tools to all graphical tools that I
> have used.
>
> It's not that I don't like pictures. I prefer them as a
> state above. The problem is that all of these graphical
> tools are so limiting that any gain from the visualization
> is lost many times over in the unwieldy nature of the
> tool.

Let's forget all we know about graphical guis and start with a clean sheet of paper.

Let's put boxes on this paper.

Let's connect those boxes with messages (data, or functionality).

Let's use simple expressions edited graphically to define those messages.

If you picture it in your head, you will see how easy it can be.

>
> I think there are a few changes that would improve
> things.
>
> 1. Stop pretending that GUIs make programming so simple
> that anyone can do it. It's a tool and possibly a better
> one but the real challenge of development (problem
> solving) is unchanged. This also means including features
> in the tool that allow for sophisticated approaches. No
> more one-size-fits all solutions.

I'm with you. Current IDEs are difficult to use, especially for GUI development. They don't cover all aspects of GUI programming.

>
> 2. Allow users to work with the GUI and with a
> deterministic and easily readable text file that can be
> modified by hand. This should be canonical format of the
> source. Until regex, diff, merge, etc. for guis is
> created, any other approach is 100% unacceptable. The
> source needs to be compilable too. I don't want to use a
> GUI to deploy my code. Moreover, I don't want to have to
> sit with some QA or Ops person and show them which buttons
> to click in order to deploy my code into production.

That's a matter of internal representation of the information.

>
> 3. Create a Turing complete graphical language. Maybe
> UML is Turing complete (I really don't know) but I can't
> take any suggestion to write an entire application from
> the ground up in UML (only) seriously. Who has that kind
> of time and patience?

How about creating the graphics from a real programming language which is structured in such a way that programs can be written in declarative style?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Enterprise Software Freakishness Posted: Oct 29, 2007 6:57 AM
Reply to this message Reply
> Let's forget all we know about graphical guis and start
> with a clean sheet of paper.

I'm with you. I think that we need to be clear that current GUI tools are not up to the task.

> Let's put boxes on this paper.
>
> Let's connect those boxes with messages (data, or
> functionality).
>
> Let's use simple expressions edited graphically to define
> those messages.
>
> If you picture it in your head, you will see how easy it
> can be.

As the saying goes, the proof of the pudding is in the eating. I'll agree it's easy when it's done easily.

> > 2. Allow users to work with the GUI and with a
> > deterministic and easily readable text file that can be
> > modified by hand. This should be canonical format of
> the
> > source. Until regex, diff, merge, etc. for guis is
> > created, any other approach is 100% unacceptable. The
> > source needs to be compilable too. I don't want to use
> a
> > GUI to deploy my code. Moreover, I don't want to have
> to
> > sit with some QA or Ops person and show them which
> buttons
> > to click in order to deploy my code into production.
>
> That's a matter of internal representation of the
> information.

Yes but for pragmatic reasons, it's necessary that the tools use a text-based canonical format. I've worked with a number of tools where this is one of the chief flaws, especially in the long term.

I have to deal with a GUI tool right now that stores it's code in a relational DB. This makes it very difficult to version, compare, merge, diff and deploy. Because the vendor's source control option does not work properly, we essentially have no real source control. It's also very difficult to even search the code for dependencies. An XML export makes this easier but has it's own issues.

> How about creating the graphics from a real programming
> language which is structured in such a way that programs
> can be written in declarative style?

I think we have the same idea. I believe that a very basic procedural language would be a good start. The first step would be identifying the control structures to support.

If you are considering attempting something like this, I might be interested in helping but my current extra-curricular schedule is kind of full right now. But I might be able to make some contributions in the near future.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Enterprise Software Freakishness Posted: Oct 29, 2007 7:09 AM
Reply to this message Reply
> If you are considering attempting something like this, I
> might be interested in helping but my current
> extra-curricular schedule is kind of full right now. But
> I might be able to make some contributions in the near
> future.

After the New Year, I'd be willing to contribute what little brain I have left.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Enterprise Software Freakishness Posted: Oct 30, 2007 9:33 AM
Reply to this message Reply
> > How about creating the graphics from a real programming
> > language which is structured in such a way that
> programs
> > can be written in declarative style?
>
> I think we have the same idea. I believe that a very
> basic procedural language would be a good start. The
> first step would be identifying the control structures to
> support.
>
> If you are considering attempting something like this, I
> might be interested in helping but my current
> extra-curricular schedule is kind of full right now. But
> I might be able to make some contributions in the near
> future.

You mean a web IDE that's fully graphical? my schedule is full as well.

Any volunteers? I can contribute with ideas.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Enterprise Software Freakishness Posted: Oct 30, 2007 3:03 PM
Reply to this message Reply
> > I might be able to make some contributions in the near
> > future.
>
> You mean a web IDE that's fully graphical? my schedule is
> full as well.
>
> Any volunteers? I can contribute with ideas.


q: what do you think of what already exists? things like:

* MATLAB or other dataflow languages?

* better conditionals http://alarmingdevelopment.org/?p=64

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Enterprise Software Freakishness Posted: Oct 31, 2007 6:51 AM
Reply to this message Reply
I haven't used MatLab.

Dataflow is how I envision the graphical IDE: each box would be a node where data come in and data come out. A node could be an algorithm or a GUI screen or another graph.

Regarding your paper, I've browsed it in the past. I'm no expert, but I in my fictional programming language, 'if', 'switch' etc have been replaced by a match construct similar to the one found in functional programming languages or LISP's cond.

From a mathematical point of view, an 'if' or 'switch' is nothing more than a function from one set of values to another set of values.

Dale Wilson

Posts: 2
Nickname: dalewilson
Registered: Sep, 2007

Re: Enterprise Software Freakishness Posted: Oct 31, 2007 8:18 AM
Reply to this message Reply
There's a lot of discussion, but it boils down to a simple distinction.

Shrink wrap software has to be the BEST available in order to survive. Everything else (i.e price) being equal, no one picks number two.

Enterprise software survives if it avoids being so bad that the screams of anguish are heard at the political level. That's a pretty low bar.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Enterprise Software Freakishness Posted: Oct 31, 2007 4:24 PM
Reply to this message Reply
another example of visual programming:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-129.html

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Enterprise Software Freakishness Posted: Nov 1, 2007 8:17 AM
Reply to this message Reply
> another example of visual programming:
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-1
> 29.html

Yeap, something like that could work for visual programming.

Imagine each box as having a set of data inputs and a set of data outputs; the inputs of one box are connected to the outputs of another box.

A box can be:

1) a computation (a mathematical function which maps data from its inputs to its outputs).
2) a GUI (input data are what the user edits, output data are the edited data).
3) a store (database, email, file, other).
4) a composite box which consists of all other boxes.

With this simple mechanism, one can create:

1) workflows.
2) algorithms.
3) guis.

Imagine now such a design tool being available from the web browser...you go to the client's site, edit the application on site, together with the client! you can finish in days what could otherwise take you months to finish.

The tool could even take over the database normalization...you could simply send data to the database box, and the box itself looks at the data and automatically applies normalization (either at compile time with a sample of data or at run-time with the real data).

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Enterprise Software Freakishness Posted: Nov 1, 2007 12:59 PM
Reply to this message Reply
I haven't done much research, but I am under the impression that visual languages tend to collapse under their own weight as the project gets larger. I guess the same can be said for ASCII.

Personally I think the (pen)ultimate thing would be to have many different ways to slice and dice things so that whatever you need at the moment is available. Sometimes that's ASCII, sometimes that's 2D graphs, sometimes it is something else - whatever, it should all be available and when you use one view it should update all others.

I can't find the reference at the moment, but some folks in the Silicon Valley area were working on just such a thing and presented some demo material a year or two back at a BayCHI Future Systems BOF meeting.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Enterprise Software Freakishness Posted: Nov 2, 2007 8:31 AM
Reply to this message Reply
> I haven't done much research, but I am under the
> impression that visual languages tend to collapse under
> their own weight as the project gets larger. I guess the
> same can be said for ASCII.
>

If the problem gets too large, you have to slice it. No tool can make a difference in this case.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Enterprise Software Freakishness Posted: Nov 2, 2007 3:13 PM
Reply to this message Reply
> If the problem gets too large, you have to slice it. No
> tool can make a difference in this case.

I think I understand what you are saying, but I disagree at some level. One important aspect of the tools is to help with managing ever larger things. Otherwise we'd all be writing binary machine code instructions instead of Haskell.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Enterprise Software Freakishness Posted: Nov 5, 2007 8:11 AM
Reply to this message Reply
> > If the problem gets too large, you have to slice it. No
> > tool can make a difference in this case.
>
> I think I understand what you are saying, but I disagree
> at some level. One important aspect of the tools is to
> help with managing ever larger things. Otherwise we'd all
> be writing binary machine code instructions instead of
> Haskell.

A tool like I described above does not have a specific limitation on how abstract the product description will be. You can make it have one box where all things happen inside it or have multiple boxes, at any given level.

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: Enterprise Software Freakishness Posted: Nov 8, 2007 6:43 AM
Reply to this message Reply
> Let's forget all we know about graphical guis and start
> with a clean sheet of paper.
>
> Let's put boxes on this paper.
>
> Let's connect those boxes with messages (data, or
> functionality).
>
> Let's use simple expressions edited graphically to define
> those messages.
>
> If you picture it in your head, you will see how easy it
> can be.

When I picture it in my head, including everything I can see that need to be in it, I see it ending up complex.

I suspect the difference is that I have actually tried to design things like this.

Take out a stack of paper, and try to draw up examples of your system - for an entire program.

For instance, a fairly simple app: It takes in a cookie from a web form, and if that cookie is found in a database, it update the firewall ruleset to allow the IP coming in to the web form access to the net. The cookie is "bought time", and when you use it is spent, and the firewall stays open for the allotted amount of time. Your little program also has to check the firewall rules back and see if they have timed out.

This is a description of probably the simplest commercial app I've ever written. It lives with simple flows.

I think even with that you're going to find that your graphical tool is going to show quite a bit of complexity.

My personal experience about programming is that the difficulty isn't in the "way of putting input to the computer" - it is in the difficulty of rigorous thought. Without training, nobody has the rigour necessary to do this well - and a graphical tool isn't going to help much. A graphical tool isn't more efficient than a text based tool; if things could be specified with graphical arrows, we could specify them with "->" in a text based language.

If you can prove me wrong, it would be wonderful, so the best of luck to you. Please, though, before you repeat the old claim that this is feasible, do the work of trying it out for a sample app.

Since I first started programming a quarter of a decade ago, there's continually been people saying that "This should be doable graphically". Nobody has yet delivered. So, please try it out in private before claiming it is doable in public - as the noise these claims generate gets in the way of regular discussion of other topics, and always has.

Eivind.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Enterprise Software Freakishness Posted: Nov 9, 2007 1:40 PM
Reply to this message Reply
> it is in the difficulty of rigorous thought.
> Without training, nobody has the rigour necessary to do
> o this well - and a graphical tool isn't going to help
> much. A graphical tool isn't more efficient than a text
> based tool; if things could be specified with graphical
> arrows, we could specify them with "->" in a text based
> language.

while i agree (not from much personal experience, more from reading about other folks' experience, like yours) that a solely visual language isn't the silver bullet it might at first seem, i don't want people to not investigate them. i think they still have a time and a place. just like ascii. or UML. or seeing the underlying machine code. or stack traces. or whatever; understanding code can be hard, and the more ways we have of looking at it the better. ditto when making the code in the first place.

i hope http://www.baychi.org/bof/future/20030325c/ Core Talk goes somewhere.

Flat View: This topic has 31 replies on 3 pages [ « | 1  2  3 | » ]
Topic: NetBeans SQE Project Bundles Five Code Quality Tools Previous Topic   Next Topic Topic: Using Scala to Explore Trees

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use