wellpast

57 ms·

541.
by wellpast 10y ago
> But hopefully we have paved the way for future models and empirical studies on the nature of self, a problem that philosophers have made essentially no headway in solving. This final statement not only seems snide but also dumb to the
542.
by wellpast 10y ago
Grassroots campaigns (Sanders, Trump) this election cycle raised general awareness of a lot of important issues. I'm not sure the fundamental issues are any more complicated today than they were yesterday. We need more grassroots activ
543.
by wellpast 10y ago
> The best you can do is estimate based on historical metrics which ... is not worth very much. I've had significant success in using historical metrics to accurately estimate software projects. It takes diligence and professional e
544.
by wellpast 10y ago
> Since the dawn of computing our industry has been engaged on a never ending quest to build the perfect language. ...unfortunately. I see PLs as mere material - sure, you can improve on them but at far more important is how we architect
545.
by wellpast 10y ago
I think another key part of the dream is IDE support. So maybe the dream is complete with: Graal + Truffle + Nitra[1]. [1] Nitra - https://github.com/JetBrains/Nitra
546.
GitHub for Data(data.world)
7 points by wellpast 10y ago|0 comments
547.
by wellpast 10y ago
Why should one always expect a thread to be interruptible? If I don't run my thread within an Executor or some other framework that could interrupt my thread, then I should be able to consider that an illegal state.
548.
by wellpast 10y ago
Here's a common pattern for sleeping on a thread you do not expect to be interrupted and both are equally valid and fine ways to implement it: try { Thread.sleep(1000); } catch (InterruptedException e) { throw new Illeg
549.
by wellpast 10y ago
Diaper pattern - Never heard that before but I like it and it's accurate. I prefer to catch Exceptions that I know how I want to handle and handle them accordingly. For other exceptions, I prefer to let them fly. If and when they happe
550.
by wellpast 10y ago
This is flawed thinking. I'd say in many cases it is perfectly desired to either swallow or re-throw exceptions. As just one example, many business rules can be correctly implemented as best-effort and if some resource (network or serv
551.
Arcade City * Dear Austin(arcade.city)
1 points by wellpast 10y ago|0 comments
552.
by wellpast 10y ago
So the problem you're talking about is how to properly manage (and coach) less experienced devs or devs who write messy code. While code reviews can tangentially deal with this, I think there are much more direct approaches to these pr
553.
by wellpast 10y ago
Continuous integration means you can work on multiple items at once and that you break up large feature dev into smaller chunks that get committed to master. For example, I might commit the data layer for a new big feature well before the U
554.
by wellpast 10y ago
For me continuous integration and refactoring have been the most important practices in keeping a code base clean, robust and agile. Code review cultures tend to encourage the opposite of these agile practices: monolithic commits, infrequen
555.
by wellpast 10y ago
Not sure how to formalize but the team's I've worked on have generally negotiated mutual respect, openness, and teamwork by collaborating on the things of greater import -- the architecture, domain conceptualization, etc. And peer
556.
by wellpast 10y ago
It's not arrogance. You don't have to write perfect code to realize that the insane cost of code review is not worth the problems it is supposed to solve. Especially when code reviews are notoriously not very good anyway at excisi
557.
by wellpast 10y ago
What often goes unmentioned in praise for code review processes is their insanely exorbitant costs -- measured in engineer hours but perhaps more costly is all of the blocking and impedance [1]. Most of the "problems" that code re
558.
by wellpast 10y ago
> The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant. Nowadays, we do programming by poking. I imagine many of us do programming by poking. But the skill set referr
559.
by wellpast 11y ago
Right. An identical query: https://github.com/search?utf8=%E2%9C%93&q=IllegalStateExcep...
560.
by wellpast 11y ago
> Not upgrading (incrementally in small, manageable chunks) is one of the highest costs to incur. Absolutely not true as generalizable statement. Not even close. I've worked on several large software projects, from systems dev and f
561.
by wellpast 11y ago
> Upgrade everything, all the time In my experience, rationality is better. Everything we do to our code assets has an associated cost. Therefore, everything we do should have a clear justification -- unless of course you have countless
562.
by wellpast 11y ago
Syntax highlighting traditionally chooses a different color for each token in this Java statement: final String id = leader(NAMES_AND_SCORES); If I try to translate this statement into English: Given a global list of names an
563.
Employers much prefer that workers be fungible(loper-os.org)
1 points by wellpast 11y ago|0 comments
564.
by wellpast 11y ago
> Talking about [Kotlin] lines of code, the number of these in open repositories on GitHub is growing exponentially over time. This could also mean you've designed a verbose and turgid language. A better metric might be # of projec
565.
by wellpast 11y ago
I think there can exist a perhaps rarer beast that values BOTH perfection and viability. What this one does is keep his/her obsessive-compulsive eye on what is the perfect goal, knowing full well it may never be reached, then she turns
566.
by wellpast 11y ago
> I'm willing to add increased coupling if it makes my code more stateless. I like statelessness as a top priority. However I'm not sure how statelessness ever comes into tension w/ coupling. Aren't they mostly orthog
567.
by wellpast 11y ago
> In some sense this is academic, ... Whether all of this is academic or not, I don't know. But what I do know is that these ideas and their practical implications have an ENORMOUS impact on the practitioner's and business&#x27
568.
by wellpast 11y ago
Those dependencies you mentioned are all highly stable. That's the objective & precise way to say that they are "the right abstractions" [1]. [1] This should further articulate why "right/wrong abstraction&quo
569.
by wellpast 11y ago
Here's a very objective and powerful way to measure complexity: dependencies and volatility. Otherwise we're all saying "complex" but not being clear and likely meaning different things. For example, a lot of people beli
570.
by wellpast 11y ago
fixed!

More ›