The definition of compiler i learned was “takes some code, translate it to semantically equivalent code in a different language (which might be machine language, bytecode…)”. This is also used in PLaI, a respected learning resource: https://www.plai.org/
I think this is a pretty acceptable definition, and yes, it does make the term transpiler a little useless.
Any dynamic language - by definition, they check types at runtime.
Or, unfortunately, a lot of static languages. Any static language that allows type casting, for instance - that's the only way they can check whether a cast from a type to one of its descendants is valid (eg, in Java, casting an Object to a, say, URL).
You say that like it's a bad thing, but that's what a static language is - types are checked at compile time and, hopefully, forgotten about at runtime.
But java.util.Date is mutable where a long isn't, and that's a problem. People can mutate a Date from under your feet if they manage to get a reference to it. This has a lot of far reaching implications, but essentially, unless you protectively copy all values of type Date you get or give, you can't trust your own internal state. You can't write a legal equals or hashCode implementation that uses a date field. The list goes on.
I would say that rather depends on what OP means by "properly".
If OP already knows Scala and would like to get better at it and one assumes that "Scala as Haskell in the JVM" is more desirable than "Scala as a better Java", then yes, that's a great suggestion.
If OP wants to learn Scala from the ground up, I disagree pretty strongly with starting there. It's a great book, well written, with a wealth of challenging and mind-opening exercises, but I wouldn't recommend that as anyone's first exposure to the language. The second or third, sure, but it purposefully restricts itself to what its authors consider a sane subset of the language.
I happen to agree with their definition, but, in my experience, knowing a programming language is about reading it as well as writing it, and by restricting your learning to a subset of the language, you'll find yourself unable to understand perfectly valid, normal code - code that is part of the standard library, for instance.
I would rather suggest reading Odersky's book while allowing oneself to skip large chunks that go rather in too much details about fairly useless things like the XML API. Or going through scala-exercises (https://www.scala-exercises.org). Or the coursera class - its first incarnation was pretty good, I assume the new one is at least of the same caliber. They might not make you an expert overnight, but they'll get you to know most of the Scala features you're likely to encounter in the wild, and to be able to read and learn from most Scala OSS projects.
But still, you end up with tests for what the author feels his code should handle, not necessarily what the real world is actually like.
Don't get me wrong, that's still valuable - if only for the non-regression aspect - but I feel property-based testing is a superior approach.
Write your code ("this is a function that sorts lists of ints"), write a property ("when given a list of ints, after sorting it, elements should be sorted and the list should have the same size"), let the framework generate test cases for you. Whenever something breaks ("lists of one element come back empty"), extract the test case and put it in a unit test to make sure the same issue doesn't crop up again in the future.
What do you mean, you should not be testing internal implementations anyway? Does that also mean you don't do unit test, only integration or end-to-end ones, because unit tests are tests of the internal implementation of your software?
Or, you know, write property-based tests instead, so you only need to worry about the logic and not the test values.
I've always found that if you let the author of a piece of code decide on what value that code should be tested with, he'll test for the edge cases that he's thought of (and dealt with), not the ones that actually crash production.
I thought the concept entertaining, up until I read the bit about "rape causing little to no long lasting harm to the victim". Shame, this could have been a fun, if weird and selfish, thing.
I agree with part of your sentence only. Managers, especially professional ones (as opposed to ones that were promoted from the kind of position they end up managing) do tend to push for client-facing features with little thought to the accumulating technical debt.
It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.
There might not be such a distinction in France. It was a summer job with some level of mentoring, which we just call "internship". It's entirely possible that this is what Americans would call an apprenticeship, my vocabulary is not wide enough to know for sure.
Yeah, it was an internship with some friend of my parents. I don't believe there was a formal contract or that I read it if there was (but I was 16 and very naive).
The "managers are assholes" bit was meant as a joke, and I learned loads from that internship. It's just that when you're that young and self centered, you tend to see what you didn't get rather than what you did.
While I agree with you now, I recall being on the edge of tears when my very first internship concluded and my manager told me I'd already gotten paid in knowledge and should not expect cash on top of that. For the longest of times, I assumed the knowledge he was talking about was "managers are assholes".
> Who says the dress code is a reasonable decision?
I'll tell you who doesn't get to say whether it is or is not: interns (unless the dress code is illegal, but that doesn't appear to have been the case).
Slave labour? I assume you're talking about internship in the US, how does that work?
In France, I personally pay my interns (no great credit to me though, it's a legal obligation), give them a bonus (usually one month's wages) at the end of the internship unless their performance / attitude has been abysmal, and make sure I devote some of my time to training them (although to be faire it probably averages under 1h a day). It's probably not the best deal in the world, but I certainly wouldn't call slave labour...
When n (for n >= 2) interns are all told separately no, then gang up and demand more time and attention be devoted to their problem, a problem for which a reasonable decision has already been taken and made clear, it is aggravating.
You might have a much higher tolerance to your time being wasted than I do, and that probably does make you the better person. I can take a fair amount of rudeness, lateness and incompetence. Wasting what little time I have on matters that I have already made clear were not up for discussion though, that'll get to me.
There might very well be an open door policy in that company - apparently, all interns had talked to their managers about the issue, so managers are available.
Just because they were denied doesn't mean they weren't able to make their case.
Coming back with a piece of paper that essentially says "look how many we are, surely you're wrong and we're right" is aggravating, especially from interns who have no experience and would better spend their time trying to understand why things work a certain way rather than assume they're right.
Dismissing them is a bit harsh, but we don't really know how aggravating they were nor how much of management's time they wasted. If this whole thing turned into a 1 hour long meeting where they refused to be told no, then I might also have thought this particular bunch might be more trouble than they're worth.
Thanks for taking the time to share this. I was aware of the community build - I believe it was discussed in some depths on Scalawags a while ago? - and find it to be an amazing initiative. Can't think of a better way to minimise the issues that Dotty might cause, and I'm in awe of the amount of work it must represent.
What I fear in that moment down the line where one feature goes over the arbitrary threshold you set yourself for community breakage, but is just too great to pass up on. Since the threshold is arbitrary anyway, it's fine to adjust it a bit... and a bit more later...
Not saying it will happen, and it would be dishonest of me not to say that I don't think you could possibly do more than you're already doing to prevent this kind of issue.
I think this is a pretty acceptable definition, and yes, it does make the term transpiler a little useless.