The difference is that you can distinguish at the type level between values that could be "null" (Optionals) and values that are never null, and the two look different from each other. Otherwise you tend to have one of two problems:
a) Every function checks all its parameters for null, and you do null checks before calling a method on any object, wasting time.
b) It's down to the programmer to figure out where a null check is necessary and where it isn't, and they sometimes get it wrong.
(Of course, better code will avoid calling isDefined or get, but even if you just use it as a like-for-like replacement, using optionals in place of null can improve your program)
Null checks in java are quite cheap, from what I've read.
If your code doesn't check for a null, JIT adds in an implicit check in case it needs to throw a NullPointerException. When you put a check in your code, it knows to eliminate the implicit check.
Putting null checks everywhere does lead to ugly, complicated-looking code though; it'd be nice if there were a simple syntax for non-null parameters.
It's not really about computational expense. It's about making reliable, maintainable software.
The problem with null is that it's a semantic gremlin. Depending on context it could mean all sorts of things including but not limited to, "the value has not yet been set", "the value is undefined", "the value is nothing" or "the software is broken". Which one of those is the correct interpretation at any given time is a question that can only really be answered by a programmer with a good knowledge of the codebase.
Worse yet, even in cases where null isn't a desired behavior it's still inescapable. If your procedure accepts reference types as parameters, it doesn't matter if it has no interest in taking null as an argument, or that it doesn't even make any sense (semantically) for null to be passed as an argument. It still has to be prepared to be handed null as an argument. At a language level, there's simply no support for the concept of, "Guys, I really do need something to go here." Which is simply insane, considering how simple a concept it is.
In languages that don't have null references, it's not that the various semantic meanings of null have been thrown out. All that's been removed is the ambiguity: For each possible (desirable) meaning, a construct is provided to represent specifically that meaning. Meaning that you've gotten rid of the problem of programmers having to magically know what null means in that case, and the worse problem of programmers introducing bugs resulting from them failing to understand null's meaning in a particular context.
It isn't. The difference is that in all the places where you don't use Option[T], you no longer have to have a null check because you have "banned null."
This doesn't seem like a particularly good idea if any of your code needs to run reasonably quickly. Even relatively tame uses of Option[T] in the collections that ship with scala can have a terrible impact if you want to run the code rather than just typecheck it. For instance, if you have some loop in which you want to perform I/O and call getOrElseUpdate on your scala.mutable.HashMap[T, Long], your code will probably spend a majority of its time creating millions of java.lang.Longs, stuffing each one into its own newly-minted Some[Long], and GCing these two things.
If you changed reasonably quickly to extremely quickly I would agree. There is some overhead involved but it is very small. In a copying collector, like the 1st generation of Hotspot's generational GC, the GC cost is proportional to the amount of non-garbage you allocate. Creating lots of very short-lived objects is almost free (allocation is very fast in all GCs). The cost is in memory consumption -- a classic tradeoff of time for space.
Of course if this is an issue you can always fall back to Java's collections or a collection class specialised to Longs. I think the Scala implementors made the right tradeoff for a general purpose library.
The idea is that you don't want to call isDefined at all - you'll want to call getOr(T default) or pass it through a chain of methods that are overloaded doFoo(Some<T> x) { .. stuff .. return Some<U> }/doFoo(None x) { return None; }
Interacting and exploring APIs is either the newest fad or a gold rush for new business, but one of the biggest things stopping me from using them is integration into my existing stable tools. webshell.io is another service which is hosting your code on an external service, leaving you vulnerable to fluctuations in their uptime or stability as a company. There may be new opportunities in turning this into a desktop application.
I would just allow for testing and building online ; want to run on your own server, just click export, pay something (or have a subscription) and there you go. Of course you open source the api wrappers completely to get more people using them outside your platform.
There's no automated service, but you can have the post office hold any package for you for a week or so. These guys look like they're going after the online retailer distribution market though, similar to Amazon's upcoming "lockers" platform.
In Canada the post will hold it, but couriers won't, and the post office won't accept delivery by UPS.
I found a way around: get to know the UPS deliveryman, have him deliver my package's to the (neighbour's) back door when I'm not home. Mostly books, so nothing I would miss if it got taken.
Combined with the recent price war, perhaps Google is recognizing that Amazon is gettin' all up in their business with Kindle Fire - ie, the best selling Android tablet prior to the Nexus7.
That's a pretty interesting situation. I certainly don't think there's any "something" blocking you, I'd guess it's more of a vague feeling of caution that you're clinging to because you can't quite understand it. It's easy to get into these traps when it's something very important (like your job).
There are a few things you can try. You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it. You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this).
Your "sudden change" probably wasn't so sudden, but rather your experience with hitting the limitations of writing shitty code. Now you want to avoid those pitfalls in the future, but your boss doesn't seem to understand.
There's also plenty of places for you to go still, if none of the above works for you.
Edit: Creating a checklist of "the smallest chunk of work" can help you keep moving rather than getting stuck in tweakfinity.
A few suggestions based on my experience (I have the same problem sometimes...):
- "get it working and keep it working": get the minimal possible functionality working (outputting some result, even if there's utterly no error handling, input is ignored, all of the requisite services are stubs and any actual processing is faked), and make sure you keep it working -- if some refactoring is going to take more than an hour or two, plan it differently. This helps you get really quickly to a proof-of-concept (with TODOs everywhere in the code), and stops you from shredding it to "do it right" because that would break it.
- keep a list of your ideas of how to do it correctly, in a separate file. Yes, for the moment we're dropping the input directly into a SQL query and returning the result directly wrapped in a <pre> tag; for the real product we'll need parametrized queries, a dynamically loading JS table (to research), etc. etc.
- stay offline. Do not download libraries or frameworks, do not research the best way to do X, do not research the problem domain or look for open source projects that do similar things but are huge and will suck up your entire afternoon when you could have just hacked out a completely unreuseable, inflexible, one-time fix for this particular problem in an hour. Research is fun, it's interesting, and it's a way to avoid actually doing what you need to do -- half-assed work. If you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours.
Great advice, both from you and grandparent. First, I wanted to say that my boss is a programmer himself, much better than I am, and he understands the value of good code very well. But he's also a bussinesperson and knows when the product is much more important than the code - I trust him on this. At least consciously. It's really not his fault at all.
---
> You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it.
I can't. I mean - I do program in my spare time and have side projects, but if anything it worsens the situation: I have more time and no deadline, so I just tinker with the code until I'm satisfied. And I am satisfied, it's not like I don't know what "good enough" means, just that in personal projects that level of "good" is even higher, because I'm the one who sets it.
> You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this)
This is exactly what I'm trying to do - but it's a workaround at best, not a solution to the problem.
> rather your experience with hitting the limitations of writing shitty code
That's true - around that time I was part of a team that developed CRM system in PHP. It was meant to be 3-4 months project but in the end it was a year long nightmare of rewrites and feeling guilty for everything. I never did any postmortem or proper analysis of what went wrong (everything) and maybe that's why my attitude changed. I wonder if it's too late now?
---
> "get it working and keep it working"
This is a way I work most of the time. And refactoring I do and am talking about is always much quicker than an hour - I do it in very small chunks, one function or class at a time, not breaking the code. It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.
> keep a list of your ideas of how to do it correctly, in a separate file
I do this with larger ideas. It's not that. Rather, I can't force myself to drop the input directly in the SQL using string formatting. I know I did it in PHP years ago and it burned me so hard I won't do it again. Willingly, at least.
> stay offline. Do not download libraries or frameworks, do not research the best way to do X...
> if you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours
This seems to be exactly what I need to do. It never occurred to me, but when I think about it I see that looking for "better" implementation in libraries eats large chunks of my time. And these implementations aren't even that good... Combined with mastery of tools, I think it can work. Thanks, I get the feeling that there is hope for me :)
> It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.
Ah ha... one solution, then, may be to force yourself to stop when it's only just barely working, instead of continuing on refactoring. :)
Pair that with a slightly stronger form of data hiding by using TrueCrypt's hidden partition feature to encrypt the second OS partition. Just make sure not to ever boot into the honeypot os afterwards, or it could overwrite parts of the hidden partition. You can safely load the honeypot os by typing in the hidden password as well so that true crypt can load the proper partition boundaries.
I'm not really sure how you're implementing scrum. Our scrum standups are always just the programmers, once a day in the mornings, and are used to keep all the programmers on the same page and talk to each other to find out if features might have a codependency, or if other blockers can be solved by something else another dev is working on. There's no "watching" of people or "intimidation".
You might want to speak to your manager next time something like that is happening, because there's no way it can be good for your productivity or the other people on your team. It's certainly not a normal practice. At the very worst, if someone isn't pulling their weight they should be dealt with in private.
A daily 30 minute standup with 10 programmers (three minutes each) is 5 hours of development time lost. That's 25 hours a week, over half a full-time developer. It's probably more. Let's say stand-up is at 0900. Nobody getting in early is going to really get in the zone because they know standup is coming. Then after standup there's another 15 - 30 minutes getting into the flow. Then it's nearly lunchtime. In other words, standup pretty much kill half the day.
Our standups are at 11:45, so we have impetus to keep it brief and get to lunch. In any case, even if it does cut into a stretch of programming, it serves as an invaluable reminder to go get lunch.
Yeah, I agree that I'd be annoyed with standup at any time before 11:30, but 11:45 is perfect and basically doesn't interfere with anything. In a certain sense it doesn't cost any dev time at all if you take it for granted that your developers should stop coding midway through the day and eat lunch. (We absolutely do not eat lunch during standup - we have standup, then we physically leave the office to go eat.) Sure, some days we end up in endless meetings which mean we're stuck in the building eating takeout, but that has nothing to do with standup.
We experimented with 10 AM scrum but I found that if I came to the office at 9ish, I used to get distracted with the thought of Scrum. Eventually, we decided to move it to the afternoons at 4:30 which works out well because you are almost done with your work day and you can get distracted all you want.
The goal is 45 seconds a developer not 5 minutes. Round up to 10 minutes a day * 5 days a week = one 50 minute developer meeting a week which is fairly common.
PS: You do lose a little time gathering, and people generally spend some time organizing there thoughts etc. But, keeping track of a short synopsis is useful, as is knowing what other people are working on, and most importantly when someone get's stuck working on the same things for a few days. It also adds a lot of pressure to get at least one thing done every day, which many people slack on.
10 people seems like a very large team for a single project, do you have multiple teams in the same standup? If that's the case then you're certainly wasting time as cross project communication is only rarely going to be useful.
Yeah, but next you'll tell us at your standups you actually stood up. No one gave me an answer when I asked why they called our meeting standup meetings.
In my current project we do actually stand up, although only due to the pleasure of the team leader. The main reason it's called a "stand up" is to serve as a reminder that it should be very short, 5 minutes max, or otherwise the time most people would feel comfortable standing for a meeting.
The exchange doesn't have much of an effect when most goods are priced relative to the exchange rate (many sites even automate this). The only thing the currency price represents is the relative change in market size where these coins are used.
