Was only half serious, half joking...
But, you do bring up an interesting question: Do Microsoft programmers use an IDE? I bet they do... Here's all I could find on Wikepedia:
On the various Microsoft Windows platforms, command-line tools for development are seldom used.
Was only half serious, half joking...
But, you do bring up an interesting question: Do Microsoft programmers use an IDE? I bet they do... Here's all I could find on Wikepedia:
On the various Microsoft Windows platforms, command-line tools for development are seldom used.
What about for Windows itself? It's easy to use a GUI to develop simple programs but not so easy for complex configurable systems. They may use VC Studio. I'm not saying they don't. I have no inside knowledge, I'm just guessing. I use a GUI myself but I find that building complex programs that run on multiple platforms is much easier using a more batch-oriented build process. In any case, I think Catalina would be a better product if it followed common conventions and -D is a defacto-standard for defining symbols on the command line.
What about for Windows itself? It's easy to use a GUI to develop simple programs but not so easy for complex configurable systems. They may use VC Studio. I'm not saying they don't. I have no inside knowledge, I'm just guessing. I use a GUI myself but I find that building complex programs that run on multiple platforms is much easier using a more batch-oriented build process. In any case, I think Catalina would be a better product if it followed common conventions and -D is a defacto-standard for defining symbols on the command line.
David is correct: -Dis the defacto standard for defining symbols on the command line - this is why I chose it for defining PASM symbols. With Catalina, defining PASM symbols on the command line is very common, but most people will never find a need to define a C symbol on the command line. I accept that it is common for Makefiles to do so - but I'm still only half convinced, since most people will never use "make" to compile their propeller programs - they will instead use Code::Blocks (which has its own build engine built-in).
As for command line tools - the reason Windows command line tools are so little used is that they're just Smile. It is not in Micro$oft's interest to improve them since they'd be undercutting their own business model. But on Linux, where you have a choice of many decent command line tools, I don't think you'd find many "power users" who ever use anything else.
David is correct: -Dis the defacto standard for defining symbols on the command line - this is why I chose it for defining PASM symbols. With Catalina, defining PASM symbols on the command line is very common, but most people will never find a need to define a C symbol on the command line. I accept that it is common for Makefiles to do so - but I'm still only half convinced, since most people will never use "make" to compile their propeller programs - they will instead use Code::Blocks (which has its own build engine built-in).
As for command line tools - the reason Windows command line tools are so little used is that they're just Smile. It is not in Micro$oft's interest to improve them since they'd be undercutting their own business model. But on Linux, where you have a choice of many decent command line tools, I don't think you'd find many "power users" who ever use anything else.
Ross.
One thing I don't really understand about your comment is why defining PASM symbols has to be different than defining C symbols. Why can't both use -D in the same way?
One thing I don't really understand about your comment is why defining PASM symbols has to be different than defining C symbols. Why can't both use -D in the same way?
Several reasons, but the main one is that the PASM symbols are really only intended for configuring the Hardware Abstraction Layer (HAL) - and they actually have nothing to do with the C program. I do allow symbols to propagate from the HAL to the C program, but I wanted the PASM symbols to remain human readable (e.g. CLOCK, PC or DEMO) yet not conflict with any symbols that might commonly appear in C programs (e.g. CLOCK, PC or DEMO!). Otherwise someone could write (for example) a C program that relies on the symbol PC and this program would mysteriously behave differently from one compilation to another! My solution was to propagate the symbol from the HAL to C, but prefix them with "__CATALINA_" - so the PASM symbol PC becomes the C symbol __CATALINA_PC - and any existing C symbol PC is undisturbed. I could have done it the other way round (e.g. made -D PC define the C symbol PC and the HAL symbol __HAL_PC) but think of all the extra typing I would have had to do!
Several reasons, but the main one is that the PASM symbols are really only intended for configuring the Hardware Abstraction Layer (HAL) - and they actually have nothing to do with the C program. I do allow symbols to propagate from the HAL to the C program, but I wanted the PASM symbols to remain human readable (e.g. CLOCK, PC or DEMO) yet not conflict with any symbols that might commonly appear in C programs (e.g. CLOCK, PC or DEMO!). Otherwise someone could write (for example) a C program that relies on the symbol PC and this program would mysteriously behave differently from one compilation to another! My solution was to propagate the symbol from the HAL to C, but prefix them with "__CATALINA_" - so the PASM symbol PC becomes the C symbol __CATALINA_PC - and any existing C symbol PC is undisturbed. I could have done it the other way round (e.g. made -D PC define the C symbol PC and the HAL symbol __HAL_PC) but think of all the extra typing I would have had to do!
As we are often talking standards here how about this:
I have have just written the ultimate killer app for the Prop, that program that is going to make every MCU user in the world want to use a Prop above all else. I have written in C. Because I want everyone to benefit I want Catalina users and propgcc users and ICC users and so on to be able to easily compile and run it after a quick download from OBEX.
I have no idea, nor do I care, what IDE the users may have or prefer or even if they have an IDE so a a quick "make" should build it.
I need to use a lot of symbol defining to to get the code to compile under all the major propeller C compilers or indeed other C platforms compilers whilst testing on a PC.
It would help if the compiler command line options were similar.
Maybe I am just an old dumb windoze user these days. But, I don't care about command line programs - they are yesteryears way. The modern way is by GUIs. Code::Blocks solves this so I am happy to stay away from the command line. I view *nix the same way. Isn't that why we now have Android???
If you look at the Arduino, doesn't it use a GUI to make it simple for the users. If I am not mistaken, they don't even refer to programs anymore, but rather refer to them as sketches. Everything to remove the user from the intricies. (I am not an arduino user, so I could be wrong here - it's just what of have seen on the periphery).
Cluso is correct.The download stats for Catalina show Windows downloads outnumber Linux downloads by 10:1 - and most Windows users would never even have heard of make (even if they are sometimes forced to resort to the command line for some obscure operations). If you also assume that some substantial fraction of Linux users (at least those under the age of 40!) would probably also prefer to use an IDE if one were available (which it is), then this means only something like 1 in 20 C programmers might ever need to use a command line option.
Much as we old fogeys might like to pretend otherwise, C programming on the Propeller will take place via an IDE - or not at all. But this is actually a good thing, since it means that users can just download plain old C code from the OBEX and compile it. They won't need to know about make or ranlib or addr2line or ar or readelf or any of the other arcana that belong to the days of relics like us
This will be true even if I decide it is worth changing Catalina to use -D instead of -W-D - such a detail would be of interest to only about 1 user in 20. Possibly even less - only you, me and David Betz seem at all interested so far!
I don't care about command line programs - they are yesteryears way.
I do love this never ending command line vs IDE debate.
If I want to travel from A to B do I take that economy seat in a Jumbo jet
or the train/bus/tram. Then again I could use my car, or motorcycle or bicycle.
Then again it might be as well to walk. Or perhaps I end up having to swim or
crawl through a swamp. It all depends on distance and what's in between.
How about if I like to build my own furniture from flat packs. Probably I
don't need much more than an electric screwdriver. But if I want to do more
custom jobs I might need a whole array of screwdrivers, spanners and other
tools. Perhaps manually operated is better in many cases.
The invention the the airplane did not make those ancient wheels "yesteryear"
or redundant. The invention of the electric screwdriver did not make hand tools
useless.
See where I'm going with this? We should not throw out a good thing just
because we have a new thing. Like the ancient wheel the command line is damn
useful and should be perfected. Sadly MS has not bothered much with that so
everyone thinks command lines are stuck in the time of CP/M and DOS.
I have no problem with IDE's if people want to use them and I often use them
myself. My biggest gripe is that there are so many of the damn things all
different. For example:
Propeller - Prop Tool or BST or PZST or now Code::Blocks/Eclipse/Netbeans
PIC chips - MPLAB
ATMEL chips - AVR studio.
X chips - A customized Eclipse
Android - A different customized Eclipse
Qt programming - Qt Creator
C# on Linux - MonoDevelop
STM32 - Whatever it is that only runs on Windows.
Pascal - Lazarus
And so on....
Given my work and hobby activities I end up having to hop between a number of
these quite regularly. Having to keep up with the quirks of all of them is a
real pain in the...
I end up praying for a simple.
# make
# make run
which during a dev session reduces to just hitting up arrow and return or I
attach it to a button in an editor.
Luckily Cluso, you have a command line interface, the text box I am typing this
into. I don't have to download, install and open up some funky "Cluso IDE",
after having installed Windows because it only runs there, and figure out which
buttons to press to say something to you. And god help me if the "Cluso IDE"
does not have the buttons for the ideas I want to convey:)
You know, this is one thing that I dislike about the Catalina community. Not only are requests often met with rejection even when they are reasonable and would serve to improve the product. Also, many of the Catalina "fans" then jump in to say how stupid the idea is and how their way of working is the only one that makes sense and everyone who does something else is stupid.
Hi David,Yes, I had the choice of using -D for PASM symbols or for C symbols (there are various technical reasons why I didn't want the same flag to define a symbol for both). I suppose I could revert to using -D for C symbols and use another flag for PASM symbols. It seems a minor point, but if there is enough opinion one way or another it is easy to change. It seems to me that not many people use the command line anyway. You and I are probably the last of a dying breed :)Ross.
I'm another command liner.. I prefer to manage my own makefiles, I basically use the same methods (with Git version control etc) as I do for all other software projects. I was also a bit surprised by how -D was used for a different purpose than "standard".. but it's no big deal for me as it's easy enough to handle via my makefiles (I set CFLAGS or similar just one place and use the variable where needed, so it matters little. I'm used to compilers having slightly different options, although -D isn't usually one of them. No big deal though, as I said.).
You know, this is one thing that I dislike about the Catalina community. Not only are requests often met with rejection even when they are reasonable and would serve to improve the product. Also, many of the Catalina "fans" then jump in to say how stupid the idea is and how their way of working is the only one that makes sense and everyone who does something else is stupid.
Huh? C'mon, David. You asked why, so I explained. Your response was "whatever". Where I live, that is generally considered quite a rude and dismissive answer, and I think I showed quite a lot of restraint by not getting annoyed by such a response when I took the time and trouble to try and answer your question.
If you weren't interested in the answer, then why did you ask the question in the first place? Just to score some kind of obscure debating point?
Also, I didn't reject your suggestion - I said I would change it in the next release if anyone else agreed it was a good idea. Are you seriously suggesting I should just agree to make a change that will take me several days of work - and add no benefit whatsoever for most users - just because one person asks for it?
What the heck is wrong with these forums these days?
Huh? C'mon, David. You asked why, so I explained. Your response was "whatever".
If you weren't interested in the answer, then why did you ask the question in the first place?
Ross.
I wasn't primarily talking about your response although I see there is now at least one other person who said a traditional -D would be helpful (Heater) so I assume it will be implemented in the next release.
This is a bit simplistic. I've developed a lot of Unix software in my time, and written and modified (and fought with!) a lot of versions of make and Makefiles. In my experience it is hardly ever the case that you can move a program from one platform to another - or one compiler to another - without needing to make at least some changes to the Makefile - and sometimes very subtle ones (Got a space instead of a tab? - fail! Missing a blank line? - fail!).
People who think Makefiles are as easy as you seem to be implying have probably never written a complex one - although they may well have used one that someone else has spent a lot of skull sweat on to make work right. This whole issue is why make files are not often written directly any more. These days one would tend to use a makefile generator like the GNU autotools. Unfortunately, for novice users this just brings yet another layer of complexity to the problem.
The alternative (again, especially for novices) is to use an IDE - one of the key things that IDEs do for you is avoid this whole issue. I agree that it is annoying that every IDE on every platform is different. If there was a perfect one no doubt we would all use it - but I have never found one.
I wasn't primarily talking about your response although I see there is now at least one other person who said a traditional -D would be helpful (Heater) so I assume it will be implemented in the next release.
David, I added to my original response after first posting it, so we seem to have cross-posted a bit. However, I won't go back and edit it again - that would only make things even more confusing.
To be honest, I'm finding these forums very tiresome at the moment, and after your response I'm now not really inclined to go to the effort required to make such a change. Perhaps I'll reconsider tomorrow, but for now, I'm calling it a day.
This is a bit simplistic. I've developed a lot of Unix software in my time, and written and modified (and fought with!) a lot of versions of make and Makefiles. In my experience it is hardly ever the case that you can move a program from one platform to another - or one compiler to another - without needing to make at least some changes to the Makefile - and sometimes very subtle ones (Got a space instead of a tab? - fail! Missing a blank line? - fail!).
People who think Makefiles are as easy as you seem to be implying have probably never written a complex one - although they may well have used one that someone else has spent a lot of skull sweat on to make work right. This whole issue is why make files are not often written directly any more. These days one would tend to use a makefile generator like the GNU autotools. Unfortunately, for novice users this just brings yet another layer of complexity to the problem.
The alternative (again, especially for novices) is to use an IDE - one of the key things that IDEs do for you is avoid this whole issue. I agree that it is annoying that every IDE on every platform is different. If there was a perfect one no doubt we would all use it - but I have never found one.
Ross.
I don't understand why some people here seem to think we need to resolve the question of "IDE or command line". To me it isn't a choice of one or the other. I use both and I think both have value. Why do we insist on always degenerating into a "my way is better than yours" debate?
I use GUI environments and like them. Generally, they are easier for the fact that one doesn't need to maintain anywhere near the number of details and or state information to progress on a project.
(I like GUI environments better when they are managed, freeing me from files entirely, or nearly entirely, leaving just objects. Nice way to work, and that's how I work in MCAD land more often than not.)
I also use command line interfaces. I like them too, and I came up on 8bitters and UNIX. Never did mind if they vary. Always did mind when they are poorly documented, or work in inconsistent ways. Verbosity on the command line can be painful too.
To me, this change boils down to a chunk of time to do the change, debug, release.. There is finite time and it competes with features. Personally, I would take new features in Catalina over command line cleanups. Any user of sufficient experience to use a command line can very easily deal with variances in said commands, and has done so over their computing life so far.
I am the one who advocated for "Catalina Command Prompt", and it works great, I can learn what is going on, test things, and then just run the rather posh GUI otherwise, keeping my mental investment in the tools lean. That rocks hard.
GIven how we see Catalina developed to date, a change that impacts the progress of features is a sales job. Some discussion on worth is entirely warranted. That change will quite literally put some nice feature into the future. No worries on that, but one must ask, "Is that worth it?", which is being asked and quite rationally. I vote no.
To clarify, if it were actually broken, then I would vote yes, but it isn't broken. Works as designed and documented. Reasonably well documented I might add.
To me, this change boils down to a chunk of time to do the change, debug, release.. There is finite time and it competes with features. Personally, I would take new features in Catalina over command line cleanups. Any user of sufficient experience to use a command line can very easily deal with variances in said commands, and has done so over their computing life so far.
I understand and agree with this philosophy. What I object to is all of the people who took this as an opportunity to essentially say that command line tools have no value and should not be given any thought or effort. I don't think I've ever said that the way someone works is wrong but the GUI advocates refuse to acknowledge any way but their own as having any value at all.
It doesn't matter though. Ross said he'd make the change if he had two people ask for it and I think two have asked for it at this point. Since almost everyone here uses the GUI pretty much exclusively, changes to the command line syntax won't have any impact on anyone.
Yeah, that's rough. I too feel frustration over "who cares about the command line?"
The thing is, without the command line folks, there would be no great GUI environments. The core of computing hasn't changed much. Today, we've boot strapped GUI environments to the point where people can simply ignore the "voodoo" under the hood, and that's fine, and something I am glad we can do. I often CHOOSE to do this, just for my own time management.
Why can't we just get more hobby time?
But, I cannot justify marginalizing basic computing skills. They are invaluable, often they are NECESSARY too, particularly where we've not boot strapped the GUI into functionality that meets general requirements.
What we've never really done in GUI land is develop SYNTAX. That, to me, is the biggest limitation. We've managed blocks, connectors, boxes and all manner of clever things to attempt to encode what is essentially language into the GUI and it's all been a big FAIL, for the most part. Edit: Not a fail in terms of helping people get stuff done. We progress nicely there. It's a fail in terms of replacing the fundamental computing elements we need to build out and boot strap new things to the point where most anybody can make use of, and benefit from, that's all.
Because of that reality, the command line is the de-facto language of note for computing. We won't see that change anytime soon, until we see what is basic computing change anytime soon, and a lot of PhD's are writing thesis on how that may potentially occur sometime in the distant future.
Here are a couple of great references to grok something about command line computing:
That author wrote a GREAT essay on this aspect of computing. Recommended because it's a good, solid, fun read, and because there is some culture there, hinted at with broad strokes, worth knowing about to better understand one another. A lot of the friction we see here is that we simply do not understand one another well, and we are communicating with text. Let's keep that in mind. I botch it often. We all do.
I must assemble the other one, coming soon to my blog, as it's long.
Edit: It's up there. That author captures perfectly where the friction is. From where I stand, simply understanding that, whatever our personal position is, helps to put comments into context. We need one another more than we don't, and that's what I'm trying to communicate here.
I understand and agree with this philosophy. What I object to is all of the people who took this as an opportunity to essentially say that command line tools have no value and should not be given any thought or effort. I don't think I've ever said that the way someone works is wrong but the GUI advocates refuse to acknowledge any way but their own as having any value at all.
I don't think this is a fair interpretation of what's been said. Personally, I still prefer to use a command line - but I've come to realize (especially over the last year or so) that I am now part of a fairly small minority. Command lines may remain the interface of choice for power users, but most others will simply not use a command line no matter what it offers. They may try it once or twice, but they won't persevere with it long enough to learn all the obscure syntax that those of us who grew up with them regard as perfectly normal. This doesn't mean such things don't have value - it is simply facing reality that the potential benefit of improving them is small, and that the time required to do so may in fact be better spent elsewhere.
It doesn't matter though. Ross said he'd make the change if he had two people ask for it and I think two have asked for it at this point. Since almost everyone here uses the GUI pretty much exclusively, changes to the command line syntax won't have any impact on anyone.
Yes, I did. But since we all seem to now agree that it affects so few users, and also because I am in the middle of some new features and enhancements that I want to release as soon as I can finish them, it won't make in the next release. Sorry.
Yes, I did. But since we all seem to now agree that it affects so few users, and also because I am in the middle of some new features and enhancements that I want to release as soon as I can finish them, it won't make in the next release. Sorry.
Well, maybe some future release then. :-)
Just out of curiosity, why didn't you just use some other letter for defining assembly symbols, maybe -K? Then both could be expressed concisely.
Re command line vs non command line, I think Catalina has the best of both worlds. When I wrote an IDE for catalina in VB.Net, all I did was use check boxes and radio buttons to select options rather than typing them in. I took that IDE further by doing things like translating Basic into C, and then translating different variants of C, but it is still terribly convenient to write those modules as command line programs that are then 'shelled' from an IDE.
The command line nature of Catalina means that it can work with my IDE and code::blocks and any other front end you might choose. For my IDE, and indeed for code::blocks, the command line nature of the program can be completely hidden from the user. Or you can shell a dos window if you want to. I like that flexibility.
And if Ross changes the syntax for the command line, no problem for my IDE as it will be just a couple of lines of vb.net code.
Well, maybe some future release then. :-)
Just out of curiosity, why didn't you just use some other letter for defining assembly symbols, maybe -K? Then both could be expressed concisely.
That's probably what I will end up doing. I just naturally used -D ... which I guess is as good an argument for making this change as any
That's probably what I will end up doing. I just naturally used -D ... which I guess is as good an argument for making this change as any
Well, as I said when I first made the observation that maybe -D should have it's traditional meaning, this isn't a blocking issue for me. In fact, if it never gets done it won't be the end of the world. I just thought becoming a bit more standard would be a benefit for those who are trying to adopt Catalina and are used to the conventions of other compilers. I can certainly type -W-D until the more traditional syntax is implemented (if ever).
David: You have really taken the GUI comments out of context. I just explained why I am not interested in the command line - I very explicitly said it maybe just me. I have moved into the modern world where GUIs rain supreme by volume of uses (as borne out here too).
I have a mate who has a production package, originally written in an old form of basic. It used a command line interface. When I helped him rewrite in VB3/4/5/6 one user refused to move to the new GUI. THis meant all the extras included in the new VB code had to be back-ported into the old basic code. What a pain. It held up progress on the new code. I must say that the new VB code was slower, but then PCs have improved in speed. Finally that user has succumbed to the modern GUI interface and the old basic support for one in a hundred users could be dropped.
I dare say that if *nix had a common GUI, then more users would use *nix than they currently do.
Just for the record, I am foremost a pasm/assembler programmer by choice. That means I love the nuts and bolts. But I don't really care for yesteryear tools. Just my opinion, just as everyone else is entitled to theirs.
Is it just me, or does it seem the GCC group (now more than one) are trying to find fault with Catalina. And is this in order to push their own barrow??? Certainly food for thought. This forum is really degenerating since GCC started!
Is it just me, or does it seem the GCC group (now more than one) are trying to find fault with Catalina. And is this in order to push their own barrow??? Certainly food for thought. This forum is really degenerating since GCC started!
I don't even know how to respond to this. I have never said anything against Catalina. I have made suggestions about how it could be improved. I hope you make suggestions as to how PropGCC can be improved as well. I'm not interested in arguments about whose compiler is better. I'm working on GCC because I want to help Parallax not because I want to hurt Catalina.
But I don't really care for yesteryear tools. Just my opinion, just as everyone else is entitled to theirs.
Calling something "yesteryear tools" is a derogatory term in my opinion intended to belittle anyone who choses to use those tools. This is exactly what I'm talkiing about.
Calling something "yesteryear tools" is a derogatory term in my opinion intended to belittle anyone who choses to use those tools. This is exactly what I'm talkiing about.
Well, I might not have chosen the term "yesteryear tools" - but I did call them "arcana that belong to the days of relics like us".
There is a lot of high feeling floating around because the GCC team is currently trying to showcase their stuff. Whether it was your intention or not, raising minor issues like command line syntax incompatibilities with "other compilers" at this point does make it look a lot like you are trying to raise a point of differentiation between GCC and Catalina. But whether or not that was not your intention, I think we have dealt with it and I for one am happy to move on.
However, from my perspective this is all good because it has meant a lift in the number of downloads of Catalina - which is currently the onlyfully functional ANSI C compiler available for the Propeller, providing both a command line and a GUI (sorry, have to get my sales up while this is still the case!).
Comments
But, you do bring up an interesting question: Do Microsoft programmers use an IDE? I bet they do... Here's all I could find on Wikepedia:
On the various Microsoft Windows platforms, command-line tools for development are seldom used.
David is correct: -D is the defacto standard for defining symbols on the command line - this is why I chose it for defining PASM symbols. With Catalina, defining PASM symbols on the command line is very common, but most people will never find a need to define a C symbol on the command line. I accept that it is common for Makefiles to do so - but I'm still only half convinced, since most people will never use "make" to compile their propeller programs - they will instead use Code::Blocks (which has its own build engine built-in).
As for command line tools - the reason Windows command line tools are so little used is that they're just Smile. It is not in Micro$oft's interest to improve them since they'd be undercutting their own business model. But on Linux, where you have a choice of many decent command line tools, I don't think you'd find many "power users" who ever use anything else.
Ross.
Several reasons, but the main one is that the PASM symbols are really only intended for configuring the Hardware Abstraction Layer (HAL) - and they actually have nothing to do with the C program. I do allow symbols to propagate from the HAL to the C program, but I wanted the PASM symbols to remain human readable (e.g. CLOCK, PC or DEMO) yet not conflict with any symbols that might commonly appear in C programs (e.g. CLOCK, PC or DEMO!). Otherwise someone could write (for example) a C program that relies on the symbol PC and this program would mysteriously behave differently from one compilation to another! My solution was to propagate the symbol from the HAL to C, but prefix them with "__CATALINA_" - so the PASM symbol PC becomes the C symbol __CATALINA_PC - and any existing C symbol PC is undisturbed. I could have done it the other way round (e.g. made -D PC define the C symbol PC and the HAL symbol __HAL_PC) but think of all the extra typing I would have had to do!
Ross.
Well, you asked!
Ross.
I have have just written the ultimate killer app for the Prop, that program that is going to make every MCU user in the world want to use a Prop above all else. I have written in C. Because I want everyone to benefit I want Catalina users and propgcc users and ICC users and so on to be able to easily compile and run it after a quick download from OBEX.
I have no idea, nor do I care, what IDE the users may have or prefer or even if they have an IDE so a a quick "make" should build it.
I need to use a lot of symbol defining to to get the code to compile under all the major propeller C compilers or indeed other C platforms compilers whilst testing on a PC.
It would help if the compiler command line options were similar.
If you look at the Arduino, doesn't it use a GUI to make it simple for the users. If I am not mistaken, they don't even refer to programs anymore, but rather refer to them as sketches. Everything to remove the user from the intricies. (I am not an arduino user, so I could be wrong here - it's just what of have seen on the periphery).
Cluso is correct.The download stats for Catalina show Windows downloads outnumber Linux downloads by 10:1 - and most Windows users would never even have heard of make (even if they are sometimes forced to resort to the command line for some obscure operations). If you also assume that some substantial fraction of Linux users (at least those under the age of 40!) would probably also prefer to use an IDE if one were available (which it is), then this means only something like 1 in 20 C programmers might ever need to use a command line option.
Much as we old fogeys might like to pretend otherwise, C programming on the Propeller will take place via an IDE - or not at all. But this is actually a good thing, since it means that users can just download plain old C code from the OBEX and compile it. They won't need to know about make or ranlib or addr2line or ar or readelf or any of the other arcana that belong to the days of relics like us
This will be true even if I decide it is worth changing Catalina to use -D instead of -W-D - such a detail would be of interest to only about 1 user in 20. Possibly even less - only you, me and David Betz seem at all interested so far!
Ross.
I do love this never ending command line vs IDE debate.
If I want to travel from A to B do I take that economy seat in a Jumbo jet
or the train/bus/tram. Then again I could use my car, or motorcycle or bicycle.
Then again it might be as well to walk. Or perhaps I end up having to swim or
crawl through a swamp. It all depends on distance and what's in between.
How about if I like to build my own furniture from flat packs. Probably I
don't need much more than an electric screwdriver. But if I want to do more
custom jobs I might need a whole array of screwdrivers, spanners and other
tools. Perhaps manually operated is better in many cases.
The invention the the airplane did not make those ancient wheels "yesteryear"
or redundant. The invention of the electric screwdriver did not make hand tools
useless.
See where I'm going with this? We should not throw out a good thing just
because we have a new thing. Like the ancient wheel the command line is damn
useful and should be perfected. Sadly MS has not bothered much with that so
everyone thinks command lines are stuck in the time of CP/M and DOS.
I have no problem with IDE's if people want to use them and I often use them
myself. My biggest gripe is that there are so many of the damn things all
different. For example:
Propeller - Prop Tool or BST or PZST or now Code::Blocks/Eclipse/Netbeans
PIC chips - MPLAB
ATMEL chips - AVR studio.
X chips - A customized Eclipse
Android - A different customized Eclipse
Qt programming - Qt Creator
C# on Linux - MonoDevelop
STM32 - Whatever it is that only runs on Windows.
Pascal - Lazarus
And so on....
Given my work and hobby activities I end up having to hop between a number of
these quite regularly. Having to keep up with the quirks of all of them is a
real pain in the...
I end up praying for a simple.
# make
# make run
which during a dev session reduces to just hitting up arrow and return or I
attach it to a button in an editor.
Luckily Cluso, you have a command line interface, the text box I am typing this
into. I don't have to download, install and open up some funky "Cluso IDE",
after having installed Windows because it only runs there, and figure out which
buttons to press to say something to you. And god help me if the "Cluso IDE"
does not have the buttons for the ideas I want to convey:)
-Tor
Huh? C'mon, David. You asked why, so I explained. Your response was "whatever". Where I live, that is generally considered quite a rude and dismissive answer, and I think I showed quite a lot of restraint by not getting annoyed by such a response when I took the time and trouble to try and answer your question.
If you weren't interested in the answer, then why did you ask the question in the first place? Just to score some kind of obscure debating point?
Also, I didn't reject your suggestion - I said I would change it in the next release if anyone else agreed it was a good idea. Are you seriously suggesting I should just agree to make a change that will take me several days of work - and add no benefit whatsoever for most users - just because one person asks for it?
What the heck is wrong with these forums these days?
Ross.
Heater,
This is a bit simplistic. I've developed a lot of Unix software in my time, and written and modified (and fought with!) a lot of versions of make and Makefiles. In my experience it is hardly ever the case that you can move a program from one platform to another - or one compiler to another - without needing to make at least some changes to the Makefile - and sometimes very subtle ones (Got a space instead of a tab? - fail! Missing a blank line? - fail!).
People who think Makefiles are as easy as you seem to be implying have probably never written a complex one - although they may well have used one that someone else has spent a lot of skull sweat on to make work right. This whole issue is why make files are not often written directly any more. These days one would tend to use a makefile generator like the GNU autotools. Unfortunately, for novice users this just brings yet another layer of complexity to the problem.
The alternative (again, especially for novices) is to use an IDE - one of the key things that IDEs do for you is avoid this whole issue. I agree that it is annoying that every IDE on every platform is different. If there was a perfect one no doubt we would all use it - but I have never found one.
Ross.
David, I added to my original response after first posting it, so we seem to have cross-posted a bit. However, I won't go back and edit it again - that would only make things even more confusing.
To be honest, I'm finding these forums very tiresome at the moment, and after your response I'm now not really inclined to go to the effort required to make such a change. Perhaps I'll reconsider tomorrow, but for now, I'm calling it a day.
Ross.
(I like GUI environments better when they are managed, freeing me from files entirely, or nearly entirely, leaving just objects. Nice way to work, and that's how I work in MCAD land more often than not.)
I also use command line interfaces. I like them too, and I came up on 8bitters and UNIX. Never did mind if they vary. Always did mind when they are poorly documented, or work in inconsistent ways. Verbosity on the command line can be painful too.
To me, this change boils down to a chunk of time to do the change, debug, release.. There is finite time and it competes with features. Personally, I would take new features in Catalina over command line cleanups. Any user of sufficient experience to use a command line can very easily deal with variances in said commands, and has done so over their computing life so far.
I am the one who advocated for "Catalina Command Prompt", and it works great, I can learn what is going on, test things, and then just run the rather posh GUI otherwise, keeping my mental investment in the tools lean. That rocks hard.
GIven how we see Catalina developed to date, a change that impacts the progress of features is a sales job. Some discussion on worth is entirely warranted. That change will quite literally put some nice feature into the future. No worries on that, but one must ask, "Is that worth it?", which is being asked and quite rationally. I vote no.
To clarify, if it were actually broken, then I would vote yes, but it isn't broken. Works as designed and documented. Reasonably well documented I might add.
It doesn't matter though. Ross said he'd make the change if he had two people ask for it and I think two have asked for it at this point. Since almost everyone here uses the GUI pretty much exclusively, changes to the command line syntax won't have any impact on anyone.
The thing is, without the command line folks, there would be no great GUI environments. The core of computing hasn't changed much. Today, we've boot strapped GUI environments to the point where people can simply ignore the "voodoo" under the hood, and that's fine, and something I am glad we can do. I often CHOOSE to do this, just for my own time management.
Why can't we just get more hobby time?
But, I cannot justify marginalizing basic computing skills. They are invaluable, often they are NECESSARY too, particularly where we've not boot strapped the GUI into functionality that meets general requirements.
What we've never really done in GUI land is develop SYNTAX. That, to me, is the biggest limitation. We've managed blocks, connectors, boxes and all manner of clever things to attempt to encode what is essentially language into the GUI and it's all been a big FAIL, for the most part. Edit: Not a fail in terms of helping people get stuff done. We progress nicely there. It's a fail in terms of replacing the fundamental computing elements we need to build out and boot strap new things to the point where most anybody can make use of, and benefit from, that's all.
Because of that reality, the command line is the de-facto language of note for computing. We won't see that change anytime soon, until we see what is basic computing change anytime soon, and a lot of PhD's are writing thesis on how that may potentially occur sometime in the distant future.
Here are a couple of great references to grok something about command line computing:
http://www.cryptonomicon.com/beginning.html
That author wrote a GREAT essay on this aspect of computing. Recommended because it's a good, solid, fun read, and because there is some culture there, hinted at with broad strokes, worth knowing about to better understand one another. A lot of the friction we see here is that we simply do not understand one another well, and we are communicating with text. Let's keep that in mind. I botch it often. We all do.
I must assemble the other one, coming soon to my blog, as it's long.
Edit: It's up there. That author captures perfectly where the friction is. From where I stand, simply understanding that, whatever our personal position is, helps to put comments into context. We need one another more than we don't, and that's what I'm trying to communicate here.
Ross.
Just out of curiosity, why didn't you just use some other letter for defining assembly symbols, maybe -K? Then both could be expressed concisely.
The command line nature of Catalina means that it can work with my IDE and code::blocks and any other front end you might choose. For my IDE, and indeed for code::blocks, the command line nature of the program can be completely hidden from the user. Or you can shell a dos window if you want to. I like that flexibility.
And if Ross changes the syntax for the command line, no problem for my IDE as it will be just a couple of lines of vb.net code.
That's probably what I will end up doing. I just naturally used -D ... which I guess is as good an argument for making this change as any
I have a mate who has a production package, originally written in an old form of basic. It used a command line interface. When I helped him rewrite in VB3/4/5/6 one user refused to move to the new GUI. THis meant all the extras included in the new VB code had to be back-ported into the old basic code. What a pain. It held up progress on the new code. I must say that the new VB code was slower, but then PCs have improved in speed. Finally that user has succumbed to the modern GUI interface and the old basic support for one in a hundred users could be dropped.
I dare say that if *nix had a common GUI, then more users would use *nix than they currently do.
Just for the record, I am foremost a pasm/assembler programmer by choice. That means I love the nuts and bolts. But I don't really care for yesteryear tools. Just my opinion, just as everyone else is entitled to theirs.
Is it just me, or does it seem the GCC group (now more than one) are trying to find fault with Catalina. And is this in order to push their own barrow??? Certainly food for thought. This forum is really degenerating since GCC started!
Well, I might not have chosen the term "yesteryear tools" - but I did call them "arcana that belong to the days of relics like us".
There is a lot of high feeling floating around because the GCC team is currently trying to showcase their stuff. Whether it was your intention or not, raising minor issues like command line syntax incompatibilities with "other compilers" at this point does make it look a lot like you are trying to raise a point of differentiation between GCC and Catalina. But whether or not that was not your intention, I think we have dealt with it and I for one am happy to move on.
However, from my perspective this is all good because it has meant a lift in the number of downloads of Catalina - which is currently the only fully functional ANSI C compiler available for the Propeller, providing both a command line and a GUI (sorry, have to get my sales up while this is still the case!).
Ross.