* relational databases (e.g. sqlite, postgres)
* regular expressions
* lisp / scheme / clojure
* emacs
* mini kanren / datalog / prolog
* neural networks and deep learning
* state machines
* caches
Ask HN: What overlooked class of tools should a self-taught programmer look into
361–370 of 416 posts
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#362Earlier quoted context omitted.
I know you're probably just trolling but I'll take the bait — I'd put all of these six before any of those three: git pull git clone git status git commit -a git push git diff I mean, the ones you mentioned are pretty useful, but if you don't have a repo in the first place, even git-log isn't going to be very useful; and if you're branching and rebasing, you probably have to commit first. (I actually prefer Magit, to…
I'm not trolling, and to assume that I am doesn't exactly "assume good faith." [0] The comment I replied to says: > Like they know enough to commit and push but that's about it. In that vein, I was suggesting what I consider to be the most basic git commands outside of the "clone, commit, push" workflow. [0]: https://news.ycombinator.com/newsguidelines.html
Oh, I didn't know you meant to imply that qualifier; I was responding only to what you said, which was absurd, not what you meant, which I now see was reasonable.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#363Unit testing, mocking, and various other testing techniques. Why? Any project of sufficient complexity is very hard to test. If all you're doing is code -> build -> run to debug your code, you can very easily break something that's not in your immediate attention. The problem is that good unit testing is hard, and time consuming. It can be so time consuming, that unless you can really plan in advance how you test, yo…
You are completely wrong. Mocking is a huge design smell. The more mocks or integration tests your projects requires to get full coverage the less modular your program is. A program that uses many mocks is a sign of very very poor design. You will find the code more complex to reason about and much harder to reuse code without necessitating a lot of glue code to make things work together. Without proper knowledge you…
I mostly agree with what you're saying, but I will add that is is also possible to write well-designed, modular, easy-to-test (minimal mocks) OOP code. It does provide more guns to shoot yourself in the foot with, I will admit.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#364Earlier quoted context omitted.
With Docker at least everything is contained in the container. Which makes isolating and resetting environments a breeze. Something I worry about often is contaminating my system's 'state'. Which always leads to broken builds or incomplete build systems because a missing dependency is not spotted on your system because it was installed by some other tool some other time. I tend to write my Makefiles to create as much…
I wish more tools did this, I almost always want a local, self-contained environment for everything. The few times I don't actively want I don't see much pain in having one. A couple minutes setup time, maybe? I have seriously considered hiring someone to audit and prune all the random little libraries and tools I've installed over the years for that one-off time I had to process a weird file format or wanted to try…
To keep my system clean, I use Darch.
Every boot is a fresh install. Any one-off only becomes persisted unless I add it to my recipes.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#365Makefiles. I always dismissed them as a C compiler thing. Something that could never be useful for Python programming. But nowadays every project I create has a Makefile to bind together all task involved on that project. From bootstrapping the dev environment, running checks/test, starting a devserver, building releases and container images. Makefiles are just such a nice place to put scripts for these common tasks…
I second this... a lot of times, broken make files are standing between you and victory, so it would be good to at least have some familiarity with them.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#366Earlier quoted context omitted.
Unit tests can give you false positives (test failed but code is correct) and false negatives (test passed but code failed). And TDD seems to create so many tests that you get huge false positive rates. I recently jumped on a project and I made a couple of fairly small code changes (a couple of hours) which caused 100 tests to fail. I then spent the next two days going through and correcting all 100 tests none of whi…
If you're saying that it's possible to do testing badly, I agree, just like it's possible to write production code badly. Sometimes teams new to unit testing do it ritualistically, without really understanding the purpose. That can lead to all sorts of bad outcomes. E.g., lots of tests that look impressive and even generate good coverage numbers, but don't really test what matters. Or tests that are highly duplicativ…
What are some resources for “good testing”, test boundaries, and possibly antipatterns?
(Ruby, Rails)
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#3671. Profiler. There's a standard tool that tells you what part of your code is slow. Over half the time it'll find something dumb and easy to fix instead of whatever you expected. 2. SQL / relational database schemas. Persistence opens up a lot of capabilities. And databases themselves are very well-optimized; if you do any nontrivial data manipulation it's likely that whatever the query planner comes up with will be…
Support for 4! Yet, my understanding is that particle filters are superior but computational more demanding. For nonlinear problems, the extended Kalman Filter linearizes the task, whereas particle filters don't and work with many point estimates instead. I loved this book: https://users.aalto.fi/~ssarkka/pub/cup_book_online_20131111... and also Thomas Schoen group does great work on Sequential Monte Carlo (SMC), MCM…
Regular old Kalman Filters are the best (literally perfect) when your problem fits all their requirements. They also have a lot of nice properties if you're dealing with a problem that mostly fits their requirements. But the linear-gaussian requirement is pretty steep, they don't always work.
I don't like the EKF much and prefer the UKF. The core filtering code is a little more complex but they're much easier to actually work with; you can give them arbitrary functions like a particle filter.
Particle filters have the advantage of being able to handle arbitrarily wacky distributions. But they are random and do some wacky things in edge cases. They'll behave much more poorly in low-evidence situations than other filters will. And they fall over spectacularly if you switch from low-evidence to high-evidence (there's a workaround for this but it's still counterintuitive). Finally they're just more computationally expensive than the others.
Birch sounds interesting, I'll take a look.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#368Earlier quoted context omitted.
You are completely wrong. Mocking is a huge design smell. The more mocks or integration tests your projects requires to get full coverage the less modular your program is. A program that uses many mocks is a sign of very very poor design. You will find the code more complex to reason about and much harder to reuse code without necessitating a lot of glue code to make things work together. Without proper knowledge you…
I mostly agree with what you're saying, but I will add that is is also possible to write well-designed, modular, easy-to-test (minimal mocks) OOP code. It does provide more guns to shoot yourself in the foot with, I will admit.
Yes you are correct. Check out smalltalk, it fits the paradigm you describe. It was actually rated the most productive programming language in the world according to namcook. Ironically, it's Definitely one of the least popular languages as well.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#369Some simple things with good ROI:
1. Ergonomics tooling: Set up your screen at an appropriate height and your keyboard at an appropriate distance, so that you aren't in pain. If you use a laptop often, try setting it on a shoebox. Use a work timer to take breaks(I've been using Workrave on its default settings lately, which is quite harsh but has worked for my productivity).
2. Diary keeping: Note what you did, what you plan to do, and the date and time. Note as often as you feel necessary. Record notes both in source comments or in general purpose diaries. Use the date to eliminate or rewrite notes that are stale.
3. File management, process management and editing. Take a little time to learn things about your operating system and editor. You don't have to master it, or do elaborate configuration(in fact, having a complex config makes it hard to transfer to other environments). What you want are little things like knowing a few handy shortcut keys or a few built-in tools.
4. Gaining familiarity with writing simple "skeleton" or mock-up code, and waiting patiently for it to mature. When first building a system it may be tempting to apply the biggest algorithmic hammer or design pattern you know of. This is the kind of trick you are learning in learning about message queues. But the most likely outcome of trying to use a trick, no matter how well intentioned, is that this will get you a wrong result more slowly, because the full shape of any problem tends to come into view slowly, progressing from blurry and unclear with a rapidly changing design into something sharp, with well-defined boundaries. As such every new system demands a beginner's mindset, and some ability to refuse engineering in-depth until you absolutely must do so to progress. Done properly, you build a system that leverages existing tools well, has some kind of value now(even if it's limited or lacking a critical feature), and then can harvest the learned lessons into a more complete form later. Trying to get all the features into one pass creates a messy soup: iterating on a subset of them naturally leads towards development of tricks like the message queuing architecture, without any prompting.
(edit)
5. Read c2 wiki when bored - it covers a lot of recurring discussions in programming: http://wiki.c2.com If you know the stuff in it you'll be reasonably prepared to think about any unusual ideas and compare them with existing examples.
Re: Ask HN: What overlooked class of tools should a self-taught programmer look into
#370Earlier quoted context omitted.
"If you've seen the concept of a grammar (likely to come up in CS programs, though not all)" Really? That was one of the very first topics in my first semester. How do you teach CS without grammars and the Chomsky hierarchy?
I wondered if someone would ask about that... It's just my own recollection from years ago when I looked at a bunch of CS curricula from public and private schools. There was a lot of patchy variation. If the topics were covered at all they'd typically be done in optional electives like a compilers course, or "theory of computation" course, taken in junior or senior years. Also depending on the school such an electiv…
"they'd typically be done in optional electives like a compilers course, or "theory of computation" course"
Okay, maybe it's because here in Germany, we have a separate line of eduction for "mere" programmers and system administrators as well as a separate branch of higher education for more "practical" skills. But if you study CS at an university, both of these course would be mandatory, together with a lot of math and some physics (to know what actually happens in a circuit).