Hacker News new | past | comments | ask | show | jobs | submit | raiflip's comments login

At that point you're left with two benefits: 1) Organizing your codebase so that it is easy to find which functions operate on which data 2) Controlling access to those methods on the programming language level. I.E, TankerService is the only class with Tanker instances and therefore the only part of the code with access to those methods.


So you're filtering specifically for timeslots where the end date is null and therefore guaranteeing that you return a timeslot dated to now?


  if timeslots.stream().matchNone(Timeslot::hasntEnded) {
    new Timeslot()
  }
Would be an improvement I guess. The way I found this code it was also wrapped in a @Transaction so it creates a new object in the database with spring magic. There was a lot of other things wrong with the code, that was not my point though. Lots of people just think FP better and of course in theory they are right but most people don't think for themselfs.

People are quick to act insulted whenever I give some critical remarks about FP.

When would you use a forEach function instead of a for each statement, I suggest maybe only use the function if the callback is actually a higher order function you get from somewhere else as I don't see the point of wrapping your logic in a closure.

Same thing with the use of observables/reactivity in UI programming, again it is illegal to question this orthodoxy. But then you take a look at how graphics programmers use immediate mode programming and fancy compute shaders to draw the entire frame every frame it makes me smile at how much simpler everything becomes.


FP has also benefited from a hype cycle, and FP does improve code in a lot of ways. Making your data immutable makes it easier to reason about, and pure functions prevent surprises. However if your argument is state is bad, and FP avoids state, so that is why it is good, but you encounter a scenario in which state is required, then the benefits of FP start to degrade.

The reality is closer that, state should be immutable, and minimized as much as possible, but at the end of the day, almost every interesting problem requires storing state. Once you reach that point, classes are simply a better solution for state than closures. Especially if your class and its variables are immutable, you get all the benefits I mentioned and none of these tradeoffs. Your state is explicitly stated.


+100

Sorry for not adding more. But just so this. I’ve loved learning Elixir of late. But my programs need state. I really miss how well I could model general state using objects like those afforded by Smalltalk and Python. I wish there was a best of both worlds, but I wonder if to do one well, you have to overreach so much with the one philosophy, that the other just can’t be tolerated well in its presence.


But agents and genservers are a good way of dealing with state.


Sometimes it sounds like bay area programmers think how expensive their area is, is how it is for programmers elsewhere. I also get paid around the same range in NYC, but my mortgage is nowhere near 10k, my taxes eat maybe 40%, and I can definitely find restaurant meals for less than $30.

The high expenses of the bay area are a policy choice by the local and state government to disallow investment. As such everyone is competing for the same old housing stock and office space that cost a 1/3rd of what it does now years ago. In effect, house owners and landlords are appropriating tech profits to themselves.

I hope the banning of single home zoning in California helps to alleviate this issue.


OP explicitly mentioned Bay Area in his post. I'd agree that housing policy is brain-dead in the Bay Area and that causes a lot of the high CoL; the other major factor is that these tech salaries are a significant fraction of total earners, which gives people selling to them enough of a market to raise prices. If 1% of the population makes $300K/year, they get to live like a 1%er. If 10% of the population makes $300K/year, they live like a 10%er.


"Turn around time to get a server spun up was ~6-8 weeks." -> ok this one threw me for a loop. I can literally get an EC2 server spun up within minutes inside Amazon. But as others have stated org quality varies a lot. If you are dealing with an org that requires you to say at the beginning of the year exactly what budget you need, I could see that.


This was years ago with their own data centers and yes budgets with server allocations at the beginning of the year or twice a year.


I think this is absolutely it. A lot of best practices go down the drain when the compiler compiles the bytecode. As such a lot of best practices are about people, not the computer. APIs can be just as stable behind a network or a library, but way more people are onboard with never break your APIs than they are never break your function.


It seems reductionist to say Amazon primarily wraps around open source. What about EC2? S3? Glue? DynamoDB? Many of the services that provide the most value are services Amazon has built out.


Om top of these, many of the core services that AWS themselves rely on, like SQS, SNS, Kinesis, Lambda, Cloudfront, ECS, Fargate, Elastic Beanstalk are mostly homemade


EC2 uses the KVM hypervisor.


Regardless of whether or not gravitons actually exist, it is feasible that the US government will want to signal to adversaries that they do have this technology. After all, a deterrent is useless if your adversary doesn't know it exists. You can't be deterred by something you don't know about.


Old Testament version of Christianity? You mean Judaism?


heh, oops. yep :)


Types are just labels that a parse has already been done and doesn't need to be done again. Use them when you don't need to parse again, don't when you do want to parse again.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: