
Metascala – A JVM written in Scala - ot
https://github.com/lihaoyi/Metascala
======
lihaoyi
Never thought I'd see this up here. I wrote this, if anyone wants to ask
anything about it

~~~
hhandoko
Not related to the project, but have you got any suggestions on good materials
for Scala learning?

Materials I've read / watched / done so far:

    
    
      - Martin Odersky's Functional Programming Coursera course
      - `Scala in Action`
      - 47 Degrees' Scala Koans
    

I'm currently reading `Scala in Depth`.

~~~
rshaban
Likewise, any tips for learning Scala without knowing/learning Java first?

~~~
yareally
Have you used any imperative, statically typed language that's compiled, such
as C#, C++ or Swift? Previous knowledge of a purely functional language would
be useful as well, but not required. Knowing Java helps with debugging and
working with libraries built from Java, which depending on what one is doing
(Android for example or using JSoup for scraping), is inescapable. You'll end
up having to semi learn Java along the way, at least from what a friend told
me (I already knew Java previously, so cannot comment on that). Scala, like
C#, has extension methods to make dealing with Java libraries easier though,
but it still doesn't solve things like JDK annoyances (type erasure).

If you're only familiar with scripting languages, it's going to be sort of a
leap into learning Scala and could be done I think, though probably not the
language I would recommend starting with since it's easy to abuse. The syntax
is nowhere the same, but Scala sort of reminds me of the "Perl of statically
compiled languages" in that you can write some really obtuse code without even
trying if you're not careful. I don't think that's a bad thing necessarily,
because it's a language that gives you a lot of flexibility (and more than
enough rope to hang yourself). If you work with someone else, be sure to
discuss some sort of agreed upon standard to using Scala, else you'll end up
with some messy code.

Scala looks a bit like Python in parts as well as Swift, but I consider it
more closer to a progressive version of C# with F# mixed into it.

------
zak_mc_kracken
So now, your Scala can be both slow to compile and also slow to run!

Seriously though, that's a pretty cool project.

~~~
anon3_
Writing something in scala feels like a waste to me. If they were to narrow
the grammar of the language down, compiler time would decrease and the code
rot situation would be much better.

Instead, teams that want to grow big in scala have to come up with their own
agreements on which features not to use.

The deeper concern I see is the lack of introspection and defensiveness in the
community when the critique is brought up. I've never seen programmers before
take such offense and have to resort to banning programmers criticizing
feature bloat.

It's not a personal attack or trying to kill Scala. There's a legitimate
feeling the language tacked on way too much, too soon.

When it comes to a programming language, negative comments won't kill it. All
languages grow their warts over time. Look at all the critique C absorbed.

~~~
tormeh
The grammar isn't a problem (at lest not for the compiler). Scalac is pretty
fast at giving you error messages. It's when your code is legal that you
really have to wait. I'd speculate that it's the code generator that's the
problem.

~~~
anon3_
Grammar ends up becoming a problem on a few fronts. I highly recommend
_Principles of Compiler Design_ [1].

One safe rule of thumb is, as grammar and rules expand, the performance and
simplicity of the compiler begin to deteriorate, particularly if features
aren't added carefully.

The second is in practice, the additional grammar gives you far more ways to
tackle the same problem. The is the conundrum that metaprogramming gives in
languages like Ruby. Teams begin the phase of coding to the domain before
letting other things fall into place.

Thinking ahead is good, but I think the issue is Scala's grammatical
flexibility makes it too tempting to dig ourselves into a DSL before we're
really ready. This is why we'd get so grumpy when PM's came to us asking for
new features that'd require a refactor. We _bought in_ to our own idioms, if
we programmed things _without_ the DSL, we'd be more nimble.

And we're not dumbasses. We're experienced programmers with experience
programming in that domain before, but the target always ends up moving for
reason's outside of engineering's control. From experience we know, DSL has no
place until you're very secure in what the needs of the business is.

That said, no codebase is future proof to the rest of the team needing last
minute changes - but I feel scala forces you into design decisions too early,
and we thought that was an _advantage_.

Actually, I liked scala for not having Java's boilerplate. Then I began to
miss those old things java forced you into.

It was painful, because the ego investment the team had in scala was huge. A
lot was on the line. Crow had to be eaten.

[1]
[http://en.wikipedia.org/wiki/Principles_of_Compiler_Design](http://en.wikipedia.org/wiki/Principles_of_Compiler_Design)

~~~
thescrewdriver
It's worth pointing out that it's a case of YMMV. There are clearly those who
haven't had success adopting Scala. I've seen Scala used successfully by
multiple teams, but I suspect a strong culture of code reviews may have been a
significant factor in our successful adoption of Scala. I would be
disappointed if they tried to remove features from Scala, the extra features
really do come in useful when used selectively.

~~~
anon3_
If a good team nails the guidelines down _before hand_ on which idioms they
plan to use and stick to them, yeah.

That is a rare qualifier to meet in my experience, many teams will be ecstatic
about scala. Many times we'd be hiring java programmers who felt that scala
would make them more relevant in the startup world.

Next is the situation where it would be, "Just hold keep holding on..." until
a. the language finally _clicks_ b. the whole system is in scala. c. Both.

Scala did just click. And there never was a best solution to solve a problem.
Python programmers were canned, we had the floor - those "distractions" were
eliminated. We just got in this vicious cycle while we burned away our runway.

Now we look back, bitter, and make excuses. What hurts my pride to say is, Why
didn't we just pick the safe bet - the Python or the Java.

I upvoted you. If you got a smart team and can make scala work somehow, all
the power to you. I think you should make a story about how you scaled your
code so the rest of us can learn

~~~
zak_mc_kracken
> If a good team nails the guidelines down before hand on which idioms they
> plan to use and stick to them, yeah.

So, like we used to do with C++? Anyone old enough to remember "C++ is fine as
long as you define a well specified subset and stay away from certain
features"? Even today, this is still what Google does about C++.

Hopefully we learned that this is never a good sign about a language.

~~~
thescrewdriver
In our case it wasn't about enforcing the use of a subset of the language, but
rather being selective about when to use more advanced features. Having the
advanced features of Scala available has proven to be very useful for us, but
we don't go to town looking for a place to use every feature we can at every
opportunity. It's a lot like chrome on a car - selectively and tastefully used
it looks good, but making the car doors and roof out of chrome isn't a good
idea.

------
CRUDmeariver
println(println("inception"))

