Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When we read the wikipedia description of the Kotlin programming language, it is stating that:
JetBrains lead Dmitry Jemerov said that most languages did not have the features they were looking for, with the exception of Scala. However, he cited the slow compile time of Scala as an obvious deficiency.[4] One of the stated goals of Kotlin is to compile as quickly as Java.
How did they achieve that goal? And why is Scala compile time so slow that it was unacceptable for the Kotlin creators? Or - in other words - which features of the Scala compiler make it slower than the Kotlin compiler?
Although I think the question is not well suited for Stack Overflow as it will tend to produce primarily opinion based answers, here is one attempt: You have two different languages, especially concerning the type system, and two completely independent implementations of compilers. So to expect them to have the "same" kind of compilation speed is already a fallacy. I have linked in my comment to another question that examines the speed of the Scala compiler. Basically, it depends on many factors, for example the amount of work that the type inferencer and implicit resolution required by a specific code base.
Nevertheless, I ran a very quick example: I compiled some Project Euler solutions in Kotlin and Scala. This gave me for a fresh re-compile of the whole project:
6 seconds in Kotlin (down to 5 seconds in successive re-builds)
10 seconds in Scala (down to 7 seconds in successive re-builds).
Origin of the source code:
I took this code for Kotlin, changed a lot of imports because apparently the Kotlin standard library changed in the meantime, in order to make it compile.
I took this code for Scala, and converted it into an sbt project with each problem wrapped in an object pXY extends App { ... } and placed it in a package euler.
Then I removed the files for which only one solution existed, ending up with 26 problems. Both projects were compiled with IntelliJ IDEA 15 CE using Rebuild Project.
To give another perspective on this business, I ran wc (word count) on the sources:
// lines words bytes
931 3603 33087 total // Kotlin
261 1166 6472 total // Scala
So now you can either argue that the Kotlin compiler needed to process "more source code" or that the Scala code was "more dense" :)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
How does one organise code in a Scala project?
After years of developing with Java (most of the times using Spring), we're trying to come up with a quick prototype in Scala.
One of the first questions that popped up is: will we just basically use the same package names and code organisation and just write code in Scala?
For example, we're used to have helpers for our entities (AccountHelper, CacheHelper...) and also sometimes we use services too (AccountService...).
ot: Further away we'll also investigate on how to port our maven submodules to sbt, but that's a different story altogether.
The answer partly depends on what is most important to you. If you are really serious about the quick prototype part, then as far as the physical file/directory layout, I would just start with one flat file and only start breaking it up when there is enough code to make that awkward. This should at least make global restructuring of your code easier until you get the overall structure right. Scala does not enforce the package:directory, class:file correspondence, and given the conciseness of Scala that can be overkill in many cases anyway.
There is nothing to stop you organizing things into multiple packages within the one file before you break it up physically once you have the structure right. Actually breaking the file up when you need to should be very easy then.
You did not say much about what your Helper & Service classes do, but from the naming convention they sound like good candidates for generic (aka parametric) traits or classes. This would allow you to factor out what all the different Helpers have in common (and similarly for Services). They should have a fair bit in common to justify the naming convention. You would then end up using or possibly extending types like Helper[Cache] and Service[Account]. I am also guessing these types will have few instances with rather broad scope and may benefit from being passed around implicitly, making Helper[_] and Service[_] into type classes. It is also possible that you will no longer need Spring at this point, since implicit lookup may give you the dependency injection you need. However, I am just going by a few class names you provided and reading an awful lot into them, so the chances are that I am completely off base here.
Another possibility is that auxiliary classes like Helper & Service are just closures in disguise. This is a fairly common case with such classes in Java. In this case you should just implement them as functions in Scala, but again I am just guessing from the names...
You could also look into the Layer Cake pattern and see if that makes sense for your project.
More information about your project would probably get you better advice than these products of my overactive imagination :).
Hera are some potentially useful links:
http://jonasboner.com/real-world-scala-dependency-injection-di/
Where does Scala look for implicits?
http://www.youtube.com/watch?v=yLbdw06tKPQ
https://vimeo.com/20308847
http://www.youtube.com/watch?v=YZxL0alO1yc
I organize packages in basically the same way, but wind up
implementing things differently.
When I first started writing scala coming from java it took me a while
to get used to a few things:
Use companion objects instead of "static"
class Bla { }
object Bla { ... }
Forget about "get*", "set*" getters and setters - use val, var - prefer val.
Get to know scala.collection., Option, and scala.collection.JavaConversions. -
(which provides implicit conversion between java and scala collection types),
so you can write code like this:
class Helper {
def lookupUser( name:String ):Option[UserInfo]
...
}
val jsonUsers:Seq[String] =
Seq( "fred", "mary", "jose" ).flatMap(
name => helper.lookupUser( name )
).map( info => helper.toJson( info ) )
or
val jsonUsers:Seq[String] = for ( name <- Seq( "fred", "mary", "jose" );
info <- helper.lookupUser( name )
) yield helper.toJson( info )
or
val jsResult = helper.lookupUser( "fred" ).map( info => helper.toJson( info )
).getOrElse( jsErrorRespose )
If you feel comfortable with that kind of code, then you have a good start ...
Good luck!
We already had our whole platform written in java. And i was very enthusiastic about scala at work. So i just added my scala code to the existing code base on the same level i.e. src/main/java also i found almost 100% compatibility from scala to java with great ease. Just include the maven scala plugin and it works.
But i would suggest keeping the scala code under src/main/scala for a cleaner code base organisation and also help in resolving minor compiler dependencies. Also having a dual build both in sbt and mvn gives great flexibility for build process.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Among all the various incomplete lists of features going into Scala 2.10, there are various mentions of improvements to Scaladoc. But it's unclear which ones there are, and which ones are actually going in -- e.g. one of the lists of improvements says "fixes to Scaladoc" with links to various pull requests, some of which got rejected.
Can anyone summarize what's actually changed between Scala 2.9 and 2.10 milestone 4, and maybe indicate what else is planned for 2.10 itself?
Also, are they finally going to fix the problem of not being able to link to methods? E.g. littered throughout my code I have things like this:
/**
* Reverse the encoding computed using `encode_ngram`.
*/
def decode_ngram(ngram: String): Iterable[String] = {
DistDocument.decode_ngram_for_counts_field(ngram)
}
where I want to refer to another method in the same class, but AFAIK there's simply no way to do it. IMO it should be something obvious like [[encode_ngram]] -- i.e. I definitely shouldn't need to give an absolute class (which would make everything break as soon as I pull out a class and stick it somewhere else), and I shouldn't need to give the parameter types if the method name itself is unambiguous (i.e. non-polymorphic).
Several new features, as well as many bugfixes are coming, but there's no definitive list of all the fixes that are in, yet. Of the more notable new features:
Implicitly added members will now be visible. A good example is to look at scala.Array, where methods like map which you might've assumed you had are now visible in the Scaladoc.
Automatically-generated SVG inheritance diagrams, for a bird's eye view of relationships between classes/traits/objects at the package-level and then also at the level of individual classes etc. For example, see the Scaladoc diagrams nightly at both the package-level (click "Content Hierarchy") as well as at the class-level.
Method-linking in some limited form should go into 2.10 (not in the nightly yet). (It's actually not totally trivial to implement in its complete form, due to practical stuff like overloading, as you noted.)
Improved use cases A member with a use case isn't doubly generated anymore, and they're now a bit clearer and simpler than before.
(Less-notable) Keyboard shortcuts for navigating Scaladoc have been added, they're explained here and here
For a more exhaustive list of bugfixes, it might be a good idea to write to scala-internals-- there's a good chance someone will compile a list of all major bugfixes in the past year for you there.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am .NET developer and I'd like to broaden my horizons a bit and after checking out modern tendencies decided to try Scala. Can you please advise a good strategy to start on it? Should I learn Java first? What source or handbook should I read? Is there any OS projects to practice Scala and grow on them?
Thanks,
Dominique
You might gain a first impression by visiting Simply Scala where you have an online interpreter available.
An absolute classic is Scala for Java Refugees which was originally written for people coming from Java, but will be quite helpful for you, considering how similar the basics of C#/Java are.
You don't need to learn Java first , but you need to have the Java runtime/development kit installed and working.
Then go to http://www.scala-lang.org/downloads and download the appropriate package for your operating system (I always prefer the nightly builds of Scala, they have more bug-fixes than the latest stable one).
After that, run the Scala REPL which is basically "Simply Scala offline" (Simply Scala uses the Scala REPL behind the covers, too). Even many Java programmers use the Scala REPL to prototype things first.
If you prefer books to learn I can recommend Programming in Scala (2nd edition) by Martin Odersky (if you start from a language design point of view and want the "reference book"). There are others like "Programming Scala" which are more targeted at beginners so to speak, but personally I found "Programming in Scala" excellent and have learned Scala with just that book.
A nice way to start Scala is working with the collection classes. .NET has added something similar lately with LINQ and extension methods, so it will be easy to pick up for you.
A small example to get you started:
//Define a class with some properties
case class Person(name: String, var age: Int, spokenLanguages: String*)
//Create some persons
val joe = Person("Joe", 42, "English","French","Danish")
val doe = Person("Doe", 23, "English","German")
val don = Person("Don", 11, "Italian","French","Polish")
val bob = Person("Bob", 17, "German")
//Access a property
joe.name
//Don had his 12th birthday!
don.age = 12
//Put the persons into a list
val persons = List(joe, doe, don, bob)
//Divide the list into minors and adults
val (minors, adults) = persons.partition(_.age < 18)
//Get the total age of all persons
val personsTotalAge = persons.map(_.age).sum
//Return a list with only those speaking English
val englishSpeakers = persons.filter(_.spokenLanguages.contains("English"))
//Same as the example above.
val englishSpeakers2 =
for{ person <- persons
language <- person.spokenLanguages
if language == "English"
} yield person
I'm not that fluent in C#, but I believe many things might look similar to you.
Some examples of Scala's XML support:
//The shoppingCart for breakfast
val shoppingCart = <list>
<item><name>Tomatoes</name><price>0.30</price><amount>4</amount></item>
<item><name>Eggs</name><price>0.15</price><amount>10</amount></item>
<item><name>Bread</name><price>2.20</price><amount>1</amount></item>
</list>
//How much does it cost?
val total = (shoppingCart \ "item").map(i => (i \ "price").text.toDouble * (i \ "amount").text.toDouble).sum
//This is a Symbol
val sym = 'SomeSymbol
//I'm too lazy to use Strings for XML! (Example for implicits)
implicit def symbol2string(symbol: Symbol) = symbol.name
//Now I can use Symbols too!
val total = (shoppingCart \ 'item).map(i => (i \ 'price).text.toDouble * (i \ 'amount).text.toDouble).sum
You don't need to learn Java first. Are you familiar with functional programming? If you are, you should be able to jump in quite fast. Anyway, here are some thoughts on how you can learn Scala:
Get a good reference book. I recommend Programming In Scala by Odersky, Spoon, and Venners. I find it as one of the most comprehensive Scala books.
As with learning any new language, try writing several small application using Scala. If you're not a functional programmer, you might program it in a different paradigm, but that's okay for now. Try writing your program without using "var, (use val instead)" not using loops, and minimizing state change overall.
Use sbt to build your program. I'm kinda hesitant to recommend this since you have to learn a new tool to write your program. But I find it a great too to write Scala apps with. And many Scala projects use sbt it seems like.
Also check out this comment and that thread overall to help you transition to Scala. Struggle against habits formed by Java when migrating to Scala
Java as a language will not be necessary to start with scala (and anyway java itself is very similar to c#, or actually it's the other way around...).
Once you start doing productive things with scala, though, you will be interacting with a lot of java libraries and learn that java-world is a much broader galaxy of more-or-less standard libraries than .net-world where a lots of the things you need are directly in the standard .NET libraries. You can learn them as you go, but not coming from a java background, the experience might feel overwhelming. It would be the same thing had you started learning java, though....
Other java-specific things you may have to learn are about generics being much less powerful in the JVM and how scala tries to work around this.
As for scala itself as a language, coming from .NET, you may benefit more from reading a few things on functional programming than from learning java. The functional paradigm is the part where I was the most ignorant in my initial approach to scala and that caused me the most trouble in understanding example code from the resources you can find on the scala website.
Building a foundation
For functional programming I would recommend reading SICP (it's online and free).
While you learn java try to take a look at F#. It's a good language, it's well documented and "lives" in the .NET ecosystem
learning scala
Resources on the scala website
Daniel Spiewak's blog
If you want to learn Scala, you'll be much better served by learning Scala and picking up the Java you need as you go. You don't need to learn Java to be able to start using Scala.
A good place to start would be reading through this question, which lists most of the Scala books currently available.
https://stackoverflow.com/questions/3359852/scala-programming-book/3360308#3360308
I don't think you need to know Java to get started on Scala. It's helpful to know the broad strokes though, because most Scala documentation I have read refers back to Java features or bugs.
Regarding Open Source projects, you cna have a look on Github for scala projects. Most open source Scala projects tend to be frameworks, though.
Regarding books, I found both the Artima book, Programming in Scala, and the Pragmatic Programmers, Programming Scala, very good.
In addition to the others: Write simple programs for a while and completely ignore advanced features of Scala. Only move there when you have a good grasp of the basics, the functional paradigm und the type system.
I advise you to take part in Coursera Functional Programming Principles in Scala by Martin Odersky. There are video lectures, assignments and even final exam.
Twitter (one of the scala lovers) recently unveiled their own scala complete tutorial -- Scala School. It is awesome guide which I recommend to all scala beginners.
Scala school was started as a series of lectures at Twitter to prepare
experienced engineers to be productive Scala programmers. ... We
think it makes the most sense to approach teaching Scala not as if
it's an improved Java but as a new language. Experience in Java is not
expected. Focus will be around the interpreter and the
object-functional style as well as the style of programming we do
here. An emphasis will be placed on maintainability, clarity of
expression, and leveraging the type system.
Most of the lessons require no software other than a Scala REPL. The
reader is encouraged to follow along, and go further! Use these
lessons as a starting point to explore the language.
I'm currently developing one which doesn't require prior programming knowledge. It will show the strength of combining functional and imperative programming, and it is very simple to follow. Furthermore, the posts will cover best practice and solve increasingly difficult problems using Scala.
http://vigtig.it/blog/
You should give it a try, part 2 is almost finished :)
Download and install Apache Maven. Use it to create a blank Scala project and write the classic Scala hello world application. This will require you to configure the pom.xml file in the project directory that Maven creates.
Then run mvn compile over and over, correcting errors until it compiles.
Then run mvn package until you pass all the unittests.
And finally, run mvn scala:run
Once you build a real project scala:run has an option to spit out the full Java command needed to run it from a shell script or batch file.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Is there a Scala library that parses Scala and creates an Abstract Syntax Tree (AST)?
Ideally I am interested in a Scala library. Plan B would be a Java library.
(I know I could leverage the EBNF from the Scala Syntax Summary.)
I would think the best way to access the AST is with a compiler plugin. You should read a soft introduction before diving in deep.
A few existing parsers:
The offical Scala compiler.
The IntelliJ IDEA Scala plugin has a parser written in Scala against IntelliJ's PsiBuilder API.
The Scala Netbeans plugin used a parser implemented in Rats! (which generates Java code), but "replaced these parser and analyzer by Scala's native compiler".
The Scala-rules project, written in Scala.
Be cautious if using the EBNF from the spec, there are apparently:
"mismatches between the appendix and the inline grammar, and mismatches between the language compiled by scalac (and utilized in the scala sources) and the language claimed by the grammar" -- Scala Trac bug #1826.
You can't build an AST for Scala from the grammar alone. There's implicits to consider, and, to consider them, there is the type inferencer to consider.
You can, however, call the compiler itself -- it is just a jar file, after all. Scala 2.8, in particular, has quite a few hooks for other programs to latch on -- work of Miles Sabin, who is doing this precisely so that the Eclipse plugin for Scala can leverage the compiler in such way.
I suggest you go to the Scala Tools mailing list, and get in contact with people there.
If you want to generate AST of a piece of code. You could use scala reflection:
showRaw(reify{
//your code here like:
print(2)
})
The code above will generate an AST:
Expr(Apply(Select(Ident(scala.Predef), TermName("print")), List(Literal(Constant(2)))))
Reference:
http://docs.scala-lang.org/overviews/reflection/symbols-trees-types.html
Here is a project by one of the compiler committers http://github.com/paulp/scala-lang-combinators
Not sure about the pure scala solutions, but if you find yourself needing to implement plan B, you can start by checking out ANTLR or Rats!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It is my opinion that every language was created for a specific purpose. What was Scala created for and what problems does it best solve?
One of the things mentioned in talks by Martin Odersky on Scala is it being a language which scales well to tackle various problems. He wasn't talking about scaling in the sense of performance but in the sense that the language itself can seem to be expanded via libraries. So that:
val lock = new ReentrantReadWriteLock
lock withReadLock {
//do stuff
}
Looks like there is some special syntactic sugar for dealing with j.u.c locks. But this is not the case, it's just using the scala language in such a way as it appears to be. The code is more readable, isn't it?
In particular the various parsing rules of the scala language make it very easy to create libraries which look like a domain-specific language (or DSL). Look at scala-test for example:
describe("MyCoolClass") {
it("should do cool stuff") {
val c = new MyCoolClass
c.prop should be ("cool")
}
}
(There are lots more examples of this - I found out this one yesterday). There is much talk about which new features are going in the Java language in JDK7 (project coin). Many of these features are special syntactic sugar to deal with some specific issue. Scala has been designed with some simple rules that mean new keywords for every little annoyance are not needed.
Another goal of Scala was to bridge the gap between functional and object-oriented languages. It contains many constructs inspired (i.e. copied from!) functional languages. I'm thing of the incredibly powerful pattern-matching, the actor-based concurrency framework and (of course) first- and higher-order functions.
Of course, your question said that there was a specific purpose and I've just given 3 separate reasons; you'll probably have to ask Martin Odersky!
One more of the original design goals was of course to create a language which runs on the Java Virtual Machine and is fully interoperable with Java classes. This has (at least) two advantages:
you can take advantage of the ubiquity, stability, features and reputation of the JVM. (think management extensions, JIT compilation, advanced Garbage Collection etc)
you can still use all your favourite Java libraries, both 3rd party and your own. If this wasn't the case, it would be a significant obstacle to using Scala commercially in many cases (mine for example).
Agree with previous answers but recommend the Introduction to An Overview of the Scala Programming Language:
The work on Scala stems from a research effort to develop better language support for component software. There are two hypotheses that we would like to validate with the Scala experiment. First, we postulate that a programming language for component software needs to be scalable in the sense that the same concepts can describe small as well as large parts. Therefore, we concentrate on mechanisms for abstraction, composition, and decomposition rather than adding a large set of primitives which might be useful for components at some level of scale, but not at other levels. Second, we postulate that scalable support for components can be provided by a programming language which unifes and generalizes object-oriented and functional programming. For statically typed languages, of which Scala is an instance, these two paradigms were up to now largely separate. (Odersky)
I'd personally classify Scala alongside Python in terms of which problems it solves and how. The conspicuous difference and occasional complaint is Type complexity. I agree Scala's abstractions are complicated and at times seemingly convoluted but for a few points:
They're also mostly optional.
Scala's compiler is like free testing and documentation as cyclomatic complexity and lines of code escalate.
When aptly implemented Scala can perform otherwise all but impossible operations behind consistent and coherent APIs. From Scala 2.8 Collections:
For instance, a String (or rather: its backing class RichString) can be seen as a sequence of Chars, yet it is not a generic collection type. Nevertheless, mapping a character to character map over a RichString should again yield a RichString, as in the following interaction with the Scala REPL:
scala> "abc" map (x => (x + 1).toChar)
res1: scala.runtime.RichString = bcd
But what happens if one applies a function from Char to Int to a string? In that case, we cannot produce a string as result, it has to be some sequence of Int elements instead. Indeed one gets:
"abc" map (x => (x + 1))
res2: scala.collection.immutable.Vector[Int] = Vector(98, 99, 100)
So it turns out that map yields different types depending on what the result type of the passed function argument is! (Odersky)
Since it's functional and uses actors (as I understand it, please comment if I've got this wrong) it makes it very easy to scale nearly anything up to any number of CPUs.
That said, I see Scala as kind of a test bed for new language features. Throw in the kitchen sink and see what happens.
My personal opinion is that for any apps involving a team of more than 3 people you are more productive with a language with Very Simple and Restrictive Syntax just because the entire job becomes more how you interact with others as opposed to just coding to make the computer do something.
The more people you add, the more time you are going to spend explaining what ?: means or the difference between | and || as applied to two booleans (In Java, you'll find very few people know).