Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jeremiep
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
50 ms
·
421.
▲
by
jeremiep
11y ago
Even with an internal class you're still doing lookups for properties. A closure can instead use local variables which are accessed by index. Why do you think its good practice to pull properties out of objects and into local variables
422.
▲
by
jeremiep
11y ago
I try to avoid OOP in my JavaScript code like the plague, I'd probably write it like this: function doSomething(obj){} var objs = [{},{},{}]; objs.forEach(doSomething); If I need late binding I'll use something l
423.
▲
by
jeremiep
11y ago
Creating an object and creating a closure both need to allocate memory in the VM, but the closure doesn't need to expose its internals the way an object does and therefore can be further optimized by the runtime. If you need to write p
424.
▲
by
jeremiep
11y ago
I wouldn't say less smart, it took me some time to get used to reify before feeling comfortable using it too. Think anonymous classes in Java for example, its almost the same thing.
425.
▲
by
jeremiep
11y ago
reify is usually a low-level construct in Clojure. A lot of libraries use it under the hood, I wouldn't be surprised if you use a few of them :)
426.
▲
by
jeremiep
11y ago
They're talking about the split of programmers, not of concerns. The client-server model is definitely here to stay but having separate groups of people handling each side is a sure way to greatly lower the quality of the product.
427.
▲
by
jeremiep
11y ago
I would rather see ES6 with no class support whatsoever and having people learn to code without them instead of adding features to satisfy the lowest common denominator. I've used classes in CoffeeScript and regretted it every single t
428.
▲
by
jeremiep
11y ago
The article doesn't mention doing away with client-server architectures but rather the separation of frontend and backend programmers which is indeed very harmful.
429.
▲
by
jeremiep
11y ago
Probably because they're being spawned over time and your FPS goes back up once the units list doesn't change anymore.
430.
▲
by
jeremiep
11y ago
Sorry, you're absolutely right, I've seen modern perl and it was actually quite clean. I didn't mean to offend by saying this!
431.
▲
by
jeremiep
11y ago
Oh I wasn't talking about Perl specifically but about languages in general. I agree that Perl projects tend to stay small enough to be quickly understood and refactored. In fact I don't remember seeing a Perl script more than a fe
432.
▲
by
jeremiep
11y ago
Some macros expand to a lot of code, especially when doing more in-depth transformations such as those performed by core.async in Clojure where they transform standard sequential code into a state machine with exactly the same semantic bu
433.
▲
by
jeremiep
11y ago
I tend to do that mostly for concurrent programs, as I want to see what happens without blocking the entire system like a debugger would. For medium/large programs I'll often prefer a debugger because I can easily and quickly try
434.
▲
by
jeremiep
11y ago
The debugger being sequential is a consequence of your code also being sequential at the CPU level. Understanding the code is often a luxury we don't have, either because we didn't write it in the first place or because there are
435.
▲
by
jeremiep
11y ago
Both points aren't possible to do with large codebases. It will take months merely to tidy the code with the effect of making the rest of the team hate you for committing thousands of files for superficial changes. Its much more produc
436.
▲
by
jeremiep
11y ago
Same goes for optimizations, where we assume 80% of the time is spent in 20% of the code. We just finished profiling our 1M LOC C++ codebase and it shows even more extreme numbers; we hit close to 95% of the time spent in 5% of the code.
437.
▲
by
jeremiep
11y ago
Well, programming can be picked up by just about anyone these days, so its no wonders you get people as mature as youtube commenters in the mix. This is what differentiate professionals from amateurs.
438.
▲
by
jeremiep
11y ago
I completely agree it takes discipline and experience to write clean code in any language. What I'm saying is that it takes more discipline to cleanly use Java or C++ than it does to use Haskell or Clojure. For the simple reason that m
439.
▲
by
jeremiep
11y ago
If a startup can't afford a decent quiet office, they most certainly can't afford all the maintenance that will be caused from creating software in a toxic open-office environment. I've never seen great code come out of an op
440.
▲
by
jeremiep
11y ago
I find it odd that it's up to employees to fix the toxic work environment of the employers, especially when we need to cash out hundreds of dollars.
441.
▲
by
jeremiep
11y ago
Which is why they are so ironic. Most open-offices reduce employee's sense of privacy, motivation and has tons of other negative effects. What began as a money saving scheme ends up costing more to the company, but goes completely unno
442.
▲
by
jeremiep
11y ago
Well said. I would add to this that design patterns do not discern between simple concerns and cross-cutting concerns and those are key elements to get right at the organizational level. Features are by definition almost always cross-cuttin
443.
▲
by
jeremiep
11y ago
My bad, I should've specified legacy C++. You're right that with lambdas now C++ has gotten much better. However I would argue against the STL being well thought out. Every single large-scale C++ project I've worked on threw
444.
▲
by
jeremiep
11y ago
I find that the older I grow as a programmer the less I enjoy cleverness. There's never a good enough reason to use clever algorithms over boring ones. In fact, most of the refactors I did over the past year was to 'undo' cle
445.
▲
by
jeremiep
11y ago
The abstractions provided by Java and C++ aren't very good compared to those provided by, say, Haskell and Clojure. For the most part, design patterns exist merely to fix the lack of a simpler lambda construct in the language. They mor
446.
▲
by
jeremiep
11y ago
But design patterns are horrible at organizing code. They have a much higher chance of introducing unneeded complexity. It should be no surprise that almost every single design pattern can be replaced with a simple lambda in languages sup
447.
▲
by
jeremiep
11y ago
Ubuntu targets a LOT of different hardware, it would be much harder to optimize the layout on their ISO image than it is to optimize for a fixed hardware platform like consoles.
448.
▲
by
jeremiep
11y ago
We also have pretty amazing hardware today that is surprisingly underused most of the time. I've seen many Unity projects with the worst code you could imagine still run close to 60 FPS when shipped. Having an easy entry point means yo
449.
▲
by
jeremiep
11y ago
Same here, I've seen too many code reviews where people complain about a badly named variables and nobody saw the design was faulty leading to costly bugs to fix in production. One thing we did on the current project is pre-commit revi
450.
▲
by
jeremiep
11y ago
The powerful idea is the ability to modify the program as it is running rather than writing a self-modifying program which indeed would be much more complicated. A good example would be the Emacs text editor. You can use it to modify the so
More ›