3 ms·

A year ago I wrote TEA cipher implementation with it for fun: https://github.com/dchest/drakon-tea https://github.com/dchest/drakon-tea (Pictures: https://git

by dchest 13y ago

A year ago I wrote TEA cipher implementation with it for fun: https://github.com/dchest/drakon-tea https://github.com/dchest/drakon-tea (Pictures: https://github.com/dchest/drakon-tea/tree/master/pics https://github.com/dchest/drakon-tea/tree/master/pics) It was painful.

jonahx 13y ago
What was painful about it? Was the language itself cumbersome to use, or was it the problem with the graphical editor software?
- dchest 13y ago
  The language is actually C (you can also use Python, etc. I think the original underlying language was a variant of Oberon). The painful part was the graphical editor, or, I'd say, the idea of using graphics for programming instead of text. Imagine aligning all these rectangles and then realizing that you got a part of algorithm wrong: now you'll have to realign everything! I think it would be much easier to edit some textual representation, and then use a program to convert it to the graphical one, if you want to read it this way.
  - donquichotte 13y ago
    This reminds me of a coworker who uses National Instruments' LabView's graphical programming capabilities to parse text files. Graphical programming is just not suitable for some tasks.
    - angdis 13y ago
      I see this a lot in LabVIEW projects (using it for things in which it is cumbersome). I think it is a symptom of the "golden hammer syndrome". LabVIEW is really, really efficient for some things and people become highly proficient at it. Unfortunately, those same folks are apt to use it for things in which it is ill-advised like text-parsing. I like to think of graphical programming languages as DSL's: when they're aimed at the right problem, they're like a hot knife through butter compared to a general purpose tool. But when you start using DSL's for things in which they are not intended you end up with nightmarishly obscure codebases.

by dchest 13y ago

jonahx 13y ago

What was painful about it? Was the language itself cumbersome to use, or was it the problem with the graphical editor software?

dchest 13y ago
The language is actually C (you can also use Python, etc. I think the original underlying language was a variant of Oberon). The painful part was the graphical editor, or, I'd say, the idea of using graphics for programming instead of text. Imagine aligning all these rectangles and then realizing that you got a part of algorithm wrong: now you'll have to realign everything! I think it would be much easier to edit some textual representation, and then use a program to convert it to the graphical one, if you want to read it this way.
- donquichotte 13y ago
  This reminds me of a coworker who uses National Instruments' LabView's graphical programming capabilities to parse text files. Graphical programming is just not suitable for some tasks.
  - angdis 13y ago
    I see this a lot in LabVIEW projects (using it for things in which it is cumbersome). I think it is a symptom of the "golden hammer syndrome". LabVIEW is really, really efficient for some things and people become highly proficient at it. Unfortunately, those same folks are apt to use it for things in which it is ill-advised like text-parsing. I like to think of graphical programming languages as DSL's: when they're aimed at the right problem, they're like a hot knife through butter compared to a general purpose tool. But when you start using DSL's for things in which they are not intended you end up with nightmarishly obscure codebases.