4 ms·

I don't think the audience for this exists. People with a mind capable of programming are also capable of learning syntax, especially since there are so many la

by Paul_S 14y ago

I don't think the audience for this exists. People with a mind capable of programming are also capable of learning syntax, especially since there are so many languages now with lightweight syntax. I fear these attempts shall remain confined to educational toys for kids, which are really cool, but I don't see them used widely in schools.

delinka 14y ago
I'm a programmer. I started learning syntax as a kid. I write code all the time. I adapt to new language concepts and syntax. I can use vim effectively. I can tolerate an IDE. I still cannot get ideas out of my head and into the computer as fast as I "need" to. I believe something graphical, visual, or the like is going the right direction. I want graphical touch programming (not typing syntax) for organizing logic into programs but I need the power to manipulate details. To me, it's not a question of ability to learn syntax, it's about speed- how fast can I get this great new idea into an app? I believe ultimately it will be by manipulating objects on a touchscreen or in some 3D holographic thing.
- yxhuvud 14y ago
  I'd suggest you learn how to touch type if you care about getting stuff out of your head fast. Just because it has a graphical interface doesn't mean the process of telling the computer what to do will be faster. The reason for this is simple - there are still just as much stuff you need to tell the computer for it to be able to do what it must.
- ef4 14y ago
  It would indeed be great to have some "higher bandwidth" way to interact with a program under development. And better graphical tools could clearly increase the bandwidth out from computer to programmer. But for bandwidth into the computer, there's still nothing that can compete with text. Consider the space of meaningful words you can type at 100wpm, and how awkward it would be to offer a similar number of choices at a similar speed on two (or even three) dimensional display.
  - JoeAltmaier 14y ago
    Depends on the language. Writing boilerplace C++ header files, which duplicate everything in the source is certainly a low-yield way to communiate with a computer. Graphics could help there; let me drag methods up and down the hierarchy and have it automatically refactor (change arguments and scope of references without me typing). Create new fields with a right-click and choose a type with a default name; drag a reference to a closure etc. Even this: if I could navigate different views on the same source e.g. without comments; without debugging prints and asserts; with references and scopes delineated. This can make it faster to find where to type. But I guess thats bandwidth out again; ok.
Argorak 14y ago
Isn't KISMET (http://www.unrealengine.com/features/kismet/ http://www.unrealengine.com/features/kismet/) an example that there is a real need for that? Game scripts are definitely non-trivial, but they are not that complex either. Also, in the case of KISMET, the programming involved is flow-oriented, where visual representations might definitely give you more clarity.
- Paul_S 14y ago
  Except KISMET doesn't scale well. When I see the baroque contraptions game designers create it makes my blood boil at the inefficiency but that's the cost of a faster design->code turnaround. Runtime efficiency sacrificed for development time savings.
  - Arelius 14y ago
    Part of that however is a symptom of Kismet's current implementation. I imagine an improved Kismet will greatly improve things.
    - Argorak 14y ago
      As far as I understood him, some of the performance problems also stem from overly complex implementations by level designers. But I guess the big advantage of KISMET is that is allows level designers to do logic _at all_ without reading into the finer details of UScript or the scripting language at hand. I must admit, my only experience with level building was some amateur work in UnrealEdit - the original, 1998 one. And there, I found triggers and stuff really annoying.
      - Arelius 14y ago
        A huge cause ause of the overly complex implementations by level designers is a direct result of problems with Kismet. For instance, I had to put together a 5 node system just to compare two bools for equality. Additionally UnrealScript isn't really made for "scripting" particularly not for the level. For instance, the whole game/editor needs to be shutdown/reloaded to recompile scripts. In that sense it's much less script and much more virtual machine'd language with gameplay specific features.

by Paul_S 14y ago

delinka 14y ago

I'm a programmer. I started learning syntax as a kid. I write code all the time. I adapt to new language concepts and syntax. I can use vim effectively. I can tolerate an IDE. I still cannot get ideas out of my head and into the computer as fast as I "need" to. I believe something graphical, visual, or the like is going the right direction. I want graphical touch programming (not typing syntax) for organizing logic into programs but I need the power to manipulate details. To me, it's not a question of ability to learn syntax, it's about speed- how fast can I get this great new idea into an app? I believe ultimately it will be by manipulating objects on a touchscreen or in some 3D holographic thing.

yxhuvud 14y ago
I'd suggest you learn how to touch type if you care about getting stuff out of your head fast. Just because it has a graphical interface doesn't mean the process of telling the computer what to do will be faster. The reason for this is simple - there are still just as much stuff you need to tell the computer for it to be able to do what it must.
ef4 14y ago
It would indeed be great to have some "higher bandwidth" way to interact with a program under development. And better graphical tools could clearly increase the bandwidth out from computer to programmer. But for bandwidth into the computer, there's still nothing that can compete with text. Consider the space of meaningful words you can type at 100wpm, and how awkward it would be to offer a similar number of choices at a similar speed on two (or even three) dimensional display.
- JoeAltmaier 14y ago
  Depends on the language. Writing boilerplace C++ header files, which duplicate everything in the source is certainly a low-yield way to communiate with a computer. Graphics could help there; let me drag methods up and down the hierarchy and have it automatically refactor (change arguments and scope of references without me typing). Create new fields with a right-click and choose a type with a default name; drag a reference to a closure etc. Even this: if I could navigate different views on the same source e.g. without comments; without debugging prints and asserts; with references and scopes delineated. This can make it faster to find where to type. But I guess thats bandwidth out again; ok.

Argorak 14y ago

Isn't KISMET (http://www.unrealengine.com/features/kismet/ http://www.unrealengine.com/features/kismet/) an example that there is a real need for that? Game scripts are definitely non-trivial, but they are not that complex either. Also, in the case of KISMET, the programming involved is flow-oriented, where visual representations might definitely give you more clarity.

Paul_S 14y ago
Except KISMET doesn't scale well. When I see the baroque contraptions game designers create it makes my blood boil at the inefficiency but that's the cost of a faster design->code turnaround. Runtime efficiency sacrificed for development time savings.
- Arelius 14y ago
  Part of that however is a symptom of Kismet's current implementation. I imagine an improved Kismet will greatly improve things.
  - Argorak 14y ago
    As far as I understood him, some of the performance problems also stem from overly complex implementations by level designers. But I guess the big advantage of KISMET is that is allows level designers to do logic _at all_ without reading into the finer details of UScript or the scripting language at hand. I must admit, my only experience with level building was some amateur work in UnrealEdit - the original, 1998 one. And there, I found triggers and stuff really annoying.
    - Arelius 14y ago
      A huge cause ause of the overly complex implementations by level designers is a direct result of problems with Kismet. For instance, I had to put together a 5 node system just to compare two bools for equality. Additionally UnrealScript isn't really made for "scripting" particularly not for the level. For instance, the whole game/editor needs to be shutdown/reloaded to recompile scripts. In that sense it's much less script and much more virtual machine'd language with gameplay specific features.