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 4 years ago.
Improve this question
Statically typed programming languages do type checking at compiling. Is type declaration an important reason that is making them significantly faster?
A statically typed language is one in which the type of every variable is known at compile-time. In some languages like C, C++, Java the programmer must manually specify the type and in other languages like Haskell and Scala has some form of type inference, the capability of the type system to deduce the type of a variable.
Does it make them faster?
1. Figuring out the type at compile-time does reduce a lot of overhead for the run-time.
2. Because the types are figured out earlier on, even functions/ methods in the language are well defined into static addresses. Where as in a dynamically typed language names are based on strings. And for each method access, lookups have to be done. Which are many, causing the language to be slower.
yes static declarations of variables improves execution speed
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
It's known, that when assigning an instance of structure to another instance, or passing it to a function, Swift essentially copies the instances by value. However I could not find anywhere if we actually have control over this process, like in C++ copy constructors. My question is whether Swift has analogue to C++ copy constructors and if not, are there anything in the language what helps to take control over passing-by-value process in Swift?
Copy constructors are implicit in Swift, and can't be user-customized.
They always copy all fields of a struct. For fields that are references to object, copying is defined as the increment of reference count (a retain).
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 5 years ago.
Improve this question
This is more of conceptual question i stumbled upon. Scala states than multiple inheritance is not supported but at same time states than "Nothing" is subclass of all types. Isn't this against the concept that Scala states.
Scala states than multiple inheritance is not supported
That is not true. Scala supports linearized multiple mixin inheritance.
but at same time states than "Nothing" is subclass of all types.
That is not true. The documentation clearly states that Nothing extends Any, and that's it. It is only a subclass of Any, and nothing else.
The documentation also states (bold emphasis mine):
Nothing is a subtype of every other type (including scala.Null)
As you can see, nowhere does the documentation say that Nothing is a subclass of all types. It only says it is a subtype of all types, which is completely different.
Isn't this against the concept that Scala states.
No, it is not.
But even if what you are saying were true, there is still no contradiction: the Scala Language Specification defines what "Scala" is, and if the SLS says that Nothing is a subclass of all classes, then that's how it is. The Scala Language Specification say anything it wants, and this will never be against the concepts of Scala, because the Scala Language Specification defines the concepts of Scala.
Now, as it turns out, your premise was wrong, and the Scala Language Specification does not say that Nothing has multiple superclasses, but it could say that if it wanted, and that would not be against the concepts of Scala, because the Scala Language Specification says what, exactly, the concepts of Scala are.
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 6 years ago.
Improve this question
Well, it says on their website that Swift is a strict language. However, I am not sure in what ways it is considered to be strict. Can you please elaborate on that?
Statements about the nature of Swift are often expressed in terms meaningful to people accustomed to the previous language, Objective-C. So in this case, the statement that Swift is "strict" typically refers to how things like variables are typed. But unless you have used another language like Objective-C or Ruby that is not strict about typing, you probably won't appreciate the difference.
For example, in Objective-C, programmers often use "dynamic typing", where a variable is typed as id and you can assign to it a value of any type, even different types at different times — now an NSString, now an NSNumber, now a UIView. But in Swift you can't do that; once we've established that this variable is a String, its value can only ever be a String.
Similarly, in Objective-C, NSArray is just "a collection of objects" of any old type. But in Swift, an Array is a collection of just one type of object and you have to say in advance exactly what type it is.
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
I'm studying functional programming using Scala, and came across this nice talk by Runar Bjarnason http://youtu.be/hzf3hTUKk8U?t=17m35s
Are there languages that already deal with this problem:
tail recursion elimination (without using trampoline or other
explicit construct)
I know that Scala can convert self call tail recursion to a loop, thus avoiding creation of stacks, but there are recursion that scala compiler does not accept #annotation.tailrec as presented on the clip at 3min - 7m.
The language sought after here is functional, has compile time type system, and has lazy evaluation.
When the above is answered, I check the question answered. But it would be nice to know if also the other language features presented by Bjarnason are managed already by some language:
- kind reference
- better type inference
- unboxed function references
The Scheme language (part of the lisp family) is guaranteed by the language specification to perform tail call optimization. However it doesn't have any of the nice language features you mention.
For a modern functional language with a powerful optimizing compiler (performs TCO and much more) with all the powerful language features you're asking for, I highly recommend Haskell
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 9 years ago.
Improve this question
I understand these two methods are identical (one is defined in terms of the other) according to this previous question:
Scala Buffer: Size or Length?
But is there a reigning best practice or recommended convention? I can think of three options:
(1) Always use size
(2) Always use length
(3) Use size for all collections exception Array
I'm leaning towards (1) or (3). The rationale behind (3) is that these methods are inherited from Java. And in Java you'd be invoking collection.size() and array.length. The argument for (1) is that it builds on and simplifies (3). The argument for (2) I'm not really sure about.
They are the same. It makes no difference. Use whatever you want.