Indeed.
I see this as a sign that 3D touch is not getting much traction.
903 karma · joined July 10, 2015
Indeed.
I see this as a sign that 3D touch is not getting much traction.
Do you seriously think your team is made of 100% people who only ever tell the truth?
Let's get realistic, we all tell lies here and there. What matters is what you lie about and why you do it.
I couldn't care less if a developer joins my team and lied to get a higher compensation. All I care about is whether they are a good hire and if they'll do good work.
In the US, this is a legal minefield and when a potential employer calls a past employer for references, that past employer will very often not reveal anything more than "We can confirm that this person was employed by us from date1 to date2" and that's it.
They will not disclose your salary, what you did, your organization, who you reported to and who reported to you, your performance reviews and anything else of that nature because all of this extra information is grounds for you to sue them later if you don't get the job you're currently applying to.
And if they do and somehow, your previous employer disclosed this to them (a big no no), you can always say "I was underpaid then and what I was making there is not relevant to the position I'm applying to with your right now. I also think I've learned a lot in my past position, which justifies this jump in compensation".
Typescript is a whole different beast and I think the article makes great points for libraries. The more types the better.
Easy to grasp for whom? A first grader? Sixth grader? Twelfth grader? College undergrad? Any specialty or only CS? Or grad level required?
You've forgotten how long it took you to get comfortable with abstract algebra, it's a lot more complex to grasp than you think.
That's a slippery slope. When you are staring at a huge stack of accumulated knowledge, you need to decide when you can start ignoring the details past a certain level.
It's not required to know assembly to write code in a modern language, but it helps. It shouldn't be required to know category theory to write code in a modern language either.
We heard the same thing with C++ 20 years ago and see where it went...
The only thing modern about Go is that it's just a few years old, but it's based on programming language concepts that were mainstream in the late 90s.
I don't know what libraries you are looking at but these are extremely rare these days. At least for the popular ones. You seem to be talking about Java like it was written eight years ago.
As for your other point, tying Java interop with existential types is pretty absurd.
I'd say both Kotlin and Scala are about equally good when it comes to interoperating with Java.
This makes no sense.
Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference.
Type inference only enables to omit type annotations in certain parts of your code. Your values are just as typed as if you had used that type annotation.
As for the original point you were trying to make, I would say Scala is no more type safe than Java. They are about on par in how they allow unsafe expressions to type check. Scala's type system is certainly richer than Java's, but that's a separate point (and maybe the one you were trying to make).
> In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.
Absolutely not.
Omitting a type in your source doesn't remove the type from that variable. The code is exactly as typed with that type annotation as it is without.
Good software benefits everyone.
Whether it's open source or not is irrelevant.
Even Java has a sane typing system if you stay away from arrays (use ArrayList for crying out loud) but beyond Java, there is a wealth of languages with very good static type systems (Scala, Kotlin, Ceylon).
Funny, as soon as you said that, I nodded and I immediately thought "For example, the universal search dialog should definitely not be modal". And then you follow with...
> "Find in Path" is a particularly obnoxious example
Totally agree and I'm surprised I missed it. Modal dialogs are not user friendly (and very old school UI).
It makes sense, but it's not user friendly, which is the point I was making.
For example, Ctrl-w is a very important keybinding on IDEA, one that I use all the time (it expands the selection to the enclosing expression). It's literally wired in my brain now. To the point that I now use it in Eclipse as well and I even started using it in other places (Sublime, etc...) and... closing the window as a result. Very annoying.
Another one is that Ctrl-n sometimes creates a new file (expected) and sometimes... something completely different depending on your current window. Again, not friendly. Optimized for development and a life saver on the long run, for sure, but it's fairly user hostile.
But what a memory.