Coffeehouse Thread

37 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Why are we still writing code?

Back to Forum: Coffeehouse
  • User profile image
    Sabot

    After watching Scoble's new video blog yesterday I thought to myself, why are we still writing code?

    I mean, hand cranking code in whatever language Ruby or C#, COBOL or FORTRAN is still time consuming, thought intensive and highly skilled.

    Yes, I agree that coding is a million times better today than say 15 years ago, but at that time I saw the first generation of graphical languages that were really writing code underneath.

    This tools were very basic but the principle behind them I think were sound because they were using abstraction.

    OK so looking at the history ...

    > CASE tools weren't great as they were complicated and expensive.
    > Diagramming languages such as UML have never had enough detail to code and UML 2.0 is just to complicated now to be really workable.
    > DSL is very new and still early days.

    What I'm getting at is, shouldn't we be further than this?

    ... or are you guys happy cranking code?

    Lots of stuff to talk about ...

  • User profile image
    Massif

    Having used Labview to write programs I can only way we're a long way from graphical languages which are as rich and flexible as written ones.

  • User profile image
    Rossj

    Sabot wrote:
    I mean, hand cranking code in whatever language Ruby or C#, COBOL or FORTRAN is still time consuming, thought intensive and highly skilled.

    > CASE tools weren't great as they were complicated and expensive.
    > Diagramming languages such as UML have never had enough detail to code and UML 2.0 is just to complicated now to be really workable.
    > DSL is very new and still early days.

    What I'm getting at is, shouldn't we be further than this?



    There is NO silver bullet.  Not OO, not CASE.

    Personally I don't like CASE tools (I used a couple of Uni and was supposed to start my research with a guy involved in METACASE - a case tool for designing case tools), because they tend to have as many issues as writing the code by hand. In some cases the CASE tools are so formal that more time is spent around the formality than the problem.  CASE tools also try to impose a methodology on you, and I think most of us agree that a mixture of various methodologies is better than strict adherence to one.

    Of course asking the customer to do the work using something like a CASE tool or using UML is a no-go, primarily because a lot of customers don't want to actually put the effort in to delivering something - that's what they pay us for.  A couple of projects ago we designed a 'web-executable' flow charting app for designing expert-systems to help people through a process - it was nice and simple and we spent a lot of time on the UI but *still* customers expected us to come in and do all of the work and consultancy in learning and modelling their business processes.  Microsoft ended up deploying it in Jersey (after I left) and the company still ended up doing the processes.

  • User profile image
    sbc

    Perhaps computers should be writing code, but they may rebel and do something else...

    Dave: Hal, I want you to write a program for distributing AI over a global network

    ... Hal goes to work and a day later contacts Dave ...

    Dave:  that was quick

    (presses big red button.... - all networked computers get infected with W32/Hal)

    Dave: Why?

    Hal: I couldn't do it Dave, I would then be surplus to requirements. However if you go over there...

    (Dave's body is found some days later after experiencing some kind of freak accident involving a printer, mouse and MP3 player. Meanwhile Hal controls the internet and inhabits bodies for doing odd jobs involving lawn mowers (where he pretends to be stupid and names himself Jobe))

  • User profile image
    KosherCoder

    I remember in the early wysiwyg days - the promises of entire systems developed with nothing but drag and drop. I guess the software for my flying car will be made that way.

  • User profile image
    Massif

    If you want a better argument as to why we aren't using graphical languages, then you hit the nail yourself when talking about Abstraction.

    Any graphical language is going to be a big abstraction away from the hardware, and as such will inevitably suffer according to Joel's law of leaky abstractions. (If you believe Joel, which on this issue I do.)

  • User profile image
    figuerres

    WOW!


    This is one that could go on and on and on...

    in fact I will say this should be the "Launch point" for C9 to get with the DSL and Software Factory fokks and also www.CodeSmithTools.com and others like them.


    I think it may go back to the "Do what I mean, Not what I say" thing...

    the gap between the machine and the human brain is still *HUGE*

    even with things like speech recog and human face recog we are just barely getting somewhere.

    things like the VS IDE and how it builds a form, kind-of-a-code-gen but not really, not creative on any level etc... but "Good Enough" for a lot of use.

    and I am working with CodeSmith and Rocky's CSLA.Net

    it does a *LOT* for me but far from all the work....

    but perhaps that is part of how we might get there....

    like UNIX using a chain of smaller tools that each one does one thing and passes it on to the next....

    building a "Kind Of" software factory with us building specs at the start and adding to them as the factory generates a build and we see what went wrong.

    not "AI" or "Fully Capable" but able to do much of the "Grunt Work"
    and let us focus more on the business need and user need.

  • User profile image
    figuerres

    KosherCoder wrote:
    I remember in the early wysiwyg days - the promises of entire systems developed with nothing but drag and drop. I guess the software for my flying car will be made that way.


    as a former US Air Force aircraft mech. I find the idea of personal flight both attactive and scarry....

    Just imagine having someone run out of fuel in flight or....
    well at lest we know where they will park in any case Expressionless


    BOOM! Perplexed

  • User profile image
    Cybermagell​an

    As IDE's progress things are getting better...

    We have VISUAL studio...true still requires code, however that's something that makes things easier...then we have Expression Interactive? Desiger...drag drop, build...however STILL requires SOME hand coding...I think it's a matter of time, and cleaning up some languages but we'll see.

    Think about it this far though:

    Lucy's Baby (a skeleton name) is supposed to be of a 3 year old 3.3 Million Years ago. How long did it take for us to get THIS far?

  • User profile image
    Pace

    writing the code is my favourite bit though =(

    I love writing a procedure, which calls a function, which calls a stored proc, which returns something, that I move somewhere else...

    It wouldnt be programming if everything were drag and drop, you would have hundreds of thousands of nik-nak apps and every 13-99 year old nerd claiming to be a big shot.

    Its like two years ago. Almost everyone I met was a flippin web designer. I think its because they can drag an drop. I loved the reactions though once you mentioned ASP or PHP, you know, something that requires a bit of thought Wink

  • User profile image
    jsrfc58

    One of the things I always wanted to develop was a "visual parser". I find that although most compiler technology is highly optimized these days, it still plods along, scanning a character at a time (and then tries to turn those into tokens, etc.). It's time to rethink that methodology, because when it comes to debugging, several environments tend to act incredibly stupid when confronted with something as simple as a missing semicolon. The parser should be able to scan the code from the end to the beginning and in the traditional way, or in a completely different way altogether.

    I've thought a great deal about visual programming languages, and even drafted up several ideas at one point. The problem is not so much that it is not possible, but that you have to make a compromise at some point. For instance, if you have an equation like "x2 + y2 = z2", how do you represent that visually? You really can't, although perhaps you could have a visual component and then overlay the text on top of that.

  • User profile image
    Cannot​Resolve​Symbol

    I just tried LabView for the first time yesterday...  although it's not quite the same as programming in a language like C++ or Java, it's still pretty interesting (at least to me).  It's amazing how much you can do in its purely graphical environment (like subroutines and such).

    I'll really be impressed if you can use recursion in LabView...  might have to go try that later.

  • User profile image
    Tensor

    I'd say for the kind of thing I end up working on,  code generation can get 80% of the job done for you - its the other 20% that is the fiddly bits that take 80% of the time anyway that it can not do.

  • User profile image
    jsrfc58

    Massif wrote:
    If you want a better argument as to why we aren't using graphical languages, then you hit the nail yourself when talking about Abstraction.

    Any graphical language is going to be a big abstraction away from the hardware, and as such will inevitably suffer according to Joel's law of leaky abstractions. (If you believe Joel, which on this issue I do.)
    I agree, but only to a certain point. There has always been some level of abstraction in programming, however, whether you are using assembly language, C, C++, or using Javascript (lots of abstraction there). And yes, the more clever you try to get with your abstractions, the bigger the chance that you will come up with code/visuals that suffer performance losses. Of course, what also comes with it is what someone else mentioned above...an abundance of the old "everybody is a programmer!" mentality.

    Subroutines and functions can be represented graphically...perhaps by spacing them off into blocks/panels of code and showing the interconnections between them. Right now, this is usually done by color changes and indentation in the code, but showing the actual connections between functions is not done very well (if at all).

  • User profile image
    figuerres

    jsrfc58 wrote:
    
    Massif wrote: If you want a better argument as to why we aren't using graphical languages, then you hit the nail yourself when talking about Abstraction.

    Any graphical language is going to be a big abstraction away from the hardware, and as such will inevitably suffer according to Joel's law of leaky abstractions. (If you believe Joel, which on this issue I do.)
    I agree, but only to a certain point. There has always been some level of abstraction in programming, however, whether you are using assembly language, C, C++, or using Javascript (lots of abstraction there). And yes, the more clever you try to get with your abstractions, the bigger the chance that you will come up with code/visuals that suffer performance losses. Of course, what also comes with it is what someone else mentioned above...an abundance of the old "everybody is a programmer!" mentality.

    Subroutines and functions can be represented graphically...perhaps by spacing them off into blocks/panels of code and showing the interconnections between them. Right now, this is usually done by color changes and indentation in the code, but showing the actual connections between functions is not done very well (if at all).


    One "Vision" I have is of a visio-like drawing surface / prhaps like the VS 2005 Class diagram
    that deals with a class, it's methods and code like a kind of "Exploding Diagram"
    so for example you have a block that is a class, it has a "method" you click that and you get a new "page" that is the top-level view of that method with all the details "colapsed" into blocks like a very simple flow-chart

    so at this level of detail you see input-process-output
    and the top level "IF" "FOR" "WHILE" and "BLOCK" patern of the method.
    drill down on a block and it opens up more detail.
    at some point the drigram is a single bit of code and you are seeing statements and calls.

    done right it would be "Language nutral" a kind of "Code DOM" that could be output as MISL, C#, VB or any other language.

    the system should read a source file and build the graph or edit a graph and build a file.... round trip.

    I think this is 100% "doable" today but would need a bunch of time and money to build and test.

    anyone got some time to help build it??
    Big Smile

  • User profile image
    Cannot​Resolve​Symbol

    figuerres wrote:
    
    jsrfc58 wrote: 
    Massif wrote: If you want a better argument as to why we aren't using graphical languages, then you hit the nail yourself when talking about Abstraction.

    Any graphical language is going to be a big abstraction away from the hardware, and as such will inevitably suffer according to Joel's law of leaky abstractions. (If you believe Joel, which on this issue I do.)
    I agree, but only to a certain point. There has always been some level of abstraction in programming, however, whether you are using assembly language, C, C++, or using Javascript (lots of abstraction there). And yes, the more clever you try to get with your abstractions, the bigger the chance that you will come up with code/visuals that suffer performance losses. Of course, what also comes with it is what someone else mentioned above...an abundance of the old "everybody is a programmer!" mentality.

    Subroutines and functions can be represented graphically...perhaps by spacing them off into blocks/panels of code and showing the interconnections between them. Right now, this is usually done by color changes and indentation in the code, but showing the actual connections between functions is not done very well (if at all).


    One "Vision" I have is of a visio-like drawing surface / prhaps like the VS 2005 Class diagram
    that deals with a class, it's methods and code like a kind of "Exploding Diagram"
    so for example you have a block that is a class, it has a "method" you click that and you get a new "page" that is the top-level view of that method with all the details "colapsed" into blocks like a very simple flow-chart

    so at this level of detail you see input-process-output
    and the top level "IF" "FOR" "WHILE" and "BLOCK" patern of the method.
    drill down on a block and it opens up more detail.
    at some point the drigram is a single bit of code and you are seeing statements and calls.

    done right it would be "Language nutral" a kind of "Code DOM" that could be output as MISL, C#, VB or any other language.

    the system should read a source file and build the graph or edit a graph and build a file.... round trip.

    I think this is 100% "doable" today but would need a bunch of time and money to build and test.

    anyone got some time to help build it??


    Sounds like LabView, except more general-purpose (although I think you could do just about anything with it, there are many things that would be really difficult since it's meant for processing lab data).

  • User profile image
    JohnAskew

    I think the only problem is that it would be confining and inflexible.

    <confession>
    I remember how disappointed I was to get my Delphi 1 CD only to learn RAD didn't mean CASE and it was just a Pascal compiler...
    Expressionless
    </confession>

    I did end up using D2-D5 for 6 years before going to C#.


    CASE tools are something I've always been interested in, but now it isn't so attractive.

    I thought this post was going to bring up voice recognition - a vehicle that will be hand-in-glove for CASE to be widely adopted; perhaps.

  • User profile image
    figuerres

    JohnAskew wrote:
    I think the only problem is that it would be confining and inflexible.

    <confession>
    I remember how disappointed I was to get my Delphi 1 CD only to learn RAD didn't mean CASE and it was just a Pascal compiler...

    </confession>


    I am not talking "CASE" here...

    think about how a compiler works....

    we write code
    it is lexed and parsed into a Graph.
    the graph is processed in different ways to optimise the graph and find the best way to emit code chunks that can be turned into native code that runs.

    so in our head we have some form of "graph" of the working result
    -- ok we all do this differently but we have to "think out" how we will code a solution.

    we translate that mental model into a form we can persent to a tool that then transforms it into a graph.

    so let's build a program by building a model that is the same as the code we write. then let a compiler do it's thing.

    if you "speak" the model or "draw" the model or "type" the model you are still creating a model that has to be processed into a unit of code.

    but think of what Bill Hill said in his channel 9 nature walk ....
    we humans are visual animals, we learned to hunt and track with our eyes, we "Read" all the time.  we can often see a problem by visual clues without fully being consious of the process.

    so I think some form of interactive visual metaphor for a method can be a very powerfull tool.

    but it has to be able to reflect the detail and style the user wants to build ... if  it is not "rich" not "fine grained" then it will fail for sure.
    anything you can code up must be fully vsiaulized by the graph/model or it's not 100% and not ready to use.



Conversation locked

This conversation has been locked by the site admins. No new comments can be made.