nrinaudo

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.

Don't do java.util.Date.

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.

I hate to be that guy, but in the fourth paragraph, the author mentions the variance issue as old news.

And else is used more than if...

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.

If you feel my comments were dismissive of your work, or your team's work, then I owe you an apology. You're right to be proud of what you've done, it's quite a list of achievements and I can only hope I ever produce work of that quality.

My english is obviously not as fluent as I thought it was. None of this was meant to be implied by my comments. I have no opinion on what the best way to advance Scala might be, nor am I even qualified to hold such an opinion. I have no idea whether Odersky's continued involvement with the language is needed or even desirable. I've no concept how much work is being done on Scala - none whatsoever? more than I could possibly imagine? probably somewhere in the middle.

What I said, and mean as my opinion and not an absolute truth, is that a non-insignificant chunk of the brains that used to work on Scala now seems to be busy on Dotty, and that the resulting work, amazing though it may be, might not make it back to Scala.

I have nothing to back this opinion up. Everybody involved with Dotty seems absolutely committed to it being the future Scala, and I've no reason to believe they're not in earnest. But I can't take the switch for granted until it's happened.

Well, two answers to that.

The first is that the linked post answers a lot of points, but not the ones I made. It makes Dotty sounds really exciting, which it is. It makes it sound as if everybody working on Dotty believes it to be the future of Scala, and I believe that to be true, too. What it does not do (that I could see) is give reassurance that Dotty and Scala will not drift appart and become two similar but incompatible languages. I felt it'd be rude to point this out, since there really is no way to provide such guarantees (just like there really is no way for me to back up my worries with anything concrete).

The second part is, I'm not casting doubts, but expressing worries. I'm not saying it will happen, I fear it might. I'm sorry if this offends - I really am, my goal is not to insult anyone or demean anyone's work. I have no hidden agenda, and I'm not trying to be one of these anti-Scala trolls that sometime crop up. I love Scala. Look at my github profile, most of my public work is in Scala, and some of my libraries represent a lot of work (which obviously does not mean they're actually any good). I really, really hope everything works out the way people mean it to - as I said, Dotty sounds really exciting. I've seen too many "let's rewrite this from scratch and then make it backward compatible, it'll be amazing" projects to be able to believe it blindly, though.

You're misreading my comment. What bothers me is not that the "father of Scala" is working on the future of Scala, but that he's working on something that I fear might become another language altogether.

I'm not saying Scala is in bad hands or a dead language. But when a project's creator looses interest and moves to different things, well, it's usually not the best sign for that project. And again, I'm not saying that this is happening right now, or even that it necessarily will, just that Dotty definitely has the potential of leading to that situation.

Absolutely. I'm saying I fear reality and theory might diverge and we find ourselves with a split language / community. I highly doubt anybody set out to write Python 3 thinking "it'll mess with the community for years to come, muhahaha".

My fear is that the feature sets diverge enough that we get two very similar but distinct languages and a split community.

I'm not afraid that the experiments have moved to Dotty. That's an ideal scenario, if successful ones are indeed ported to Scala. I'm just not convinced they will be.

Thanks. I'll give this a thorough read - I think it deserves more than the cursory read I can afford to give it right now - and appreciate the time investment this no doubt represents.