Our tools

Pages: 1234
@garob: you are weird.

I did that exactly once -- an assembler program -- during study hall in high school.

Yeah well when you have paper you can draw diagrams and stuff easily.
Sure. And even writing pseudo-code / algorithms on paper is fine too, but actual
code
is another story.
I actually hat using paper, of course every new 5 lines of code I compile so ...
I hat using paper too.

I would use paper but my handwriting is awful. It's easier to draw diagrams in a drawing program and write notes on the side.
I typically use Enterprise Architect before writing any code. I usually flesh out my UML model first, let the system spit out my classes, methods, etc... and go from there. Paper is only used if you have zero tools... and even then I wouldn't use it. Grab yourself a white board at least...
Last edited on
closed account (z05DSL3A)
I tend to use the simple tools for modeling; Index Cards, Post-it notes, Paper and whiteboards (with digital camera to keep records).

I have never found a CASE tool that does everything I want, the way I want to do it. I find myself fighting the tool or spending to much time with the minutia so that I generates code correctly, or the code generated is adorned with lots of meta data for round trip engineering which make the code ugly and god forbid you accidentally delete some of it...
Is not using paper a bad habit?Because normally I just jump in and create functions as I go along and build the program, bottom-top I think it is called?Like my current cars game, I still have to make a text feature for points.

Is that way of design bad?
In the real world and a somewhat structured Dev department, you'll be writing technical documentation prior to writing your functions, or your development lead will be... or analyst, whoever... You can't just get in there and code as you go. Time should always be spent planning or 5 weeks down the road you'll find that all this time you've backed yourself into a corner. Using paper is perfectly fine in some cases. It really just depends on what tools the developer is familiar with. Most of the tools, such as Enterprise Architect, Visual Paradigm, etc..., can be time consuming to learn and require specialized skills to get the most out of it. I've been modeling software for 10 years and as an analyst I typically use overkill requirements and modelling tools before I go into code. Whatever tools work best are the way to go.

bottom-top I think it is called

You mean bottom-up approach.

Is that way of design bad?

For a small program it's probably not a big deal for you, but most of the time it's going to be a problem where ever you work.
I've written a medium-sized (~20 kLOC) program from the bottom-up because when I started I had no idea which way the design would ultimately go. As the project progressed and the basic components were completed, I could picture the design better and better, until everything just fell nicely into place. I would compare to solving a jigsaw puzzle. You start by putting together small clusters and you get more general pieces as you progress. It was very rewarding, and I don't think it would have been the same if I had started from the top-down.

The order doesn't matter that much if the design is known from the beginning, though. It wouldn't be strange to write the top and bottom at the same time if you have several people working on the project.
You both pose good points, I will keep them at heart.
I don't see why not. Again, what's so great about an IDE? All it is, really, is a collection of little buttons that you can press to call other programs. With the command line, you just type. The only advantage I can think of is that you click buttons rather than type stuff, and to be honest, I don't see that as much of an advantage.


I agree someone proficient with Vi / ViM can do this just as fast, I mean faster than an IDE, eg.

my teacher is crazy fast with it, I just really CBF learning it.

like he seriously knows every command off by heart, regex to works. can easily just map keys to run and do certain things. It is by far faster than any IDE, but if your not a relic that's used to it. (I'm talking punchcard relic) Then an IDE is the only way to fly.

however Gedit + commandline not quite as good as the power of VI....

While I can't give any really good examples in C++ I can in java, Netbeans stepthrough debugging is the best debugging I have ever seen. it shows what every variables value is, what every loop equates to. Something gdb could never hope to do with a mouseclick and no user knowledge.
Last edited on
Codeblock+gdb shows all the local variables with 1 click
I know it has a step through just the same, But I never can see what any of the values/ loop conditions etc are...

Where do you get this?
mouseclick in the above post was a typo, was reffering to console/cmd line. I just said that really poorly :P
In Vi all I really know how to do is delete stuff, write the buffer to a file and close the program (some people don't know how to close it, apparently; and they get stuck in it unable to use their system (on vmode 3 OSes)).
I use gedit & gcc too, of course that is because I can't get SDL to load in windows but we will ignore that ....

Anywho does anyone know of a Mac OSx emulator?
you'll have to type a longer command line


Also I was looking for the post that had something that stated you could develop iPhone apps on windows and saw this, and I would like to state that you only have to use the arrow key in the command prompt(or whatever linux calls it) and you will summon you last command I have gone through a few days of flipping before it stopped.
does anyone know of a Mac OSx emulator?

OSx86 is an x86 port of OSX I think.

I would like to state that you only have to use the arrow key in the command prompt(or whatever linux calls it)

Firstly, it's "terminal" or "shell." Secondly, windows cmd does that too and thirdly, that's just Bash, not the terminal itself (xterm). Bash has a huge command history.

you'll have to type a longer command line

Is make all a "long" command?
"Command prompt" refers to the shell's state in which it waits for user input.
"Terminal" or "console", or "emulator" appended to either term, is the text display.
"Shell" is the program that interprets user input.
So, technically, what DrChill said was correct.
And how does chrisname know what terminal emulator DrChill was talking about?
Pages: 1234