Sometimes passion's gonna away
Pages: 12
What do you do when you're not in the mood to work ? I mean, when you're tired or you have problems in real world, but you have to work, you must do your job. Or if it's not necessary, you must keep in fit, writing code and programming.
Which is the best method to bring the smile on your face when you program ? :)
Which is the best method to bring the smile on your face when you program ? :)
This is exactly why I don't program professionally.
My desire to code goes in and out. I find that when I code for so long, I tire of a project and want nothing to do with it for weeks/months. If I'm working professionally, that obviously isn't an option.
If I was a professional programmer I have no doubt I would not only hate my job, but I would lose my hobby as well.
My desire to code goes in and out. I find that when I code for so long, I tire of a project and want nothing to do with it for weeks/months. If I'm working professionally, that obviously isn't an option.
If I was a professional programmer I have no doubt I would not only hate my job, but I would lose my hobby as well.
I am a professional programmer for over a decade.
You have to put everything into perspective. If you believe, as I do, that the
ultimate goal in life is to be happy, then focus your energies on what is most
troubling and make it right. The rest can wait.
Sometimes I get sick of writing code too. Fortunately for me, my role is broad
enough that there are plenty of other things for me to do that are still aligned
with company goals. For example, if I just wrote a (largish) chunk of code to
do something, I might go back and write a Wiki page explaining how others
can use my code. Or, as I'm always juggling multiple projects at once, I might
go off and do a little upfront design on one of the other projects.
I definitely experience a "programming biorhythm" where I tire of writing code
or a tire of something else. The key is to try to do something else for a while.
You have to put everything into perspective. If you believe, as I do, that the
ultimate goal in life is to be happy, then focus your energies on what is most
troubling and make it right. The rest can wait.
Sometimes I get sick of writing code too. Fortunately for me, my role is broad
enough that there are plenty of other things for me to do that are still aligned
with company goals. For example, if I just wrote a (largish) chunk of code to
do something, I might go back and write a Wiki page explaining how others
can use my code. Or, as I'm always juggling multiple projects at once, I might
go off and do a little upfront design on one of the other projects.
I definitely experience a "programming biorhythm" where I tire of writing code
or a tire of something else. The key is to try to do something else for a while.
I often feel like this after solving a particularly hard problem. If I've been struggling with something for some time, it may take me somewhere between half that long to twice that long to get inspired again, depending on how hard the problem was. In that sense, the feeling is a lot like DOMS (http://en.wikipedia.org/wiki/Delayed_onset_muscle_soreness ).
Other times, it's completely different. There have been times during personal projects that I was unable to write for months at a time, not because of exhaustion, but because I knew the next part was terribly dull. I suppose you could avoid that in a professional environment by trying to get someone else to write that part.
I've programmed for a living in the past, and I can't say I've felt this. Then again, the stuff I did at that job was ten times easier than what I do for free (the money was accordingly not great). I'm sorry, but it's just not exciting to write in a language without buffer overflows and memory leaks.
I absolutely agree. If you can do something, anything, else while you're like that, do it. Write documentation, switch to a different project for a while, code something for fun, whatever, just don't touch the same project if you can avoid it. You'll actually be more productive by not writing at all.
Other times, it's completely different. There have been times during personal projects that I was unable to write for months at a time, not because of exhaustion, but because I knew the next part was terribly dull. I suppose you could avoid that in a professional environment by trying to get someone else to write that part.
I've programmed for a living in the past, and I can't say I've felt this. Then again, the stuff I did at that job was ten times easier than what I do for free (the money was accordingly not great). I'm sorry, but it's just not exciting to write in a language without buffer overflows and memory leaks.
| jsmith wrote: |
|---|
| The key is to try to do something else for a while. |
Last edited on
I get like this. I was supposed to be writing an emulator, but I got bored of trying to find numeric representations of each opcode and trying to fit everything together... When I started the project I wrote over a thousand lines of code in a few hours because I was happy with the prospect of having my own emulator, but now it's lost it's lustre. I'll finish eventually...
Usually an hour or two of playing games sorts me out; but obviously if you're a professional programmer there's not much you can do...
I guess that's why people like Dilbert and XKCD.
Usually an hour or two of playing games sorts me out; but obviously if you're a professional programmer there's not much you can do...
I guess that's why people like Dilbert and XKCD.
| I'll finish eventually... |
Depends on where you're working. If it's a company that produces software, management may be more aware of the needs of programmers. If you're writing software for internal use of a company that does something entirely different, however, you're not likely to get special treatment.
For me, the key to completing personal programming projects is to find the smallest piece
that gives me the biggest bang for my buck and code that first. Even though the last
10% might take 90% of the overall project, for me at least it feels like the end is nearer.
that gives me the biggest bang for my buck and code that first. Even though the last
10% might take 90% of the overall project, for me at least it feels like the end is nearer.
For me, it's to have some uncertainty about what I need to do next. If I've already written all or most of it in my head, then actually writing it becomes just a formality. If I'm writing because I need some tool, it will get finished. If I'm writing because I want to try something out, that's probably as much as I'll ever write. It's not like I have anything to prove to myself.
| I get like this. I was supposed to be writing an emulator |
Really? I've written NES/SNES emulators and NSF/SPC players. What system were you targetting? Are you on the nesdev scene?
**gets all excited to see someone from his other world**
@helios
No, I will. I'll finish it because I want to. At one point I deleted my whole project. But that felt like defeat, so I restored the files. In fact, now you said that, I feel more inclined to finish, as if to prove you wrong. You didn't do that on purpose, did you?
@Disch
I've seen you on a forum somewhere, when I was looking for information. But I'm doing the 8086. I think I'm in over my head, tbh, and emulation, while fun, isn't quite "my thing," but it's about as close as I can get to hardware (emulating it) for now. I was going to emulate the Genesis/Megadrive or Dreamcast, but there's too many games console emulators. I've not come across THAT many 16-bit 8086 emulators... The only ones I have, actually, were DOS emulators like DOSBox.
One thing that's got me stumped is graphics and sound. The 8086 itself I'm almost finished with but for the opcodes (although I imagine I'm going to have a horrendous amount of debugging)... I figure that's a couple thousand lines of code at the most (and that's my badly written pre-code, before I go through and optimize it to make it smaller), most of the instruction set seems to need at most about ten lines (so I can probably inline alot of them). Unfortunately I can't imagine how I'm going to do graphics and sound. I guess I could temporarily use someone else's graphics card emulator until I figure out how to write one...
No, I will. I'll finish it because I want to. At one point I deleted my whole project. But that felt like defeat, so I restored the files. In fact, now you said that, I feel more inclined to finish, as if to prove you wrong. You didn't do that on purpose, did you?
@Disch
I've seen you on a forum somewhere, when I was looking for information. But I'm doing the 8086. I think I'm in over my head, tbh, and emulation, while fun, isn't quite "my thing," but it's about as close as I can get to hardware (emulating it) for now. I was going to emulate the Genesis/Megadrive or Dreamcast, but there's too many games console emulators. I've not come across THAT many 16-bit 8086 emulators... The only ones I have, actually, were DOS emulators like DOSBox.
One thing that's got me stumped is graphics and sound. The 8086 itself I'm almost finished with but for the opcodes (although I imagine I'm going to have a horrendous amount of debugging)... I figure that's a couple thousand lines of code at the most (and that's my badly written pre-code, before I go through and optimize it to make it smaller), most of the instruction set seems to need at most about ten lines (so I can probably inline alot of them). Unfortunately I can't imagine how I'm going to do graphics and sound. I guess I could temporarily use someone else's graphics card emulator until I figure out how to write one...
Last edited on
| helios wrote: |
|---|
| I often feel like this after solving a particularly hard problem. If I've been struggling with something for some time, it may take me somewhere between half that long to twice that long to get inspired again, depending on how hard the problem was. |
This. I look back on the change log I have for the MUD I am making and it's off and on every 3-6 months...
i feel that too.
i think going out with my girlfriend would get the stress out after coding for a while, but another problem occurs i'm sick of my girlfriend so i go back on coding. then repeat.
i think it's bad for a beginner to feel this. huhuhu, so sad for me. i envy you professionals above.
i think going out with my girlfriend would get the stress out after coding for a while, but another problem occurs i'm sick of my girlfriend so i go back on coding. then repeat.
i think it's bad for a beginner to feel this. huhuhu, so sad for me. i envy you professionals above.
| The key is to try to do something else for a while. |
That's a good point ! Sometimes I listen music to calm my mind.
I'm not a professional programmer, but not a begginer, I programm for 2 years and I know programming languages, I' a student. The point is that the satisfaction makes my brain to work and to continue. It's better than a cup of cofee/tea, satisfaction is the main reason [in my opinion].
And when I do alorithmic jobs I stop programming and I start to think on the paper. My bugs are fixed and I can continue the work.
Really How do you begin making an emulator? I thought of trying to edit OoT but I never started ...
You grab a specification of the architecture and write something with equivalent behavior.
The specification would include things like opcode list, type of machine (register machine, stack machine, etc.), size of the operands, and so on.
There's basically two types of emulators: high and low level. LLE works by simulating the machine interfaces at the low level. Its advantage is that the code can be made more portable. HLE replicates guest interfaces using host interfaces. For example, using OpenGL graphics instead of whatever the guest uses. A LLE would instead simulate the component using the host's CPU. These are generally faster than LLE, but the code is more complex and less portable; LLE only assumes only the CPU exists, while HLE makes more assumptions.
The specification would include things like opcode list, type of machine (register machine, stack machine, etc.), size of the operands, and so on.
There's basically two types of emulators: high and low level. LLE works by simulating the machine interfaces at the low level. Its advantage is that the code can be made more portable. HLE replicates guest interfaces using host interfaces. For example, using OpenGL graphics instead of whatever the guest uses. A LLE would instead simulate the component using the host's CPU. These are generally faster than LLE, but the code is more complex and less portable; LLE only assumes only the CPU exists, while HLE makes more assumptions.
| You grab a specification of the architecture and write something with equivalent behavior. |
It's a little more than that; you're doing what it does, but in software so it'll normally be slower. But a (for example) 3 GHz processor emulating a 25MHz processor is obviously going to be faster unless the code is written really badly. I can't see that you could write could that bad though...
And aren't emulators that try to run most of the instructions on the host system normally referred to as virtual machines? Or am I getting confused..?
Last edited on
| you're doing what it does, but in software so it'll normally be slower |
The overall execution speed shouldn't matter, but the relative speeds of the virtual instructions should be maintained in relation to their real counterparts.
Hardware emulators are subsets of virtual machines. A virtual machine implements a machine in software, regardless of whether the machine exists or not. Hardware emulators are virtual machines that implement a real machine.
There are also emulators that don't emulate hardware. So, in other words, not all emulators are virtual machines, and not all virtual machines are emulators.
emulators ( ( hardware emulators ) ) virtual machines
Last edited on
I typed up a reply, but it seems the Internet decided to keep it.
I cba to type it again; so here is a summary:
I meant that it makes what you're doing a little more than what you said. You're not just copying the behaviour: you're doing it in software, which is slower and you tend to have to add nasty little hacks to get things to work properly; like this:
Personally I think that's pretty ugly; but it works.
I cba to type it again; so here is a summary:
| That doesn't make it more. It just makes it slower. |
I meant that it makes what you're doing a little more than what you said. You're not just copying the behaviour: you're doing it in software, which is slower and you tend to have to add nasty little hacks to get things to work properly; like this:
|
|
Personally I think that's pretty ugly; but it works.
It's still just replicating behavior. How it's done is irrelevant. A slow emulator isn't any less of an emulator.
Oh, by the way, cpu_registers::Xl and cpu_registers::Xh point to the same place for all values of X.
Oh, by the way, cpu_registers::Xl and cpu_registers::Xh point to the same place for all values of X.
Last edited on
The point of that is to emulate the way placing something into al is reflected in ax and (if they exist, which in this case, they do not) eax and rax, but with byte-ordering being irrelevant (provided _BIG_ENDIAN is defined/not defined correctly, which can be done on the fly using gcc on the command line or with a Makefile).
Are you telling me that moving e.g. 400 into cpu_registers::ax.al will move 400 into cpu_registers::bx.bl as well?
Ugh. Linux kernel takes ages to compile.
| Oh, by the way, cpu_registers::Xl and cpu_registers::Xh point to the same place for all values of X. |
Are you telling me that moving e.g. 400 into cpu_registers::ax.al will move 400 into cpu_registers::bx.bl as well?
Ugh. Linux kernel takes ages to compile.
Last edited on
Pages: 12