|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On December 21 2013 10:30 Maero wrote:Yep. Any operations on a python string must result in a new string. Good illustration Cyx. Edit: Just to contribute something: One way around this is to turn the string into a list instead, modify an element, and rejoin. e.g.
>>> str = "string"
>>> str = list(str)
>>> str[2] = 'a'
>>> str = ''.join(str)
>>> str
'staing'
But the way in your book is probably just about the same as far as efficiency goes, if not a little better.
Thanks for this. I'm having a general tough time learning coding things period. Did you guys run into this problem too when you first started to learn how to program?
For example, one of the exercises in the book was to create a mock character point distribution system (i.e. str, vit, int, dex etc.) from a limited pool of points. It took me like an hour and a half just to figure out not to use lists but dictionary pair sequences because with my current knowledge it's just a lot simpler and easier to modify the values in that type of sequence. It took me like another 2 more hours to figure out how to actually make the code work the way I wanted it to. My problem is my working memory sucks. It's difficult for me to keep track of all the values and conditions of everything. Sometimes I write out the returned values in a loop on a scratch pad just to remember everything... Do you keep track of every line of code in your head?
Usually, what makes it click for is just fixing the logic of my pseudo code or realizing exactly what it is I'm actually trying to do (If that makes sense). And then my code became shorter and simpler.
|
Sure, nobody starts out a genius. A lot of these things come with experience, but it's always important to get a clear vision of what you're trying to do. What I found really helps is saying out loud what you're trying to do, to yourself or to another person. No cheating, you have to say it out loud.
Nice anecdote: http://hwrnmnbsol.livejournal.com/148664.html
|
On December 23 2013 07:06 lannisport wrote:Show nested quote +On December 21 2013 10:30 Maero wrote:Yep. Any operations on a python string must result in a new string. Good illustration Cyx. Edit: Just to contribute something: One way around this is to turn the string into a list instead, modify an element, and rejoin. e.g.
>>> str = "string"
>>> str = list(str)
>>> str[2] = 'a'
>>> str = ''.join(str)
>>> str
'staing'
But the way in your book is probably just about the same as far as efficiency goes, if not a little better. Thanks for this. I'm having a general tough time learning coding things period. Did you guys run into this problem too when you first started to learn how to program? For example, one of the exercises in the book was to create a mock character point distribution system (i.e. str, vit, int, dex etc.) from a limited pool of points. It took me like an hour and a half just to figure out not to use lists but dictionary pair sequences because with my current knowledge it's just a lot simpler and easier to modify the values in that type of sequence. It took me like another 2 more hours to figure out how to actually make the code work the way I wanted it to. My problem is my working memory sucks. It's difficult for me to keep track of all the values and conditions of everything. Sometimes I write out the returned values in a loop on a scratch pad just to remember everything... Do you keep track of every line of code in your head? Usually, what makes it click for is just fixing the logic of my pseudo code or realizing exactly what it is I'm actually trying to do (If that makes sense). And then my code became shorter and simpler.
Haha... Yeah man, it doesn't stop feeling like that tbh. I mean, yes you do get FAR better at it, but the kinds of problems you're mentioning are among the basic 'what it means to be a programmer' trials =P That being said, your problems DO change, and you work on bigger more complex things, but your memory is never going to be good enough to hold onto everything you want to remember, and your mind never sharp enough to write exactly what you mean. So get used to it I guess =P but you are starting to figure out some things, don't worry if you can't keep track of it all.
|
@Michael: Thanks for the tip! That anecdote was great. I have a Jurassic park velociraptor relic from childhood laying around so I might just ask him some questions. It's so true though because when I first posted my python problem I actually did not understand how it worked at all until I actually typed out my question... So the nature of the question changed from, "How does this work?" to "This is how it works right?"
@Cyx: That is a comforting but also scary thought. I do find that past exercises that I revisit can be done rather quickly and painlessly. What would take me an hour or two before takes a few minutes only now. But perhaps the better way to review would be to ask how I would do the exercise with my current knowledge. How to make the code better or more concise. Oh and happy birthday!
|
So this might be irrelevant to the topic that is currently going on, but how many front-end developers are out there? Every time I come here I see a lot of back-end programming. The farthest back-end programming I do is PHP if you even want to consider that as back-end 
|
Poll: I'm aSoftware developer (12) 32% Computer scientist (9) 24% Web developer (5) 13% Other (4) 11% Mobile developer (3) 8% Firmware developer (2) 5% OS / Low level developer (2) 5% Back-end developer (1) 3% Data analyst (0) 0% 38 total votes Your vote: I'm a (Vote): Web developer
(Vote): Back-end developer
(Vote): Mobile developer
(Vote): Software developer
(Vote): Computer scientist
(Vote): Firmware developer
(Vote): OS / Low level developer
(Vote): Data analyst
(Vote): Other
|
Back-end Perl developer here. 
|
On December 23 2013 07:06 lannisport wrote:Show nested quote +On December 21 2013 10:30 Maero wrote:Yep. Any operations on a python string must result in a new string. Good illustration Cyx. Edit: Just to contribute something: One way around this is to turn the string into a list instead, modify an element, and rejoin. e.g.
>>> str = "string"
>>> str = list(str)
>>> str[2] = 'a'
>>> str = ''.join(str)
>>> str
'staing'
But the way in your book is probably just about the same as far as efficiency goes, if not a little better. Thanks for this. I'm having a general tough time learning coding things period. Did you guys run into this problem too when you first started to learn how to program? For example, one of the exercises in the book was to create a mock character point distribution system (i.e. str, vit, int, dex etc.) from a limited pool of points. It took me like an hour and a half just to figure out not to use lists but dictionary pair sequences because with my current knowledge it's just a lot simpler and easier to modify the values in that type of sequence. It took me like another 2 more hours to figure out how to actually make the code work the way I wanted it to. My problem is my working memory sucks. It's difficult for me to keep track of all the values and conditions of everything. Sometimes I write out the returned values in a loop on a scratch pad just to remember everything... Do you keep track of every line of code in your head? Usually, what makes it click for is just fixing the logic of my pseudo code or realizing exactly what it is I'm actually trying to do (If that makes sense). And then my code became shorter and simpler.
Man please don't do it that way. I don't want to sound like a douche, but, on top of this solution being far from elegant or efficient (which, let's be honest, no one gives a shit about for now), the real problem is that if you're having issues with learning to program, you have to avoid as much as possible using black boxes like list() or .join, until you are able to perfectly understand them and code them yourself in less than 20 minutes (the logic part I mean, not the user input checking/exception handling). That's a trap many people fall into when they're starting with a language like python, which is so dev-friendly.
Also, electronics engineer student here, so very low level I guess?
[edit: just to make it clear: of course you can use entire libraries of function you wouldn't be able to code, and that's why they are there. But in the context of learning, and for functions/methods as simple as list and join, which only handle really simple and small data, I think you have to be able to do what I previously talked about]
[edit2: example:
def strToLs(string):
ls=[]
for char in string:
ls=ls+[char] #Not using ls.append(char) cause I would be shooting a bullet in my own foot :)
return ls
It's not rocket science, very far from it. But if you don't make the effort of trying to understand what this does once, it can very quickly become a heavy burden. Approximately knowing what a function does/what you'd have to do if you were to code it yourself enables you to better know what it needs to properly run, when it should be used to great effect, and when it shouldn't. Of course I know people who never did this and still are great devs who have a good understanding of what's going on in the back, but I also know people who relied on built in stuff like that their whole (student) life and thus have a very poor grasp of programming and algorithms in general. Since you seem to struggle a bit, you have to be diligent and honest with yourself and not let stuff you know you should understand overwhelm you. So just once in while, when you use them, just think 10secs about whether you're not using a bazooka to kill a fly]
|
On December 23 2013 19:11 FakePseudo wrote:Show nested quote +On December 23 2013 07:06 lannisport wrote:On December 21 2013 10:30 Maero wrote:Yep. Any operations on a python string must result in a new string. Good illustration Cyx. Edit: Just to contribute something: One way around this is to turn the string into a list instead, modify an element, and rejoin. e.g.
>>> str = "string"
>>> str = list(str)
>>> str[2] = 'a'
>>> str = ''.join(str)
>>> str
'staing'
But the way in your book is probably just about the same as far as efficiency goes, if not a little better. Thanks for this. I'm having a general tough time learning coding things period. Did you guys run into this problem too when you first started to learn how to program? For example, one of the exercises in the book was to create a mock character point distribution system (i.e. str, vit, int, dex etc.) from a limited pool of points. It took me like an hour and a half just to figure out not to use lists but dictionary pair sequences because with my current knowledge it's just a lot simpler and easier to modify the values in that type of sequence. It took me like another 2 more hours to figure out how to actually make the code work the way I wanted it to. My problem is my working memory sucks. It's difficult for me to keep track of all the values and conditions of everything. Sometimes I write out the returned values in a loop on a scratch pad just to remember everything... Do you keep track of every line of code in your head? Usually, what makes it click for is just fixing the logic of my pseudo code or realizing exactly what it is I'm actually trying to do (If that makes sense). And then my code became shorter and simpler. Man please don't do it that way. I don't want to sound like a douche, but, on top of this solution being far from elegant or efficient (which, let's be honest, no one gives a shit about for now), the real problem is that if you're having issues with learning to program, you have to avoid as much as possible using black boxes like list() or .join, until you are able to perfectly understand them and code them yourself in less than 20 minutes (the logic part I mean, not the user input checking/exception handling). That's a trap many people fall into when they're starting with a language like python, which is so dev-friendly. Also, electronics engineer student here, so very low level I guess?
Don't need to perfectly understand anything. You need a functional knowledge, then if it's appropriate/you need it, you go and acquire the deeper knowledge, when you're building software.
Learn how to program first - as an example, do some small simple programs unix programs that you can just use on the command line. (A few examples could be cat, cp, ls)
You can always check out Martyr2s Mega Project list and find something you think is interesting - then just do it - don't care about how bad or good your code might be, you will learn that, what you need to do is to write a lot of code, because before you have done that, many concepts doesn't make much sense.
So get going
Also, I'm firmware engineer by trade but working with some windows application development for some time.
|
Amateur software + web front-end.
|
[Java]
Is it a good idea to have an interface of a class that has a lot of methods just to show some overview of functionalities? E.g. simply treating the interface as a Class.h file.
|
Why?
Just document your code properly,
|
On December 24 2013 00:09 Yoshi- wrote:
Why?
Just document your code properly,
Well, comments are irrelevant. If you have a class that has 200+ or many more lines, would you rather look the whole file or would you rather see an interface with a list of methods? Of course, you may need to see implementation later but wouldn't you like to have some overview first?
|
Any decent IDE can list the (public) methods to get a quick overview. You don't need a separate interface imo.
|
On December 24 2013 00:43 darkness wrote:Show nested quote +On December 24 2013 00:09 Yoshi- wrote:
Why?
Just document your code properly, Well, comments are irrelevant. If you have a class that has 200+ or many more lines, would you rather look the whole file or would you rather see an interface with a list of methods? Of course, you may need to see implementation later but wouldn't you like to have some overview first?
That's why you document it. Use a way of commenting that creates a browsable documentation. Like... javadoc, I guess?
|
On December 24 2013 00:43 darkness wrote:Show nested quote +On December 24 2013 00:09 Yoshi- wrote:
Why?
Just document your code properly, Well, comments are irrelevant. If you have a class that has 200+ or many more lines, would you rather look the whole file or would you rather see an interface with a list of methods? Of course, you may need to see implementation later but wouldn't you like to have some overview first?
There is a huge difference between comments and proper documentation.
And like someone already said you can easily get something quite handy with javadoc, there really isn't any reason to abuse interfaces for that.
|
On December 24 2013 00:43 darkness wrote:Show nested quote +On December 24 2013 00:09 Yoshi- wrote:
Why?
Just document your code properly, Well, comments are irrelevant. If you have a class that has 200+ or many more lines, would you rather look the whole file or would you rather see an interface with a list of methods? Of course, you may need to see implementation later but wouldn't you like to have some overview first?
Have you ever seen a code base from real life? I mean, come on. That's not what interfaces are for, that's what JavaDoc is for. Program the C way in C, the Java way in Java and so on - embrace the difference, don't go "oh, let's program Java like C" or something completely silly like that. Yes you can do it, no it makes no sense.
Also to quote you "Well, comments are irrelevant", if you do like this
//initialize sum to 0
int sum = 0;
//add i to sum if i is smaller than size of arraylist
for(int i = 0; i < arrayList.size(); i++)
{
sum =+ i;
}
Then yes, your comments are utterly and completely irrelevant, you don't tell me something I couldn't be expected to read. If you, however, do anything that I need to think about to understand, you better damn well write a comment that explains why you chose this way of doing it (if there's more than one obvious way to do it) and what it does.
Do you remember why what/why/how you wrote some code that is 3-6-9-12-24 months old? I sure as hell don't, and that's why you write high level comments where appropriate and low level when you explain why you did it.
Look at any open source code base in Java and look at how much a lot of it is documented.
If your opinion is still that "Comments are irrelevant", well... I don't know what to write then.
|
On December 23 2013 23:50 darkness wrote:
[Java]
Is it a good idea to have an interface of a class that has a lot of methods just to show some overview of functionalities? E.g. simply treating the interface as a Class.h file.
There have been plenty of opinions posted above. You've obviously opened up a can of worms.
I, for one, love the C-style header way of collecting function prototypes, but often my C structures are designed as differently as night and day compared to java objects. I'd probably hate to reference someone else's java class using it's interface.
In Java, while debugging or coding, you frequently reference the API and javadocs. Thus, when organizing your code for other people to use, try to make it fit within the same work flow that they already used. This is a key feature of successful projects. If you know someone else will reference your class, do all the work of understanding the class for them, and write it up in javadoc format. If you don't it will take more time overall for them to read through your code and figure out what to do, what the arguments mean, etc.
If you just want to make a quick reference for yourself, I love using the Interface feature as a virtual to-do list. I leave it in my project at the end for completion sake, so a lot of my projects have this C-style header interface.
It's your code, though, and you can make your own decision how to document it.
EDIT: Low Level/ OS developer here
|
|
|
|
|
|
|
|
|
|
EPT
