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

More challenging projects every programmer should try

web.eecs.utk.edu

Post reply on HN
Print view View original

101–110 of 232 posts

Re: More challenging projects every programmer should try

#101

Post by abhgh »

simias wrote: post #27

I would add "build a toy regex engine" to the list. A couple of years ago I implemented a toy regex engine from scratch (building NFAs then turning them into DFAs). I thought it was an enlightening experience because it showed me that the core principles behind regular languages are fairly simple, although you could spend years optimizing and improving your implementation. How do you deal with unicode? How do you mod…

I agree with this ... I coded a Thompson NFA [1] out of interest a few years ago; definitely recommended as an exercise.

[1] https://swtch.com/~rsc/regexp/regexp1.html

Re: More challenging projects every programmer should try

#102

Post by m3at »

kamel3d wrote: post #62
gjvnq wrote: post #35

Earlier quoted context omitted.

I tried making a bitcoin trading bot and almost all of the money (about 10 bucks, not no big problem). My main mistake was using the historical trades instead of the historical offers as a testing dataset.

did it work at the end? I want to make a crypto trading bot seems simpler than stock one

Not the GP but I made trading algorithm for a living (not on crypto) and have friends still doing that (on crypto): yes it can work, but in 99% of cases you shouldn't do it for the money. Let me expand:

If you can afford to spare part of your income and invest that for long term buy and hold, that'll work better (ex. ETF).

If you can't spare anything, focusing on leveling up trendy skills, then you can land a better job on the short term.

However if you just want to trade for the fun of it, yes crypto can be simpler than stock, mainly because the API are better. Set up a maximum budget as a safety net and enjoy :)

Re: More challenging projects every programmer should try

#103

Post by schoen »

theshank wrote: post #97
schoen wrote: post #51

Earlier quoted context omitted.

I really enjoyed taking Ullman's Automata course on Coursera. I found it was great for better appreciating topics like * searching * implementation of automata in electronic circuits * challenges of formal specifications for things like protocols and grammars, as well as for verifying their correctness; implementation strategies for applying these specifications * computability and complexity * programming language t…

Thank you for sharing this one. I was looking for a course like this! BTW this course is now offered on edx.

Oh, thanks for the update! It looks like the new version is at

https://www.edx.org/course/automata-theory

Definitely recommended if you like somewhat dry and mathematical stuff with deep relevance to many areas of computer science. :-)

Re: More challenging projects every programmer should try

#104

Post by profquail »

chubot wrote: post #71
simias wrote: post #27

I would add "build a toy regex engine" to the list. A couple of years ago I implemented a toy regex engine from scratch (building NFAs then turning them into DFAs). I thought it was an enlightening experience because it showed me that the core principles behind regular languages are fairly simple, although you could spend years optimizing and improving your implementation. How do you deal with unicode? How do you mod…

Yeah the "optimize for years" part is interesting... Supposedly the derivatives technique (re-popularized by a 2009 paper) will build a more optimal DFA directly, rather than building the NFA first, converting to DFA, and then optimizing the DFA. I put a bunch of links and quotes about that here, including nascent implementations: http://www.oilshell.org/blog/2020/07/ideas-questions.html Also related: http://www.oils…

I wrote an implementation of this several years back. If you’re interested in the code: https://github.com/jack-pappas/facio/tree/master/Reggie

The derivatives approach makes Unicode support easier since its able to keep the symbols sets for each transition edge (in the DFA) more compact by virtue of supporting negation. If you add in aggressive term-normalization, hash-consing, and an efficient dense-set implementation (all of which I’ve done in my implementation), the derivatives approach can be extremely fast, even when generating the DFA for something like the lexer of a full programming language (in my case, F#).

Re: More challenging projects every programmer should try

#106

Post by IgorPartola »

atomicnumber3 wrote: post #21
henning wrote: post #9

As someone who has played with writing trading bots but never traded them with real money, some advice: if your results seem too good to be true, they probably are. Your trading bot may be doing unrealistic things or its results may not be reliable if the following are true: - You are trading in a market with low liquidity or one that is controlled by a small number of market participants. I'm not an expert but I thi…

I worked in this industry. 2 more common issues: * Doing a latency-sensitive trade when you don't have good execution. It's easy to go wild in simulation and think you can flip in and out of positions. But if you're a retail trader (and in this context, by that I mean "not connected directly to the exchanges, at the minimum") * Not taking into account the impact of your own trading on markets. This is obviously impos…

Would you mind if I asked you a question since I have never worked in this industry but did play with crypto trading a while back. Before Mt Gox was shut down I was trading on a couple of tertiary small exchanges and at the time there was a lot of talk of arbitrage between different exchanges and how transaction latency and fees made it very risky at best and a losing proposition in most cases. But what I was wondering about is whether in a situation like that (one large exchange dominating the market, several smaller exchanges trading the same commodity) if it was possible to use the large exchange as a sort of oracle. Essentially my hypothesis was that Mt Gox sets the price and other exchanges follow on a delay so if I watch Mt Gox I can predict where the price on the secondary exchanges will go a few seconds to a few minutes ahead of it moving. I ran a bunch of historical data through some basic analysis scripts and noticed that indeed there was a pattern but when I actually implemented a bot to trade BTC it lost money more often than not. I am curious if (a) that idea has any validity and (b) was me losing money on this strategy due to latency and implementation errors or due to some fundamental principle of trading that I am missing.

Re: More challenging projects every programmer should try

#107

Post by shhsshs »

Waterluvian wrote: post #54

Writing a Game Boy emulator has been the most fulfilling and interesting programming project in my life. I love, most of all, how modular the project is. I can do an hour here or there and make meaningful progress. I'm really eager to discover other very large programming projects that break down into sensible bites so well.

I had never considered an emulator to be anywhere inside of the realm of possible projects I could take on for fun. I just thought it would be too complex without having a ton of very specific knowledge.

Your comment prompted me to go look up some other attempts, and I’m really glad I did. It seems much more approachable to me now. Thanks!

Re: More challenging projects every programmer should try

#108

Post by ghoward »

avl999 wrote: post #34
0xbadcafebee wrote: post #13

> it is really simple to create the basic "database". You can start by using the dictionary data structure that comes with whatever programming language you're using and slap a web API on top of it. Better yet: do it in C. There's no "dictionary" object type so you have to make it yourself. You'll soon learn a whole bunch of fallacies about how those "dictionaries" actually work. After you spent a good deal of time d…

I disagree with the C advice. If you don't want to rely on higher level language primitives like Dictionaries and so on there is nothing stopping you from rolling out your own implementations of these data structures in a more sane language (Go, Python, Java, Clojure whatever, anything but C). The project is challenging enough without having to fight segfaults and undefined behaviors.

I'm not sure I agree with you. Writing a hash map implementation in C made me a much better programmer as far as performance goes because I understand the machine better.

Re: More challenging projects every programmer should try

#109

Post by kernelmode »

ashleyn wrote: post #7

Write a toy compiler for a basic like language, you'll learn about what your languages are actually doing.

One of the best free resources on making interpreters (with VM, OOP and garbage collection support): https://craftinginterpreters.com
Post reply on HN