Why not Scala?
15 views
Skip to first unread message
Tom
Nov 18, 2009, 4:25:30 AM11/18/09
to Noop
It strikes me that many of your stated aims (what noop says "Yes" and
"No" to) are very much aligned with what Scala already does. From
what I understand you guys are writing the compiler in Scala currently
(since noop isn't yet self-hosting, correct?), which would seem to
indicate that you are both familiar with it and hold it in high enough
esteem to use it. Yet you clearly find it lacking enough to create a
whole new language!
Do you think Scala has fundamental flaws that can only be addressed
with a new language?
Not to evangelize too much, but it seems like one of Scala's many
selling points is that you can practically extend the language itself
via libraries, so why not use that and apply your philosophies to
something that already has a lot of traction?
"No" to) are very much aligned with what Scala already does. From
what I understand you guys are writing the compiler in Scala currently
(since noop isn't yet self-hosting, correct?), which would seem to
indicate that you are both familiar with it and hold it in high enough
esteem to use it. Yet you clearly find it lacking enough to create a
whole new language!
Do you think Scala has fundamental flaws that can only be addressed
with a new language?
Not to evangelize too much, but it seems like one of Scala's many
selling points is that you can practically extend the language itself
via libraries, so why not use that and apply your philosophies to
something that already has a lot of traction?
Alex Eagle
Nov 30, 2009, 8:08:54 AM11/30/09
to Noop
It's a fair question, I've actually been thinking about writing
something about this over the last couple days, since scanning through
Alex Payne's new oreilly book which I made a friend buy :)
Like you say, we clearly do like Scala. It's an improvement over Java
in a lot of ways. But I think if your focus is on maintainable, large
corporate systems, you would make some different design decisions.
Scala has static methods and statically modifiable state, in a big
way, by having object separate from class. This is death to
testability, as you cannot mock out a call to a static method. Even in
the Noop interpreter, I already have an example [1]. I'm forced to
have an object as my entry point, and would like to have the JVM exit
with the exit code returned from the program I'm running, so I need
System.exit. But I want to test my main, and System.exit will kill the
test runner. So I have to build the mock into the production code. If
you use a third-party scala library, you'll be stuck with that sort of
un-replaceable dependency, and they really hurt when they touch the
boundaries of your program, like parsing options, dealing with I/O,
and so on.
The syntax lends itself to unreadability. If you look at some gnarly
scala code, you'll see nested left-folds with underscore for the
captured variable, or spaces as a DSL where the parity of the number
of words determines the order of method calls. Optional semicolons
where the statement may not continue on the next line, or may mean
something different. All of that stuff feels nice to write, but not as
nice in a code review, or when you're browsing the code trying to spot
where your bug might be hiding. It's reminiscent of obfuscated perl.
We prefer to be explicit with all that stuff. As another example, look
at the problem with relative package names in imports. In Scala 2.8,
there will be two different semantics for the same syntax, to try to
fix the issue with hiding classes that have ambiguous relative parents
with the same name. I think this was to "avoid typing", which I feel
strongly is a tooling problem, not a language problem. "Avoid typing"
also favors the code writer over the code reader which we think is
backwards.
As to your point about developing something within the Scala ecosystem
that can meet our goals, that's a fair observation. Scala does allow a
great flexibility in how libraries can be used, for a statically typed
language. How do we avoid you falling into the problem with statics,
though? And how does the dependency injector get bootstrapped? I feel
like our library would need to make you code in a non-Scala idiom, and
you'd have to ask your team to remember to use our library all the
time. We might also have to wrap a lot of the standard libraries.
-Alex
something about this over the last couple days, since scanning through
Alex Payne's new oreilly book which I made a friend buy :)
Like you say, we clearly do like Scala. It's an improvement over Java
in a lot of ways. But I think if your focus is on maintainable, large
corporate systems, you would make some different design decisions.
Scala has static methods and statically modifiable state, in a big
way, by having object separate from class. This is death to
testability, as you cannot mock out a call to a static method. Even in
the Noop interpreter, I already have an example [1]. I'm forced to
have an object as my entry point, and would like to have the JVM exit
with the exit code returned from the program I'm running, so I need
System.exit. But I want to test my main, and System.exit will kill the
test runner. So I have to build the mock into the production code. If
you use a third-party scala library, you'll be stuck with that sort of
un-replaceable dependency, and they really hurt when they touch the
boundaries of your program, like parsing options, dealing with I/O,
and so on.
The syntax lends itself to unreadability. If you look at some gnarly
scala code, you'll see nested left-folds with underscore for the
captured variable, or spaces as a DSL where the parity of the number
of words determines the order of method calls. Optional semicolons
where the statement may not continue on the next line, or may mean
something different. All of that stuff feels nice to write, but not as
nice in a code review, or when you're browsing the code trying to spot
where your bug might be hiding. It's reminiscent of obfuscated perl.
We prefer to be explicit with all that stuff. As another example, look
at the problem with relative package names in imports. In Scala 2.8,
there will be two different semantics for the same syntax, to try to
fix the issue with hiding classes that have ambiguous relative parents
with the same name. I think this was to "avoid typing", which I feel
strongly is a tooling problem, not a language problem. "Avoid typing"
also favors the code writer over the code reader which we think is
backwards.
As to your point about developing something within the Scala ecosystem
that can meet our goals, that's a fair observation. Scala does allow a
great flexibility in how libraries can be used, for a statically typed
language. How do we avoid you falling into the problem with statics,
though? And how does the dependency injector get bootstrapped? I feel
like our library would need to make you code in a non-Scala idiom, and
you'd have to ask your team to remember to use our library all the
time. We might also have to wrap a lot of the standard libraries.
-Alex
Nilanjan
Dec 2, 2009, 10:36:32 PM12/2/09
to Noop
Having pure functions and higher order functions mostly takes care of
testability issues.
def doit(callback: () => Boolean = { () => System.exit(1) }) {
...
}
now for testing you could always pass a mock implementation of the
callback.
Thanks
Nilanjan
testability issues.
def doit(callback: () => Boolean = { () => System.exit(1) }) {
...
}
now for testing you could always pass a mock implementation of the
callback.
Thanks
Nilanjan
Christian Gruber
Dec 4, 2009, 5:46:57 PM12/4/09
to Noop
Adding to this a bit. It's not just philosophy of testability, but
also to balance several principles. These also include readability of
code (and this is my personal view, not that of the project but I'm
not enjoying reading the more advanced features of scala), elimination
of boilerplate, making it easier ondo the right thing and harder to do
the wrong thing (eliminating statics, replacing implementation
inheritance with a strong delegation pattern), etc. Scala does some
of wha I want to see in a language, but I prefer other options for
some of scala's choices. It's a fine language, but not the language I
want to code in. In fac the project is only written in scala against
my preference, and I'm only ok with it because well eliminate it when
noop is self hosting.
Having said that, scala's a lot more powerful and elegant than many
modern languages. Hats off to it's creators. Some of what scala has
done inspired some of our proposals.
Christian
also to balance several principles. These also include readability of
code (and this is my personal view, not that of the project but I'm
not enjoying reading the more advanced features of scala), elimination
of boilerplate, making it easier ondo the right thing and harder to do
the wrong thing (eliminating statics, replacing implementation
inheritance with a strong delegation pattern), etc. Scala does some
of wha I want to see in a language, but I prefer other options for
some of scala's choices. It's a fine language, but not the language I
want to code in. In fac the project is only written in scala against
my preference, and I'm only ok with it because well eliminate it when
noop is self hosting.
Having said that, scala's a lot more powerful and elegant than many
modern languages. Hats off to it's creators. Some of what scala has
done inspired some of our proposals.
Christian
Reply all
Reply to author
Forward
0 new messages