Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof You Can Become a Better Programmer

new2code.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Proof You Can Become a Better Programmer

#11

Post by natdempk »

Is it just me or is his improved solution a possibly incorrect way to solve the second problem? With his solution "aabbcccaa" compresses to "a4b2c3", but I would expect that to compress to in "a2b2c3a2".

Am I misunderstanding the problem here? In the context of compression why would it just be about counting letters? Why wouldn't you just use a hash of character counts if that is all you care about? Don't you want to maintain the form of the string also so you can unpack the original value?

Re: Proof You Can Become a Better Programmer

#12

Post by CydeWeys »

dri_ft wrote: post #2

I slightly prefer the 'worse' solution for the second problem, at least in terms of substance, not necessarily style. The trick the 'improved' version does with uniq seems a little hacky to me, somehow. The first problem has a clear improvement. I just checked ruby doc and 'reduce' and 'inject' seem to be synonyms, as far as I can tell.

I've never done Ruby, but what I don't like about that second solution is how much logic it puts into formatting directives in a string literal:

> "#{x}#{input.split('').count(x)}"

Just because Ruby apparently allows you to do that much in a formatting directive doesn't mean you should.

Re: Proof You Can Become a Better Programmer

#13

Post by adamnemecek »

You don't become a better programmer by doing Project Euler like problems. Pick a real world project that's of interest to you and try to implement it. When starting out, it's not the worst idea to pick something that's been implemented quite a few times so that you can reference other people's work if you get stuck. You'll be surprised how much you can learn from implementing e.g. ls.

Also, you can contribute to open source.

Btw, this project I'm contributing to called AudioKit (if you are interested in audio stuff on Apple hw, you should definitely check it out) is looking for contributors

https://github.com/audiokit/AudioKit

Re: Proof You Can Become a Better Programmer

#14

Post by bshimmin »

jaredharley wrote: post #8
bshimmin wrote: post #5

What on earth does he mean by saying that "the reduce method [instead of inject] is performance friendly and a more "Ruby way" of doing things"? `reduce` is an alias for `inject`...

Based on the linked github page[1], it looks like that comment was an extrapolation from a guideline in Airbnb's Ruby Style Guide, where Airbnb prefers the use of `reduce` instead of `inject`: - Prefer `reduce` over `inject`. I haven't seen any other evidence to show reduce is more performance friendly. [1]: https://github.com/airbnb/ruby#collections

How could it be..? https://github.com/ruby/ruby/blob/ruby_2_3/enum.c#L3509-L351...

I prefer `reduce` too, because it feels conceptually easier to understand (similarly `foldl`, though Ruby doesn't have that).

Re: Proof You Can Become a Better Programmer

#17

Post by agf »

I appreciate the lesson trying to be taught here -- don't be intimidated by what you don't know, develop a plan, and practice -- but I don't think the author chose good examples.

For the LCM example, the second solution doesn't show any understanding of the underlying problem. The point of project Euler is to think about algorithms -- not to take advantage of "batteries included" features of programming language standard libraries.

For the duplicate counting problem, while the second answer is shorter, it's a bad solution. Just a few of the problems: it calls `split` many times instead of once; `count` can be called directly on a string; `chars` is the right way to get the characters of a string in Ruby; and finally the problem can be solved in 1-2 passes over the data using something like Ruby's `Enumerable#group_by` or Python's `itertools.groupby` rather than in a number of passes proportional to the length of the data -- O(n) rather than O(n^2).

Re: Proof You Can Become a Better Programmer

#18

Post by rootlocus »

sbov wrote: post #10

Problem 2 is underspecified so both answers might be wrong. Should the output on the string "aaaabbbaa" be "a4b3a2" or "a6b3"? Or is that invalid input? I don't think you can reasonably answer the problem without an example like this.

He mentions he was asked to write the answer during an interview, so it's possible the problem was underspecified intentionally to test how the candidate explores the input space.

Re: Proof You Can Become a Better Programmer

#19

Post by reledi »

adamnemecek wrote: post #13

You don't become a better programmer by doing Project Euler like problems. Pick a real world project that's of interest to you and try to implement it. When starting out, it's not the worst idea to pick something that's been implemented quite a few times so that you can reference other people's work if you get stuck. You'll be surprised how much you can learn from implementing e.g. ls. Also, you can contribute to ope…

> Pick a real world project that's of interest to you and try to implement it. Or contribute to open source.

Also pairing with someone who's more experienced than you.

Re: Proof You Can Become a Better Programmer

#20

Post by danso »

adamnemecek wrote: post #13

You don't become a better programmer by doing Project Euler like problems. Pick a real world project that's of interest to you and try to implement it. When starting out, it's not the worst idea to pick something that's been implemented quite a few times so that you can reference other people's work if you get stuck. You'll be surprised how much you can learn from implementing e.g. ls. Also, you can contribute to ope…

Totally agree. It's like how writing papers (to be graded by a teacher) about Shakespeare only makes you marginally a better writer, less so if you want to be a novelist or a journalist who appeals to mass audiences. Until you write real-world projects, in which the code has to be read (and edited) by real people, and which the output affects real people, all of the software engineering precepts (including the 2 hard problems in computer science) will remain abstract to you.
Post reply on HN