Especially in "java" but other programming languages too. What's the hardest thing you got told to create?
I'm about to start my second year and am wondering what sort of stuff may await me and see if I should start practising now or not.
asif49 9 Posting Whiz in Training
Narue 5,707 Bad Cop Team Colleague
Perhaps you should simply study the material and take assignments as they come. Professors don't generally give assignments that are far removed from previously taught material.
asif49 9 Posting Whiz in Training
I've studied most of the material but just wanted to know how hard java programs can get like even for work assignments after you leave uni.
Currently the hardest I've had to do was to make a chat system between several different computers which are connected via comport cables. Was pretty difficult in my opinion.
Narue 5,707 Bad Cop Team Colleague
wanted to know how hard java programs can get
Java is a general purpose language that's used extensively in the classroom and the real world, the range of difficulty will be approximately from Hello World to infinity. Your question is silly.
asif49 9 Posting Whiz in Training
If it was to infinity they'd ask you to build a universe with java or something unrealistic like that.
My question isn't silly, your responses definitely are though.
Netcode commented: be serious with what you want -1
Netcode 33 Veteran Poster
Talking about difficulty, it may even depend on your level of knowledge.
Currently the hardest I've had to do was to make a chat system between several different computers which are connected via comport cables. Was pretty difficult in my opinion.
The same chat system may be a joke to someone who's more knowledgeable so the extent to which java prgramming can be difficult is infinity because it depends on the developer's knowledge and what the project entails
Taywin 312 Posting Virtuoso
Hmm... I didn't really use Java that much during my undergraduate... I used some in my graduate but not enough... Though, I can do it if I want to. I don't really find that coding is that hard, but to solve a problem by coming up with a right algorithm is difficult. It once took me almost the whole assignment time (2 1/2 weeks) to finish a LISP program in partial order in advanced AI class (graduate level)... The professor gave us a template and we had to fill in the whole thing. Even worse, we were competing each other to see whose program is the fastest including the professor's code! No one won this competition but professor...
mustafaneguib 1 Junior Poster in Training
i had to build a compiler for c- programming language for my compiler construction course. i developed it in c++. it was quite tough. i had to do lexical analysis, type checking, etc...
not an easy thing to make in 4 months on your own, and on top of that i had to make an auction website for my web programming course, and also a virtual machine which interpreted MIPS 32 architecture instruction set. all this was to be done in the same semester.
Joe Shmoe 33 Light Poster
I had to write a triply nested recursive algorithm to draw squares on the screen. Your probably thinking how hard could it possibly be to just draw squares on the screen? Well look at the code below. Anyway, I don't understand why CS teachers emphasize recursion so much. In my opinion it just over complicates the problem. I also don't like the idea of pushing so much data onto the stack when a simple for loop will do the trick. All of my CS teachers (had three so far) taught recursion even before talking about loops. Just think about how little recursion is used in the average everyday program. Almost never. Loops are used in pretty much every program, yet the teachers think they are being so clever because they did it Recursively. It's the same thing with calculus - Do you ever use it in real life? No. But for some reason, these people feel the need to teach meaningless (well not meaningless, but you know what I mean) overly complex things.
Sorry for the rant. I hope you guys would agree.
Here is the program anyway. It's horribly constructed because I had to do it recursively. It's python btw.
from turtle import *
ifEven = 0
"""
This function will setup the window and turtle
pre: turtle is included
post: screen setup
"""
def init():
setup(600, 600)
speed('fastest')
home()
left(180)
"""
This is 3/4 square drawing function
pre: the depth and size have been inputed
post: the square is drawn
"""
def drawhelper(depth, size):
if depth != 0:
ifEven = depth % 2
if(ifEven):
pencolor('green')
else:
pencolor('red')
forward(size/2)
right(90)
forward(size)
right(90)
forward(size)
right(90)
forward(size/2)
right(180)
forward(size/2)
left(90)
forward(size)
left(90)
forward(size)
left(90)
forward(size/2)
right(180)
forward(size/4)
left(90)
drawhelper(depth - 1, size/2)
ifEven = depth % 2
if(ifEven):
pencolor('green')
else:
pencolor('red')
right(90)
forward(-size/4)
forward(size/2)
right(90)
forward(size * 3/4)
left(90)
drawhelper(depth - 1, size/2)
ifEven = depth % 2
if(ifEven):
pencolor('green')
else:
pencolor('red')
right(90)
forward(-size * 3/4)
left(90)
forward(-size/2)
forward(size/2)
right(90)
forward(size)
right(90)
forward(size * 3/4)
left(90)
drawhelper(depth - 1, size/2)
ifEven = depth % 2
if(ifEven):
pencolor('green')
else:
pencolor('red')
right(90)
forward(-size * 3/4)
left(90)
forward(-size)
left(90)
forward(-size/2)
"""
This will draw the full square
pre: depth and size
post: the whole square drawn
"""
def draw(depth,size):
drawhelper(depth,size)
forward(size/2)
right(90)
forward(size/2)
drawhelper(depth,size)
"""
Main function
none
none
"""
def main():
init()
depth = int(input("Type the depth: "))
size = int(input("Type the size: "))
draw(depth,size)
main()
Rashakil Fol 978 Super Senior Demiposter Team Colleague
I had to write a triply nested recursive algorithm to draw squares on the screen.
By "triply nested recursive algorithm", I take it you refer to a function which calls itself in three places.
Your probably thinking how hard could it possibly be to just draw squares on the screen? Well look at the code below.
Judging by the extremely simple program below, it's quite easy.
Anyway, I don't understand why CS teachers emphasize recursion so much. In my opinion it just over complicates the problem.
The reason it's emphasized is because it's very useful. It also forces students to understand how their programming language (in particular, regarding the scoping of local variables and function parameters in recursive functions) actually works. Recursion is used all the time in all kinds of software, so it's not like they're going to ignore it.
I also don't like the idea of pushing so much data onto the stack when a simple for loop will do the trick.
A simple for loop won't do the trick. Go ahead and try converting the program below to a simple for loop. You'd have to manually implement a stack of state variables. A recursive implementation expresses the behavior in a much more straightforward manner, because you can follow the behavior of the function in a straightforward manner.
All of my CS teachers (had three so far) taught recursion even before talking about loops. Just think about how little recursion is used in the average everyday program. Almost never.
Actually, it's more like the case that you almost never use recursion because you're no good at it. Recursion happens all the time. In typical software, it happens without you trying to make it happen. I write or edit code that uses recursion every day. It is so easy to roll off examples where you'd use it: traversing a DOM tree, parsing a language, deleting a section of a btree in parallel, writing a program to analyze your project's header file inclusion graph, etc etc etc.
Here are ways you can get recursion when you don't mean to do it. If you have a function X that calls a function Y it takes as a parameter, that parameter Y could end up calling X again. For example, X's job might be to acquire resources and pass a handle to them to Y, and then release them when Y returns. Then Y needs to do a similar thing so it uses X for some other purpose. Then X is getting called recursively. It also happens a lot when you have callbacks that you generally intend to use across threads. Suppose the function X has it so that Y evaluates on a given thread, and has Y calls some callback that then has the original thread (which X ran on) gets the data and does stuff with it. This sort of callback situation, which you are expected to be comfortable with, will result in mutual recursion if the target thread happens to be the same as the one you are on. You can't avoid it.
Loops are used in pretty much every program, yet the teachers think they are being so clever because they did it Recursively.
The teachers don't think they're being clever. They're not going to sit around teaching you loops because anybody can write a loop. The idea of a loop is straightforward. Your biggest problem right now is that since you're ignorant of new ideas, you can't use them, and therefore they're not useful to you, and if they're not useful, why bother learning them? Do you see the fallacy here? There is no reason to bitch about being taught recursion unless you're actually bad at it, in which case you need to man up and practice it. (And it is the case that you're bad at it. You don't really understand how it works. I can tell by the code you posted.) You'll suck at programming if you don't get better at things you find uncomfortable.
It's the same thing with calculus - Do you ever use it in real life? No.
Yes. I do use calculus in real life. I use it a lot.
But for some reason, these people feel the need to teach meaningless (well not meaningless, but you know what I mean) overly complex things.
Calculus is not complicated.
Joe Shmoe 33 Light Poster
A simple for loop won't do the trick. Go ahead and try converting the program below to a simple for loop. You'd have to manually implement a stack of state variables. A recursive implementation expresses the behavior in a much more straightforward manner, because you can follow the behavior of the function in a straightforward manner.
That's funny because someone else told me that too, but I actually found it was easier doing it using for loops. I did it both ways. I don't understand how that is a more straightforward manner. It makes you have to think about how it's going to unwind after the recursion is done. With a for loop, the thinking is very linear.
Your biggest problem right now is that since you're ignorant of new ideas, you can't use them, and therefore they're not useful to you, and if they're not useful, why bother learning them? Do you see the fallacy here? There is no reason to bitch about being taught recursion unless you're actually bad at it, in which case you need to man up and practice it.
I just wrote that program, so yes, I can use recursion. I am just saying that it is easier for me and for the computer to use for loops instead of recursion. Why fill up the stack?
parsing a language
I have written my own language interpreter, and never used recursion.
Here is the loop version. It's in a different language (BASIC):
#COMPILE EXE
#DIM ALL
GLOBAL xMax AS LONG, yMax AS LONG
'This function will make it fullscreen by getting the width and hight of the monitor
'Pre: none
'Post: window set up
SUB init()
LOCAL hWnd AS DWORD
CONSOLE SET LOC 0, 0
DESKTOP GET SIZE TO xMax, yMax
GRAPHIC WINDOW "Squares", 0, 0, xMax, yMax TO hWnd
GRAPHIC ATTACH hWnd, 0, REDRAW
GRAPHIC COLOR %RGB_WHITE, 0
GRAPHIC CLEAR
GRAPHIC REDRAW
CONSOLE SET FOCUS
END SUB
'This function will draw a single square
'Pre: x and y position, the size, and whether the square is red or not
'Post: a single square drawn on the screen
SUB makeSquare(x AS INTEGER, y AS INTEGER, squSize AS INTEGER, isRed AS LONG)
squSize /= 2
IF isRed THEN
GRAPHIC BOX (x-squSize, y-squSize) - (x+squSize, y+squSize), 0, -1, %RGB_RED, 0
ELSE
GRAPHIC BOX (x-squSize, y-squSize) - (x+squSize, y+squSize), 0, -1, %RGB_GREEN, 0
END IF
END SUB
'The main function
'Pre: The input is different. It will ask for the size of the smallest (deepest) square and the number of levels
'Post: Final product. This one also fills the squares.
FUNCTION PBMAIN () AS LONG
LOCAL x AS INTEGER
LOCAL y AS INTEGER
LOCAL i AS INTEGER
LOCAL sizeInc AS INTEGER
LOCAL theSize AS INTEGER
LOCAL theLevels AS INTEGER
init
sizeInc = 1
INPUT "Type the size of the smallest (deepest) square (enter for default): ", theSize
INPUT "Type the number of levels (enter for default): ", theLevels
IF theSize = 0 THEN theSize = 10
IF theLevels = 0 THEN theLevels = 8
PRINT "Processing. . ."
WHILE i < theLevels
FOR y = theSize * sizeInc TO yMax STEP theSize * (sizeInc * 2)
FOR x = theSize * sizeInc TO xMax STEP theSize * (sizeInc * 2)
makeSquare x, y, theSize * sizeInc, i MOD 2
NEXT x
NEXT y
sizeInc *= 2
INCR i
WEND
GRAPHIC REDRAW
PRINT "Complete."
PRINT "Any key. . ."
WAITKEY$
END FUNCTION Joe Shmoe 33 Light Poster
Rashakil, how did you learn how to program? Did you start off by taking a class or did you teach yourself in an unofficial manner? I taught myself since I was 10 years old and I think that's probably why there's a difference in the ways we would approach the problem. It's probably because when I taught myself, I always used for loops and have become used to using them. For you, I am guessing you learned recursion fairly early on, and then therefore find it easier to think about problems that way.
I don't see why there's a problem doing it non-recursively if it is easier for me doing it that way.
Rashakil Fol 978 Super Senior Demiposter Team Colleague
It makes you have to think about how it's going to unwind after the recursion is done. With a for loop, the thinking is very linear.
Because you have a problem that can be done linearly with filled-in squares. It's a perfectly legitimate way to solve that particular problem. Now make it so that the width of the smaller squares is 1/3 the width the next bigger square instead of 1/2.
And under recursion, the thinking is very logical. All you have to think is "my 3/4-square (with n levels underneath) has three half-size 3/4-squares attached to it here, here, and here (with n-1 levels underneath).
I have written my own language interpreter, and never used recursion.
How are you parsing expressions like (1 + 2 * (3 + 4))? How are you representing them? How are you handling control structures within control structures? I'm going to guess this language interpreter is incredibly simplistic.
Rashakil, how did you learn how to program? Did you start off by taking a class or did you teach yourself in an unofficial manner? I taught myself since I was 10 years old and I think that's probably why there's a difference in the ways we would approach the problem. It's probably because when I taught myself, I always used for loops and have become used to using them. For you, I am guessing you learned recursion fairly early on, and then therefore find it easier to think about problems that way.
I started "programming" when I spent my time inventing sorting algorithms on a deck of cards for fun before I entered kindergarten. I started programming on a computer around when I was 12, when I made spreadsheets for things like running NCAA basketball pools. Then I learned some HTML, became a web standards zealot for a while, and barely touched Javascript. Then I got a TI-83+ calculator in 9th grade and wrote a lot of programs for that (never using recursion because there aren't local variables). Around that time I also taught myself Q-BASIC and started trying to read a book on C++ but couldn't get far into it. Then in the summer before 11th grade, I got an HP-49G and started programming it using Reverse Polish Lisp, a stack-based language like Forth or Factor. By this time I was comfortable with recursion, having nonchalantly used it myself without anybody bothering to teach to me that it's some kind of special thing that you can do. The next summer I read straight through Programming Perl without having a computer to really program it on, wrote video games in Q-BASIC such as Tetris and wrote some plugins for a certain game server using Java. I made another go at C++ and got lost. Then, a year or so later, I went to college and the CS II course that I started with taught C++. I got comfortable with C++ in that course, and also I taught myself Scheme and Haskell and taught myself all sorts of things about type systems and parsers and purely functional data structures and programming language design while ignoring all my CS classes. Then I graduated and got a job writing web applications in C#. Then I quit that job and got another job writing database engine software in C++. And that's what I'm doing right now.
I don't write everything recursively and certainly for the problem you're showing, if you just asked me to rip out a program that outputted the desired picture, I'd have done it the same way as you. If the size ratio was anything but 1/2 I'd just do it recursively, still by drawing filled-in squares on top of the lower level's filled-in squares but the easiest way would still be to do it recursively.
I don't see why there's a problem doing it non-recursively if it is easier for me doing it that way.
The point is not that you should do things recursively that you don't need to do recursively, it's that you should get good at doing things recursively so that you can program the things that need to be done recursively. Otherwise you'll only be able to write simplistic sh*tty programs.
I can tell you're not comfortable with recursion, you only barely managed to eke out a recursive algorithm that works. One way I know is that you're bitching about it, and you wouldn't bitch about it if it were easy. Another way I know is that you've made ifEven a global variable and are reinitializing it after every recursive call, when it would be so much simpler just to have it be a local variable within the function itself.
(I also have no idea why your code retraces its steps over and over again. What's the point of going forward(-size/2) and then forward(size/2) over parts you've already written? Is there something wonky about the "pen" in this API that requires this?)
Rashakil Fol 978 Super Senior Demiposter Team Colleague
Let's make a fair comparison by writing a program that has access to the same draw-me-a-filled-in-square API and uses recursion. Let's say we have a drawBox(x1, y1, x2, y2, outlineColor) function as our drawing primitive that draws a filled in square with an outline.
Let's implement drawFigure(levels, size, x, y, ratio) that draws the figure with "size" being the size of the central square, (x, y) being the center point, "ratio" being the ratio of square sizes (which is just 2 in your programs). So drawFigure(levels, size, size, size, 2) would implement your program.
def drawFigure(levels, size, x, y, ratio):
if levels >= 0:
h = size / 2
sr = size / ratio
drawFigure(levels - 1, sr, x - h, y - h, ratio)
drawFigure(levels - 1, sr, x + h, y - h, ratio)
drawFigure(levels - 1, sr, x - h, y + h, ratio)
drawFigure(levels - 1, sr, x + h, y + h, ratio)
drawBox(x - h, y - h, x + h, y + h, 'green' if levels % 2 else 'red')And that's it!
That's a lot simpler than a for loop inside a for loop inside a while loop.
Joe Shmoe 33 Light Poster
How are you parsing expressions like (1 + 2 * (3 + 4))? How are you representing them? How are you handling control structures within control structures? I'm going to guess this language interpreter is incredibly simplistic.
It's pretty simplistic. Control structures within control structures are handled by just using a stack. No, it does not parse expressions like that. I could implement that, but didn't take the time. I wrote it a few years back, so there are many things about it that I could improve.
Here is a simple nested loop example in my language:
define:value i
define:value j
->while [value] i < 10
+ i
out I is = [value] i [newline] $
->while [value] j < 3
+ j
out J is = [value] j [newline] $
->repeat 2
out major test [newline] $
<-
<-
->repeat 2
out yay [newline] $
<-
setvalue j 0
<-
AnyKey Press any key to get out. . . $I started "programming" when I spent my time inventing sorting algorithms on a deck of cards for fun before I entered kindergarten.
I have trouble believing that.
The example you made does seem simpler than the iterative way. Would doing it this way effect the speed at all or do you think it would execute the same speed both ways?
Taywin 312 Posting Virtuoso
Would doing it this way effect the speed at all or do you think it would execute the same speed both ways?
It depends on how you construct your code. Do you know how to compute the time cost for an algorithm? Assuming everything is the same and comparing your code with the recursive that Rashkil gave, his would be faster.
One major downside for recursive is that it is limited. If the number of loop is very high, recursive is not the way to go because it could max out the memory usage. However, if it is doing the job that you are doing here, recursive would be appropriate because it is more efficient and logically intuitive.
Rashakil Fol 978 Super Senior Demiposter Team Colleague
The example you made does seem simpler than the iterative way. Would doing it this way effect the speed at all or do you think it would execute the same speed both ways?
It would execute with the same speed. It draws the same number of squares, including all the ones that are occulted by larger squares.
If you wanted a faster implementation, ...
def drawFigure(levels, size, x, y, ratio):
draw3(levels, size, x, y, ratio, 1, 1, true)
def draw3(levels, size, x, y, ratio, dx, dy, fourth_too):
if levels >= 0:
h = size / 2
sr = size / ratio
draw3(levels - 1, sr, x + dx * h, y + dy * h, ratio, dx, dy, false)
draw3(levels - 1, sr, x - dx * h, y + dy * h, ratio, -dx, dy, false)
draw3(levels - 1, sr, x + dx * h, y - dy * h, ratio, dx, -dy, false)
if fourth_too:
draw3(levels - 1, sr, x - dx * h, y - dy * h, ratio, -dx, -dy, false)
drawBox(x - h, y - h, x + h, y + h, 'green' if levels % 2 else 'red')That only draws the squares that are visible.
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.