Hacker News Reader

Comment by hmmk | Hacker News Reader

What exactly did you have trouble with? These really are simple problems, all you need are an understanding of loops, ASCII character codes, and basic arithmetic.

To be honest, I'm surprised a seasoned developer of 5+ years can't do these, or at least have a decent stab at them.

View on HN

Why would you expect the modern application developer to even know what ASCII is?

There is a chance I wouldn’t know what ASCII encoding was if my exposure to programming didn’t start in the 8 bit era. C is foreign to a lot of self taught programmers.

A modern application developer should be at least vaguely familiar with Unicode, so character encodings should not be an entirely foreign concept.

You should be able to use a search engine to figure out what ASCII is, though. That's fair game to expect. The text document mentions ASCII, so it's not like a developer would be left without a clue.

ASCII does still map to the most commonly used parts of Unicode, so there is that. I would agree that I wouldn't have the foggiest idea what most of the ASCII character codes are if I hadn't cut my teeth on archaic stuff like QBasic; I remember a lot of silly little toy assignments doing rot13 or manually upper and lowercasing strings. But they do come up from time to time when you get into, for instance, JS keydown/keyup events. But any competently designed modern API ought to at least have named constants for this kind of crap

Don’t ask me why I remember that the lazy non performant way to put a character on the screen in assembly was to store the ASCII number in the A register and

JSR $FDED

The fast way was to copy the bytes directly to the $400-$7FF address space and figure out the non contiguous memory map -> screen yourself.

(After a "...I never used that in QBasic!", google explained that this is for the 6502)

I'm right now trying ti get around being made to learn ASCII for vocational school (some certification is useful to pass automated recruiters).

I base my Opinion on it being a bad idea to rely on manual translation, and untill then I'll have learned to write code that does the translation for me.

Remember the context, this is an introduction to computer science course. The slides for the lecture for that week most likely explained everything you need to know to solve the problem.

Even completely ignoring ASCII, it is trivial to create a dictionary mapping integers to characters.

In this modern time, no one needs to know what the ASCII code for @ is, but I think it is logical to expect people to know that some encoding exists and that letters can be mapped to numbers.

Also, all the ASCII you need to know to solve the problem is explained at length in the problem description.

I couldn't tell you offhand how to convert between an int and an ASCII character.

...But if you give me a second...

Now that I've typed "ascii character codes" into google, I can tell you how to convert between an int and a character.

You don't have to memorize everything. Well over half of our job is knowing how to find information quickly.

We probably underestimate how many people out there are just copy/pasters. No offence OP but I hope you dont work on anything that handles money/user data/requires security.

I do! I develop bespoke add-ons for the accounting software Sage 200. Fear not, my work is peer-reviewed by my boss who has 35+ years experience in the field.

If I get something wrong, my boss lets me know, I learn from my mistakes and ship out good quality software.

I just replied above, but I've never been amazing at being able to figure out how I should be using for loops to solve problems quickly and efficiently.

I do tend to make things harder for myself, as my boss and fianceè have told me before.

I usually end up with a very convoluted solution which I end up coming back to and refactoring the next day.

I'm curious, what sort of approaches do you take to your programming tasks at work? Is it more like e.g. writing SQL where you'd think more about relating sets of data rather than looping over individual items?

I was actually going to recommend exactly that - I find that, when I have a problem that I’m having trouble solving, just brute-forcing the damned thing helps me focus on the hard parts of the problem, and then I end up rewriting things in a “better” way that I’m actually not ashamed to put my name to.

Correct first, then simple and fast later. With more experience you'll be able to devise simpler, correct first solutions that you can then speed up later.

There's an old Kent Beck quote that fits here... "Make it work. Make it right. Make it fast." Your approach fits that.

http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

I've seen so many projects where the developers have taken this to heart way too much. The problem is they use it as an excuse to give up after stage 2 thinking stage 3 can come along when it actually becomes a problem.

The thing is that performance issues tend to creep up on you so slowly that you don't realise it until you have a very important client with tons of data screaming at you to fix it now. To fix it then you have a huge architecture issue because the whole system is so inefficient. So rather than rewrite the entire code base to actually be efficient you are forced to hack in some kind of caching solution. Then your problems multiply.

Make it fast from the start. Premature optimisation being the root of all evil is a lie!

What is your hypothesis on where that lie comes from?

Ok, it's a bit of an exaggeration and obviously depends a lot on what your definition of premature is. I guess the statement is actually a tautology, by definition premature means too soon. I just see people who think that any optimisation at all is bad, whereas in a lot of instances optimisation as you are writing the initial code is not premature. In my experience...

If you do that you'll write great, fast code but it'll take you longer to do it. That's great if you have unlimited resources, but try doing it in a startup where failing to ship in a month means your whole business fails.

So... Maybe don't prematurely optimize?

I'm not sure you two actually disagree, but rather that you're thinking on different scales. Make it right, then make it fast is usually talking about specific snippets of code, rather than the whole program, so your whole program should be "made fast from the start" because you went through the process of making it right and then making it fast on the components themselves.

Yes, that's a great way of thinking about it!

I mean the question also is whether OP has done any programming in C before. If the majority of your expierience is in VB.NET and web technologies I can see this being a major hurdle aside from the actual algorithmic problem.

I don't think C is the issue here but mental shift . I have suffered from same situation in the past. He should just spend time and interpret the question, internalize it , and then code it

You don't even need to understand ASCII. You can hard code an array of all the letters in the alphabet, search for a given letter and replace it with the letter 13 places ahead in the array. If you were really lazy and didn't want to worry about the logic for rolling over when going past Z, you could even rewrite the first 13 letters at the end.

I have no trouble believing that there are many developers out there with no understanding of character encodings. Because I have seen many applications where the handling of character encodings is nothing but kludges upon buggy ad hoc kludges.

Reply on news.ycombinator.com