How many languages you know?
-
@BC_Programmer said:
and a little x86 Assembly (which perhaps ironically I've only ever used in VB6...)
I didn't know you can use x86 assembly in VB6.@BC_Programmer said:
Why is that always how stuff is done with open source systems? Create some hard to use command-line program with a bajillion command-line options, then when people complain about ease of use some other person makes an ill-thought out GUI from hell that basically just let's you choose what switches to run the command-line program with, and call it a solved problem.(case and point: nmap and zenmap). How about they do, you know, what most normal developers would do and make the functionality a library- then have that console program access the library directly and have the GUI program access that library directly. And then the command line program can show the results from calls to that library as text and the GUI can use it appropriately for it's various UI elements, without ridiculously unnecessary parsing of the output of some command. a command line tool is not a "library" but they seem to get treated as such an awful lot sometimes.
I understand your point, however maybe you do not understand the UNIX point. Many programs in UNIX, you pipe commands together to make something, and can make other stuff too.In the case of my program: I tried to make it some output is on stdout and some on stderr, in case you need to read it, it should not be too difficult (you can ask for a list of fonts, or list of cards, or whatever). Also, it acts like an interpreter for some kind of programming language (although it has multiple syntaxes depending on what mode you are in, and the mode can change inside of one input file), but there is also interactive mode (you enter the commands interactively). The GUI could have some WYSIWYG style editor and menus and stuff, which generates the input file for the program and passes the correct switches and then print it. Magic Set Editor is other way around -- it is first designed as GUI, and then command-line mode is added too. But there is being alternative programs for in case different people prefer.
-
@zzo38 said:
I understand your point, however maybe you do not understand the UNIX point. Many programs in UNIX, you pipe commands together to make something, and can make other stuff too.
I think it has to be said, 30 years on, that the UNIX philosophy might be great for creating database servers, but it's complete shit for creating a friendly GUI.
-
@blakeyrat said:
I think it has to be said, 30 years on, that the UNIX philosophy might be great for creating database servers, but it's complete shit for creating a friendly GUI.
What about an angry GUI?
-
@boomzilla said:
@blakeyrat said:
I think it has to be said, 30 years on, that the UNIX philosophy might be great for creating database servers, but it's complete shit for creating a friendly GUI.
What about an angry GUI?IBM still has the edge there.
-
-
@zzo38 said:
I didn't know you can use x86 assembly in VB6.
Well, to be fair, it's not really assembly, but rather actually placing machine code (in hex) in a string variable and then looping through each character and creating a new string variable that contains the actual bytes for that hex string, then hacking about with CallWindowProc() to pass control to that machine code. (I would usually have the comments detail the Assembly code). Needless to say it is in retrospect very disgusting, and I only used it to try to make things like subclassing windows easier, which arguably is not something that should ever be done in VB6.
I understand your point, however maybe you do not understand the UNIX point. Many programs in UNIX, you pipe commands together to make something, and can make other stuff too.
Well, I know that, but What I mean is I've never really "got" why an actual program would use another program in that fashion- I can understand piping and redirection and whatnot in the case of a shell script, but to me I've always thought it would make more sense to have something be a library of some sort that could be used from both a command line program as well as a GUI program, instead of having the GUI program parse the output of the command line program/utility. Arguably the reason is that the usefulness of the command-line program itself only really becomes evident after it's already strongly coupled to character output, but given that most of these command line tools are open source I don't see why (and no doubt there is a reason) their functionality hasn't been turned into a library, rather than having other programs call it and parse output.I've always considered system() type calls to other executables as sort of kludgy for some reason.
-
@BC_Programmer said:
I've always thought it would make more sense to have something be a library of some sort that could be used from both a command line program as well as a GUI program, instead of having the GUI program parse the output of the command line program/utility. ... but given that most of these command line tools are open source I don't see why (and no doubt there is a reason) their functionality hasn't been turned into a library ...
Well, you can convert some of them into a library (my program should be able to be converted into a library too, without too much difficulty (make a change file, or use something like#define main TeXnicard_mainand#include "texnicard.c"and/or change other things to fit for the library), which if someone wants to do, of course it is allowed. However, sometimes it is licensing reasons, such as the GNU GPL is not the same as the GNU LGPL so that a program using a library with GNU GPL is also must be GNU GPL licensed as well. I don't know whether or not that is one reason. But regardless, I am not going to write my program as a library but someone can modify it if they want to, to do something like that??
