Hacker News new | ask | show | jobs
by dclara 4529 days ago
Of course. If it's in Java, I'd definitely do that. We are using Hashmap everywhere. Since the original code looks like this, I thought Ruby does not support hash.

We usually implement code on the application level, so we don't really care about the underlying algorithms. But if we have to implement on the system level, we do care about the how to manipulate the memory and number of executions, like Big O.

3 comments

The original code is like this because it's an exercise. Of course ruby has hashes.
The CTF does not give a description of the problem, but the code instead. And it persuades the new users not to change algorithm too much, just save a few steps, which implies to have minor changes of the code only.

Look at my another comment, hash may not be always better than list.

Sure a hash isn't always better than a list. In this case, it most definitely is. :)
Yes, agreed. I was sort of mislead or implied. It'd be better if CFT can give out the problem description followed by the sample code or don't give any sample code at all.

For me, it makes more sense to receive the detailed information, especially the system condition and restriction for trouble shooting and problem solving, followed by brainstorming, instead of going directly to fix code. Because we are used to the pattern to make minimum code change, especially in production. If the code should be completely changed, then we need to know the requirement and re-implement it. Sounds like we have different convention though.

The change required is a tiny one.
Unfortunately, I cannot agree with you completely.

If there is no language constraint and the system resource constraint, to the problem we have understand so far, using Java will be the fastest and easiest way without hashmap.

Load the complete file as a string (depending on how the size of the data set, up to 2^31 - 1), then using string.indexOf() function will get the best result.

The underlying algorithm for indexOf() is implemented by JVM in C code which is must fast than any other implementation.

My gut told me that it's weird to use hashmap to do string lookup. Everybody knows hashmap is used to lookup key-value pairs. The real reason for not using hashmap here are:

1. hashmap's lookup Big O is O(n), but not the build cost. if the data set size is huge, it takes long time to build the hashmap since every new element exceeded the initialCapacity being added needs a rehash

2. the underlying implementation of indexOf() will use a sort of algorithm called "automata" or something else to do a fast search within a string.

So there are lots of alternative solutions. Don't always think there is only one. I'm not in this field, and I'm not interesting to get into to it too much. But I don't think the best answer is that tiny change.

This is why I suggested to consider if you are doing application level optimization or changing system level algorithm. Building software is a lot more than code manipulation. Understanding requirement is the first step in the SDLC (Software Development Life Cycle).

Thanks a lot for your reference. A couple days ago, I was almost convinced to use GO after I took a look about half of its examples. People said, we are not going to catch up the languages which are changed every 6 months. The same applied for Javascript and JQuery, you don't really need the latter, and there are so many JavaScript libraries. Once you change your job, you may abandon some of them. Look at my another comment. For the same reason, I'm not going to take time to learn a new language.
You dont have to use Ruby. I actually did it in Python because I dont know Ruby. Just had to change the !# and fiddle around a little with the input reading.
Thank you for your advice, I'm really new to this game and I even don't know how to use github. Don't laugh at me, because I have enough experience on coding by myself and reading/modifying other people's code. I don't have time to play coding on CTF, but I'm curious about how other people are thinking about it, especially about distributed system.

Coding is the last thing we need to concern since various languages are available to implement. System architecture design, data modeling, application performance, security and algorithms are more important.

Regarding the language itself, I understand that Ruby and Python are quick and easy, but that's not for real production systems. Lots of teenagers are using it now. Maybe you are not happy to hear like that. Here are two blog articles regarding it:

http://bingobo.info/blog/contents/do-not-rely-on-other-platf...

http://bingobo.info/blog/contents/having-a-solid-foundation-...

LOL @ "don't let other people control your tools" and then going straight into "how to set up your Windows environment" in the next post after one of your links.
Thanks for reading. Is there any conflict between the two?

The original words was "You're giving them a throat to choke". The minimum set of tools is always necessary either on Windows or Linux, especially from Open Source. Just make sure don't take the risk of your application to do re-implementation later.

Lots of teenagers are using it now.

:)

I'm curious how people can put down vote on my comments. According to the guide line from HN, down vote is only available for people who have enough karmas.

BTW, if you are not happy to hear that, I'd like to know your opinion.

I didn't downvote, but I'm guessing it's the jab that "Ruby and Python are quick and easy, but that's not for real production systems."

There are tons of high-profile sites using ruby or python in production. Reddit is written in Python, Twitter got quite a bit of mileage out of Ruby...

There is a lot of teenagers with high enough karma around :)
I don't look down on teenagers if they are able to build websites using those languages. Maybe this type of exercise is really good or suit for them. And definitely coding is the no. 1 skill they occupy.

What I'm talking to are the hackers who are aiming for running startup companies and those who are going to grow to be software engineers.