2. If you can, step through any new code with the debugger. You may find the execution path isn't what you thought it was.
Ask HN: What change in your programming technique has been most transformative?
211–215 of 215 posts
Re: Ask HN: What change in your programming technique has been most transformative?
#212Re: Ask HN: What change in your programming technique has been most transformative?
#213Functional Programming fundamentally changed the way that I solve problems. It also changed my expectations for how code should be designed. The concepts that influenced me the most were immutability and the power of mapping+filtering. Whenever I read a for/while loop now, I’ll attempt to convert it to the FP equivalent in my head so that I can understand it better.
map and filter are not concepts of FP - they are just syntactic sugar around for loops. fully evident if you check any native source code. many languages (such as go which I currently use) do not even have these functions but can apply FP. this is by design of simplicity and visibility: it does not get much easier to read than a simple for loop and know the exact iterations count at runtime.
Re: Ask HN: What change in your programming technique has been most transformative?
#214Earlier quoted context omitted.
Can anyone give a specific example of code they've worked with that was "too clever"? Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system. So I ask, when you have felt that code is "too cleve…
Clever: for(let i=0;i Readable: for (let i = 1; i
Array
.from({length: 100}, (v, k) => k+1)
.map(i => {
if (i % 3 == 0 && i % 5 == 0) return "FizzBuzz"
if (i % 3 == 0) return "Fizz"
if (i % 5 == 0) return "Buzz"
return i
})
.forEach(console.log)Re: Ask HN: What change in your programming technique has been most transformative?
#215Earlier quoted context omitted.
Thanks for that "Parse, don't validate" link. It definitely is the clearest explanation for type driven development I've found. Turns out, years ago I was writing some C# code and I found myself wanting to explore something like that. However, it wasn't idiomatic for C# (especially at the time), and I talked myself out of it. Since then, I've wondered if that's what people mean by type driven development. It's cool t…
Is C# nowadays friendly enough for type driven development? Using TypeScript daily, I have a great time with type driven development. (C# and TS was created by the same guy) I was never comfortable with Java community approach of automating stuff, with their heavy use of reflections, method name parsing instead of being strict in typings, use generics, macro, templating, etc.
You'd be using types in a way that pretty much no one in C# does (not idiomatic), except for maybe those who are explicitly trying to go for type driven development (for example, people doing things like railway oriented programming).